logoalt Hacker News

fragmedetoday at 12:09 AM1 replyview on HN

The bricklayer's building that falls over, or the cook that makes food that tastes bad and no one wants to eat and makes people sick isn't going to have a job for very long, however. And of course, the job of "cook" runs the gamut from minimum wage at a shitty diner, to being very well paid at a Michelin star restaurant. So shipping code > beautiful code, but three years from now, that one "quick and dirty hack" just to get the next version out the door has become three hundred hacks, and that tech debt is a liability preventing any movement, either fixing existing bugs or in shipping new features.

So maybe not every line of code needs to be even more beautiful than the last, but there's clearly a balance to be had. And yes, sometimes the business people are right. Sometimes they are wrong, however.


Replies

britchtoday at 12:25 AM

I think we're both arguing for balance here

When I started programming I wanted everything I wrote to be museum-ready. I was slow as shit and waaay too precious about code. As I've matured I realize that's not a good way to work.

I think my lowest acceptable quality bar is still pretty high (and I'm fortunate to work somewhere that is valued). But as time has gone on I've tried to emphasize speed and knowing when something is "good enough"

I feel that it's an important skillset for the profession, but often craft-oriented engineers dismiss it at "business people not understanding"

As always this depends a bit on where you work and your projects