At one of my previous assignments there was a lot of focus on how to make and keep a developer happy. As this is a topic that I am quite passionate about, I would like to share some thoughts I have about it.
The “developer experience” can be a rather broad topic and what it should include will differ from company to company. I have managed to form an opinion about what I consider a good or bad developer experience based on the companies I have worked for.
When I started in IT back in 1996, this concept did not exist. You where basically stuck in a closet and forced to do your work. Thankfully the dot.com boom changed this, enabling developers to write their own salary cheques. Over time this has changed and now we have ‘The developer experience’!
Points I consider part of the developer experience are:
- Onboarding
- Mentorship/Guidance
- Tools (Software and Hardware)
- Documentation
- Autonomy (Giving them enough rope to hang themselves with)
- Team
Onboarding
No matter how experienced you are, your first day at a new company will always be a bit scary. Starting from “where will I park”, “will the people be nice”, “will I have proper hardware” and sometimes most important “will they have proper coffee”, it remains an exciting day. Often you can already have some insight into how it would go on your first day, based on the process of interviewing and accepting the job.
But unfortunately, no matter how much research you do upfront, what you get could be the total opposite of what you expected. I have not had to many bad first days, but have had better and worse ones.
So what would an ideal first day look like? This would significantly differ from person to person, but for me:
- Do not start too early.
- Arrange parking if not easily accessible.
- Make sure you have an individual responsible for the person on the first day. Greeting them on arrival. Things like, where do I find coffee, where are the toilets, somebody to have lunch with.
- Have a clear agenda for the first day (actually first week).
- Ensure it is possible to meet the team or part of the team.
- Issue suitable hardware and make sure all relevant permissions have been granted upfront. The hardware should be available and ready to use! Nice shiny and new!! Having to “unbox” it yourself can also be cool. Getting some other guys second hand hardware is never nice.
That is quite a list and requires some effort from the company that you are joining. Unfortunately, many companies do not give this enough priority and in doing so, create a bad first impression. And bad first days are the worst! Having a bad first day may also have a knock-on effect. When family and friends ask you how your first day was, and if you had a bad first day, this is information that will start spreading into the community. This could possibly cause somebody not applying for a position that the company might have in the future.
Mentorship/Guidance
This one is very important. Depending on the level of the new developer the effort required could vastly differ. In some cases a “tour guide” would be sufficient, in other an actual mentor type role would be required. It does not have to be the most senior member of the team, but a person that knows their way around the code, but also the organization. It is important that the person taking on this responsibility likes doing this and is well prepared. Again, this requires time and effort, but should not be neglected.
Tools (Software and Hardware)
There is nothing worse than starting at a new job and getting shown your workspace and being horrible… in every way! Worst spot in the room (at the toilet door or entrance) with your back to everybody entering. An office chair that dates back to before WWII. And then… that last pc, revived from the deepest darkest corner of IT support storage! Having bad hardware assigned should never happen, you do not expect Max Verstappen to win F1 in a Daihatsu Charade. Also ensure that you provide the best software available for the developer to perform optimally. When you sit down at your desk, the computer should be good, the desk should be good (and adjustable), good office chair (from this century) offering good support. Personally I also find the direction the desk is facing important. I prefer sitting with my back to a wall or at least have the desk pointed towards the most used entrance. Being the new guy, this would also help in seeing and possibly interacting with more people sooner. Many companies are now working in a hybrid mode (1 day office, 4 days home), so having an actual assigned desk becomes less important. But try to at least make the new guy as comfortable as possible while he is working from the office. This will also help in motivating him to come to the office more often and with pleasure.
Documentation
Biggest problem with documentation is, once you have it, to keep it up to date. I have worked at companies ranging from having a one pager to so much you get lost in it. I think this point also ties into the onboarding process. If your documentation about the company and tech is insufficient, at least try and make your onboarding documentation complete enough so that the new developers can use it while they are finding their way in the company and tech stack. Something basic like an email or page with the most important links already goes a long way. I have gotten used to always documenting my first few days at a new company. Tips and tricks, people, processes, etc. This is very valuable as it ensures you do not have to start new every morning figuring stuff out. This can also be a good resource to the company in providing feedback to what they missed as part of their onboarding documentation. As mentioned, onboarding documentation should not only include company information, but also technical information.
Samples would be:
- How do I setup my local environment.
- Code change procedures.
- Coding rules and guidelines.
- Team responsibilities.
- How to register sick leave.
What I have found most valuable is a guide on how to write a new application/feature within the new landscape. Basically an A to Z, step by step, guide to build your own app and deploy it and see it running. This again requires some work from the company, but in my experience is absolutely worth the time. Most developers get up to speed much quicker as they find it easier to “learn by doing”.
Autonomy
With great power comes great responsibility. This definitely applies to software development teams and autonomy. This is typically one of those things that if you have to little, it makes you unhappy, but having to much could be overwhelming. So what would the correct amount be? Like with all things software development related, it depends. It depends on the team setup, the type of work you are doing, level of trust between the team members, etc. In some companies it ends up being the internal processes that limits the autonomy of a team, but having inflexible team members can also hamper your personal autonomy and indirectly also the teams. I think teams should be free to build whatever they want to, if it could be properly supported by a relevant argument. But it is important that clear guidelines exist in terms of things like resources (cost) as with many companies moving to the cloud this very quickly becomes a bigger issue than anticipated. I would rather be helped by a transparent system or experts in the field, to ensure my application is running cost effectively than having to figure it all out by myself. But this again ties into having proper borders set which your teams have to operate within. And then also making it possible to “colour outside the lines” when it is needed, but with proper supporting facts.
Team
Working in a team of developers has never been easy. Basically your team can make you or break you, there is not really a way around this in my opinion. If all the members it the team cannot come to a mutually beneficial agreement, then unfortunately there are only 2 ways out. Become a sheep or find a better fitting team. I have witnessed too many times how one person in a team can change the entire dynamic and effectiveness of a team (for the worse). Just for management to say, “you need to sort it out amongst yourselves”. Being the person that makes the hard choices is not always pleasant, but part of the job. And if it results in less knowledge in your team, but making it operate as a well oiled machine, the decision should be easy. As all developers I also have some pretty strong opinions about what is good and what is bad. I have learned over the years that being open to new ideas and accepting other people’s way of doing things, make your life much better (You catch more flies with honey).
You can make a difference
In conclusion, the developer experience, we can all play a part in making this better or worse for others (and ourselves). Unfortunately, the responsibility begins with the company and it’s commitment to spend time and money on this. (As it is no small task and should not be underestimated). I am quite happy to report that more companies are realising that this is key to having happy and productive developers. Also open source frameworks like Backstage are helping in providing a starter platform for this.
With increasing developer responsibilities, pressure and expectations, it is essential to make and keep them happy!
