Creating a good foundation for a great developer experience
Created in Midjourney, https://www.midjourney.com/app/

Creating a good foundation for a great developer experience

This is a follow-up article to one of my posts I made lately that covered my recent and past experiences as a developer, software architect and staff engineer.

When working in a large organisation of software engineering teams building many complex products, I have found that there are some basic things that makes the lives of developers much more pleasant and increase developer happiness. As a side effect the quality and productivity is also improved. It's a win-win recipe.

The 'paradox' of complete freedom of choice

Freedom of choice is often perceived as something that will make developers happy. Of course it is better to allow everyone to use the tools and products they want to! Or is it really?

Leaving up to the team or even individual contributors to select programming languages, frameworks, platforms and architecture might seem like a good idea, but my experience is actually quite the opposite. From what I have seen over the years developers are not happier without boundaries and guidelines. Restricting the degrees of freedom on a certain level though, will boost developer experience and happiness.

That said, I think it is important to let developers decide on their own exactly how to solve problems on a lower functional and code level. No one likes to be told how to implement a certain algoritm or piece of code logic.

The helpers

I have identified 4 things that will help developers in their job by setting up guidelines and rules.

  • API Guidelines - API guidelines are best practises and rules about how to design an API. An API can be internal or external but should always follow these guidelines. This can either be a document developed in-house. Or a reference to an external standard like the Google AIP. The important thing is that it is followed and respected.
  • Tech Radar - A tech radar is a way to list different techniques, tools, platforms, languages and frameworks and the level of adoption they have by the organisation. This concept was made popular by Thoughtworks. The idea is to have a single place within an engineering org where developers can see what choices they have when selecting technology to solve a problem. It can be simple or very detailed depending on the requirements of the specific organisation. A tech radar is a living document that needs to be curated and kept up to date continuously.
  • Service Contract - A dear child has many names they say, but I have chosen 'Service Contract' as the name for this tool. Others might call it differently, but the idea is often the exact same. And the idea is to have a set of requirements that are documented and that a service or application needs to comply with to be allowed to be part of the greater software ecosystem in an organisation. This document can contain things like requirements on logging, tracing, metrics, communication protocols, documentation and security. But it could also contain more detailed requirements like how a service should be deployed and run in an environment. Other requirements I have often seen in this kind of document is requirements on testing of the code and things related to operations.

  • Golden Paths - Originally the concept of golden paths was founded at Spotify. And it is outlining the opinionated and supported way to build something. The golden paths are manifestations of the three other things in the list above. Golden paths are guides on how to properly implement a service or application and at the same time follow rules and guidelines that apply. Golden paths can be either written guides with examples, or fully fledged template projects providing most of the boiler plate functionality for a specific type of service or application. The idea is that if golden paths are followed/used when creating a new service or application there should be little or no work left to adhere to API Guidelines, Tech Radar and Service contract. Developers could start building value directly. Without having to spend much time on making sure they are compliant. Golden paths like everything else in this list need constant curation and changes to be up to date.

Choose boring technology

This by now pretty famous, and fun presentation by Dan McKinley makes a point about not using every new shiny toy you stumble upon, but as often as possible resort to using well known and proven (boring?) technology when building a solution. He makes a lot of arguments that makes sense to me, that I strive to follow.

Simplicity is the ultimate sophistication

A quote from Leonardo Da Vinci, meaning that simple solutions are better than complex ones. This can of course be applied to software engineering and is almost always true.

Wrapping up

I know that my views on this by some people sometimes is seen as controversial and backward-looking. Why would anyone want to take away the joy from developers to learn new things and use new shiny toys? It is really not about that at all. I do think that to be a good, or even great developer you need to constantly learn and develop as a professional. I do not see this as something contradicting at all.

There are times for experimenting, learning and looking at the latest in the market. But the time is not when you try to create value in building software that is secure, robust and reliable, and doing this with high productivity and top quality as a goal.


I hope this little writeup can inspire, upset or at least spark a thought with some of you ??

As always, I love all comments and feedback. Please share if you like.

(Opinions expressed are solely my own and do not express the views or opinions of my current or any former employer.)

/F


?????? Kim ?berg

SW Engineer | Opinion Leader | Public Speaker

1 年

Great writeup Fredrik. Enjoyed the original post and even more so this more elaborate take ?? Am definitely of the same opinion in terms of restricting some degrees of freedom being the way to go ??

要查看或添加评论,请登录

社区洞察

其他会员也浏览了