I just joined a new team as a lead and #2 is killing me, to the point where I have felt like giving up. The documentation my team was given was a hastily thrown-together hack that was full of missing and incorrect steps. It should not take more than a few days to set up a
local development environment, but I’ve had to fight for admin rights, ask a million questions, and have other leads work with me for days on end (who themselves struggled with their own dev env). These are not very hard problems to solve, but they do take time and dedication. I’ve been on many other teams where I was either given a pre-configured VM image or I had comprehensive, clear set up instructions, allowing me to be up and running in hours instead of weeks.
This is also a project management issue. Too many times, PMs or tech leads are not at all technical and have little to no comprehension of the complex environments they oversee nor “technical empathy” for the engineers. It matters not to them what can empower a developer or make them more productive, and too often devs are told “you’re a developer, you should be able to figure it out” or “just use the tools we gave you”. Some of this
does come from heightened and constantly changing security requirements that everyone is expected to blindly implement, but there is also an inherent laziness where leadership doesn’t consider what those kinds of changes mean for everyone involved.
Many, many projects needlessly waste ridiculous amounts of time and money on these issues.
Yeah, it's crazy to me how common it is to just let basic dev environment polish languish.
In a small enough place, I usually will just fix whatever is slowest and most annoying about it myself.
At bigger places... good luck. Sometimes you can get away with hacking together some scripts that do things for your personal setup, but if there isn't buy in to fix the problem you're often out of luck.
But I think this one point is the one item that ultimately decides on the lifetime of a project and whether it will turn legacy. If the README doesn't even describe how to start the project or successfully invoke a single unit test, how is anyone going to deploy this or change anything of the core code? Also not having this usually means unreliable deployments, broken CIs and constant firefighting. This might be considered acceptable for 1-person-projects until that one person might change projects or jobs.
This is also a project management issue. Too many times, PMs or tech leads are not at all technical and have little to no comprehension of the complex environments they oversee nor “technical empathy” for the engineers. It matters not to them what can empower a developer or make them more productive, and too often devs are told “you’re a developer, you should be able to figure it out” or “just use the tools we gave you”. Some of this does come from heightened and constantly changing security requirements that everyone is expected to blindly implement, but there is also an inherent laziness where leadership doesn’t consider what those kinds of changes mean for everyone involved.
Many, many projects needlessly waste ridiculous amounts of time and money on these issues.