Read on Twitter
Developer experience is tied at the hip with the codebase structure, architecture and other aspects that do not fall under the traditional scope of "dev tools" teams. So it’s important for devxp to take an active role in groups that makes decisions about the codebase itself.
This might be obvious to many folks here. At the risk of preaching to the choir, I wanted to record this thought and expand further with some concrete example in this thread.
In devxp surveys, we often hear - “make build times faster please!” or “our CI checks are a flaky mess”. These are valid concerns and are absolutely within the scope of problems that a developer experience team should be striving to improve.
Thankfully, we can use tools to improve the state of the world: switch to a build system that supports remote build caching, roll out a system that automatically suppresses flaky tests, parallelize CI checks, optimize the type of hardware we do local and CI builds on, etc.
These tooling changes are easier to make and more impactful with some codebases than others. This is where the collaboration between devxp and engineers working in the codebase comes in. Some of these codebase traits are:
Modularization: monolithic codebases are slower to build, no matter what kind of hardware/optimizations you throw at them. Iterating on a small logical module is more pleasant than having to recompile the world with every change. It also requires nuance and good tooling support.
App architecture: that accounts for separation of concern makes tests (and not only tests) easier to write. The tests are smaller, faster to execute and more reliable.
When the above tests are flaky, they’re more likely to be independently flaky (as opposed to systemic flakiness related to shared state), making them easier to manage with tooling. This improves both the local dev cycles and getting code merged into the mainline branch (i.e. CI).
Consistency: makes the developer experience of onboarding more pleasant. It also makes large refactors easier to do with tooling rather then heroic cross-org efforts.
Choice of language: can have a huge impact on build times (see recent threads about Uber iOS rewrite), but modern languages also improve productivity and safety. Having visibility into the tradeoffs you’re making is key here, but some problems won't surface until you scale.
I’m sure there are other examples (please share if you have them!). The next question is - what's the best way to enable this collaboration? But that's for a future thread (though, again, I'd love to hear people's thoughts on that, especially if you work in a larger organization)