3 ms·

Keeping the resume up to date is a huge factor. Me and a good friend of mine are principal engineers at our company. I tend to think we are well respected and

Keeping the resume up to date is a huge factor. Me and a good friend of mine are principal engineers at our company. I tend to think we are well respected and have done a good job over the years. A few years ago we read our company’s job ads and realized that neither of us should even bother applying for our own jobs because our resumes didn’t have all the latest stuff that was asked for. Since then I constantly add new stuff to new projects even if it’s not strictly necessary’. One factor is to keep the resume up to date. Another factor is that you learn something and the new stuff may actually be better. You just have to be willing to back out. Microservices would be an example where a lot of people wanted to do it but it showed that in our case this architecture only added overhead without benefits so we scaled it back. Resume driven development is a completely rational choice for employees. And companies have brought it on themselves with stupid job requirements and hiring policies.

hinkley 5y ago
There's a compromise to be made, and it does happen on the rare occasions when management can pull their head out of their asses long enough to realize that optimizing for throughput is a bad case of Goodhart's Law. Sometimes you let engineers do things that don't necessarily need to be done because it makes them happy. Not everything that might make them happy, not the biggest most ridiculous thing they say will make them happy (but objectively don't actually know until they try), but a few things, and consistently. What I see happen often enough is that someone who finally who has no fucks left to give takes big gambles to get permission to work on something, and what makes it resume fodder isn't that it does in fact look good on the resume, but that they have already begun to check out before the project even started. With the exception of some progressives, almost everyone who talks about retention or revolving doors only start talking about it after the proverbial barn doors are open and all the best animals have already left. Nothing you do at this point will get back the people you couldn't afford to lose and already did. You're really fighting the last war at this point.
gorjusborg 5y ago
I see that as a cultural or communication failure in your organization, not something intrinsic to software development. If you have to sneak tech that isn't vetted into projects, then you haven't made the case to management well enough, or management is running their company into the ground. You'd be able to accomplish a lot more with a lot less headache and cost by vetting new tech before going full-RDD it in a critical system.

hinkley 5y ago

There's a compromise to be made, and it does happen on the rare occasions when management can pull their head out of their asses long enough to realize that optimizing for throughput is a bad case of Goodhart's Law. Sometimes you let engineers do things that don't necessarily need to be done because it makes them happy. Not everything that might make them happy, not the biggest most ridiculous thing they say will make them happy (but objectively don't actually know until they try), but a few things, and consistently. What I see happen often enough is that someone who finally who has no fucks left to give takes big gambles to get permission to work on something, and what makes it resume fodder isn't that it does in fact look good on the resume, but that they have already begun to check out before the project even started. With the exception of some progressives, almost everyone who talks about retention or revolving doors only start talking about it after the proverbial barn doors are open and all the best animals have already left. Nothing you do at this point will get back the people you couldn't afford to lose and already did. You're really fighting the last war at this point.

gorjusborg 5y ago

I see that as a cultural or communication failure in your organization, not something intrinsic to software development. If you have to sneak tech that isn't vetted into projects, then you haven't made the case to management well enough, or management is running their company into the ground. You'd be able to accomplish a lot more with a lot less headache and cost by vetting new tech before going full-RDD it in a critical system.