[acdha]

Two thoughts:

* in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production.

* building a cloud-based development where someone can refresh it automatically means you’ve identified a reliable process for installing and configuring everything. That same process can be run locally, probably using the same container definitions for everything except the parts they’re focused on.

[dimgl]

> in every single case I’ve seen, the developers who broke their local environments that badly had significant skill deficits which affected their general productivity. Investing in training paid dividends far beyond not having to deal with their local environment getting hosed since they also stopped creating massive security and performance problems in production.

I mirror this sentiment.

Another one that I've commonly seen: a bit of a yellow flag if a developer is struggling with Git. Becomes a red flag if the issues continue to happen after training. Usually means they don't understand other technical fundamentals.

[keybored]

A lot of developers struggle with Git. The only reason I don’t is because I’m interested in version control (too much according to some people I argue with).

Well I say that I don’t struggle but I’ve never had to use submodules.[1]

[1] Torvalds: people say that submodules is hard to use. True. But it’s gotten better now/it’s getting better. (Google Tech Talk 2007)

[acdha]

For me it comes down to how often something is holding you back. It’s perfectly reasonable for someone to only use the core Git operations, but if they’re losing work or having trouble collaborating that’s when I start to expect them to recognize that and try to improve.

[IX-103]

If you've never seen good developers bork their local environments then you clearly haven't worked on a large enough and complex enough project.

I worked on a large project that needed to support development on many platforms. The amount of scripting for the git hooks and build hooks alone required its own development team. When subtly incompatible changes in git hooks rolled out, you would see a few people that ran commands in just the wrong way to bork their repository. These commands are usually fine, but when combined with an otherwise invisible change in the hooks, would just break things. Now the actual breakage rate was low, like 1 in 1000 in a given month, but with as many developers as were working on this project that was always a couple of people that had to nuke their local repo from orbit (it's the only way to be sure).

[acdha]

Note that I’m specifically referring to breaking it in a way which is significantly harder to recover from than rerunning a known setup process (Simon’s comparison to a cloud environment where you could reset it on-demand). It’s not about never making mistakes, it’s about having a good conceptual understanding and habits around configuration management.