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

51–60 of 333 posts

Re: How good engineers write bad code at big companies

#51

Post by alephnerd »

zwnow wrote: post #43
alephnerd wrote: post #38

Earlier quoted context omitted.

Ime, a lot of the onus falls on Engineering and Product Management failing to make a case for why certain engineering decisions (eg. Investing in continual tech debt grooming) have business value. The point of a business is to generate revenue. The point of employees is to do work that helps generate revenue. As such, any decision needs to ensure it has a business case aligned with revenue generation. Good engineerin…

I work for some event ticketing business and I'd sign this. My bosses want features quickly. Does not matter to them if I need extra time to make stuff secure, doesn't matter to them if it wont scale. Its about short term revenue. Can always rebuild the software to fit the next short term goal...

If you understand what are the metrics being tracked, and what are the primary goals that an initiative or product has, you can make a case.

We are an engineering discipline and engineering decisions can have revenue making implications. But it is hubris to assume why you should care about the nitty gritties of a codebase. It's the same way no one in leadership cares about the nitty-gritties of HR policies or accounting practices - people are hired to deal with the intricacies.

When I was a PM, I didn't have a difficult time making a business case for "keep the lights on" or tech debt work so long as I was able to attach tangible revenue implications (eg. X customer might churn because of subpar experience and we have both customer testimony and user stats showing that) or roadmap implications (eg. If we spend 6 months refactoring our monorepo, we can add new revenue generating modules every quarter instead of annually).

Re: How good engineers write bad code at big companies

#52

Post by mikert89 »

bad_haircut72 wrote: post #49
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…

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

Re: How good engineers write bad code at big companies

#53

Post by jeltz »

samdoesnothing wrote: post #31

I think it's more that optimizing your hiring process for leetcode savants selects developers who prioritize algorithmic practice over everything else. They also deprioritize character over raw technical skill. But it turns out you need well rounded developers who are able to work with others, communicate well, and have taste. If your hiring process deprioritizes that, don't be surprised when the software produced is…

Yes, that is an issue they have but I do not think it is the main issue. In these orgs even week rounded engineers can be made to write bad code.

Re: How good engineers write bad code at big companies

#54

Post by tim1994 »

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…

Another reason I can think of is the requirement not to introduce a breaking change. It is very frustrating if the codebase has a lot of hacky/bad code in it but a lot of it can't be changed...

Re: How good engineers write bad code at big companies

#55

Post by samdoesnothing »

jeltz wrote: post #53
samdoesnothing wrote: post #31

I think it's more that optimizing your hiring process for leetcode savants selects developers who prioritize algorithmic practice over everything else. They also deprioritize character over raw technical skill. But it turns out you need well rounded developers who are able to work with others, communicate well, and have taste. If your hiring process deprioritizes that, don't be surprised when the software produced is…

Yes, that is an issue they have but I do not think it is the main issue. In these orgs even week rounded engineers can be made to write bad code.

Yeah that's true. As with most things it's a mix of factors.

Re: How good engineers write bad code at big companies

#56

Post by ethanwillis »

alephnerd wrote: post #38
hkleppe wrote: post #24

You have to realise there is a almost full complete disconnect between engineering and business value

Ime, a lot of the onus falls on Engineering and Product Management failing to make a case for why certain engineering decisions (eg. Investing in continual tech debt grooming) have business value. The point of a business is to generate revenue. The point of employees is to do work that helps generate revenue. As such, any decision needs to ensure it has a business case aligned with revenue generation. Good engineerin…

The point of a business is to generate profit.

Re: How good engineers write bad code at big companies

#59

Post by dave_sid »

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

You can’t often demote them because usually the people responsible for bad initial design decisions left the company years ago with a desperate need to go and start a new mess somewhere else.

Re: How good engineers write bad code at big companies

#60

Post by Herring »

hkleppe wrote: post #24

You have to realise there is a almost full complete disconnect between engineering and business value

I think that’s a bit unfair. I’d say shipping a product that solves a problem is the baseline entry fee into the market, just table stakes. Profitability is determined by the machine built around the product, like the efficiency of capital deployment, the speed of distribution, the defensibility of the business model against competition, etc. The product is just one variable in a much bigger equation.
Post reply on HN