What does it take to be a good developer? It's a developer that has leadership qualities, someone able to direct a team, ensure focus is aimed in the right direction, needs of the company are being met, and the relationships between the developers and the rest of the team are healthy. Being a developer with leadership qualities doesn't often come easily or naturally. It takes effort and a desire to make a difference in order to find yourself being that person.
A good developer that wants to lead isn't afraid of asking questions, getting lost in the code with their peers, interacting with the leadership with potentially differing views, and introducing changes where needed.
I want to explore some aspects that can contribute to making a developer into one with good leadership qualities. We'll start with the concept I feel is most important, something vital to the longevity of a team and the product.
Documentation
When it comes to being a good developer with strong leadership qualities, I personally value documentation and the ability to write about your code, process, and reasoning for things really high on the chart. This helps the team in so many ways, it's something I ask during the first interview; "What's your documentation process, and what tools do you use?"
Documentation, when done right, can and will save you and your team time, money, and energy. Let's imagine the following - your lead developer has decided to move on from the team and you and the others will now be responsible for picking up things and where they left off. For the lucky ones, the lead will have left plenty of notes, documentation, and information on what does what, where things are, and how to handle them. You'll adjust in a reasonable time frame and the team will continue to move forward.
On the other-hand, this theoretical developer has left no traces of documentation. The code isn't commented on, how things are deployed are a mystery, and the server setup is anyone's guess. You and your team are now struggling to figure out up from down and scrambling to piece together any sort of meaningful documentation to help ease the chaos.
So, which would you rather be? The good developer who, for whatever situation, leaves your team ready and able to face things on their own? Or the developer who isn't mindful of others and allows them to not only struggle, but experience real stress from the unknowns of how things work?
Documentation Tools
Thankfully, we don't have to invent some sort of tool to help us document our processes, thoughts, or ways of doing things. In my experience, the following methodologies have been rated and listed for your consideration.
Confluence: A+
The ease of organizing related articles within their own section can be amazing. The formatting is clean and super helpful to style different elements. The access control is easy and makes sense, plus, non-technical people can easily find their way within Confluence far quicker than most other systems.
Having an internal wiki system is great. It's developer friendly, you can utilize markdown, and it's super easy to link various articles and documentation pages together. You can quickly grant access to others in order to view things which is a plus. The downside is that non-technical people will absolutely struggle to navigate within Gitlab.
Trello: C-
This tool isn't really designed for sharing notes, but there are teams that can make it work. Ideally, you'll use this for, at minimum, documenting bugs and tasks. At the worst, you can create card lanes based on which features and areas of the project you're documenting. I wouldn't recommend this as the final solution to documentation.
These are very difficult to search, link together and properly format. They do not allow markdown, require lots of manual work to share, and aren't easy to recall when working in a team environment. At the end of the day, you'll just have a bunch of various sheets in a huge folder. I strongly discourage this.
Absolutely NO to the following
- Email as documentation (you'll lose track of things).
- Slack/Discord/Skype, or chat apps (it's impossible to efficiently track and maintain documentation).
- Code-only Comments (this requires way too many assumptions to maintain, it's simply not advisable).
Other tools that I could suggest, but don't have experience with:
Get this article and more in my newest e-book
Pay what you want, $0 or $100 - Developer Leadership