Hacker News Reader

Comment by fnordpiglet | Hacker News Reader

They also tend to be brilliant engineers. It’s a heck of a lot easier to always be writing 1.0 of something. It’s a hellaciously difficult engineering task to improve a system that’s been improved upon for decades. These folks should be admired and respected, they’re by far the most crucial people at any company older than 30 years old. Instead we get condescending garbage like the linked article.

View on HN

I just wish hiring managers saw it the same way. It's hard to explain how your last major project was a web enhancement that would have taken a couple days on a virgin codebase, because for you it involved a month of excavating through multiple strata of code dating nearly two decades old, spread across three codebases, two backend languages, a code generator which no one working there understands anymore, and a library who's documentation now only exists on the wayback machine.

A secret I’ve learned is you only need one job, so you don’t need to take just any job or be hireable at every job. It might take longer, but finding a manager that “gets it” is very important. The most important thing is to find someone who recognizes further that a team is more than the sum of its parts, that each individual is unique and not a cog to be evaluated on a metric rubric and forced into compliance with some idealized engineer. They do exist - I was one for many many years. I’ve recently given up in disgust though and switched back to IC, but senior enough I can shape how managers manage engineers. Regardless, my advice is, if it’s helpful, find the right job with the right team and the right company. It’ll take longer, may pay less at first, but finding the right place that respects work at its value not at its marketability is key to any successful career.

Or a library who's code now only exists on the wayback machine... and of the modified version that you actually use only a single copy exists on an old machine that one of the devs in the company never bothered to hand in for recycling...

Never mind that it's part of a decade old contract stipulating a quarter century support...

Greenfield is easy. :)

I wish people like this would architectural decision records so people inheriting it later wouldn't be left in the dark by the decisions made in the system

Because sometimes on the outside systems look confusingly written, but it could be a reflection of the scope of confusing business rules to begin with that they had to scope out

What I propose wherever I go is writing a deprecation plan before production release. It may not be kept up to date over the lifetime but at least a plan for what it would look like to exit to another platform exists documenting assumptions and one way doors, why things were done, and what a replacement would look like and why. I’ve never had great success though, people are too eager to make the next 1.0.

Reply on news.ycombinator.com