jaaron

This is much more the real story but I doubt most folks will ever hear it.

Totally agree. Mesos project always had a trouble with governance and didn't build out the larger community the way other projects did. If they had built that coalition, made the project more accessible to others, who knows, maybe it would have gone differently.

Then again, k8s succeeded in part due to the Google reputation (even if undeserved) and it's use of GoLang. I always found Mesos' use of C++ meant many of the users (often developing in Java, Go, or Node) just wouldn't contribute.

I preferred Mesos to k8s. I think it's core architecture (a 2-level scheduler) is a better foundation. For the longest time, I felt k8s was effectively an overgrown hobby project that had no place being deployed the way it was. That had me realize something in the shower this morning:

k8s is the Rails of the cloud.

Back when Rails came out, it too was a bit of a hobby project. When coming from more established enterprise web frameworks, Rails felt like a toy. It didn't have the features, robustness, safety, and scalability of "proper" frameworks.

What did Rails do? It was easy to get started and it hid a lot of the boring and painful work of web frameworks at the time.

Through the sheer force of will of a massive community, Rails grew up and became something more the toy it started as. I was pretty arrogant in my opinions about the Rails community at first, but then I ended up working on several Rails projects over the years.

It still hides a lot under the hood, there are still arguably better technical frameworks out there and plenty of folks use it improperly, when they don't need to, and without really understanding the fundamentals, meaning that they tend to get in trouble when pushing the limits or moving outside the golden path of development.

And I feel the same way about k8s. I think it started out without anywhere near the features of similar frameworks. It didn't scale well, was simplistic in it's model, and overly complicated in it's implementation. But it was much more approachable than something like Mesos and answered the question of "why am I containerizing everything?", giving everything a purpose to those who started down the path of Docker. And now it has a huge following and industry behind it.

At this point, I've learned that what becomes popular isn't necessarily the "right" or "correct" architecture. There's a lot more to programming trends (and fads) than that. The whole industry seems to want to reinvent the wheel every decade, almost like some sort of planned obsolescence to justify our work. Nevertheless, it's rarely wise to fight against the tide and when you have the enough of the industry moving in a direction, we can make even toys into real tools.

I look to my art manager colleagues (I work in video games) with some envy, because their interview process is easier due to art candidates having portfolios.

We just don't have that in the software industry, at least not portfolios that we can legally share or that other employers would trust, so we end up essentially torturing each other with coding tests.

I don't think everyone having a portfolio of open source code is a reasonable ask, but the idea of portfolios, if we could create them, would bring some sanity to our industry's interview practices.

I'm not sure "switched" is the right word. Minecraft is still massively popular.

Anecdotally, the elementary school crowd my son plays games with play both with regularity.

I agree with everything in xyzelement's comment.

As a hiring manager, it's only one source, but it's an important one. Examples of how I use it:

- Posting job openings and company updates to my personal LinkedIn status.

- Using the recruiting tools (these cost extra) to search for candidates with specific skills.

- Looking through the staff of a specific company in search of potential candidates for a specific role.

- For most candidates I'm only 2, sometimes 3, hops away on LinkedIn. I look to see who we know in common.

- Sometimes it's the only resume-like document I have for a candidate, so I refer to it during an interview and I often share the candidate's LinkedIn profile with other interviewers when providing them context/background about the candidate

- Less often, to directly message former coworkers if I don't have some other better way to reach them.

- Also less often, there are some active LinkedIn interest groups, but in my experience, the quality of discussion isn't as good as other forums.

I'm in LinkedIn almost every day, one way or another. So are most tech recruiters I work with. For anyone who is not actively part of the recruiting effort, I have no idea why you'd be on it that regularly.

For what it's worth, we also use a lot of other recruiting tools, but I would say that it's odd to find an engineer who doesn't have a LinkedIn profile and I do recommend them for anyone who is actively job hunting (at least within tech). It's great for when you're on the market, passively or actively.

An active GitHub account is also good, but it's not a place recruiters or hiring managers start their search.

An active personal website is even more valuable than an active GitHub account, but also not likely the way a recruiter or hiring manager finds you.

Oh, one other thought: for lots of startups and companies, applications aren't where we find all our best talent. That's not to say you shouldn't apply, it's just that the signal to noise ratio for applications is low. As a hiring manager, you can't just wait around for the best people apply for your team. You have to actively recruit. If you want to be recruited for those sort of jobs, LinkedIn is a pretty important way to show up on their radar.

I don't like LinkedIn as a social network but as a hiring manager, there's nothing else close to it. Sometimes we wish there were, but it definitely fills a niche.

It's true, Elastic can relicense as they see fit.

I should perhaps do a bit better clarifying between:

a) The code

b) The community

The issue is more that the open source work had been happening under the support and auspices of Elastic with a certain license. Elastic is relicensing and the rest of the community is within rights to not want to support Elastic's now non-open source fork.

Amazon's poor behavior doesn't excuse Elastic's poor behavior.

Amazon's violation of Elastic's trademark is an issue between two companies: Amazon & Elastic. Elastic has the courts available to them to pursue their case.

Elastric's change of license affects the larger open source and technical communities and it's understandable that contributors who supported the open source project are upset when Elastic changes the nature of the relationship.

I'm surprised to see the reaction here on HN, but I'm starting to realize I'm from an older generation of open source contributors and don't share the values of some here.

The point of open source wasn't to enable viable business models for companies like Elastic. The ASL is commercial-friendly, but the design of the license wasn't to enable any specific business model. It was to ensure the widest range of freedoms.

A lot is made of the way Amazon is "taking advantage" of the license, but they aren't. They're doing exactly what is allowed, what anyone is allowed.

IMHO, if you're releasing your work under an ASL-like license, then you're making a specific promise to the community about the freedoms related to your code. You're making a promise to all the adopters and contributors. The license is a promise (literally a contract) about what to expect from each other so that we can all contribute on the project together.

When an actor unilaterally changes that agreement, it's understandable some may be upset.

And while I know it's trendy of HN to discount non-profits like Apache as out of touch or old-school, they serve an important function in the open source ecosystem. As a non-profit, Apache doesn't really care too much what Amazon or any big or small tech company does with the code, as long as the original code remains open source and there is a community that can continue to work on it. The continuation of the community is paramount, above and beyond any one company's business model. We want software, particularly internet middleware, to be stable and last for generations.

When we take a long term view for the health of the interview, Elastic's move is great for Elastic, but not for the internet as a whole. Consider where we'll be if/when Elastic collapses. Right now, Elastic has plenty of fans, but we have no guarantee that they will remain competent, competitive, and innovative over time. If their hosted service suffers, their new license ensures that no one else can compete.

The advantage of broadly supported open source projects is that they can out last any one company (e.g. Sun) or any one person, so that we can build a technical commons for the future.

Mailing lists is the answer.

- Achievable

- Searchable

- Linkable

- Asynchronous

- Accessible

I like using Slack and we use it heavily with my team, but I agree it has issues.

Meanwhile, we've been using mailing lists for established open source projects for years for all of these reasons.

You're misunderstanding what the parent poster was saying: when working on a large AAA game, content management (art, game design, etc.) is as much a bottleneck as engineering efforts. And a number of those bugs you're concerned about are rooted in content too, not lower level engine bugs.

I've worked about half of my career in the game industry. I've practiced TDD and written automated tests (and frameworks) for desktop, web and mobile apps. Some of those have been in the medical industry where the testing is crucial. I say this to make it clear that I'm familiar with solid software engineering practices.

With that in mind, games are the hardest software I've encountered for writing automated tests. It's just notoriously difficult to do in an effective manner. It's not impossible, but it's incredibly difficult.

I definitely prefer WSL.

I've found this article to be one of the better on setup of that environment:

https://elecming.medium.com/the-ultimate-emacs-hacking-tutor...

I've been debating on getting my team of engineers a book as a gift, with Code Complete or Pragmatic Programmer as high on the list. Trouble is, as others noted, they're best when you're starting out and less helpful later in your career.

Does anyone have any books they recommend for senior engineers (approx 10 years experience)?

Perhaps it's harder to recommend one book because by that time generalized knowledge should already have been absorbed.

As with everyone else, the answer is CI/CD. Having run a team that built out its own Mac build farm... it's a pain.

First:

If the code is for you, and for you exclusively, go ahead.

If you're writing code as part of a team for a customer, then it isn't for you and it's whole purpose is to solve the problem at hand.

Secondly:

The primary issue I have with a NIH code-it-yourself approach is that it doesn't scale over time. Professionally, over two decades, I have seen several teams go through a technical evaluation and decide, in the end, that no open or closed source solution exactly fit their needs. So they coded it themselves.

Fast forward three to five years and everyone regretted the NIH approach. Those open or closed source solutions had matured and easily surpassed the home grown feature set, which still required a team of engineers to invest in.

There are exceptions, of course. Sometimes you have to build it yourself. But more often than not, it's much, much more effective to let go of your ego and collaborate with others, particularly on open source solutions in which you always have the option to fork the codebase and bring it, effectively, in house.

Generally, I find those that strongly advocate for NIH overly discount the long term costs of maintaining software.

The ASF board's job isn't to enforce "standards." It's intentionally an open community-driven group, which means there's going to be a wide range of projects.

See my response to yc-kraln:

https://news.ycombinator.com/item?id=25215345

Disclaimer: Apache member and former board member here.

A couple of points:

The goal of the Apache Software Foundation is to provide a proven, reliable governance model to open source projects which choose to join. Governance models aren't (generally) exciting, but they're really important for _mature_ projects that grow beyond the original developer or team. The ASF provides things like:

- A contribution model that allows for clarity around copyright ownership

- A nonprofit that makes it easy for individuals and companies to interface with

- Clear rules around project ownership and decision making that are oriented for _community_ ownership as opposed to ownership/sponsorship by a specific company or individual.

That last point is what particularly distinguishes the ASF from organizations like the Linux Foundation which is more suitable for direct corporate involvement.

As a truly community driven organization, the ASF doesn't have an agenda or policy to pick and choose which projects join. We don't go hunting for popular projects, we don't have a portfolio we need to fill out. Any community of developers is invited to join as long as they agree with our principles. So that means we get everything from an open source project being "donated" out of some company to a scrappy group of developers trying to grow their project.

As for Java, that's a historical point in that many critical open source Java projects in the early 2000's found their home in Apache. And while the ASF tends to have projects that fit the "internet middleware" shape, we have communities that range from desktop software to core libraries in diverse range of languages.

My measured speed at home is typically over 600 Mbs. Most (not all) of the house and devices are networked over ethernet. I'm super happy that we have all the bandswidth because on most days:

- We have 2 adults working full time from home. We're in the entertainment/technology industry. We're streaming video calls and transferring massive files/repos _constantly_. One uses a remote desktop solution to get to their media workstation in the office regularly, requiring a low latency connection.

- We have 2 children going to school from home (schools haven't reopened here), spending the day on either Zoom or on Netflix/video games.

And then there's all the smartphones and other smart devices around the house regularly eating up bandwidth.

I don't always need all that bandwidth, but when I do, it's crucially important.

Someone "swatted" the whole office.

Reiterating what KMag wrote below:

For some, publicly declaring your commitment to one another can have a powerful affect on the relationship. It can communicate a shared vision and commitment for a lifetime. It is not requisite for that commitment, but it leverages cultural support structures that can help keep a relationship healthy.

For me personally, I believe marriage provides a couple with an important concept that they are part of something greater than themselves. This is not an exclusively religious idea (I consider myself an atheist). When times are difficult (and they will be over the course of a lifetime), this bond can help a relationship survive when otherwise the pressure to give up can be significant.

And if you're going to use WSL, check out:

https://medium.com/@elecming/the-ultimate-emacs-hacking-tuto...

You have to go back almost 20 years to understand the relationship between the ASF and the Java community. Java at the time was positioned to be a core web technology (originally as applets, then as as backend tech via J2EE) and Apache was interested in ensuring the web ecosystem as a whole wasn't locked up in proprietary tech. The ASF was rather influential in working with Sun at the time to foster was eventually became a vibrant open source community.

I know the ASF isn't as trendy these days, but that's never really bothered those of us who volunteer. The focus has always been about a stable, open source ecosystem, primarily, but not exclusively for the internet and its underlying infrastructure. The goal is measured in decades.

It wasn't about being "enterprisey" or anything like that. The ASF as a foundation doesn't really care about the language or tech stack. Being a more mature non-profit, many corporations have found it easier to interface with the ASF than many other open source organizations out there, which does lend itself to seeing a lot of enterprisey donations.

Best headset for sitting is a inside-out, tethered VR headset.

Until recently, the Oculus Rift S would be a great pick for that.

I don't yet have an HP Reverb G2, but I expect good things out of that headset. The HTC Cosmos would also be a good choice.

The Valve Index (yes, I mistyped before) is an awesome headset, but the lighthouse emitter based tracking system isn't great for seated. Not only is it a hassle to setup, but it's easier for your chair or monitor or whatever to block the laser grid from the lighthouse units. And if you're seated, you aren't taking advantage of the highly accurate room-scale tracking the lighthouses provide. I'd stick with the convenience of an inside-out headset if you're primarily doing seated VR.

For example, I tended to prefer my Rift S for sim games (sim racing, sim flight) for all the reasons listed above.

As the others noted, those platforms are all deprecated now. Even when they weren't, they didn't give anywhere near the experience of other headsets.

[I've had the Google cardboard, DayDream and the Samsung Gear headsets.]

Yes. My bad.

I have owned about a dozen VR headsets at this point, including the Quest (not the Quest 2) and the Vive Index. The Index is fantastic, but it's difficult to compare to the Quest which is truly in a category of its own.

For headsets, there are several properties that segment the market:

1. Tracking: outside cameras/emitters vs inside-out tracking

2. Tethered vs wireless (including PC powered, but using wireless transmission)

3. PC powered vs standalone device

For each of these, there are multiple vendors to choose from, except for standalone devices. In this case, the Oculus Quest is unique. There's no other competition.

Moreover, the Quest is the only device that can be run without a corresponding high end PC. If you don't have a PC like that, then the cost is prohibitive. There's also the space factor. VR needs space, which is already an issue. With the PC powered headsets, you also need that PC to be close enough to your open VR space. Otherwise, you need to rearrange your living space or invest in a VR dedicated PC.

In summary, the Vive Index is fantastic and arguably the best headset in the market right now, but the Oculus Quest fills a different niche of that market.

(And as to the topic of the article: I'm done with Oculus based on Facebook's policies).

I lived like this for a while, both in Hong Kong and in Los Angeles, with two kids. There's a sense to it.

But what's not discussed in this article is the friction of this sort of lifestyle. The time when you couldn't get the rideshare when you needed it. The time lost using less efficient public transport. The hassle you go through every time you need to do... anything.

And as the children get older? Well, the lifestyle gets old too.

Don't pay for what you don't need and won't use. I agree. Just keep in mind you're paying for more than just the few minutes you're actually in a car.

One of my favorite games, Elite Dangerous, has a fairly to-scale representation of the milky way in it: 400 billion stars.

One of my favorite things is to wander around the galaxy in the galaxy-map mode in VR in that game.

I like the differentiation that engineering is programming integrated over time. [1]

To be a programmer you need the direct hard skills of coding literacy, analytical and logical thinking, combined with enough grit and creativity to see a problem through to completion. If you have that, you'll be a decent programmer, but you may not be a good engineer.

Engineering requires the maturity of thought to consider your actions and your solution over time. It requires more wholistic thinking and not just from the tech architecture point of view. Human soft skills tend to be more important over these time scales: communication, empathy, humility, courage. It's these skills that sustain success.

[1] https://www.oreilly.com/library/view/software-engineering-at...

I think we're seeing more awareness that the situation due to a number of factors: climate change, yes, but overzealous fire suppression and public policy too.

Yet when the topic turns to historical California, I'm surprised there isn't more acknowledgement of just how much of the California ecosystem has changed in the last couple hundred years, making comparisons not quite as apt. Invasive grasses, as just one example, have completely changed the landscape.