4 ms·
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) th
by albatross13 5y ago
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.
- dimitrios1 5y agoI 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.
- albatross13 5y agoI 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.
- reidjs 5y agoHe means that those customers wouldn't exist in the first place if it weren't for the messy code.
- srean 5y agoWhen things eventually break, its possible that those customers and more would leave also because of that same code.
- philosopher1234 5y agoAnything 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.
- srean 5y agoDepends 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.
- Dracophoenix 5y agoAnd 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.
- darkerside 5y agoYou 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.
- djenendik 5y agoYes because those other 20 have been debugged...
- shepherdjerred 5y agoI 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.
- raman162 5y agoI 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.
- metafunctor 5y agoWhat 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.
- Proziam 5y agoEvery 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.
- metafunctor 5y ago600 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.
- bobfromsweden 5y agoYeah, 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.
- a9h74j 5y agoWhy 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.
- gautamdivgi 5y agoThe 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.
- dboreham 5y agoBecause code review is mostly a delusional fantasy?
- infinityplus1 5y agoThere 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.
- a1369209993 5y agoHow 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.
- ta988 5y agoand in hardcore level Perl
- a1369209993 5y agoWell, I was talking about 6000-line bash scripts, but yes, perl does come up fairly often as well.