After writing code for a few different projects over the last decade, there are some things I have observed.
Most teams have an onboarding plan.
Most teams have a ton of resources for a new developer coming onboard. These can include documents that explain the technical architecture of the system, the processes used by the teams to collaborate or make changes, on-call calendars, machine setup instructions, and so on.
Most teams assign a mentor. The mentor is ideally supposed to navigate the new joiner through their joining experience.
But most of the time, even with these things in place, I have felt either overwhelmed, lost, dissatisfied, bored, or worst, all of those. I have not been able to pinpoint the reasons for this.
After thinking about this some more, I have come to realize that I don’t really like reading a ton of things unless it lies in my area of interest, or unless it is to solve a problem I have run into.
I have loved AWS for quite a while now, but it was not until I started getting professional questions about it, did I start to dive deep and went through an associate architect certification.
I have been curious about functional programming, but not until I joined a team that uses only functional programs, did I start to really compare object oriented and functional design patterns.
I am unsure how many developers feel this way. But having realized this for myself, I now try and go in with a plan of action.
When possible, I have started to either refactor, or influence refactoring, the Day 1 experience of a Developer.
Then tried to refactor the Week 1 experience.
And then tried to ensure a Developer’s journey is as smooth as possible when getting started, and beyond.
Even if I am not around with the team anymore.
I am uncertain, but maybe this process is called “DevEx” or just "DEx" (Developer Experience), I like "DevEx".
So, what do I do for “DevEx”?
Well, for me, the goal is to create a simple exercise for the new joiner.
The exercise takes the Developer from making changes to a mock system that mirrors the architecture of the target system the developer will interact with, at a smaller scale, and exposes them to all the processes and access needed to get a change into the system.
The exercise provides the bare minimum setup and steps needed to take a task all the way through.
This ensures they get or seek information, only when they need it. They would still be referring the documents in the onboarding plan, but now they will be reading them with a well-defined context.
This way we ensure they have a clear destination to drive towards, with speed limits and rest areas they can look up.
My opinion is teams with better “DevEx” would ultimately be more productive. But absent any statistical evidence, I would just say I have always felt good after taking a task from concept to implementation. And with this exercise, my desire is for others to experience the same.
Since the challenge to onboard someone is not new, and to quote my favorite author, I don’t want to “teach birds how to fly”. I am sure you have your own way of making the developer’s success a priority. So, in that spirit, what are the ways you have onboarded your developers?
How do you do “DevEx”?