Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

181–190 of 333 posts

Re: How good engineers write bad code at big companies

#181

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 is it necessary for big tech companies to act this way?

This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let engineers write better code, make better products, maybe even consider societal good in their strategic planning, and still turn a healthy profit. But the cost of perhaps taking a few degrees off their YoY trend line is unacceptable to the insatiable greed of their controlling shareholders.

Re: How good engineers write bad code at big companies

#182
post #173
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…

We just went through a ton of layoffs, while those companies are making record profits.

Re: How good engineers write bad code at big companies

#184

Earlier quoted context omitted.

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…

It's interesting that you talk that there's a lot of good management, followed by a list of things I'd call bad management: Forget about good vs bad code, of course that's unimportant. But insufficient maintenance that causes lower velocity on the next set of changes matters. Good engineering will tell you when the issue isn't just about code that is ugly, but code that slows changes down so much you'd be better off…

> code that slows changes down so much you'd be better off improving it

Note that the minimum amount of time necessary for a change is ~zero. A few minutes in practice because CI checks need to run, but that's it.

Re: How good engineers write bad code at big companies

#185
post #36

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

> "... so you're saying they wrote bad code on purpose?" Depends how you define "one purpose". I feel like I could polish any code to perfection forever. But the threshold of bad is going to be very murky. Is it still bad after 5min? After 30? After an hour? After a day? Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks. And you'll find people who think it's too…

> Wherever you think is the right effort/benefit threshold, it will turn out to be different in a few weeks.

Very true. And experiencing this has absolutely been a useful lesson to me. I remember feeling pained over some code I wanted to write in a more robust and principled way in front of a big deadline, and after a bit of friendly push and pull with my manager, I agreed to console myself by throwing in some TODOs and FIXMEs in the comments instead of getting carried away overengineering or burning rubber just beautifying my style. I remember this ritual feeling painful at the time, though it helped me cross the finish line sooner. A few months later, it was clear that ~80% of that code would be good enough for the next year or so— by which time other parts of the application would have evolved as well. I even ended up glad I'd deferred a few of those changes just so the small refactors could be informed by things we'd learned in the meantime.

Sometimes it goes the other way, or course! Many times I've been glad for some extra care I put in early, or regretful about some I didn't. But you're right that that balance always seems to change in retrospect, one way or the other.

Re: How good engineers write bad code at big companies

#186
post #160

Earlier quoted context omitted.

> Why does bad code bother engineers so much? I’ll take a stab. Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review. “You’re a senior engineer - why did fixing this take so long?” Because of the gar…

I don't think it's that. It bothers me a lot too, and not because anyone else is judging me or anything. I think it's just that it's depressing... it sucks to be doing bad work, on top of other bad work, and unable to do good work instead. It is incredibly frustrating to care about quality but be surrounded by and constrained to work on crap. Just feels like everything went horribly wrong somewhere and you're powerle…

That's in addition to the parent comment. They are both true. Caring is for other people, the tickets must flow.

Re: How good engineers write bad code at big companies

#187

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…

I think you are ascribing too much into this. If he does not believe anything then there will be nothing to write about. It looks like he does not believe in _your_ ideals - that does not make it nihilism though.

Re: How good engineers write bad code at big companies

#188
post #165

Earlier quoted context omitted.

> Why does bad code bother engineers so much? I’ll take a stab. Because I’m being held accountable for the bad results of the bad code. Because I’m being held to task to fix the problems caused by the bad code on a schedule that I didn’t agree with. Because management is using someone else’s bad code to deny me a positive annual review. “You’re a senior engineer - why did fixing this take so long?” Because of the gar…

> “You’re a senior engineer - why did fixing this take so long?” exactly! If a senior engineer is responsible for the problem, but he wasn't given room to develop a proper solution in the first place, then he cannot be blamed for the outcome. And yet, this is exactly what happens. If a system had been made well, and functions well, same senior engineer does not get the credit for not causing problems! This is what ha…

Only the bottom line matters and the bottom line isn't a good product, it's a good bonus or stock.

Re: How good engineers write bad code at big companies

#189

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 is it necessary for big tech companies to act this way? This question gets directly at the cause of the author's nihilism: the necessity is borne from the endless pursuit of positive quarterly growth, the "binding fiduciary duty to shareholders". Which is a lie, there is no such legally binding fiduciary duty. So the aforementioned necessity is also a lie. Companies could operate on a longer time horizon, let e…

Fuck Jack Welch

Re: How good engineers write bad code at big companies

#190

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…

I think the engineer jumping between giant companies for three years or less every time rarely works on particularly key things. Big tech companies do a LOT of stuff, and most of it is crap that isn't moving the needle. This post describes teams that are constantly changing priorities (chasing trends?) and IME that's not true of the really core, central functions at companies. But very true of the "support/enabling" or "what else can we do?!" side functions.

For instance, Github Actions being a meh product is called out in the article - that's a classic "check the box" feature that's good enough for a lot of people (let's not forget that Jenkins was no picnic before it) but is never gonna massively increase GH's bottom line.

Those sorts of projects are easy places for politics to fester since they are easy to ignore for the most influential-and usually strongest-parts of leadership.

On the other hand, if you're on a core, mission-critical team and other people's code is turning into your bad performance review, you need to figure out if the problem is (a) bad/toxic manager or (b) a failure to keep your management chain informed at what the root issues are and how you can improve it.

Post reply on HN