If your developer labor force is interchangeable (you can fire or replace someone easily) then you don't have to care about DX. If your labor force is not so interchangeable, don't copy the practices of places where that is the case.
I disagree. Create good developer experience, and developers can be "interchangeable" (work on each other's code more easily). Poor developer experience and you'll ensure only that team has any clue how to run their crazy build tools + dev env.
Good developer experience doesn't make developers interchangeable. It reduces the roadblocks (cognitive, technical, and aesthetic) that makes a developer's job harder, which means those same developers can get their job done more quickly.
In product-speak, it makes it more likely your product is adopted broadly.
Microsoft used to understand this. Visual Studio, VS Code, and the Linux subsystem for Windows are some of the outcomes of this understanding.
Our labour force and developer experience is like a rusty bucket. If we hire any old person quick enough it'll replace the pissed off people leaking out the holes!
Has anyone ever seen such a place in practice? what were they doing right? I've seen this claimed a few times before but it was always wilful blindness + not measuring anything related.
Things that I have experienced in the past, that as a whole impacted my developer experience. This is especially important when you join an established project and there isn't really room for improvements and only room for cranking out new features:
* No local dev, push to AWS and test
* Local dev only with console.log / println! / cout / ...
* No ability to attach a debugger
* No PDB / map files in production
* No automated smoke testing
* Always sprinting with deploys every 2 weeks
* No linter / formatter / ... enforced on PRs
* A history of PRs where the only comment is 'LGTM'
* Security rules set up company wide without taking into account Developer Experience (e.g. Local Admin on Windows)
DevEx reads to me like DevOps or platform engineering, etc. - its something that FAANGs care about with 1000s of developers but is probably a waste of time if you are not at that scale.
Early in my career, I worked on a team of 6 in a small division (acquired startup). We really cared about DevEx and built a set of tooling that allowed us to build and ship insanely fast (while still maintaining a solid CI and PM approval process for every feature). We astonished the rest of the Megacorp that was enmired in Byzantine process-what took them weeks took us hours. Sure, we shipped a bug from time to time—it was trivial to rollback, fix, and push. For them, shipping a bug was disastrous—it took so long to roll out fixes and rolling back was impossible. So naturally, the answer is “more verification.” They start chasing after the impossible dream of “0 bugs shipped.” In this case, a bad DevEx begets worse DevEx, and a software lifecycle that is trapped in a tar pit.
Unless you plan to go fast, you'll just keep getting slower and slower. And slow feedback is bad feedback.
I see lots of people adding slow tests to already-slow test suites and thinking they're helping. They are not helping. They're only making the problem worse. Those are often the same shops that measure "test coverage" in number of test cases.
DevEx encompasses both of those practices, in my opinion.
I’m the DevEx lead at my current company, and I’m in the process of standing up platform engineering as a practice.
My company doesn’t have 1000s on developers (200-300).
It is still worth spending time in those practices in order to reduce manual effort, increase self service and keep the average developer focused on what matters: writing code.
Elon Musk, in a tour last year mentioned SpaceX’s philosophy that “a high production rate cures many ills.” [0] That’s really what DevEx is about. Whatever you are building, you will get it wrong. The faster you can iterate, and the less you can care about each iteration, the faster you will eventually get it right.
SpaceX has INSANELY smart people that work there because they want to make rockets. You can't take anything from SpaceX, with that kind of access to brain capital (including literal rocket scientists, but also overqualified people at every level working for peanuts because it's their dream job) and extrapolate from it.
Now if you want to take Toyota's approach which is similar (but includes things like how to make it happen via management and process, not sheer force of will and access to huge brain capital) you have something worth paying attention to.
reply