How well do you know your code?
QDivision’s Tony Giamanco, Senior Software Engineer explains why knowing the code is half the battle. Take a look!
Know your code.
If the code is a simple microservice or a few microservices, you may have a good working knowledge of the code. But what happens when you have twenty microservices with Single Page Applications (SPAs) and native apps or the code is part of a monolith? The size and complexity of the code present familiarity challenges with every “nook and cranny.”
Senior developers might have a good understanding of the code. However, it’s important to think about new additions to the team and how they will become familiar with the code. Other developers might have the mindset of just debugging to understand what is happening. This could affect other work needing to be done. Consider these perspectives when getting to know your code.
Knowing the code, however, is half the battle. The other half is understanding the business rules or how the end-user will interact with the application.
What happens when the more experienced developers are on vacation or even leave the company? Could you pick up where they left off? Or better yet, what if the product owner is not accessible? Will you be able to answer the business-related questions?
There are knowledge gaps present in every team, and these gaps need to be as small as possible. In some cases, code hasn’t been touched for long periods of time or have been over-engineered, making it hard to read. Others times, code is just poorly written. Whatever the case, it is the responsibility of all developers to get to know their code well enough to answer questions, make changes, or ramp up new developers.
How can you get to know your code?
The best way to get to know the code is working with the experienced developers, whether it be pairing or mobbing. These concepts have become a part of our everyday work.
A while back, I wasn’t a fan of pairing, and thus, mobbing was out of the question. This didn’t mean I wouldn’t help others. It just meant I knew the code well enough to add functionality. Looking back, I realize developers only worked on the functionality they knew. I’d like to say that wasn’t me, but I’m guilty too.
Recently, I have switched to a new team that focuses on improving processes to better assist developers. In other words, we are working as a staff augmentation group that allows teams to implement functionality where they once could not (due to other commitments).
Our first task was to implement a new security model. We worked with each team to understand their current security model and how the apps worked. We relied on the developers to get us up to speed. It was surprising how many times we heard, “I don’t know” in response to a question.
In some cases, the code was inherited by the team. In other cases, the developer assigned to the code walk-thru was new to the team. And still, in other cases, we discovered the code hadn’t been touched in several months.
What about those cases when the code is actively developed, and the developers still don’t know this code?
There could be several reasons why a developer does not know the code. Siloed work, for example. If a developer thought, “I can bang this out to get a quick win and submit a code review.” Caution should be taken here though because sometimes code reviews are not enough. Developers could look only at who authored the change and just approve the merge request without understanding the change.
With my new team, we began working in a new codebase. Developers know it’s difficult to jump into a codebase without having any idea of its purpose or functionality. Our teams were helpful in some areas of their code, but in other cases, it was up to us to find the gaps and come up with solutions.
As part of our kick-off, we decided to work in the mobbing paradigm on large coding efforts. We had to rely on one another’s strengths and come together to understand the code. There were times we had to debug code to understand what was happening. We were able to discuss different approaches to new implementations among the team, and each developer was able to voice his/her ideas. As we moved from one team to the next, we learned which approaches worked well and which ones didn’t. Yes, we had some challenges along the way, but we learned quite a bit from each implementation. The lessons learned allowed the team to move faster.
Some benefits we experienced with mobbing (and even pairing) include the ability for anyone on the team to discuss changes with other teams, product owners, or other stakeholders. Also, we didn’t hand off any code during someone’s vacation. The team continued to move forward on the changes, and we were able to spend more time developing and less time being “stuck.” And since everyone on the team was involved during the development, we were able to deliver high quality code. Lastly, our standups changed. Now, it’s more of a conversation between the mob and the stakeholders versus reporting to each other what has been completed.
There were other challenges along the way. We knew one another; however, we have never worked on a project together. We were all different skill levels, different personalities, and different generations. We didn’t set rules such as when do we start/stop mobbing or when should we break. We would start when one of us suggested, continue until lunch, reconvene after lunch, and worked until quitting time. One of the biggest challenges for me was that I didn’t have any time to think and digest the code which required me to circle back and look at what was done.
How do we work through the code when mobbing or pairing?
When mobbing or pairing, we have multiple people striving to reach a shared goal. This is the meaning of collaboration and one of our core values at QDivision. Collaborating within the team is beneficial and keeps us all focused on the same goal.
In the paring or mobbing paradigm, there are not any siloed individuals. Each member of the team brings a different skill set so that we can lean on each other as collective intelligence. “[Insert the number of teams members here] heads are better than one.” In addition, ideas and understandings get bounced around. Maybe certain developers have a better understanding of the code — or maybe you do. Either way, knowledge is shared. Every person becomes a stronger developer and the entire team benefits. Another benefit, when mobbing, there isn’t any “mystery” code. And when those teams we are working with benefit, the end-user will also ultimately benefit.
Since most of my experience was legacy development, I had little experience with React and React Native Git Hub frameworks. When changes came up in those frameworks, it seemed to be a daunting task. However, with pairing/mobbing, I worked with experienced individuals to make changes. And you know what happens? You become more comfortable and confident working in those frameworks. Also, with mobbing or pairing, are now able to assist other developers who could be less proficient with the legacy applications.
There may be some challenges the team could face when mobbing. The mob is only as knowledgeable as the least experienced parts. If a new team of developers isn’t familiar with one another, mobbing allows the developers to get to know each other. However, some developers may resist the change because they enjoy working alone. There may be personality conflicts. In my opinion, the benefits outweigh the challenges.
Don’t be afraid to try new things like pairing or mobbing. Don’t be afraid of asking the more experienced developer(s) to work with you. Don’t be afraid to suggest new ideas and/or processes.
The goal here is to deliver maintainable, testable, expressive, and readable code when development is finished. #WeAreQDivision