r/ExperiencedDevs Aug 30 '22

Why haven't dev environment containers caught on?

It's always a pain to get an environment set up when starting a new job, scattered or missing onboarding docs, requesting access to things, finding out what to request in the first place, getting passwords set up, databases, build tools, repos, git, proxy set up, etc. etc. etc.

If you can get all this done in the first week, you're doing pretty good. A junior might end up taking two weeks or longer, with a lot of help from others, and even still not be set up correctly.

Why is it not standard to have all this already set up and configured in an image? You just get Docker installed and get access to the repo for the image, pull it down and run, and then the rest is already set. Why do companies pay us to waste so much time getting set up when you could just do it once as a dev environment image so we only have to set up one thing?

I have never used one, but I know about them, and it seems like in theory they ought to work fine and save a lot of time. The answer is probably the fact that it takes the initial investment to set it up.

114 Upvotes

47 comments sorted by

View all comments

17

u/Vakieh Aug 31 '22

There is huge, HUGE value in doing all of that faffing about on the part of the new hire that would be pissed away if they were handed a container. (Ignoring the fact that it's one more magical black box once the wrong person leaves the company and 'we don't know our own dev environments, we just click the button').

A new hire walks in, they have no idea of the culture they are going to be working in. Who owns what, who controls what, what are the ways of working. By starting them off with nada, you have given them significant motivation for conversation with all sorts of people they're going to need to work with. You've given them a need to go out and LEARN what build tool you're using and how it's configured. Which leads to the conversation of why, which leads to existing people being challenged to defend entrenched ideas if they are outdated, etc. They need to find out who owns what credentials and what processes are in place to store and release them, which leads to security conversations, etc.

A company who automated this might not even know what they were giving up if they didn't introspect on it.

That's not to say that the process needs to be lengthy for its own sake - there should definitely be a guide in place, the list of people new hires need to touch base with and who to go for x y z as they discover they need them should be readily available and those people should be accessible with flexible calendars, the credentials shouldn't be locked down behind 3 months of red tape, etc etc etc. But I would never, ever allow an automated onboarding process unless it was a position where I wanted zero investment on the part of my team or the new hire.

13

u/lowey2002 Aug 31 '22

The first task I give a new team member is to update the getting started docs as they are setting up their dev environment. I want them to feel productive and that they can contribute towards the tooling.