How to take care of the developer’s experience?
If you look up “experience” in terms of software development you will find that there are two areas: external and internal experience.
Almost every company is focused on external experience during development. Generally, it’s pretty natural because we want to provide our users with the best, simplest, and most useful product.
At the same time, only a few companies are focused on internal experience. In my opinion, it is just as important as external — but this will be a great candidate for another article :)
In this one, I would like to focus on a small part of it — Developer Experience and our approach in handling it.
Growth challenges
Most product developers in Docplanner are focused on creating an awesome user (patient/doctor/facility) experience. They shouldn’t be constantly blocked by code complexity, or have to go through a lot of trouble to create some simple features.
A long time ago when there were just a couple of us in the IT department, we didn’t have these problems. As our product evolved and the company expanded, though, creating new features from the developer’s perspective became more and more difficult.
After spotting this problem we decided to create a team that will bring focus to the Developer’s Experience — the Development Quality Team. As the DQ team, we try to understand what developers are struggling with the most and seek to optimize their experience using various methods.
How to provide a good developer experience?
When we were talking about Developer Experience (shortly called DX), we found out that there is no golden ratio and that you need to think about your company’s challenges from the developer’s point of view.
We know that to provide the best DX, we will need a lot of help from both Devs and PO’s, especially with gathering information to help us shape our DX strategy and build our roadmap. We need to focus on using the developer’s feedback and data to help us accomplish this.
We started with building our manifesto and we wanted to show what our role is using the key perspectives shown below.
From the Developer perspective:
- provide support for modernizing our tech stack
- make the local development environment fast and easy to maintain
- help with monolith modularization and moving to a microservices architecture
- simplifying solutions that we already have
- provide fast and stable CI
- promote legacy cleanups and fight with the mess
- provide workshops/learning materials
- provide internal tools to achieve above
From the Product Owner perspective:
- supporting product teams in a matter of methodology and technology
- Ad Hoc consultation
- Part-joining other teams to help with conceptual work and plan
From the SRE/DevOps perspective:
- providing support with infrastructure development
- systematically upgrading tech stack
How we found out what to do
We know that generally, we have two potential sources of information: subjective and objective. Subjective data is collected from developers, POs, SREs. Each product team has KPIs and current issues to solve but the DQ team has to look at this globally and try to collect and prioritize topics from each product team.
Objective information is all data that you can collect from the application and infrastructure analysis. Most of our areas are CI/CD time, static analysis, performance, code quality, coding standards, and vulnerabilities.
Subjective pieces of information:
- Gather developers’ feedback
- Talk with POs about current and future projects
- Join product teams and gather information from the source
Objective pieces of information:
- Main application CI/CD time — set some reference value for the process and along with DevOps monitor it and take actions if it increases above our pain value.
- Main application legacy logical lines of code (LLOC) and complexity — I think that this is pretty clear. We need to clean and promote cleaning no longer supported old code from the monolith.
- Amount of main application bugs
- Code in modules — right now the monolith is pretty chaotic and difficult to predict on a daily basis, especially its stability and scalability.
- Number of vulnerable packages — this will indicate our progress in improving the dependencies management process
Team
Looking at our responsibilities you can say that there are a lot of them — and you are right. We are facing a lot of problems, challenges, and new things. However, we have a great team with amazing, experienced people inspired by a passion for tech.
Right now, the Development Quality team consists of seven developers — 4 backends, 2 frontends, and 1 full-stack. We are divided into shared areas like code quality, security, and performance with common goals that have an impact on developer experience.
Real use case
In the early phase of developing our team’s strategy, we found that DX is all about developers and their product team perspective: how constraints influence their productivity and efficiency. First of all, we know that we need to focus on bottlenecks with product evolution in our core domain — bookings. This is the place where all magic happens, the strict connection between patient and doctor. Along with the patient booking team, we started to talk about current constraints and future plans with the product’s evolution. After that, we were ready to build a common route map with goals, focusing on real problems.
A Few Words at The End
A couple of months ago we introduced the above methodologies and we are trying to constantly monitor their effectiveness. We are aware that in such a dynamically changing and evolving place like our organization, our activities must change together with the company. In the end, what matters most from our perspective, in a day to day work is the developer experience and how we can positively impact their efficiency and productivity.
