Hacker News Reader

Comment by dman | Hacker News Reader

How do you create incentive structures for new employees who have to spend months (years?) coming upto speed with giant state machines before they feel remotely confident of the the effect of their changes? For better or for worse, currently the glory is in writing new systems rather than improving existing ones.

View on HN

"state machines" - nice pun in this context.

You get them doing interesting work on the system as often as you can.

Fixing bugs and babysitting all day isn't going to convince people to stick around. Best you can do is get them something they can try to work with.

Unfortunately, it's not just about "glory". If you work in "obsolete" languages/environments, you likely will be perceived as less valuable to your next employer.

This right here is a huge problem with our industry. If you're not jumping from employer to employer every 1.7 years, you're labeled as out of date. It takes some really talented developers to truly understand some of these old systems. They should be given the proper respect they deserve.

No, you can stick around.

I wouldn't consider someone who spent 5 years on AWS, especially if they moved internally, out of date.

Whereas I've done nothing remotely close to where I want to be in about 3 years. I feel very scared about my skills, especially since I'm not even 10 years into my career.

I spent 9 years at my first FT job out of college at a hedge fund known at the time for culling the bottom 10% of performers annually at the time. That long of tenure at a place with that reputation has openned more doors than it has closed, especially within the finance industry. Lately, I've been getting 4-6 emails from local recruiters per week.

An aside, even when you spend that long in a single position, you do need to keep learning on new and relevant technology; I attended every on house training seminar I could, which helped a lot, and spent a good portion every day reading. I spent 7 years at that company in the same effective role, and never changed job titles, but saw a >200% increase in take home pay in that same period.

In reality it often means these systems are built in bad, ineffective way. Most likely in bad, ineffective languages/technologies. You don't need 17 years to be able to contribute to Apache Spark. You would not call that a small project, would you?

I heard that COBOL programmers do pretty well because they are a rare commodity serving expensive industries.

If you're happy with working with something that destroys your brain and makes you useless to any other software technology developed in the last 20 years be my guest.

COBOL doesn't destroy your brain, that I recall. In fact, if it bores you, it leaves a lot of brain capacity available for funner stuff, like MVS exploits via Resolve.

To me, it's the cool-app-of-the-month-that-harvests-private-data-off-peoples-devices that is brain-killing.

Reply on news.ycombinator.com