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

151–160 of 333 posts

Re: How good engineers write bad code at big companies

#151

Post by zmj »

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…

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

Re: How good engineers write bad code at big companies

#152

Post by bigfishrunning »

Aeolun wrote: post #123
pmarreck wrote: post #95

Meanwhile, I have a ton of experience, am personable, am highly technical, and can't find something for some reason despite requesting a fairly moderate salary ($180k) given being 53 and having worked in technology for decades.

Something like if you are not a manager at 53 there must be something wrong with you? That’s what people keep telling me to watch out for.

Not everyone wants to be a manager -- effective management and effective engineering are two very different and rarely overlapping skill sets. It honestly seems strange to me that transitioning into management is such a common career path for engineers.

Re: How good engineers write bad code at big companies

#153

Post by bcrosby95 »

mikert89 wrote: post #52
bad_haircut72 wrote: post #49

Earlier quoted context omitted.

100% this. Stuff like database schemas gets comitted in the first sprint and never gets refactored, which completely locks you in to long term design decisions, then every subsequent PR will get held up for days in arguments around meaningless "code quality" arguments which ultimately affect nothing

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.

Re: How good engineers write bad code at big companies

#154

Post by jeltz »

zmj wrote: post #151
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…

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…

Having tried both I would rather be ground up again than just accepting my fate. I rather die fighting than the alternative.

Re: How good engineers write bad code at big companies

#155

Post by AppleBananaPie »

superconduct123 wrote: post #79
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…

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…

In the context of reviews my experience has only been code review quality brought up as a negative thing for folks and the bar to not be a negative is low enough that folks slowly take less and less time to review code well because it isn't valued come review time.

Re: How good engineers write bad code at big companies

#156

Post by jeltz »

bdangubic wrote: post #63
zanellato19 wrote: post #61

Earlier quoted context omitted.

Yeah, this is a deliberate choice to make labor less powerful. Capital is willing to be less efficient for that. He does touch upon this by saying that Capital wants every worker to be replaceable.

if I learned anything in my (too) long career is that one should do everything possible to ensure that whoever pays you needs you more than you need the money they are paying you. it is not easy to get there right away but if you make this core thing in your career it is achievable and your career will be happy and prosperous

Doesn't that just mean you are underpaid?

Re: How good engineers write bad code at big companies

#157

Post by jeltz »

jimbokun wrote: post #85
jeltz wrote: post #25

Earlier quoted context omitted.

It works as designed if your goal is to get your next promo package. It does not work as designed if the goal is to actually make the company more profitable. This constant rushing rarely ends up in things bring delivered faster or cheaper in the long term or even the medium term.

Profitable over what time horizon?

Any really. Rushing the team is more about looking good so you get promoted than about profit in any form.

Re: How good engineers write bad code at big companies

#158

Post by jeltz »

alfalfasprout wrote: post #124
jeltz wrote: 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…

> 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 have personally seen has not been caused by th…

Maybe, but then they are not "good engineers". A blog post about bad engineers writing bad code is not very exciting.

Re: How good engineers write bad code at big companies

#159

Post by jeltz »

cadamsdotcom wrote: post #148

There’s a cost-benefit component missing from the analysis. “Bad” code is probably “good enough for now” code that was written some time ago on a bet that doing it better would never be needed as it wouldn’t need to change. Also, “good” code is costly especially if taking longer to build the thing causes the company to miss its market.

In my experience a lot of bad was bad even when it was written. And that writing good code is often cheaper (within reason, perfection is bad) over any project bigger than a couple of months. The payoff from having good code shows up very quickly.

Re: How good engineers write bad code at big companies

#160

Post by ajkjk »

jagged-chisel wrote: post #139
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? 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 powerless to do anything about it and your only option is to suck it up.
Post reply on HN