Hacker News new | ask | show | jobs
by scruple 3051 days ago
Those places are basically unicorns, as far as I can tell. I have my own anecdotes, of course, and they oscillate between "we cared about code quality" and "we didn't have time." My experiences and the conversations I've had with others lead me to the conclusion that: almost all of us have deadlines that we didn't really help set, that we're always struggling to meet those deadlines, and that there is a stupid amount of money on the line that drives these decisions. And, so it goes, "get it done and ship it yesterday" is the commonality that I see.

That said, despite the frustration, I do try to hold myself accountable for writing clear and concise code as much as I possibly can and off-setting the times when I have to commit some clever hack with long-form narrative style comments.

1 comments

I've also seen the opposite happen as well where endless feedback and getting the "perfect" architecture has almost sunk a few teams. If you take too long building the ivory tower then the market may move past you.

The thing I care about is if it's a deliberate decision made with consideration of the rest of the business of if it's driven by fear/reactionary/habit.

The former usually means that you'll try and budget in time after the crisis to fix it up, the latter tends to spiral into a complete mess that no one wants to touch after a certain amount of time has passed.

Any team striving for a perfect architecture rather than building something that works and then seeing where the bottlenecks are isn't focused on "code quality": they are ignoring best practice in favor of intellectual satisfaction. The best software architecture is any architecture that solves the problem.
Yeah, there's a natural tension in this. I know I tend to wander towards the "ship it" category but yet I've found my best work was when I was paired with someone on the "correctness" side of the equation.

It forces a constant re-evaluation of your methods and reasoning on both sides which leads to something even better than the two individual approaches.