Software development is an inherently humans-based, intellectual activity.
The developers are an integral part of an organisation and a human quanta to deliver business value. He/she is a consumer of the organisation's tools and processes to deliver business value.
While generic tools and techniques for achieving productivity and good experience are all over the internet since genesis, I have been fascinated by developer productivity/experience for the past 1.5 years, and recently I decided to go fully down the rabbit hole and explore everything I possibly could on developer experience.
I have collected my experience in software development and have spent hours reading articles, listening to podcasts, taking notes and trying to link the knowledge together in a coherent way. Finally, I distilled my thoughts on developer experience down into a short essay for you to enjoy.
Before we dig deeper into developer experience, let’s understand what an Ideal day looks like for a software developer with good developer experience.
- If your organisation is following Agile methodology for driving the project, then usually the first thing you do as a developer is to attend standups, where you share, what you have done yesterday, What you are doing today and what are your existing blockers. And from this first activity of the day, your experience at work starts.
- Once you are done with stand-up, you get on with your development activities for at least a few uninterrupted hours. You will resolve queries of your managers and consumers of your software/service in parallel by directing them to the documentation you have for the service.
- Once you are done with the code, you will test your code and get immediate feedback on the test it its integrations.
- You will take out some dedicated time to help junior developers in your team to proceed ahead in their development using guidelines and best practices the team is following.
- You deploy your code in the environment using an automated pipeline into the respective environment for other teams to test or use it. Once testing is concluded you have to deploy the code in production using continuous deployment.
- By end of the day, your will wrap up your work and leave the day, with a feeling of achievement and a meaningful contribution to your team.
Reality check: Typical day for a developer. There is some truth in it based on the organisation's adoption of developer experience. Hope you can relate to it
- You as a developer start your day with standup, stating your progress on stories you are working on.
- You call out your blockers for the fifth time in these standups. Since you are dependent on other teams to unblock you and the issue you have raised is not of priority for them, therefore you are still blocked
- Your team members are progressing ahead with their tasks, which gives you a feeling of being left behind
- Once the standup is done you try to reach out to the team you are dependent on for the 100th time, and it seems to you that they have put you on ignore. The feeling of frustration is increasing.
- You reach out to your team members but they are so overloaded with work items that they have no time to help you.
- There is no documentation you can follow to resolve the issue by yourself.
- In parallel, you are pinged by your manager to resolve his queries, since you are blocked you cannot be of much help.
- By the end of the day when you are warping at work, you feel demotivated and frustrated.
Now we have explored two ways of working mentioned above.
To say we can achieve the ideal state of great developer experience in one go, would be an overstatement. But instead, we should strive to achieve it through iterative improvement.
Before moving further, let’s understand what developer experience is and why you need good developer experience.
What is Developer Experience (DX)?
For me, It is an experience that which developer goes through in the system from onboarding to development to pushing changes into production and then supporting it.
I consider them as customers of the environment they work in and the tools and processes they use to do their job, it relates to all kinds of artifacts and activities that a developer may encounter as part of their involvement in software development.
Why do you need a great Developer experience (DX)?
Competition for Talent: Developers are more in demand than ever.
Companies that sensibly manage their investment in people will prosper in the long run.
With demand still so high, developers are expensive, hard to hire and difficult to keep.
Why would a developer put up with a poor developer experience when they can likely find a job that better aligns with their needs and preferences?
Retention: Organisations with good developer experience are more likely to be recommended by employees to their colleagues, peers, and friends.
Productivity increases: providing a good developer experience is one of the best ways to increase productivity within a dev team. Among other things, this means allowing developers to focus on the day-to-day work of building the products without any distractions.
Time to market is faster: because of increased developer productivity, work is done more efficiently. It speeds up the process of launching new products or new features on the market.
According to McKinsey’s 2020 study, “companies in the top quartile of the Developer Velocity Index outperform others in the market by four to five times”. A positive developer experience can bring multiple benefits to your business.
Now that we have a point of view of what developer experience is and why we need it, let’s understand the factors which can impact developer experience.
Factors which impact developer experience
Psychological Safety: Involving into the blame games if something breaks down, instead of capturing it as a lesson learnt which can be used to improve the system. Reduces the safety of the environment where one can fail and experiment with new things, ideas and innovation.
Empathy: Having a culture of empathy towards team members will lead to a safe environment where people will take ownership.
Leaders of the team should watch out for roadblocks and should not put pressure on the team to deliver their story points at any cost instead they should try to unblock the team from the roadblocks.
This is where the show tells of the team’s velocity can demotivate team members since the chart will represent low progression or in some cases no progress at all, but the fact is the team was blocked due to dependencies on the other teams.
Instead, we should have a chart of recurring blockers which in turn gives us an opportunity to automate and create a self-service experience to resolve blockers. And for those blockers which cannot be automated will allow us to size our stories better for the next iteration.
Poor Communication: How information flows within and across teams impacts the performance of the whole system. Working in an organisation where systems are dependent on multiple systems which in turn are dependent on multiple teams has reduced the transparency for knowledge sharing.
We should measure the way communication is flowing within and across the team.
The following are examples of metrics that may be used as proxies to measure communication, collaboration, and coordination
- Discoverability of documentation and expertise.
- How quickly work is integrated with other teams.
Flow: In order to achieve high-quality work, people require a state in which nothing else seems to matter; the state where developers are not interrupted by meetings and pings on communicator applications at work. It is important to set boundaries to get productive and stay productive, for example, by blocking off time for a focus period.
There is research that indicates it can take up to 23 minutes to get back into the state of flow and return to high productivity.
But, we should find a balance between individual productivity and collaboration within and across teams. A success of a system is a success of an individual and not vice versa.
Cognitive Load: It refers to the amount of working memory required to learn and get used to the process, tool and technology in an organisation. Lack of proper documentation of the process and technology introduces a lack of direction and frustration to come up to speed and start contributing to the team.
For example: If the development team is dependent on the other team’s good work, then there should be proper documentation and training provided to the teams who wish to reuse work done.
Feedback Loop: Feedbacks are the delay between actions and reactions for which an engineer or a team has to wait. Effective software development needs continuous interactions, collaborations, and iterations. There is one thing necessary for the collaboration- feedback as soon as possible. With fast feedback, there is fast dealing with problems and, therefore, the fast launch of the final perfect product.
In his research on developer effectiveness, Tim Cochran recommends identifying developers’ feedback loops and optimizing them by making them fast and simple. He found that “feedback loops for developers in highly-effective environments are significantly shorter than those in environments with a low effectiveness.“
Conclusion
There’s always more work to be done to make developers’ lives easier but in the interest of the reader’s time and length of this post, I will conclude this post by saying, organisations should facilitate developers to get their job done and get their creation into production as effectively as possible instead of fighting the system.
People will want to stay at your company for longer if they aren’t burnt out fighting against the process just to do their job.
