Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

Post reply on HN
Print view View original

171–180 of 333 posts

Re: How good engineers write bad code at big companies

#171

Post by sophia01 »

The matter of fact is that big companies (think the usual monorepo business going on in FAANG) don't care about the actual code. The code was never the point of the exercise. Eventually you realize this. Code is like the ether. The company needs it in order to do its thing, and the code needs to be dealt with in order to operate.

In the end it doesn't matter how normalized and pretty you design the database, someone will eventually show up and write a pipeline that dumps every row of it into JSON once an hour and ships it to some far away corner of the company. Someone will write a shitty script to deal with the fact that those rows don't represent a consistent point-in-time snapshot of your database. In the end it doesn't matter anyway, it'll all be rewritten or coerced through some migration into some ugly system in a few months anyway that it doesn't conform to and could never match.

The thing that matters is the process. When you decide you want to do it, do you have the process to mend the ether to do what you need it to do in two months? Do you have the processes in place to catch it when it's so catastrophic it's blowing up your balance sheet?

Re: How good engineers write bad code at big companies

#173

Post by ford »

Herring wrote: post #5

> 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 engine…

Has it been many people's experience that big companies intentionally remove experienced engineers from your team to something unrelated, in the name of fungibility? I've surely seen efforts within a team to make sure that there's not a single person who's necessary for the team to reach full productivity, and I think most would agree this model does not make for resilient teams. But many of the best engineers I know have had much more energy invested in getting them to stay than to leave

Re: How good engineers write bad code at big companies

#174

Post by JohnMakin »

brendoelfrendo wrote: post #161
sfink wrote: post #149

Earlier quoted context omitted.

Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. I got into this career because I like mucking about with this kind of work. Programming is sort of like building thought sculptures. Ok, maintaining them too. I spend a lot of my adult life working with these systems, so of course I car…

> Hm, those are all valid, but they're also from the perspective of only caring about external forces. It's as if the work itself is only relevant insofar as we get something out of it. Well, I don't know that we can separate external forces from why people might dislike bad code... being held to a standard that is unachievable because of someone else's mess and someone else's expectations is all too common in life,…

sandbagging or messing with metrics is an inevitable part of playing a role in $BIGTECHCO. Even if people don’t admit it or aren’t aware of it, it happens everywhere. If anyone resents it they just resent you’re doing it better than they could. much of what we do is all a political game. I’ve had situations where I cannot do something that clearly needs to be done, I in the past will find reasons to slow things down and point to (thing that needs to be done) as the reason why. Eventually the manager above you will prioritize it or discipline you. If you’re right and are valuable and your manager isn’t stupid, you’ll get your way, and they can take credit for the sudden velocity gain. I’ve also done the opposite in speeding things up to expose brittle unsustainable processes.

Not endorsing it, but, it just seems to me the way most performance management works at these companies (I came from a company that liked to think it was amazon with stack ranking) you have to do it or you will get shanked inevitably before you vest. This is just my personal experience. TLDR it’s how you make things “happen”

It’s very cynical. Thankfully these days I work on much smaller teams where everyone helps as much as they can because you’re constantly treading water, but there’s very little room for this kind of political maneuvering and bs.

Re: How good engineers write bad code at big companies

#175

Post by surajrmal »

mikert89 wrote: post #37

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 extremel…

Catching architecture problems in code review is usually a red flag for process problems. Anything substantial should have been reviewed for architecture prior to a code review, especially if it spans multiple commits. Code review should feel rote and focus on rubrics around style and best practices in an ideal case. Of course you will still find architectural issues during code reviews in many cases but that shouldn't be often as it's not reliable to expect the reviewer to have the necessary context to catch them.

Re: How good engineers write bad code at big companies

#176

Post by tehnub »

asdfman123 wrote: post #92
area51org wrote: post #72

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…

No, big tech engineers are highly motivated. There's lots of money, good management, and plenty of incentive. (I'm a Google engineer myself). The problem I observe is a fairly universal one: management doesn't care about good code, it cares about results. It's generally hard for anyone without specific experience with a codebase to tell what you're doing with it. Management can't evaluate the value of maintenance wor…

>Management can't evaluate the value of maintenance work, so it doesn't value it at all.

So it's the McNamara fallacy?

Re: How good engineers write bad code at big companies

#177

Post by jiggawatts »

ianbutler wrote: post #135

I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions. Experience CAN remove pitfalls, though developers even disagree about those sometimes. Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've…

Good code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc.

Bad code is one of those things that we can almost all agree on, often even the person writing it.

Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with that opinion. You and I however will almost certainly not agree on what our favourite movie of all time is. The nuances and personal tastes become more important at the last few percentage points approaching 100% "like".

Re: How good engineers write bad code at big companies

#178

Post by vlovich123 »

sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> Why does bad code bother engineers so much?

Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.

It could be maturity to resign to powerless forces or it could be the inability to obtain that mastery or the willingness to let go of that mastery. I would think it’s more mature to fight the good fight, but at some point you just get old and tired I imagine. And it’s interesting to posit the author is nihilistic when this “uncontrollable forces” itself is a nihilistic take imho.

Re: How good engineers write bad code at big companies

#179

Post by bdangubic »

vlovich123 wrote: post #178
sfpotter wrote: post #93

I've read a few of this guys posts now and have consistently been rubbed the wrong way by them. I think I know why now. It's not that he's wrong . His analysis is reasonable and straightforward. I think it's that the basis for his analysis is ultimately a form of nihilism, coming from someone who (maybe?) used to be an idealist but was burnt by a bad experience and must now explain why believing in anything is misgui…

> Why does bad code bother engineers so much? Others have said some true things but the core is missed. It bothers engineers who care about mastery. It’s the same for architects who see design flaws in buildings that were done by those who don’t care about mastery. Or a filmmaker who watches a movie with lots of flaws. Caring about obtaining mastery means having the capability of seeing the flaws and resolving them.…

there’s like 7 of these mastery-seekers worldwide

Re: How good engineers write bad code at big companies

#180

Post by ianbutler »

jiggawatts wrote: post #177
ianbutler wrote: post #135

I don't think there's an objective assessment of good code. I've been writing code for over 20 years at this point and most times I've seen what people describe as their own good code I disagree with various decisions. Experience CAN remove pitfalls, though developers even disagree about those sometimes. Organization, chosen abstractions, naming etc are basically personal thinking and have differed on every team I've…

Good code is subjective, especially once you start wandering into the territory of more esoteric approaches such as functional programming, domain-specific languages, code-generation, etc. Bad code is one of those things that we can almost all agree on, often even the person writing it. Alternatively: I don't know how to make a good movie, but I can recognise a really bad one, and you'll almost certainly agree with t…

I think we can agree on a version of bad code, specifically extremely bad code.

Just as we might agree on universally panned bad movies, but disagree on cult followings or one of us for a particular reason can't stand a popular movie.

That is to say we can all agree on extremes, but just because something isn't extremely bad doesn't make it good in everyone's eyes and that's where the contention is.

Post reply on HN