Live data from Hacker News

How good engineers write bad code at big companies

seangoedecke.com

161–170 of 333 posts

Re: How good engineers write bad code at big companies

#161
post #149

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…

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, and the reality is that your livelihood might depend on meeting those expectations. If you like programming, you might also like maintaining or refactoring code; it goes with the territory, and it can be fun to see how something can be improved or challenge yourself to see how far you can improve it. But it tends to be less enjoyable when your ability to eat and house yourself rides on someone else's bad code.

> If you try to do something right and take pride in your work, your teammates will be resentful that you're not closing your bugs fast enough.

Right, but why would they resent that? Probably because management has expectations on the team, and they are concerned that you're sandbagging the metrics. It ends up being a management or cultural problem regardless.

> Bad code is actually fine. It happens. But I want to know why the code is bad, whether the reasons are defensible or not.

Agreed!

Re: How good engineers write bad code at big companies

#162

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…

I used to obsess about code, but over time I came to dread coming into a new codebase and finding layers upon layers of pointless mini-architecture. There would be a controller calling into a separate package where the actual implementation is, then that would call into a layer where service calls are, then all that would be abstracted just in case and built into a separate jar, and so on. And there would still be cr…

I feel like its just a reflection of people's minds. People organize their thoughts very different from one another and people often don't organize their thoughts at all when under certain constraints such as needing to ship NOW.

Especially with enterprise code you're hammering your thoughts into a shape roughly compatible with someone else's so its no wonder overtime with the constant revolving door of people that without careful shaping things can get nuts.

Re: How good engineers write bad code at big companies

#163
post #151

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…

My feeling when I found this blog was "so I'm NOT the only one!". It's the painful truth about staff+ engineering that I've also experienced, but haven't felt safe to talk about. You're not wrong that there's something cynical or nihilistic about it. The core thesis is "do what the company wants, even if it's not what they should want". That idea may be unpalatable, but getting ground up in the corporate gears is wor…

My personal feeling is that there's a way to both agree with the underlying issues Sean writes about while being more optimistic and providing better alternatives. Something I feel I should start writing about more.

Re: How good engineers write bad code at big companies

#164

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 can find an experienced doctor, plumber, musician or mechanical engineer that was doing it 50 years ago. I’m not going to find someone that was doing software 50 years ago. And if I do, their experience is completely unrelatable.

I worked on compilers and tools starting in 1981. Proprietary compiler technology has disappeared over the decades and the development tools/language/process/compute have changed considerably. But the skills and role of a compiler developer seem similar, although maybe it just means this sub-field of software has matured.

Re: How good engineers write bad code at big companies

#165

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? 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 happens when management/stakeholders don't understand what is going on, but have an expectation that is not well communicated to the engineers (and also inversely too, where engineers are not communicating the situation properly to management - or they refuse to hear it/ignore it).

Re: How good engineers write bad code at big companies

#166
At the end of the day writing good code is rarely the "end" someone is shooting for. It's more research, more features, more experimentation, etc. Maybe hobby projects and library maintainers are the exceptions.

In my experience, big companies have the biggest incentive to write good code. They have the highest conviction in their bets, and they know with high confidence they will be around in 10 years. One large tech company I worked at had a rule of thumb that all code would need to be maintained for ~7 years - at which point, as the author points out, the entire team may have been replaced. This is precisely when the time it takes to write good code is a worthy investment

Re: How good engineers write bad code at big companies

#167

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…

Totally agree, I've found that as well working in big tech People focus way to much on the superficial stuff like code cleanliness, formatting, organization, local structure of the code Because that stuff is easy to talk about, kind of like bikeshedding. Plus a lot of times code reviewers just want to comment something to show they aren't just rubber stamping it. Whereas it takes a lot more brain power to think about…

>does the change actually make sense in the big picture"

Ideally by the time your at code review this is not a question. It sucks for everyone for it to come up.

I think people also avoid rejecting for this reason becasue of that

Re: How good engineers write bad code at big companies

#168
I don’t mind bad code, I know why it happens and a lot of good points are made here in the comments.

What I cannot stand and can barely tolerate is kruft and sloppiness. massive sections of commented out functions, leaving the poor guy to come along 2 years later wondering if it was important or why it was left there. Unused functions. bad, inconsistent, or nonexistent naming conventions. Terrible or annoying file/project structure.

None of this stuff has to be. Not doing this stuff requires a bare minimum of effort and time and doesn’t require any familiarity with a codebase. It’s a lack of professional pride, and that deeply annoys me when I inevitably have to clean it up because it’s an unreadable mess.

Re: How good engineers write bad code at big companies

#170

Earlier quoted context omitted.

ive never actually seen someone get fired for making some deep architectural software mistake. its alway for moving too slow, or "low code quality". i think people that were promoted for building systems that turned out bad, should be demoted

All systems eventually turn bad. The idea that you can gold plate something so it won't is naive. It isn't about getting it right from the start, its about having the will to change it once your system or uses evolve into something that turns it wrong.

A good system, i. e. one that got it right from the start, is one that is cost-effective to change. (“Will” has little to do with it.)
Post reply on HN