Hacker News Reader

Comment by albatross13 | Hacker News Reader

It's kind of a double edged sword- I've worked with a few people that "work hard" and "get things done", only to find out once they leave (or go on vacation) that now we have to untangle a 600 line bash script that's integral to production.

I'm being a bit hyperbolic here, but the gist of my point is: not everyone who works hard is worth keeping around, especially if their hard work leads to an un-managable mess in the future.

View on HN

I used to think like this too, but now-a-days, it's more like "What a luxury to be in a position where you get paid to untangle a 600 line bash script"

That is, usually these few hard workers are typically the ones responsible for getting a company to profitability precisely because of their GSD attitude. Now that the company has some runway, the architecture and refactoring can proceed.

I never felt luxury when our service didn’t scale to meet the goals of higher-ups because the code was over engineered with hacks piled on top. It doesn’t matter how good of an MVP you built if it is so inflexible that it has to be thrown away and rebuilt to meet tomorrow’s needs.

Managers tend to reward those who complete tasks today as minimally as possible at the expense of the product tomorrow.

I think scrappy MVPs have their place,it's just knowing when to use one. If you're a very early stage start-up and you're trying to validate your idea, the quicker you can see if that idea is valuable is better than risking time building a clean code architecture.

I can assure you, when shit is broken in production and customers are knocking at the door threatening to cancel it is not a luxury to find out these types of things...let alone start untangling the web.

You can always leave if you're not happy. Parent's point is that without that 600 line bash script person, your company/job might not even exist.

I'll remind you that, for every failing 600 line bash script you debug, there are probably 20 others that are sitting there, just working.

Yes because those other 20 have been debugged...

He means that those customers wouldn't exist in the first place if it weren't for the messy code.

And window repair customers wouldn't exist if it weren't for broken windows! If Bastiat were alive, he'd have a field day with the computing industry and its Freakanomics-like underpinnings.

When things eventually break, its possible that those customers and more would leave also because of that same code.

Anything is possible. Better to focus on what is likely. Did you stop using google over any of their outages? Most people didn't. These things matter, but people in software overstate them.

Depends on what's on the line.

Software for automatic trading, dosing radiotherapy, controller for moonshot etc will have different requirements on correctness than ordering of search results.

Ignoring these things can have people killed/ruined and they have.

What perverted sense of luxury is this?

There is no shortage of software jobs. There are plenty of opportunities to work with a relatively clean codebase, capable and experiences colleagues, unencumbered by the VC runway bullshit.

Every company begins somewhere. If you want new companies to make it, allowing for there to continue to be 'plenty of opportunities' in the future, then accepting that there are times when repairing the ~sins~ necessities of the past is reasonable.

600 line bash scripts are not always necessary for new companies to make it. Sometimes, sure. Often, even, on the way to understand what is actually needed.

Many new companies spend too much time perfecting the wrong thing.

But messy code is NOT a requirement to make it.

Messy code, in and of itself, does not help.

Messy code might be a sort of inevitable step on the path to product/market fit. However, it is most certainly not a goal, and dealing with messy code is not a luxury. It is more likely a sign that the early tech people weren't very good.

Yeah, this is probably a different kind of "hard work" than what the author is talking about. There's some people who work hard for the sake of results (hitting certain numbers, clearing tickets/stories, etc).

There's a different sort of hard work involved in achieving deep mastery over something. Reading, researching, building and testing ideas... it takes hard work to become an expert at something, but I guess you're far more likely to see the former type of hard work than this.

Why not rotate their assignments as a matter of policy. They might do a deep dive and fix something no one bothers to fix on a similar assignment. But then it is due dilligence to have another look at their work. I know this sounds theoretical compared to practice, but it seems to be on the level of separating conceptual or design breakthoughs from production-izing code.

How is that hyperbolic? 600 lines is pretty short for a (longest-involved-in-this-project) un-managable mess of a production-critical bash script. I've seen several well upwards of 6000 lines.

and in hardcore level Perl

Well, I was talking about 6000-line bash scripts, but yes, perl does come up fairly often as well.

The obvious question is why this wasn’t caught and rectified in code review? This seems to be as much a failure due to lack of oversight as opposed to the failure of the person who created the mess.

There are no code reviews when we have to keep churning features quickly and continuously, with always changing requirements in the next meeting with the client.

Because code review is mostly a delusional fantasy?

Reply on news.ycombinator.com