I don't really buy that this is the main reason. A good senior engineer is for the most part able to not write bad code from day one, just at a very low speed and with the need to ask other people frequenyly. Even if you do not know the code base or domain yet there are a lot of things you can do to avoid writing bad code. Yes, as someone new you will make mistakes and misunderstand things but a lot of the bad code I have personally seen has not been caused by that. Most bad code I have seen has been caused by people rushing and not having their fundamentals in order. Like not actually doing reviews, not spending a few extra hours to think about architecture, etc. Also a big issue is that people just let the complexity of systems explode for the gain of short term projects.
I think the issue is more that engineers face unreasonable pressure to deliver short term value and that there is no respect for the craft/engineering from many managers or even engineers.
> Big companies know that treating engineers as fungible and moving them around destroys their ability to develop long-term expertise in a single codebase. That’s a deliberate tradeoff. They’re giving up some amount of expertise and software quality in order to gain the ability to rapidly deploy skilled engineers onto whatever the problem-of-the-month is.
And also to "keep the balance of power tilted away from engineers and towards tech company leadership." The author touched on that and forgot about it. You don't want key projects depending on a group of engineers that might get hit by a bus or unionize or demonstrate against Israel or something. Network effects and moats and the occasional lobbying/collusion mean the quality of your product is less important.
Maybe I have it wrong but the very essence of "engineering" is managing the constraints of (1) providing an acceptable solution to a problem (2) within some fixed parameters of time and cost.
The code may look "bad" in a vacuum but if it yielded a successful outcome then the engineer was able to achieve his/her goal for the business.
The stories shared in this article are exactly what you'd expect from big tech. These are some of the most successful firms in the history of capitalism. As an engineer you are just grist in the mill. If you want to reliably produce "good" code then IMO become an artist. And no ... working at a research facility or non-profit wont save you.
The short tenure is a symptom of a larger problem. The deeper problem is that very little is expected of big company software employees. Conversely those same employees tend to expect a lot in return. You can call that entitlement, poor expectation management, first world problems, and all kinds of other names.
I have not worked for a FAANG, so maybe things are different there, but I don't suspect so. People are people no matter where you put them.
Increasing compensation is not the solution. It can be a factor in a larger solution, but just increasing compensation increases employee entitlement which makes this problem worse, not better.
The best solution I have seen is risk/reward. Put people in charge of their assigned effort with real adult danger of liabilities. Likewise, award them for their successes. This is called ownership, and it works because it modifies people's behavior. The rewards and liabilities do not have to be tied to compensation. Actually, associating these rewards/liabilities to social credibility within the team/organization appears more effective because it reinforces the targeted behaviors.
I have seen this missing in all of my software career until my current employment. Conversely people in the military are pushed into this liability/reward scenario from the very beginning and its very effective. It has always been striking to see the difference in my dual career progression.
I worked for a company writing Elixir code several years ago. Prior to my arrival, the ignorant architect had deployed Elixir in a way that broke the BEAM (which he viewed as "old and deprecated"). Furthermore, one of the "staff" engineers—instead of using private functions as they're intended—created a pattern of SomePublicModule and SomePublicModule.Private, where he placed all the "private" functions in the SomePublicModule.Private module as public functions so that he could "test them."
I tried almost in vain to fix these two ridiculous decisions, but the company refused to let code fixes through the review process if they touched "well-established, stable code that has been thoroughly tested." After being there for a couple of years, the only thing I was able to fight through and fix was the BEAM issue, which ultimately cost me my job.
My point in all this is that, at least sometimes, it isn't good engineers writing silly code, but rather a combination of incompetent/ignorant engineers making stupid decisions, and company policies that prevent these terrible decisions from ever being fixed, so good engineers have no choice but to write bad code to compensate for the other bad code that was already cemented in place.
The actual coding work in most non-tech big companies, is considered a low-level or dirty work and is delegated to the contractors or junior developers, who just can't bother anyone to get the information. As a result, bad code happens.
Also, the process, security, approvals and compliance could dominate so much that less than 20 lines of code changes per week could become the norm and acceptable.
I think it's more that optimizing your hiring process for leetcode savants selects developers who prioritize algorithmic practice over everything else. They also deprioritize character over raw technical skill. But it turns out you need well rounded developers who are able to work with others, communicate well, and have taste. If your hiring process deprioritizes that, don't be surprised when the software produced is shite.
The other reason is the volume of the code being produced combined with the constant product changes. An innocent change like mixing two close but still different concepts can easily poison the whole codebase and take years to undo and may even be nearly impossible to fix if it propagates to external systems outside of direct control
I think, sadly, that's often "the job". My career has been good so far, all things considered, but I think it would probably be better if embracing that idea came more naturally to me.
One of my first strange and unpleasant realizations in transitioning from studying computer science to "working in the real world" came in a 1:1 meeting with my manager at my first job out of school. I was complaining about code quality both in the context of some of our existing codebases and some new code one of my peers (also a junior developer) had recently written. When the light bulb finally lit up in my naive little head, the question I asked my manager with a sense of horror and outrage was "... so you're saying they wrote bad code on purpose?". The painful thought was that I, too, would (or had already) found myself tasked with pushing code that I knew sucked, for reasons entirely unrelated to architecture or design or other purely "technical" constraints.
I used to fantasize about moving into a different software niche, maybe in safety critical systems, where correctness is more highly valued. But recently I'm coming to realize that the thing I crave (and miss from my school days) is the joy of the craft— something involving elegance and taste in a way that even the strictest standards of correctness doesn't necessitate.
I think for the most part, truly excellent code isn't something many businesses perceive themselves as needing (even if many practical benefits can flow from its virtues). And, probably, for many businesses, such indifference is right. So excellent code, where it exists, is probably more often "gotten away with", half-snuck in by stubborn engineers who are productive enough to burn time injecting some extra consideration and effort into their code, than it is commissioned by a business which understands that it wants good code.
what I see alot is that the syntax and overall code architecture is text book, but its the completely wrong approach that creates extremely complicated tech debt. All the code reviews will be on the syntax, and none on the big picture of the business problem, or whether the implementation is overcomplicated.
in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremely risky and complicated. The individuals that built the software will lord over everyone else with their arcane knowledge of this big pile of junk
The claim this article makes about very short tenures at big tech is misleading. Because of headcount growth, the median tenure is naturally going to be short. Google grew headcount by 60% the year before 2013, so no wonder the median tenure was 1.1 years. A better statistic to use would be median tenure conditional on that the employee has already left.
Maybe it's things like 4-year tenure, or shorter tenure, or something else.
But I think it's a matter of motivation, Bob.
> The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.
It is only briefly touched on in the article but most of the “best” engineers spend almost no time coding or engineering. I’ve worked at multiple Fortune 500 companies and many weeks I would be lucky to spend 4-8 hours coding. Often I would just work on things that interest me after hours or on the weekend since it would be unlikely to be bothered. Unless some other unfortunate soul happens to see you are online.
69 comments
[ 2.6 ms ] story [ 59.8 ms ] threadI think the issue is more that engineers face unreasonable pressure to deliver short term value and that there is no respect for the craft/engineering from many managers or even engineers.
I think this is crucial. Even old hands working on their area of expertise can be compromised by deadlines.
And also to "keep the balance of power tilted away from engineers and towards tech company leadership." The author touched on that and forgot about it. You don't want key projects depending on a group of engineers that might get hit by a bus or unionize or demonstrate against Israel or something. Network effects and moats and the occasional lobbying/collusion mean the quality of your product is less important.
https://suno.com/song/d6d77518-16ca-455f-ade1-0e8d08fc4b0b
The code may look "bad" in a vacuum but if it yielded a successful outcome then the engineer was able to achieve his/her goal for the business.
The stories shared in this article are exactly what you'd expect from big tech. These are some of the most successful firms in the history of capitalism. As an engineer you are just grist in the mill. If you want to reliably produce "good" code then IMO become an artist. And no ... working at a research facility or non-profit wont save you.
A big company is like a collection of small companies. Code quality varies depending on where you are in it.
Similarly, nothing leads me to believe small companies are any better. Some are excellent. Some are nightmare spaghetti.
I have not worked for a FAANG, so maybe things are different there, but I don't suspect so. People are people no matter where you put them.
Increasing compensation is not the solution. It can be a factor in a larger solution, but just increasing compensation increases employee entitlement which makes this problem worse, not better.
The best solution I have seen is risk/reward. Put people in charge of their assigned effort with real adult danger of liabilities. Likewise, award them for their successes. This is called ownership, and it works because it modifies people's behavior. The rewards and liabilities do not have to be tied to compensation. Actually, associating these rewards/liabilities to social credibility within the team/organization appears more effective because it reinforces the targeted behaviors.
I have seen this missing in all of my software career until my current employment. Conversely people in the military are pushed into this liability/reward scenario from the very beginning and its very effective. It has always been striking to see the difference in my dual career progression.
I tried almost in vain to fix these two ridiculous decisions, but the company refused to let code fixes through the review process if they touched "well-established, stable code that has been thoroughly tested." After being there for a couple of years, the only thing I was able to fight through and fix was the BEAM issue, which ultimately cost me my job.
My point in all this is that, at least sometimes, it isn't good engineers writing silly code, but rather a combination of incompetent/ignorant engineers making stupid decisions, and company policies that prevent these terrible decisions from ever being fixed, so good engineers have no choice but to write bad code to compensate for the other bad code that was already cemented in place.
Also, the process, security, approvals and compliance could dominate so much that less than 20 lines of code changes per week could become the norm and acceptable.
In my experience, while this line is often repeated, in practice it’s rarely really a “deliberate” tradeoff. Rather it’s mostly accidental.
One of my first strange and unpleasant realizations in transitioning from studying computer science to "working in the real world" came in a 1:1 meeting with my manager at my first job out of school. I was complaining about code quality both in the context of some of our existing codebases and some new code one of my peers (also a junior developer) had recently written. When the light bulb finally lit up in my naive little head, the question I asked my manager with a sense of horror and outrage was "... so you're saying they wrote bad code on purpose?". The painful thought was that I, too, would (or had already) found myself tasked with pushing code that I knew sucked, for reasons entirely unrelated to architecture or design or other purely "technical" constraints.
I used to fantasize about moving into a different software niche, maybe in safety critical systems, where correctness is more highly valued. But recently I'm coming to realize that the thing I crave (and miss from my school days) is the joy of the craft— something involving elegance and taste in a way that even the strictest standards of correctness doesn't necessitate.
I think for the most part, truly excellent code isn't something many businesses perceive themselves as needing (even if many practical benefits can flow from its virtues). And, probably, for many businesses, such indifference is right. So excellent code, where it exists, is probably more often "gotten away with", half-snuck in by stubborn engineers who are productive enough to burn time injecting some extra consideration and effort into their code, than it is commissioned by a business which understands that it wants good code.
in the short run (1-2 years) there is no repercussion for this, but eventually making changes will be extremely risky and complicated. The individuals that built the software will lord over everyone else with their arcane knowledge of this big pile of junk
But I think it's a matter of motivation, Bob.
> The thing is, Bob, it's not that I'm lazy, it's that I just don't care. It's a problem of motivation, all right? Now if I work my ass off and Initech ships a few extra units, I don't see another dime, so where's the motivation? ... my only real motivation is not to be hassled. That, and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.