About a day. We have about a dozen external dependencies (databases, caches, front end build systems, etc), custom scripts to set up/populate some of the data

About a day. We have about a dozen external dependencies (databases, caches, front end build systems, etc), custom scripts to set up/populate some of the data stores, and even some third party tools that need to be custom-compiled on every system. We don't use Docker. So it's not as if setup is trivially simple. But with a clear and specific guide, anyone who isn't terrified of the command line can follow along. Since we added docs, the only person who wasn't working on their first ticket by the end of day 2 was an intern. When I came on we didn't have docs, and setup time was closer to a week. Depending on just how low-hanging the fruit is that we can point the new developer at, most have a bug fix in QA by day 4. Since we grow slowly and turn over slowly, it's really not a huge deal to have the new person spend a day setting up their environment a couple times a year. It gives them a little insight into how the infrastructure fits together, and an excuse to interact with the team when they need to ask for help (being referenced once or twice a year, the docs are invariably just enough out of date to occasion a few error messages) and discover that we are in fact friendly and helpful. The best also ask why things are the way they are and gain a little insight into the history of the codebase and the areas that we know are clean or messy or drowning in tech debt. Are you growing so fast that you have new hires setting up a dozen new development environments from scratch every month? Then yeah, it's probably worth a week of developer time to decrease setup time from 12 hours to 2. If you're growing at a more reasonable pace - even a new hire every month - the ROI is probably not there.