4 ms·

Companies don't have a moral responsibility to do that, but it's a smart retention strategy. If good devs feel like they're learning useless non transferable sk

Companies don't have a moral responsibility to do that, but it's a smart retention strategy. If good devs feel like they're learning useless non transferable skills, they'll be more likely to leave for the sake of their career. If they feel like the business is investing in them, they'll be more likely to stay.

pfranz 9y ago
Resume Driven Development can be just as bad for everyone involved.
- dwaltrip 9y ago
  That's a slanted take. Skills and experience that are only useful inside of one specific company are more likely to be less meaningful and effective (almost by definition). Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Of course, there is a balance here. Sometimes frustrating tasks must be done. In that case, ideally the end goal is sufficiently motivating.
  - Silhouette 9y ago
    Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Right, but to those people, whether you use Docker or Kubernetes or custom scripting or a unicorn whose horn magically creates new instances when you need them is mostly just an implementation detail. It's no more interesting than exactly which compiler or DB you use; these are just tools, means to an end. If the differences are significant for your use case, sure, you evaluate and choose accordingly, but then you use the tools to get on with the job. The deep, interesting stuff is almost always in what you can build once you're into that territory.
    - dwaltrip 9y ago
      This is definitely true for many people. However, I do think it's likely there are some fundamental principles at play that make tool 1 better than tool 2 in specific contexts, and I think it is valuable and interesting to explore that. Perhaps we are getting into the scientist vs. engineer mindset. I would guess, though, that the best engineers undoubtedly have some scientific curiousity helping them excel in their craft.
      - pfranz 9y ago
        I think the conflict can be that engineers know what they're interested in, scratching their own itch, but that's not always aligned with what's best for the company. The balance is finding both. One extreme is that I see companies hold on to toxic employees because they're brilliant, even if they are bad for the company long term.
  - pfranz 9y ago
    (it does look like we're saying the same thing) Catering to a developer's whim as a retention strategy is not going to end well for anybody. In an ideal situation it can be mutually beneficial (that's what good management is--but that's not only relevant to your tech stack), in the worst case the developer leaves and there's new hotness from 3 years ago that doesn't work very well and nobody wants to touch.

pfranz 9y ago

Resume Driven Development can be just as bad for everyone involved.

dwaltrip 9y ago
That's a slanted take. Skills and experience that are only useful inside of one specific company are more likely to be less meaningful and effective (almost by definition). Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Of course, there is a balance here. Sometimes frustrating tasks must be done. In that case, ideally the end goal is sufficiently motivating.
- Silhouette 9y ago
  Many highly competent individuals like to understand the fundamentals and first principles of how systems work and how different problems can be solved, and thus find work that provides no transferable knowledge/experience to be less appealing. Right, but to those people, whether you use Docker or Kubernetes or custom scripting or a unicorn whose horn magically creates new instances when you need them is mostly just an implementation detail. It's no more interesting than exactly which compiler or DB you use; these are just tools, means to an end. If the differences are significant for your use case, sure, you evaluate and choose accordingly, but then you use the tools to get on with the job. The deep, interesting stuff is almost always in what you can build once you're into that territory.
  - dwaltrip 9y ago
    This is definitely true for many people. However, I do think it's likely there are some fundamental principles at play that make tool 1 better than tool 2 in specific contexts, and I think it is valuable and interesting to explore that. Perhaps we are getting into the scientist vs. engineer mindset. I would guess, though, that the best engineers undoubtedly have some scientific curiousity helping them excel in their craft.
    - pfranz 9y ago
      I think the conflict can be that engineers know what they're interested in, scratching their own itch, but that's not always aligned with what's best for the company. The balance is finding both. One extreme is that I see companies hold on to toxic employees because they're brilliant, even if they are bad for the company long term.
- pfranz 9y ago
  (it does look like we're saying the same thing) Catering to a developer's whim as a retention strategy is not going to end well for anybody. In an ideal situation it can be mutually beneficial (that's what good management is--but that's not only relevant to your tech stack), in the worst case the developer leaves and there's new hotness from 3 years ago that doesn't work very well and nobody wants to touch.