undefined | Better HN

0 pointseconomicalidea2y ago0 comments

I disagree with your point that this analogy does not apply.

You say there are some codebases that need over 9000 IQ to do anything. While that might be true, it is not the norm and a small fraction, so it’s not relevant to the broader argument.

You say it’s completely different in programming. Sure it doesn’t help if one of your workers is a complete idiot — but that was not the premise - it was unskilled but energetic.

And there are always menial tasks to do — you pointed out some example yourself.

So to sum up my points are: - most codebases do not require gigabrain for every single change

- there are always menial tasks to be done in a team environment

- “untalented” people don’t necessarily slow things down in development

- in fact talent is irrelevant when writing code - I would even argue that being talented is not always an advantage, in any field or profession - but that last point probably would need some more explanation.

0 comments

forgetfreeman2y ago

100% of the most catastrophic IT disasters I've witnessed have been directly attributable to the most intelligent and skilled programmers I've worked with.

Example 1: I got hired to work in the dev department at a large regional printing company. One of the suites of software built in-house took large retail clients orders for printed store display material. From the client's initial order the software would automatically detail print batch sizes, assign these to the work queue, and would then go on to figure out how many of each type of display needed to be boxed and shipped to each of the client's retail locations and would create shipping labels, packing lists, etc. from this. At it's heart was a 10 page long SQL query that I couldn't make heads or tails of after two weeks spent studying it. I left the company certain of two things: 1. the dev that wrote that was one of the 3 smartest people I've ever met and 2. when he left the company they had literally zero chance of ever hiring someone to maintain that system.

Example 2: I got hired by the 2nd largest print media conglomerate in North America to help manage a fleet of 31 newspaper websites and a fleet of 125 niche verticals. This was at a time when the industry was just beginning to come to terms with their revenue models being gutted by craigslist and the shift to online marketing. To say the least money was tight. It was decided that the back-end systems that drove the integration between newsroom terminals, printroom layout qeues, and the newspapers' websites needed updating.

They hired #2 on my list of top 3 most intelligent people I've ever met to drive a complete overhaul of the system. It was decided a complete rewrite in a cutting-edge language was called for. The guy in charge didn't sleep for 3 days after which he'd provably onboarded and synthesized a complete understanding of the chosen language and it's ecosystem despite no prior experience, then went on to single-handedly rearchitect (feature complete) a system with roughly the same LoC as an operating system. In six weeks.

Over the course of the next 18 months the dev department responsible for implementing this masterwork (no sarcasm) floundered and the project was eventually scrapped having blown through the entirety of it's original 2M budget with literally nothing of use or note to show for it. Apparently nobody else on the team was capable of implementing and debugging the blizzard of microservices the new architecture called for.

My key takeaways: proposals to make codebases "interesting" should be met with deep skepticism if not outright hostility, and a roomfull of mid-level developers are significantly less likely to get an organization into deep trouble than a single rockstar with the bit between their teeth.

j / k navigate · click thread line to collapse