Thanks a lot for this article. There's so little content out there still discussing the practicalities of DX work.
We've been scrabbling trying to see what insight we can get from metrics - there's a deep desire to be data-driven in our approach, but a dearth of useful data. Particularly gathering DX data for internal platforms seems to be quite a lot more difficult than for external facing systems. The number of customers is so much lower and it lends itself more to direct contact that objective measures of behaviour.
In that context some of your ideas here are exactly where we ended up, we're specifically restructuring our documentation to provide more direct answers to the "how do I?" questions and trying to establish a pipeline from support requests to documentation solutions (as well, as code solutions, of course).
It is deeply gratifying to see others coming to similar conclusions and to increased the shared knowledge in this space.
I love the idea of internal developer tooling teams, but I wondered if exactly what you mentioned was going to be a problem.
Even documentation seems silly to take a data-driven approach. All documentation, particularly externally facing documentation, is a value-add to the business.
Another option for internal is how fast or how friction-less onboarding developers is. Could be new developers, junior devs, or if you run some kind of rotation. Are you scoping or sizing less time/effort to onboard?
Funny you should mention that - onboarding time/complexity is our most pressing issue right now. Documentation is part of the problem, but automation is a bigger one. Setting up DX as a function and taking responsibility for discovering and fixing these kinds of problems is, in and of itself, the closest thing to a silver bullet.
FWIW, this is my second internal DX role (we actually called it DevCare last time around) and it's fair to say that the problems are quite different, as are the organisations. It strikes me that the way of thinking and the ownership of the domain are what matter most.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hi Amara,
Thanks a lot for this article. There's so little content out there still discussing the practicalities of DX work.
We've been scrabbling trying to see what insight we can get from metrics - there's a deep desire to be data-driven in our approach, but a dearth of useful data. Particularly gathering DX data for internal platforms seems to be quite a lot more difficult than for external facing systems. The number of customers is so much lower and it lends itself more to direct contact that objective measures of behaviour.
In that context some of your ideas here are exactly where we ended up, we're specifically restructuring our documentation to provide more direct answers to the "how do I?" questions and trying to establish a pipeline from support requests to documentation solutions (as well, as code solutions, of course).
It is deeply gratifying to see others coming to similar conclusions and to increased the shared knowledge in this space.
I love the idea of internal developer tooling teams, but I wondered if exactly what you mentioned was going to be a problem.
Even documentation seems silly to take a data-driven approach. All documentation, particularly externally facing documentation, is a value-add to the business.
Another option for internal is how fast or how friction-less onboarding developers is. Could be new developers, junior devs, or if you run some kind of rotation. Are you scoping or sizing less time/effort to onboard?
Funny you should mention that - onboarding time/complexity is our most pressing issue right now. Documentation is part of the problem, but automation is a bigger one. Setting up DX as a function and taking responsibility for discovering and fixing these kinds of problems is, in and of itself, the closest thing to a silver bullet.
FWIW, this is my second internal DX role (we actually called it DevCare last time around) and it's fair to say that the problems are quite different, as are the organisations. It strikes me that the way of thinking and the ownership of the domain are what matter most.