4 ms·
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
by dman 8y ago
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.
- DrScump 8y agoUnfortunately, 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.
- JustSomeNobody 8y agoThis 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.
- s2g 8y agoNo, 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.
- hermitdev 8y agoI 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.
- ror6ax 8y agoIn 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?
- gowld 8y agoI heard that COBOL programmers do pretty well because they are a rare commodity serving expensive industries.
- raverbashing 8y agoIf 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.
- DrScump 8y agoCOBOL 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.
- s2g 8y agoYou 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.
- PopePompous 8y ago"state machines" - nice pun in this context.