Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

11–20 of 333 posts

Re: How good engineers write bad code at big companies

#11
post #4

> 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.

Yeah, I in my experience this is the root of most bad code. People rushing. And it is not even necessarily faster to rush, since often working slow and methodical wins the race. I don't get why we as managers and engineers have just accepted rushing and taking shortcuts as the default. Especially at the big tech companies this constant rush makes zero sense, they have tons of engineers they use very inefficiently.

Re: How good engineers write bad code at big companies

#12

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. Thes…

> The code may look "bad" in a vacuum

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

#13
post #3

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…

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

#14
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.

Re: How good engineers write bad code at big companies

#15

It’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

#16
post #3

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…

I think it's probably a bit of both. A good senior engineer may pick up a task and look at the system, seeing hacks duct taped together with kite string, and have the choice between "doing it right" (aka rewrite/refactor) and getting shit done.

Re: How good engineers write bad code at big companies

#17
post #15

It’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.

Then you've been fortunate to work at places that respect engineering.

Re: How good engineers write bad code at big companies

#18
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.

Re: How good engineers write bad code at big companies

#19
post #3

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…

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.

100% agreed. But to me that sounds like a typical case of rushing instead of working like responsible engineers. If the foundation is built on sand then that needs to be fixed. Engineers being expected to magically paper over a lack of clear requirements is what leads to bad code. I am fine with helping gather the requirements but if I get a list of unclear and shifting requirements and just is expected to fix it I obviously will fail.

Re: How good engineers write bad code at big companies

#20
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.

Post reply on HN