Developer won’t get hit by a bus, they’ll get hired by Netflix

I agree with the author&#x27;s point about using popular tech stacks to alleviate the ramp-up time for new hire productivity, but that is not the optimal solution. The optimal solution is for management to not let high-productivity talent from leaving - increase their comp to whatever offers they might get in the open market. That&#x27;s how labor economic works - it&#x27;s a market.<p>Investment bank and management consulting figured this out a long time ago. Example - when you new grad starts in i-banking, they&#x27;re in training for 4-6 weeks. Not doing anything productive, just training to do the job. Not the case in engineering, you are assigned user stories day one and your training is doing the work. So new i-banks are highly paid (so they don&#x27;t leave because talent is perceived to be scarce and valuable) and they&#x27;re companies invest in them (through training early on).<p>Right now, corporate managers are vomiting in their mouth when the have to look at how much they need to pay to keep their engineers from leaving. It&#x27;s because of the perception of engineers - they&#x27;re seen as semi-skilled labor (cost center, not strategic to the business) and are easily replaceable (no, they&#x27;re not). Culturally, they have been conditioned to think this way, so no wonder turn over is so high every where.

The &quot;hit by a bus&quot; thing is used for the most dramatic effect: there&#x27;s nothing you can do, there&#x27;s no grace period where a &quot;poached&quot; developer can give some wisdom to his&#x2F;her successor etc.<p>Managers know that it&#x27;s not the most likely case, but it&#x27;s still possible.

There&#x27;s several reasons a bus is seen as worse than them being poached:<p>* Early startup employees have golden handcuffs regarding switching jobs. Sure, Facebook is offering them $500k but they&#x27;d be on the hook for $200k in taxes if they exercise their options and they leave a bunch more un-vested options on the table.<p>* You can mitigate them leaving by having a better work environment, equity and so on. Not much you can do about a bus.<p>* You can pay them to stay on for another month or to consult after the fact. No amount of money get&#x27;s you an hour long phone call to the afterlife.<p>edit: Also, the article underestimates the effort needed to get a FAANG job. They don&#x27;t just call you up and offer you a job. They offer you the chance to take a grueling set of white board interviews that require months of studying to pass.

FAANG companies can certainly offer more money, but there are lots of things other companies can offer too (besides Ruby on Rails apparently).<p>- ownership of the product and process<p>- less red tape and politics<p>- good work life balance<p>- location other than Silicon Valley<p>- boss who pays attention to engineer needs and wants<p>Money is a huge factor but it isn&#x27;t the only one!

The author makes it sound like Rails is the recommended way to build software that is maintained by a revolving door of junior developers whom you don&#x27;t have to motivate or compensate, because you can just hire another cog-in-the-machine when the old ones inevitably wise up to your game.<p>Not sure if that was the intended message.

Instead of &quot;hit by a bus,&quot; I prefer the term &quot;win the lotto.&quot;<p>Any member of your team could win a life-changing amount of money in the lottery, inherit it, win a gambling bet, etc. Frame it as a good thing rather than a death or a change of hire - somebody might just flat out retire because they don&#x27;t financially need your employment anymore.

I always call it the &quot;lottery problem&quot; instead of the &quot;bus problem&quot; because it&#x27;s more positive. Also for some people, getting hired at a FAANG is like winning the lottery so it jives with OP&#x27;s article.

&gt; <i>you want more than one person in your business to have domain knowledge</i><p>&gt; <i>Everything gets a lot easier if you select the right software and framework</i><p>Huh? Domain knowledge doesn&#x27;t refer to your tech stack or coding practices. It refers to <i>why</i> you&#x27;ve built things the way you&#x27;ve built them -- customer requirements, business requirements, technical requirements.<p>Ruby on Rails may improve <i>onboarding</i> time, but it has <i>zero</i> to do with domain knowledge.

This is such a low-effort blog post:<p>1. It&#x27;s click-baity. From the headline you&#x27;d think it would be a discussion about why engineers hop jobs so frequently, why in particular FAANGs seem to be so attractive, and what we could do to increase retention. Instead, the post just quickly summarises what we&#x27;ve known for ages (turnover is a big problem), very briefly goes off on a completely irrelevant tangent (that it&#x27;s more likely for an engineer to change the company than to be hit by a bus, which is true, but pointless) and then tops it off by the insane suggestion that &quot;just use Rails&quot; is the answer to all of your turnover woes (more on that below).<p>2. There is an interesting discussion here to be had: <i>why</i> exactly do companies suck so badly at retaining talent? My take on it is that we all (companies, developers, etc.) routinely emphasise the wrong things (office perks, showing off tech skills, etc., instead of a good understanding of the product) and burn people out, but as said: this is a much larger discussion. More importantly though I disagree with the received wisdom that &quot;developers are developers&quot; and domain knowledge is worth nothing. Of course, you always should be prepared for the worst (i.e. the proverbial bus), but it should still be the companies&#x27; priority to retain good people as long as possible because once somebody leaves, so much knowledge just goes to waste and has to be reacquired. At my last company, my whole team was fired because they thought that some other team would be just as good for the product, ignoring the fact that we&#x27;d built up the product ourselves and all the knowledge for two years. But to the higher-ups, the view was that developers are exchangeable.<p>3. The author just really comes across as immature and uniformed with their unilateral praise of Rails. I&#x27;ve worked on Rails apps so messy that they were almost impossible to understand. And, by now, Rails is by far not the only framework with strong conventions and a lot of out-of-the-box support for many common things - Spring Boot for example (whatever its faults) arguably supports even many more requirements. But more importantly, for any kind of non-trivial app, the complexity is not just in the technology: it&#x27;s in the (often contradictory) requirements, the different architectural tradeoffs, the little gotchas, the personalities in the team, etc. etc.

&gt; Everything gets a lot easier if you select the right software and framework, primarily if you use Ruby on Rails. Rails itself is a full-stack framework that has a best practice for every piece of a web application. If you are committed to doing things “the Rails way,” you cut the total cost of ownership by A LOT.<p>Rails has an incredibly large community but I think this statement would be equally true for any tool you&#x27;re well versed in

Being on the receiving end of poaching is simply a failure to compete in arenas beyond compensation.<p>Not only must you compensate your talent at the top of the market and then some (including generous equity), but you must give your employees an amazing work environment with excellent work&#x2F;life balance, <i>while</i> providing something for them to work on that motivates them on an ideological level.<p>When any part of this aegis cracks, poaching has the potential to ravage your ranks.<p>I would say that in the case of especially valuable or world-class talent, it&#x27;s the founder&#x27;s responsibility to know as much as they can about that person, and to truly pitch them on a level that fully aligns across all dimensions of that person&#x27;s life. Give them not only excellent comp, but <i>fulfillment and purpose</i> that is congruent or even symbiotic with their personal lives and overall ambitions.<p>Deep down, most people aren&#x27;t pawns that you can simply acquire with a number and expect the highest quality work from.

Realistically speaking, isn&#x27;t getting hired by Netflix et. al. a practical impossibility for 99+ % of software developers?

A good idiom doesn&#x27;t need over-explanation, and I think the &quot;bus factor&quot; is a good idiom; no Rails or Netflix commentary required.

I don&#x27;t care how you put it, but the fact is that people leave. I led an engineering team I was quite proud of, and days came that I had to let top engineers go. Everyone has growth arcs, and they had opportunities to seize their dream jobs working on things they&#x27;d never get to otherwise. I was proud to have felt like a stepping stone on the way to their dreams, even though it screwed the business temporarily. I learned a lot of what this article is trying to say. Calling it a bus sounds like a one in a million disaster to prepare for. Getting hired by Netflix is far more likely but just as impactful.<p>This is written to business leaders, but I feel like if phrased differently would sound familiar and accepted by HN. Namely, don&#x27;t adopt esoteric technologies no one else knows. Document production process. Never let mission critical operations exist solely in your lead engineer&#x27;s head.<p>The fact is that it&#x27;s never a good time for your best people to leave, but that&#x27;s inevitable on a long enough timeline. It&#x27;s the duty of business leaders to be prepared for that so they don&#x27;t have to resort to dirty tactics to convince them to stay.

I&#x27;ve felt companies would want what the post lays out:<p>- A safe software stack<p>- Make code understandable (industry best practices)<p>- Focus on employee ramp up time<p>I was confused when some companies stressed different things, and I didn&#x27;t quite realize until reading this post that it might be coming from a place of fear of losing engineers.<p>What I&#x27;ve seen:<p>1) Committees for coding standards<p>2) Teamwork over code ownership<p>3) Peer code reviews to enforce quality<p>Sounds like these things would help increase code quality and reduce the bus factor. But I think there are some dangers.<p>1) Committees can mean that no individual is responsible for bad decisions<p>2,3) Teamwork is great if people have separate roles. Too many cooks can become a real problem otherwise.<p>I suspect people afraid of responsibility are more likely to embrace committees and teamwork. Dickheads incapable of working with others are more likely to take ownership (or else they&#x27;d be completely unemployable).<p>I also suspect many startups cargo cult practices that work well for giants, but are net negatives that encourage your employees to leave if you&#x27;re small. Lacking ownership but getting paid super well is a better tradeoff than lacking ownership AND lacking amazing pay.

I guess I&#x27;ll be the one to say it. No, I am much more likely to be hit by a bus than hired by any high-caliber tech company. I&#x27;d say stroke or heart attack top the list for me - probably will happen before 40 too.

And here I am, can&#x27;t even get a recruiter from Netflix to reply, after submitting my resume on a job that I was match for 10&#x2F;10 requirements on the description AND got someone to refer me.

&gt; “Staying on the Rails” makes any new developer productive almost immediately ... Sticking to the standards evangelized by the community and adding proper documentation ... makes onboarding a breeze, which creates more productive developers, which makes hiring more accessible, which reduces your “bus factor.”<p>You could make the reverse argument. Using &quot;industry standard&quot; tools makes your top performers much more likely to get poached. Using unusual (but enjoyable) technologies might increase employee loyalty.

I use the phrase &quot;win the lottery&quot; rather than &quot;hit by a bus&quot;. Has the same impact but it&#x27;s less negative (though probably less likely :-))

Sometimes it does happen. I once interviewed with a company that was hiring because one of their engineers had died in a motorcycle accident.<p>Personally, I think trying to reframe it as happy and positive and coming with a grace period is a little frivolous. Your team should be prepared to transition someone&#x27;s responsibilities in the context of a sudden, wrenching, and traumatic change.

When working on a project, I would title my documentation something like &quot;Bus Document,&quot; aiming for a soup-to-nuts file describing how the project came to be all the way out with appendices describing each file format, etc. I spent a lot of time talking about the Bus Factor, to little avail. A pity.

Nitpicking, but FWIW that&#x27;s not the definition of a bus factor I&#x27;ve learned. It&#x27;s a number of people to be hit by a bus for the project to die. Bus factor of one is a SPOF, so you need to increase your factor, not decrease it.

That might be an unusual situation but actually happened to me. I used to be in a team of two, going to work after one weekend - he&#x27;s dead.

This reads basically as an ad for &quot;use rails its better than the rest, cause it&#x27;s what we use, and you need us! So hire us!&quot;

Are $500k+ yearly salaries in SV really that usual?

Pretty sure the author will also get &quot;poached&quot; if a FAANG offers them 200k more than what they currently make.

is this a RoR ad? It doesn&#x27;t really provide any new insights. If your devs are hired by nflx or hit by a bus the outcome is the same. It&#x27;s just a saying

&quot;Hit by a bus&quot; means hired away. That&#x27;s the meaning of the phrase.

In Soviet Russia, if developer go to Netflix, developer get hit with bus.

&gt; never underestimate the amount of money the FAANGs have to poach your talent.<p>I really wish we&#x27;d stop using the word &quot;poach&quot;. It&#x27;s a loaded word with negative connotations, but what it really means here is &quot;offer someone a better situation than you offered them&quot;. Employees have agency, they aren&#x27;t wild elephants who need your &quot;protection&quot; from &quot;predators&quot; who just want to pay them more.

And frogs don&#x27;t really sit in boiling water.<p>These are called figures of speech for a reason, being literal about them is not admirable nor worthwhile.

Why is Netflix seen as such a tech giant? They serve videos. CBS, HBO, Vimeo, Youtube, Amazon do it too. Nothing special.