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

71–80 of 333 posts

Re: How good engineers write bad code at big companies

#71

Post by jjmarr »

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

Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning.

Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define.

The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to SWE.

It takes a decade or more before you're trustworthy enough to architect a building and there's a million layers of approvals. Then it takes years before groundbreaking, and years more as the building increases in size.

Your whole life might be dominated by a single large project like Hudson Yards, which has been floating around as an idea since 1956. The most recent proposal started in 2006, broke ground in 2012, and another 6+ years to finish. Then when companies were about to move their offices there, COVID-19 happened and the leases fell through.

I'd rather the system that gives average SWEs regular opportunities to lead large projects from scratch and make mistakes.

Re: How good engineers write bad code at big companies

#72

Post by area51org »

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 of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired.

Re: How good engineers write bad code at big companies

#73

Post by jeltz »

nosianu wrote: post #46
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…

Then how do you work with this: https://news.ycombinator.com/item?id=18442941 I did that job, just after university, but that is not my comment. I bookmarked it though because that person said it so well. You will write bad code, because what you already find there - and that one company is not alone! - is already so bad, there is no way to do a good job on top of literally millions of escalating hacks. And don't thi…

It is possible that some projects like Oracle are beyond hope but in general cleaning up a messy code base is done piece by piece and by refusing to merge most patches which make things worse. Better than you found it is the main principle.

Re: How good engineers write bad code at big companies

#75

Post by jimbokun »

rented_mule wrote: post #69
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…

I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?

Well obviously this is the same code the AIs were trained on.

Re: How good engineers write bad code at big companies

#76

Post by sethhochberg »

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…

Its hard to have good enough requirements gathering and documentation and product design practices to let an engineer really wrap their head around a problem well enough to come up with and then consistently follow a thoughtful, long-term-maintainable design for a system during implementation.

And its even harder to make sure everyone who reviews or tests that code has a similar level of understanding about the problem the system is trying to solve to review code or test for fitness for purpose, and challenge/validate the design choices made.

And its perhaps hardest of all to have an org-wide planning or roadmap process that can be tolerant of that well-informed peer reviewer or tester actually pushing back in a meaningful way and "delaying" work.

Thats not to say that this level of shared understanding in a team isn't possible or isn't worth pursuing: but it IS a hard thing to do and a relatively small number of engineering organizations pull it off consistently. Some view it as an unacceptable level of overhead and don't even try. But most, in my experience, hope that enough of the right things happen on enough of the right projects to keep the whole mess afloat.

Re: How good engineers write bad code at big companies

#77

Post by mberning »

It is only briefly touched on in the article but most of the “best” engineers spend almost no time coding or engineering. I’ve worked at multiple Fortune 500 companies and many weeks I would be lucky to spend 4-8 hours coding. Often I would just work on things that interest me after hours or on the weekend since it would be unlikely to be bothered. Unless some other unfortunate soul happens to see you are online.

Re: How good engineers write bad code at big companies

#78

Post by ozim »

jjmarr wrote: post #71
mikert89 wrote: post #52

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

Because businesses, as a rule, value moving fast. Being first to market makes money and generally results in winning. Oftentimes the circumstances are "we don't know the requirements", not because of shitty management, but because the problem is inherently hard to define. The business conditions that do heavily penalize bad architectural decisions, like physical structural engineering, can suck to work in compared to…

It is not only being first. It also is about responding to customers - not fun part is your customers don’t care about your app. They have to use dozens of different apps on daily basis, so when you have customer interaction you better be able to do stuff right there because they might be available in 3 months or next year to talk about your app.

I don’t like all the fantasy about “just talk to the customers” - nah it is not just, it is super hard to get their time.

Re: How good engineers write bad code at big companies

#79

Post by superconduct123 »

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 logic, correctness, and "does the change actually make sense in the big picture"

Part of it too is that as a reviewer a lot of times you just don't have enough context to know if the change makes sense

Re: How good engineers write bad code at big companies

#80

Post by sarchertech »

rented_mule wrote: post #69
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…

I've seen too much of the same. It strikes me that the pattern you describe also matches a lot of AI generated code I see, especially when it's big chunks of generated code. Are we automating this problem and going all-in on the long term costs?

100% yes. The most dangerous developers you’ll ever work with are the tactical tornadoes who crap out extraordinary amounts of code that mostly implements the exact feature that product asked them for with zero thought given to any other concerns.

AI makes these types of developers much more dangerous because they will accept anything the AI generates tha looks like it works, and they’re experienced at pushing nonsense through code reviews.

AI also provides more of a “productivity” boost to these types of developers because unlike everyone else they actually spend the majority of their time typing code.

Post reply on HN