So, like me, you develop software. Either you write back-end, front-end, or both; you can resume your days in writing dozens of lines of code in a language built by aliens for aliens (in a good sense 😁), day after day; you and your team create incredible products and make your employer happier and successful when things go well in time.
But not all the glitter is gold everywhere, all the time. Sometimes, you join an organization where you can only feel tired at the end of the week or month, tired of skidding on ice to the point of feeling your legs hurting but realizing that effort didn’t make you go as far as you could. You didn’t deliver the things you wanted; you still think you need to accomplish your mission. You feel you have failed. It can affect your self-esteem or, more seriously, bring the haunting ghost of impostor syndrome. So why does this happen to so many developers? Why are they so stuck and unable to express their creativity through what they do best?
We hear a lot about how important it is to make attractive and intuitive user interfaces and how customers value software engineered with thinking in ergonomic usability, strategically well-placed data, responsiveness, and simplicity, which we can sum up as UX or User Experience. , the reason why most of the software companies have dedicated professionals to handle it.
But what about companies start looking at the pillars nobody gives the rightful value? DX,or Development Experience. Developers are persons (ok, some are robots). As persons, we want to extend the joy and passion of life to our workplace and our craft.
Development tools, languages, and frameworks have improved enormously over the years to give us all sorts of automation to save time instead of writing tons of boilerplate code repeatedly, giving us instant and, more recently, intelligent feedback with suggestions to make us more productive. However, developers are still blamed for not being as productive as they are supposed to be. Why?
What is DX?
Making a parallel with UX, the DX or Developer Experience is the experience we developers have on how easy or complex we can perform our work. Over the years in our software engineering careers, unless some devs are building a start-up or only worked with greenfield projects, we usually join many companies with already consolidated solutions and corporate culture. We rapidly become users (or internal clients) of others’ code and procedures. Most of the time, the original authors have left the company for a while.
What is the pain of poor DX?
Imagine you just joined a new company, fueled with enthusiasm as it should be. You now have to spend days or months onboarding and learning about procedures, APIs, and frameworks, sometimes in-house (aaargh) ones; you have to read pages and more of documentation and ask veterans how and why things are the way they are. Sometimes, dealing with some dev divas with big egos will steep your learning curve.
It is very common you have to unlearn what you know well to adapt your mind to new tools and ways of doing things. It all takes lots of time and energy. After some months, even after all this effort and time, if you’re unlucky enough to have landed a company with very poor DX, you will still feel like your feet are in a mud puddle; the development experience is terrible, and you can’t perform.
As a developer, I would choose empathy if I had to define DX in one word. When being empathetic, you put yourself in the shoes of others; you worry about how other developers will feel by understanding, using, and maintaining your code, reading your documents, and following your procedures. You want your peers to feel productive and empowered. You want to make their experience using your art as enjoyable and intuitive as a beautiful and self-explanatory user interface could be.
The days of being a non-replaceable nerd who writes unintelligible code that makes everyone else a hostage of an evil genius are gone for good. We have to showcase how good devs we are by making the hard things look and work as simple, not the contrary.
Symptoms of bad DX
- Overengineering simple things: If a simple change in the code requires knowing rocket science, it won’t skyrocket.
- Excessive obsolescence: Being underproductive because of obsolete programming languages and tools is like a good pilot driving a terrible car. Staying tuned to updating tech and methodologies is crucial.
- Faulty collaboration culture: We don’t need to be friends to act friendly to our colleagues. Being truly helpful is the first step to building trust and long-term relationships. Remember,
emphaty! - Hierarchy over skills: Not having the autonomy for proposing intelligent changes when it’s due because someone with a higher hank but a poorer technical vision (this exists a lot) dictated something should be done that way in detriment to a healthy and sustainable solution, makes you question why you were hired after all.
- Bad management: More often than I would like to see, agile methodologies are used as disguises for
micromanaging and scope creep. Estimates are often taken as contracts carved in stone, and “resources” are allocated or reallocated without a careful plan about their skills and preferences. Also, constant distractions and unnecessary meetings (that could easily be an email) are productivity killers and don’t consider the residual effects they cause to the dev’s “zone”. - Excessive bureaucracy: Alongside outdated tech, being strongly dependent on other people or restrictions to set your infrastructure makes it everything very slow and sometimes even blocking. Big techs and banks suffer more from it, I know.
Some steps for providing a better DX
- Reducing ramp-up: Good Onboarding, clarity, and transparency are crucial for knowing the environment well and what we can do to improve it constantly. It takes months for an engineer to achieve full productivity, but this time can be shortened with good DX.
- Clear documentation: Relying on updated and well-written documentation can speed up onboarding and ensure knowledge sharing democratically to everyone.
- Standards that make sense: either for the codebase or internal processes. We love meaningful and clear standards.
- Modern architecture: Designing architecture with modern patterns that best handle the project needs empowers developers and gives them the feeling they’re not becoming deprecated.
- Good test coverage: A good testing culture helps keep others’ work working, with better client feedback and an overall healthy development environment. Writing a good suite of tests may take development and delivery longer, but this time, it pays off in a crescent productivity trend.
- Pipelines / DevOps / CI/CD: Automating things saves us time, allowing us to focus on what matters and ensure consistency without constant surveillance to ensure that developers follow development or deployment rules. Automation will always be the most sustainable option.
- External resources: Using modern APIs, SDKs, libraries, well-maintained open-source repositories, specifications, and relying on open standards can reduce the learning curve and increase productivity. Do not reinvent the wheel!
Symptoms of a good DX
- Faster deliveries: If you can master the tools, processes, and domain of your company rapidly, you can build things quicker and deliver more in less time. Startups are often shut down due to losing the timing.
- Motivation: When developers know they can count on each other, on their management, and on their tooling, they automatically get a motivation boost to give their best.
- Company’s longevity: With well-designed code, good documentation, tangible processes, and proper automation, operational continuity is safe if one or many developers leave. Acquiring and training new talents to continue propagating its healthy culture will be easier.
- Good reputation: There’s nothing better than referring the workplace you love to a professional you trust. A nice workplace is to be remembered, while terrible ones deserve to be forgotten.
Final thoughts
I hope you liked my sincere take on the subject, tailored based on my experience over almost two decades as a software engineer. You can significantly impact your organization’s culture by improving the overall DX with your existing tools and people. Developing good software is already hard enough. Let’s build the community we deserve.