Hacker News Reader

Comment by hinkley | Hacker News Reader

The sad fact of software projects is that some part of the work is always a bit of bribery to keep skilled labor engaged. You’re always throwing them bones, letting them work on a few things that don’t really need to be done but make them happy. That’s lost sometimes when I’m lamenting NIH or wheel reinvention, but it’s a matter of degrees. Let them have one big thing and a bunch of small things.

Companies go off the rails and get trashed talked when they clamp down and go for zero fun, 100% financially justifiable task lists.

As a tech ages out you can’t find anyone good to work on it. And when you make them, morale craters.

View on HN

From my perspective, there's loads of this legacy/boring crap (lots of PHP&Rails). As a "old" coder, I love those legacy apps that folk can't/don't give to their internal team - it becomes consulting work for me :)

any tips on how to get started here? I have plenty of past Rails experience and although I'd prefer rewriting the stack endpoint by endpoint in something like Phoenix, I'd probably be amenable to other kinds of work yet staying in the Ruby ecosystem

I just kept telling my network to hand over their legacy projects. I'm not in the resume builder phase of the career. And folk (managers and devs) on the legacy project are happy to hand it over (provided they trust you). Helps all of their OKRs.

And sometimes you get landed a fun legacy one where you have to rebuild some binary by de-compiling first (thanks for not stripping the binary previous long-gone dev) and then spend days re-factoring it to work with updated AT commands on the new hardware. And nobody's rushing you, cause you're like the only one doing it; and finding another person to even WANT to do this is $HARDWORK.

I'm still out here doing VB6/VBA, Perl as well.

You can get people to stay longer as long as they are getting material to pad their resume. This seems counterintuitive at first, but one thing devs are good (bad?) at is avoiding pressure sales or getting “trapped”. An employee who feels stuck has lowered expectations from another job, and so it’s easier for them to leave. They don’t wait for “better”, they wait for “not here”.

Amongst a group of people I talked about this with, we estimated that places that allowed resume farming saw between 6 and 9 months longer average employe retention times. For a place aiming at 3-4 year turnover that’s a substantial fraction of your goal.

That's the trouble though isn't it—leaving it to mature gracefully in the cellar gets you to a point where only an expert somilier in that particular varietal knows really what to do with it, and you pay through the nose for their knowledge.

What do you do with a 20 year old embedded Linux system which still "works" and where management has been saying they'll replace it for more than ten years but meanwhile don't touch it, and, oh yeah, "make it secure"? I can actually imagine somewhat exotic network firewalls that would be sufficiently secure (might even be a fun project) but there's zero provision for the required effort.

>meanwhile don't touch it, and, oh yeah, "make it secure"?

Yeah never take such a job, this is the manager trying to screw you.

Security is a big word, from stability to observe-ability to hack-ability, there is no way to secure a system without touching it.

I characterize refactoring as an exercise in staying familiar with the code. With security we talk about data at rest versus data in motion, which is a hard problem. You can stare at code a lot and think you understand it, but when you see it actually run it's a different experience. Poking at things teaches you a lot faster and more deeply than treating it like a religious artifact.

Reply on news.ycombinator.com