Hacker News Reader

Comment by ConceptJunkie | Hacker News Reader

I don't know about you, but I've rarely worked on a codebase that _wasn't_ awful in some way, and I am definitely not early in my career. I've come to the conclusion that most programmers are simply awful at their jobs, and the developers that can write clear, concise code are a small minority. I've known a few, but not many.

View on HN

Especially in big companies it's really hard to keep your code concise. I have often started with a very clean design that totally feel apart when new requirements came in. If you give managers the choice to hack it into the code in 1x time or redesign the code in 2x time most of them will vote for the first option. Go through that cycle a few times and your code will be a big mess

This 100%.

I’ve worked on several codebases over the years where a mgr said “here’s a special case, inputs of (foo, bar) should give baz2 not baz1. Coder whips up a hacky workaround to that very specific ask in the simplest place possible, not the right place. A few dozen requests come in like this over the months. Overrides and exceptions are now scattered all over the code base, without any semblance of order, functions no longer do what they advertise because data is modified downstream, etc.

Sometimes the time to redo it right is worth the investment in terms of future maintenance. Other times it’s too foregone and you have to bite the bullet and stick with the mess.

It's hard to blame them. I've been in similar situations multiple times where a requirement seems simple enough on the surface that you only get a few hours to work on it. But it's actually not that easy to write it cleanly.

That hacky workaround you're talking about? Well, my task depends on it. The workaround too depends on another hack. With the amount of time I have to work on it, it's a no brainer.

Earlier in my career, I tried to fix them, but they started to break other "hacks" and down the rabbit hole I go. Sometimes it's just not worth it.

If you don't act over-pessimist with that "1x vs 2x" comparison, management only sees that you offer two valid options and the second one takes double time for no reason. So obvious, take option 1.

Maybe you can propose to hack the code in an accumulative +1x time from the previous hacks (thus making it clear that next hacks will take more and more time), or design it into the system with a nice and constant 2x. That could be a strong indication for management that the hackish way does have a long term cost.

90% of developers think they're better than 90% of developers, but it's just an ego trip. Chances are, people have just had to compromise on design due to pressures from within the organisation. Or, as is often the case, they completed the exploratory coding phase of a new feature and the manager shipped it before they could refactor.

This so much. You talk with product managers etc about a new feature that could revolutionize a certain portion of your product so you start hacking away to get an alpha. The alpha is shown to some of the sales people and higher ups who start frothing at the mouth to put it into customers hands. The PM then says we need to ship this ASAP and into production goes code that was just feeling out whether or not the feature was even possible to begin with. Add a couple of months of no major refactor but tons of bug fixes plus additional features and you end up in a really fun place :]

There are so many bad developers out there, I find this difficult to be true.

Is it useful to calibrate the software scale in a way that concludes the majority of codebases are "awful" ?

What are we usefully communicating with the word, if 90% of codebases qualify?

Maybe software development is hard, sometimes unpleasant enough, to justify the crazy salaries, and the endless complaining about every codebase more than 2 years old is not quite justified..

As a collective group, software devs are really prone to self-flagellating while they go about delivering billions of dollars in value.

I've also rarely worked on a codebase that wasn't awful in some way, and I've come to the conclusion that maintaining best practices across a sprawling codebase is really hard.

Obviously. For 70 years now, the number of programmers has been doubling every 5 years. In consequence, on averge, half the programmers have less than 5 years of experience. Therefore almost all the code will be produced in a awful way, using awful new reinvented programming language-du-jour, and new reinvented configuration-and-build-system-du-jour.

Reply on news.ycombinator.com