Hacker News Reader

> All too often, being obsessive about code cleanliness is a type of bikeshedding

"All too often"? Is it? I hear this all the time and very very rarely actually see it. It definitely exists, but our community seems to treat this unicorn as if it's the major issue affecting productivity.

Way way more often I see the opposite. "Just ship it! Lean startup!" a month ago leads to the inability to ship now because every part of the code you touch to add a new feature results in everything breaking. And of course there's no unit tests or any kind of documentation or even agreement among those working on it regarding what responsibilities each part of your system has. It inevitably results in the dreaded "big rewrite", if you haven't fallen behind your competitors enough at this point and are still in business.

Like you say, it's a balance and a hard one but I'm getting more and more convinced that this false consensus results in bad advice, especially when non-technical people start throwing around "just ship" and "move fast and break things" without even knowing there is a balance.

There is also absolutely no context to this lean advice that this balance is completely different for different types of programming. You will never get a good search engine written by "moving fast and breaking things", you're going to have to do some architecture/design work before you start writing code. But if you are setting up a wordpress blog to do affiliate marketing then by all means just fucking ship it.

Maybe I'm living in a bubble that's very different from everywhere else? Where people went too far with good advice? If that's the case then I want out! I will hire some obsessive bike shedders and teach them to consider time as an important factor. Way easier than trying to retrain people who think that loose coupling or not putting every method you can think of into one monster class is "obsessive perfectionism".

> It's a hard balance to strike, because there certainly have been projects where people couldn't move forward or feel pride in anything because the code was so messy. But in these situations I've found it's best to try to see the big picture and pick my battles.

This.

Sometimes it's really hard to tell when you're shaving a yak instead of fixing broken windows. What are some ways to tell you're doing the wrong one?

Yak-shaving isn't necessarily a waste of time. Sometimes you have to spend time on something locally suboptimal to get something closer to globally optimal.

With the "weekend project" idea it seems that we easily forget how real jobs often require time and struggle, even for smart people.

Put another way. . it's hard sometimes to recognize - and accept - the influence of all the other stakeholders in the project, around and above you. And sometimes it's hard to deal with the 80/20 rule and stop polishing the apple. . .the apple might not be shiny enough for you, but other people don't even the apple that you are continually shining.

The key is to pick the correct battle.