It should go without saying that being a professional software developer is not just about your ability to write good code. In most cases, you will be working alongside other people towards a common goal. How you interact with your colleagues, fellow developers or otherwise, is just as important as your coding ability. The following are my thoughts about what I’ve come to value in my own experience as a software developer.
Actively Share Knowledge
Knowledge sharing within companies is an important practice that has multiple benefits at both a personal level for each individual involved as well as for company culture as a whole. Knowledge sharing sessions can take many forms such as quick and concise ‘lunch & learns’, weekly tech talks, pair-programming sessions, or even simply writing out a well structured Slack post that can be shared indefinitely.
Just attending these sessions is good and will provide you with plenty of value, but actually taking an active role and sharing knowledge yourself could be just as valuable. By sharing your knowledge and experiences with your colleagues you go through a process of self-learning. This is because while preparing to present your content, you will get a chance to re-evaluate and solidify your understanding of the work you are presenting. Follow-up Q&As might also lead to interesting discussions that might inspire further research and future sharing sessions.
It seems that often the biggest obstacle for knowledge sharing is that you might think you don’t have anything worth sharing, but that couldn’t be farther from the truth. As a software developer you’re solving intricate problems on a daily basis and we often take it for granted that what we are doing is akin to modern day wizardry. The next time you are given an opportunity to take part in knowledge sharing, consider talking about some of these topics:
- Talk about a tricky bug that you fixed or a post-mortem for a nasty incident on the production environment. What was your debugging process? Perhaps you learned something new about the language or library you’re working with in the process. Did you end up doing something like CPU or memory profiling to figure out what’s happening? It might be that not all your colleagues have had experience with using such techniques and the information you provide could be invaluable to them.
- A library or tool you’ve used that you found useful. When solving problems we frequently check if other people have solved the same problem first; then we apply it to our problem and forget about it. By sharing what you’ve found you could end up helping a colleague who might encounter a similar scenario in their own work.
- Did you use a new design pattern or a new architectural style entirely for a particular service? Talk about it, think about how it can be applied to other domains within your company and discuss their strengths and weaknesses.
Look for Improvements Outside your Bubble
As software developers we have a tendency of sticking within our own bubble alongside our direct colleagues: other software developers. We discuss and solve technical problems together, usually specifically related to the task we’ve been assigned to. This isn’t inherently a bad thing, but we can do better.
Software developers have the expertise and skillset to look at any particular process within the company and find improvements. This should not be restricted solely to the projects that the company is delivering, but also to internal processes which everyone makes use of. There are opportunities for continuous improvement at any level of an organisation, even if you only make it 1% better.
How we achieve this will largely depend on the company’s structure and communication tools; some companies have fully embraced the power that a strong development team can bring by, for example, dedicating Friday afternoons to working on any improvements they would like to. You might not have the same autonomy to work on whatever you want to, but you can’t let that stop you from striking up conversations around improvements that can be made.
- Most organisations make use of a lot of different tools and platforms for their processes such as communication platforms and issue tracking systems. These products may have features which, at the time they were set up, either didn’t exist or weren’t used. This could be anything from direct integrations with other tools, a robust API that you can take advantage of, or even just some configuration settings that nobody ever looked into.
- Issue tracking tools can provide a lot of insight and opportunities for improvement. Look at other departments’ tickets and see if you can spot any patterns or frequent tasks which could be ripe for automation.
- If your company uses an open communication tool, take a look into what your colleagues in other departments are discussing. Start getting an idea of other business functions and what their processes look like. You might be surprised at how many opportunities there might be to improve their processes.
- Lunchtime conversations and watercooler talks are a great place to organically meet people from other departments and discuss what they work on and what problems they face.
Speak up if you Disagree
Workplace discussions are happening constantly in meetings, private conversations, issue tracking comments or in the company’s messaging platform. Software developers are no exception to this. We discuss architecture, libraries and frameworks, other languages, bugs, and much more on a daily basis. These discussions are great opportunities for learning something new, especially if you ever find yourself in disagreement.
When you find yourself disagreeing with what is being said, it’s important to understand where this disagreement is coming from. There could be many possible reasons, but staying silent won’t get anyone anywhere. In these situations you can speak up in order to clear out any doubts or confusion.
- Are there any assumptions being made you think are not valid? The other people involved might be thinking that these are reasonable assumptions, or perhaps they have some information that you lack. You might come to realise that your own assumptions are not valid.
- If you are disagreeing with priorities on which action points should be done first, explain why. Provide an alternative priority backed up with a reasonable explanation. There is often some common ground that works better for everyone.
- Do you think you have a better solution to the problem you’re discussing? Don’t dismiss or shoot down other ideas in favour of your own. Understand and validate those ideas before bringing up alternatives. Suggest where you think improvements can be made, or where the proposed solution might encounter problems.
Remember that in these discussions everyone involved should be objectively focused on the same goal and trying to determine the best way forward. Always assume good intent and keep an open mind. You will sometimes find that you are wrong, and this should be used as an opportunity for learning, not shame or resentment. Above all else, keep it professional and do not let it become personal.
Take Ownership of your Mistakes
No matter how careful you are, you are going to make some mistakes. You might make a lot of small, mostly insignificant mistakes; or you could make a big mistake that has a big impact. You hear a lot of stories about developers ‘accidentally crashing the production database’ because it is something that actually happens. How you react to these mistakes is critical and could define what your colleagues think of you moving forward.
You should immediately take ownership of your mistake. Don’t try to hide the mistake or blame something else such as the code being too complex. Even in scenarios where it is an easy mistake to make due to, for example, a lack of automated testing or a difference between your testing and production environments, you are still responsible for the ongoing incident.
If you’re struggling to fix a problem you caused it’s also important to ask for help immediately. This isn’t the time for pride or ego to get in the way. Some incidents might have long-lasting consequences. For example a bug that caused a data inconsistency across a multitude of microservices might cause recurring incidents. You need to make sure your team is aware of this, and as much as possible strive to resolve them yourself when they pop up (assuming the data inconsistency can’t be fixed all at once).
Finally, it is necessary to make sure the mistake doesn’t happen again. You can’t just hope that you don’t make the mistake again. You need to come up with an action plan to tackle what allowed the mistake to happen in the first place? Were there tests missing? Write them. Did the service accept any request without proper validation? Add validation (and write tests for it). Did you accidentally run a long SQL query on production instead of test? Configure your database client or terminal to use a separate colour scheme when connected to production. There’s always something you can do to avoid the mistake from happening again.
Discuss What you Like (and Dislike) Working On
This usually tends to happen between you and your manager, but there is value in taking this further than your private one-on-one sessions.
Not all developers like working on the same type of tasks. Some developers might love working closely with product designers while others might prefer to be working on the plumbing and infrastructure that keep our systems running. There’s no right or wrong type of task to enjoy working on and it is all subjective. If you communicate the tasks you enjoy working on with your team members you might find that they’d be more willing to let you work on those tasks when they crop up.
Likewise it’s just as important to speak up about tasks you don’t enjoy working on. However the aim here is not so that you don’t get assigned those tasks. It could be that the reason you don’t enjoy working on some things is because you lack the right knowledge on how to best approach them. Your colleagues might have the knowledge and experience to show you a better way of doing things. At the very least you could go from not enjoying the task to feeling indifferent about working on it.
I hope that some of these thoughts will be of some value to you. I’d also love to hear your own thoughts and feedback on this piece, so if you have any feel free to leave a comment or reach out to me directly.
