> They are almost certainly working to a deadline, or to a series of overlapping deadlines for different projects. I think this is crucial. Even old hands working on their area of expertise can be compromised by deadlines.
How good engineers write bad code at big companies
11–20 of 333 posts
Re: How good engineers write bad code at big companies
#12Maybe 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. Thes…
Substitute "buggy" for "bad". The links in the first sentence of the article refer to bugs, which affect end users of the products.
> If you want to reliably produce "good" code then IMO become an artist.
This is not about aesthetics but rather about QA.
Re: How good engineers write bad code at big companies
#13I 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…
Re: How good engineers write bad code at big companies
#14I 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.
Re: How good engineers write bad code at big companies
#15It’s always a trade off between raising the bar and making a deadline. The deadline always wins since the boss doesn’t know how to read code
Re: How good engineers write bad code at big companies
#16I 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…
Re: How good engineers write bad code at big companies
#17It’s always a trade off between raising the bar and making a deadline. The deadline always wins since the boss doesn’t know how to read code
Sadly a lot of engineers have been indoctrinated into this mindset and I have had to fight quite many battles to conceive my fellow engineers that missing a deadline is not the worst thing in the world.
Re: How good engineers write bad code at big companies
#18I 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.
Re: How good engineers write bad code at big companies
#19I 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…
The worst code I've ever written is because of shifting or unforeseen requirements. It doesn't matter how good the architect is if the foundation is built on sand.
Re: How good engineers write bad code at big companies
#20Also, 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.