Ask HN: Does your company's code – suck? | Hacker News Reader

Ask HN: Does your company's code – suck?

4 pointsskwee3575 comments

I'm not a very good business man. I care more about the code than the product. I grew up writing code and this what puts me in the flow state and gives me joy.

Imagine the shock and devastation I've had when I've learned that code doesn't really matter. The product is what's important.

So. From an Engineer perspective - how's code in your company? Is it readable? Maintainable? DX friendly? Or do you need to remember 7 different, cumbersome commands and edit 5 different files in order to locally debug your services?

View on HN

It's an endless cycle, honestly. We have shipping deadlines we can't miss, so we write some code we're not proud of. Then we do our best to live with it until it's hard to continue. This triggers a refactor that snowballs. Then that causes us to be behind for our new deadline, so we put in some code that we're not proud of....

All in all, I would say that the quality of the code depends on how close we are at the moment to shipping.

I’ve worked at several companies over 20 years, and generally speaking the quality of the code has been inversely proportional to the number of people who worked on it.

Hey, welcome to the real world:) This is your job now, so try not to take it too personally and don't forget to find a balance between work and life (yes they are different).

Jokes aside, I've been working with 2k - 5k line files in both python and JS for the last 10 years or so, in different code bases for various companies. That is, code I did not write but had to understand, extend and fix.

I've only worked with maybe just 2 super clean and well written codebases, for new prodcts/projects written by short-term contractors. The code was just beautiful and I learned a few things just by reading it. Both projects never saw a public release and the companies are long gone.

The projects with the superbad, just kill me now code, are moving along, slowly but steadily.

(also, FWIW, its Customers > Product > Code)

Every company I've ever worked at had roughly 50/50 amazing and terrible code. The larger a codebase at a company gets the more likely that there will be code in there that is _just_ good enough and no more. Polish and other elements of excellent code cost money and time to produce. It doesn't always make sense to invest the necessary money and time into it. Sometimes quick and dirty is literally the correct decision to make from a business standpoint.

it varies depending on how old it is, when it was last worked on, how quickly it was produced, and how important it is. Some is very good. Some is quite bad. But most is fair to middling...

Reply on news.ycombinator.com