|
|
|
|
|
|
by milesvp
2152 days ago
|
|
|
Very much this. New hires must always be tasked to improve onboarding documentation. At a previous place I worked, I went from expecting it to take a new hire several months to be productive to less than a couple weeks and a big reason was continuing to have newbies tweak docs and fill in details that might be easy to gloss over by soneone who already knows the tech. As for containers, I’m not sure I follow. We ended up using vagrant and then test kitchen for our VMs, which really helped with on boarding. The team had too many people who couldn’t be expected to troubleshoot much of the backend anyways. We had stayed away from containerization because it added complexity without any clear benefits for our use cases. But test kitchen definitely papered over the need to get a local environment running with all the dependencies, which might change with different services, and that seemed like a good thing. |
|
|
1. Nobody has to install dependencies. Docker is the only dependency (with compose).
2. Everybody has the same configuration.
3. Software versions are (mostly) tightly controlled. This requires whoever sets up the dev environment to make sure they use specific versions, and not :latest.
4. Devs don't need to spend time worrying about how the dev environment works, just the code.
This means that my README for a project usually has a section describing setup that just says:
1. run `dev/install` (any libraries from eg. NPM, go modules, etc.)
2. run `docker-compose up`
3. Check that the application is running on port XX.
This actually works great, and it does allow new devs to get to work quickly, and it does allow us to use devs that know very little about the underlying software that we're using, unless something doesn't work correctly. And that does happen, much more often than I would like. Then it takes my time and theirs to get up and running, and that was definitely not the goal.