6 ms·

What I’ve seen more often is software engineers preparing for their next job (or the job they want next) by pushing to build a project with a tool chain that th

What I’ve seen more often is software engineers preparing for their next job (or the job they want next) by pushing to build a project with a tool chain that they want to have on their resume. It’s not so much that they want to use X because Google does and it solves their problem, but that they want to look like they know how to use X because then maybe Google will be interested in hiring them—and if not then at least they know that they’re as smart as all those stuck up Googlers anyway.

yongjik 5y ago
The funny thing is, Google doesn't care that you have three years' Kubernetes experience. They want you to solve leetcode problems. So, it would have been better for everybody if you chose a boring technology, kept the system running with no hassle and no 3am pages, and spent the quiet evening studying on algorithm questions. But apparently that's not sexy enough.
jacobsenscott 5y ago
This is the main reason, and you can't blame engineers. The only way to raise your salary is to job hop, so the only point of having a job is to train for your next job. Also, as a company trying to hire people you need to use the latest fads to attract new employees. It is a vicious cycle for sure. There is no room in this dysfunctional industry to use simple proven technology that is appropriate to your size.
- weatherlite 5y ago
  > and you can't blame engineers I think you can definitely blame them and in fact I'd expect CTO's and managers to discourage employees from doing that. A small silly decision can later cost millions in rewrites or maintenance. In the end we'll all benefit if not every brochure website needs to have 50 micro services and use the latest nosql solution. We're the ones who end up maintaining these systems.
  - deleted 5y ago
    [deleted]
  - jacobsenscott 5y ago
    You can discourage that. And people move on to jobs where they can pad their resume, and it gets harder and harder to hire people because they don't see a future in your "boring tech stack".
    - weatherlite 5y ago
      Just as there are people who'd leave if the stack is "boring" there are people who'd leave if the tech stack is insane. Personally I wouldn't want to work in a team that prioritizes resume driven development. It's usually teams that care very little about the company or product, their only motivation is tinkering with shiny tech. That's not for me.
      - AA-BA-94-2A-56 5y ago
        Means to an end. I'd work in a team that prioritises resume-driven development for about a year, to brush myself up on all the new stuff. I think it'd be foolish not to, honestly. It comes down to whether you see the software you write or yourself as the important product of writing software. Paradoxically, I see myself as the most important product. Usually my work is a tradeoff between being productive and teaching myself. If I'm being too productive, I back off and experiment more and teach myself concepts.
        weatherlite 5y ago
        > being productive and teaching myself You can learn Kafka, Map Reduce, Elixir, DynamoDB and shiny new JS framework X like Meteor or whatever, or you can just go deeper on the fundamentals and the traditional tech you already know (learning SQL to a deeper level, becoming really good in Java/.NET/PHP/vanilla JS etc etc). I think the job market has room for both; and to me the second path is more enjoyable and sustainable but to each his own.
    - 5y ago
pram 5y ago
I call it Resume Driven Development!
KennyBlanken 5y ago
Which is funny because I can imagine a conversation that goes something along the lines of: "So tell me about a project at your last job?" "I used Mapreduce to blah blah blah." "So you had tens of billions of records?" "Well, no." "So why did you use Mapreduce over other solutions?" "............."
- CGamesPlay 5y ago
  “Management requirements were that the system would scale to that level. Probably overly optimistic in their part, but it did give me the experience to work at a really high-scale place like here!”
  - weatherlite 5y ago
    You have to be a good liar and hope no more follow ups are asked, I don't know if its worth it.
    - bboylen 5y ago
      For a non senior engineer it is very likely the truth to be fair
- spaetzleesser 5y ago
  “So why did you use Mapreduce over other solutions?" You almost never get asked that in an interview though.
  - disgruntledphd2 5y ago
    I ask the equivalent DS question in a lot of my interviews. Generally people tell me about the hot new XGBoost model they fitted, and I ask them how much better it was than logistic regression. 9/10 they don't have a good answer. That being said, my favourite answer was from a candidate who told me that Kaggle contestants didn't use log reg, and therefore it was a bad choice. Oddly enough, we didn't hire that candidate. OTOH, I've worked at places where they wouldn't hire you if you didn't talk about your awesome neural networks/XGboost experience, so it really depends on the interviewer.
commandlinefan 5y ago
> We like to think that we’re hyper-rational > they want to have on their resume So in other words... we actually are being hyper-rational, it's the people who discard any experience in anything that's > 5 years old that are creating the problem.
spaetzleesser 5y ago
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.
didip 5y ago
Yup. Resume Driven Development is so rampant. The worst one is when that engineer shoehorned completely unrelated technology just because it is hip.
chimprich 5y ago
Also known as "career driven development". Controversial idea: I don't think this is necessarily a bad thing. If an org is using sexy tooling that people want to use and looks good on a CV, then it keeps engineers happy and attracts new engineers who want to work with it. Disclaimers: provided it's not an actually terrible fit for whatever you're trying to do, or the overhead is enormous, etc.
deleted 5y ago
[deleted]
wpietri 5y ago
For sure. It costs when you put it in. It costs in maintenance (or in working around unmaintainable systems). And then it costs to take it out again. I was brought in on a cleanup job a few years back and discovered that key parts of their infrastructure went through a system nobody understood and were scared to touch. It was using Docker, but for no obvious reason, and it was version-locked to a very specific release in the 0.9 series. After some archaeology, I found the original commits. They were from an engineer who wasn't there long. On a hunch, I googled him. I found a video of a conference talk on Docker where he exaggerated the scope and value of what he had done. So I ripped it out again, making the system simpler, more reliable, and less scary for the staff.
technolo-g 5y ago
I call this "Resume Driven Development"
gorjusborg 5y ago
It's called RDD (Resume Driven Development) in my parts. It's sad that software engineers do it to each other, because this year's RDD project is next years legacy rewrite. If people could be mature and thoughtful and select technologies that have a natural sympathy for the domain and problem they are trying to solve, we'd all be a bit happier. In my mind, you are shirking your duty if you practice RDD.
ben7799 5y ago
Years ago my current team was horrible about this. Perhaps the worst case (but there are so many).. we were 99% java. We hit containerization and a team member hard sells introducing a container that did a relatively small job but was written in Go instead of Java/Python/whatever that is already present. Team member literally resigns to go work at a Go-Centric job the day they got the merge request approved. I heard about the resignation IN the code review meeting. Luckily it is/was a tiny thing that hasn't needed much maintenance. One of the funny things about this being about the "cool kids" doing stuff is the people doing the following were often viewed as the "cool kids" but could only stay that way for a certain amount of time until their tech debt from over-engineering everything caught up with them.

yongjik 5y ago

The funny thing is, Google doesn't care that you have three years' Kubernetes experience. They want you to solve leetcode problems. So, it would have been better for everybody if you chose a boring technology, kept the system running with no hassle and no 3am pages, and spent the quiet evening studying on algorithm questions. But apparently that's not sexy enough.

jacobsenscott 5y ago

This is the main reason, and you can't blame engineers. The only way to raise your salary is to job hop, so the only point of having a job is to train for your next job. Also, as a company trying to hire people you need to use the latest fads to attract new employees. It is a vicious cycle for sure. There is no room in this dysfunctional industry to use simple proven technology that is appropriate to your size.

weatherlite 5y ago
> and you can't blame engineers I think you can definitely blame them and in fact I'd expect CTO's and managers to discourage employees from doing that. A small silly decision can later cost millions in rewrites or maintenance. In the end we'll all benefit if not every brochure website needs to have 50 micro services and use the latest nosql solution. We're the ones who end up maintaining these systems.
- deleted 5y ago
  [deleted]
- jacobsenscott 5y ago
  You can discourage that. And people move on to jobs where they can pad their resume, and it gets harder and harder to hire people because they don't see a future in your "boring tech stack".
  - weatherlite 5y ago
    Just as there are people who'd leave if the stack is "boring" there are people who'd leave if the tech stack is insane. Personally I wouldn't want to work in a team that prioritizes resume driven development. It's usually teams that care very little about the company or product, their only motivation is tinkering with shiny tech. That's not for me.
    - AA-BA-94-2A-56 5y ago
      Means to an end. I'd work in a team that prioritises resume-driven development for about a year, to brush myself up on all the new stuff. I think it'd be foolish not to, honestly. It comes down to whether you see the software you write or yourself as the important product of writing software. Paradoxically, I see myself as the most important product. Usually my work is a tradeoff between being productive and teaching myself. If I'm being too productive, I back off and experiment more and teach myself concepts.
      - weatherlite 5y ago
        > being productive and teaching myself You can learn Kafka, Map Reduce, Elixir, DynamoDB and shiny new JS framework X like Meteor or whatever, or you can just go deeper on the fundamentals and the traditional tech you already know (learning SQL to a deeper level, becoming really good in Java/.NET/PHP/vanilla JS etc etc). I think the job market has room for both; and to me the second path is more enjoyable and sustainable but to each his own.
  - 5y ago

pram 5y ago

I call it Resume Driven Development!

KennyBlanken 5y ago

Which is funny because I can imagine a conversation that goes something along the lines of: "So tell me about a project at your last job?" "I used Mapreduce to blah blah blah." "So you had tens of billions of records?" "Well, no." "So why did you use Mapreduce over other solutions?" "............."

CGamesPlay 5y ago
“Management requirements were that the system would scale to that level. Probably overly optimistic in their part, but it did give me the experience to work at a really high-scale place like here!”
- weatherlite 5y ago
  You have to be a good liar and hope no more follow ups are asked, I don't know if its worth it.
  - bboylen 5y ago
    For a non senior engineer it is very likely the truth to be fair
spaetzleesser 5y ago
“So why did you use Mapreduce over other solutions?" You almost never get asked that in an interview though.
- disgruntledphd2 5y ago
  I ask the equivalent DS question in a lot of my interviews. Generally people tell me about the hot new XGBoost model they fitted, and I ask them how much better it was than logistic regression. 9/10 they don't have a good answer. That being said, my favourite answer was from a candidate who told me that Kaggle contestants didn't use log reg, and therefore it was a bad choice. Oddly enough, we didn't hire that candidate. OTOH, I've worked at places where they wouldn't hire you if you didn't talk about your awesome neural networks/XGboost experience, so it really depends on the interviewer.

commandlinefan 5y ago

> We like to think that we’re hyper-rational > they want to have on their resume So in other words... we actually are being hyper-rational, it's the people who discard any experience in anything that's > 5 years old that are creating the problem.

spaetzleesser 5y ago

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.

didip 5y ago

Yup. Resume Driven Development is so rampant. The worst one is when that engineer shoehorned completely unrelated technology just because it is hip.

chimprich 5y ago

Also known as "career driven development". Controversial idea: I don't think this is necessarily a bad thing. If an org is using sexy tooling that people want to use and looks good on a CV, then it keeps engineers happy and attracts new engineers who want to work with it. Disclaimers: provided it's not an actually terrible fit for whatever you're trying to do, or the overhead is enormous, etc.

deleted 5y ago

[deleted]

wpietri 5y ago

For sure. It costs when you put it in. It costs in maintenance (or in working around unmaintainable systems). And then it costs to take it out again. I was brought in on a cleanup job a few years back and discovered that key parts of their infrastructure went through a system nobody understood and were scared to touch. It was using Docker, but for no obvious reason, and it was version-locked to a very specific release in the 0.9 series. After some archaeology, I found the original commits. They were from an engineer who wasn't there long. On a hunch, I googled him. I found a video of a conference talk on Docker where he exaggerated the scope and value of what he had done. So I ripped it out again, making the system simpler, more reliable, and less scary for the staff.

technolo-g 5y ago

I call this "Resume Driven Development"

gorjusborg 5y ago

It's called RDD (Resume Driven Development) in my parts. It's sad that software engineers do it to each other, because this year's RDD project is next years legacy rewrite. If people could be mature and thoughtful and select technologies that have a natural sympathy for the domain and problem they are trying to solve, we'd all be a bit happier. In my mind, you are shirking your duty if you practice RDD.

ben7799 5y ago

Years ago my current team was horrible about this. Perhaps the worst case (but there are so many).. we were 99% java. We hit containerization and a team member hard sells introducing a container that did a relatively small job but was written in Go instead of Java/Python/whatever that is already present. Team member literally resigns to go work at a Go-Centric job the day they got the merge request approved. I heard about the resignation IN the code review meeting. Luckily it is/was a tiny thing that hasn't needed much maintenance. One of the funny things about this being about the "cool kids" doing stuff is the people doing the following were often viewed as the "cool kids" but could only stay that way for a certain amount of time until their tech debt from over-engineering everything caught up with them.