6 ms·

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have

I think that the main point was that docker skills are transferable, i.e. you can expect a new hire to be productive in less time. Too many companies still have in-house build/deploy systems that are probably great for their purpose but don't offer valuable experience that would be usable outside that company.

notyourday 9y ago
In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.
- tokenizerrr 9y ago
  Your observation is incorrect.
- sigjuice 9y ago
  Yes. Each time you start a container, you are basically saying “make clean” as well.
  - notyourday 9y ago
    Except that people who write software to be put in containers cannot write that Makefile to save their life so for something that should be a ten line dependency they manage to build entire Linux, entire X and all unneeded tool chains.
- noahwilde 9y ago
  Writing a dockerfile successfully is maybe that. But learning to make a dockerfile should take someone a day to figure out. What the entire movement is about is creating an ecosystem around a common standard for dev ops.
- krizzo 9y ago
  I use Makefiles for creating docker files there is an advantage to docker from fat binaries. Both tools exist for a reason, used both wisely you can save time and effort.
Silhouette 9y ago
If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?
- noahwilde 9y ago
  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.

notyourday 9y ago

In my observation, Docker skills is a modern day ability to type "make", without being able to actually write a Makefile or debug a Makefile.

tokenizerrr 9y ago
Your observation is incorrect.
sigjuice 9y ago
Yes. Each time you start a container, you are basically saying “make clean” as well.
- notyourday 9y ago
  Except that people who write software to be put in containers cannot write that Makefile to save their life so for something that should be a ten line dependency they manage to build entire Linux, entire X and all unneeded tool chains.
noahwilde 9y ago
Writing a dockerfile successfully is maybe that. But learning to make a dockerfile should take someone a day to figure out. What the entire movement is about is creating an ecosystem around a common standard for dev ops.
krizzo 9y ago
I use Makefiles for creating docker files there is an advantage to docker from fat binaries. Both tools exist for a reason, used both wisely you can save time and effort.

Silhouette 9y ago

If a company has existing in-house systems that are working well, why should they care about "valuable experience that would be usable outside the company"? Unless you think it's their responsibility to train people so those people can then leave and take the benefit of that training to some other, possibly competing, business?

noahwilde 9y ago
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.