PS: this is a First Draft - brain dump of the sub topics I want to explore
DX is multi-faceted. You’re gonna have to measure a whole lot of quantitative, and qualitative metrics to get a full understanding of your dx
- That said, we’ll be looking at both the technical, and cultural side of DX.
Context
This series of notes will likely focus on internal DX, as that’s what I have most experience in.
- Improving collaboration and productivity within your teams and the context of your company
- Ensuring your technical practices are aligned with business objectives
Topics
- Onboarding
- Whenever someone new is onboarding, they’re a very good candidate for collaboration
- How much of your onboarding is self-service
- Speak to the 2 week threshold I’ve experienced
- How much of onboarding should’ve be self-service vs assisted?
- Keeping docs up to date
- Dan North’s Red carpet philosophy
- Trying to minimise the time/cost between a new dev joining the team, and being productive
- Stay Saasy - Optimize onboarding
- typical time to first pr.
- time to first ticket? feature? what metrics can help you get the pulse on the quality of your onboarding?
- why is it important
- readwise has a bunch of articles. this is worth its own note at this point😅
search queries:
"onboarding" || "dx" || "developer experience"
- What is DX
- Why does it matter
- Fast Feedback loops
- also go into detail about the different kinds of feedback loops
- technical: local dev, ci,
- social: human interactions: dev to dev collab, dev to qa, dev to product, dev to design, dev to rest of company
- Types of cognitive load, and how you can reduce them
- How this ties into complexity
- this might be redundant. one of the core ideas of improving dx is reducing cognitive load associated with delivering customer value
- There could be some trivial examples of increased cognitive load associated with everyday development that we aren’t even aware of
- Where does platform engineering fit in
- Tools to increase dev confidence when pushing, merging
- Local experience
- Pull Request process
- Deploying
- iteration velocity increases with improved dx. Dev interuppted podcast or the substack will be good reference. accelerate is also a good source to reference
- Are there manual steps pre/during/post deployment that slow the process down?
- What other areas of the sdlc can be worked on?
- Tools not limited to development, e.g., tools for comms (Slack, Teams, Discord, etc.)
- Effects of scrum/agile processes on DX
- “All software systems are sociotechnical systems”
- Collaboration between devs and QA
- How would you describe delivery efficiency? & how does improving developer experience help here?
- Loom by John Cutler semi related to this topic
- Improving DX can reduce developer burnout
- devs actually want to ship. it feels good & has a restorative nature.
- On Finding out how to improve DX
- Talk to your devs. those closest to the work. they’re well aware of the friction
- Surveys & polls. keep these short & engaging. & actually action out stuff based off the feedback, if you don’t want to see engagement fizzle.
- Motivation: for engineering, business, product. what will investing in our DX do for us?
- Tools: Daily communication & knowledge documentation
References
- LeeRob
- What is DX
- DevEx: What Actually Drives Productivity - there’s a few highlights in my readwise that could be good to cite.
- https://podcasts.apple.com/za/podcast/legacy-code-rocks/id1146634772?i=1000611333019
- https://open.spotify.com/episode/4kvwFx913BZZl9Ggroz7W7?si=28e61ce4766647cb
- https://open.spotify.com/episode/7ommJx6HsS65WwHYIVcLPu?si=6d3e8b96539448ca
- https://podcasts.apple.com/za/podcast/thoughtworks-technology-podcast/id881136697?i=1000631830296
- https://podcasts.apple.com/za/podcast/corecursive-coding-stories/id1330329512?i=1000633456580
-
- worth taking notes on this vid.
Acknowledgements
- Shot to Tyler for helping with this outline so far
https://www.youtube.com/watch?v=YkOGZCYWT6w
- you’re trying to make it easy to:
- onboard
- build
- test
- debug
Guiding principles
- Flow state
- You know the feels here, being fully immersed & engaged in your work for a few hours.
- Your processes and company culture can have a huge impact on this. How often are your developers ‘interrupted’, and for what? It’s good to regularly do cost benefit analysis on this
- Cognitive load
- Feedback loops
How to get started
- Talk to your devs. Surveys are helpful here
Side-note
- Introspect on, & iterate your process/SDLC as you would your product, & business.
- This is where regular surveys with devs comes in
SDLC is part of DX
The process of how something goes from idea to production has a big impact on DX. Some guiding principles, heuristics, questions:
Stay SaaSy - Optimise onboarding
I asked the authors:
I’m curious, why do you think onboarding is one of the highest ROI periods?
Response
Onboarding is high ROI for many reasons, for example:
- It sets a tempo for the job. People get in routines and if your routine is suboptimal to start, it can be hard to dig out of.
- Things can get challenging around the first performance cycle if you don’t start strong (e.g. within 12 months). A bad score there can impact morale and further change your course.
- Then there’s complex impacts like when yearly planning happens, e.g. your team might decide they need someone strong to help the team if you haven’t started off very well. Then you can suddenly be sharing leadership of a team that hinders your development. First impressions matter!
For all these reasons and more, starting strong is important.
Related reading
Patterns of Effective Teams • Dan North • GOTO 2017
5 Jan 2024
- DX is a high leverage activity. Simplifying onboarding is part of improving dx
- the effect of man hours saved adds up, when multiplied.
- you want your devs to spend more time on things that actually matter, ie the product. And less time on ‘fighting’ their tooling, dev environment, and process