Software Engineering

The Four Lessons I learned from Merging a Monstrous Pull Request

  • Software
  • Software Engineering
  • Software Quality
  • Git

Some months ago, I worked on a new feature for our Android app. Deadlines were tight, and the scope was ambitious. Fast forward two months, many lines of codes, a lot of stress and we managed to deliver everything on time. However, there was a small problem. For those two months of development, we were working from a branch that was never merged into our master branch. In case this does not mean anything to you, let me explain why this is a problem: We had written hundreds of new lines of code, created many new files, and modified many more. The pull request had so many commits and files that BitBucket could not load all of them. If you think resolving merge conflicts was time-consuming, imagine how long it took to review such a monster.

I know what you are thinking: "What were you thinking? Why didn't you merge earlier? " Yes, I was aware of the situation and its consequences. But that is not the point of this article. Instead, the purpose of this article is to discuss 4 important lessons I learned from this experience.

School is important but nothing like learning from Senior developers.

After completing my Bachelor's and Master's, I have to admit that I learned a lot from the teachers and books. However, it is not possible to be fully prepared for the work environment just by attending lectures and reading books. After the senior developer reviewed my code, I became aware of the knowledge gaps I had. Gaps associated with architectural patterns, Java standards, and Java-specific and Android-specific concepts. Correcting code is a fantastic learning experience. After my experience fixing the massive pull request, I realized that to learn from senior developers, it is essential to ask "why." But not with the purpose of challenging him/her but to genuinely understand why things are the way they are and why he/she believes one method, pattern, or solution is better than another.

There is usually more than one way to solve a problem

One of the beauties of software development is that there are many ways of solving a given problem. Having the freedom to develop a solution that you find attractive and useful is just amazing. However, it is essential to be open to alternative solutions and accept the fact that, in many cases, the most appropriate solution might not be your solution. In the case of the pull request I worked with, I was proud of the algorithms and architectural decisions I made; however, after the code was reviewed, a lot of the code I implemented needed to be refactored. In some cases because it was wrong, in other cases because it did not follow company standards, and in other cases, because my solution was not necessarily the best solution. It definitely hurts when someone criticizes your code but, referring back to item #1, it is essential to understand why other solutions or approaches are better. In all cases that the reviewer asked me to refactor, I wondered why. Not with the intentions of challenging him and start an argument but for the purpose of learning. Asking why helped me understand the pros and cons of the solutions and overall helped me learn new ways of solving common problems. In conclusion, be open to solutions that are not yours and understand how they differentiate to yours.

Coding standards are necessary but following them is even more

When you have a school project or you are building an app for yourself, it does not really matter what coding standard you use or if you use at all. Most likely you are the only person involved in the project, or the project is small. However, at the company level, coding standards do matter. When you work as a developer for a company, the software system you are developing is a company asset. Moreover, you are not the only one developing such an asset. Having and following company coding standards ensures that the code stays consistent and thus understandable to everyone, regardless of who wrote it. While writing the code for the new feature of the Android app, I was a bit frustrated because I was not used to writing code following those specific standards. In fact, on multiple occasions I forgot to follow them. This resulted in me having to rewrite variables name or method names later on. It is important to remember that the purpose of a coding standard is not to make your life miserable but to ensure the code has consistency and good quality.

Do not take constructive criticism or feedback as attacks

(This is my favorite point and a big one) ... If you have worked with BitBucket, you may know that it is possible to see how many comments have been posted to a pull request. For my massive pull request I still remember how such a number was increasing by the second (not literally, but yes, very fast. Not joke, by the end of the review there were more than 500 comments). I started to think that correcting the pull request was going to take longer than the time it took to write the code. I even thought I would have to re-write the entire program again. I have to admit that at times I was frustrated and upset (I am sure the reviewer noticed). But he was not doing this to make my life miserable. He was doing it because it was the best for the code, and thus for the company. As the senior developer, he had to make sure my code followed the standards of the company and that the solutions I implemented were appropriate. It is natural to feel frustrated or upset when someone asks you to change the code you worked so hard to make. But it is essential to understand (as mentioned in item #2) that there are many solutions to a problem and the best solution may not be yours. The worse thing that could be done in this type of situations is to get defensive and offended by the comments or feedback. Instead, accept the feedback offered, understand why you are asked to change the code, and learn from that feedback. In other words, put your ego down, accept the feedback, and learn from it. It is definitely not easy, but it is necessary if you want to grow as a developer and as a person. If your next reviewer has a lot of feedback for you be opened to it, understand his perspective, and learn from it. You might not necessarily agree with everything, but there is always room for you to improve and learn from the seniors.


In case you are wondering, the massive branch has now been merged, and everything is in order. The lessons I learned from the massive pull request experience was the importance of embracing and accepting feedback, the importance of learning from senior developers, the importance of following coding standards, and finally to be opened and tolerant to other's solutions.

If you enjoyed this article, please recommend and share. Don't forget to subscribe and follow me on Twitter to stay up-to-date with my latest posts. See you in the next one.

● ● ●

How would you rate this article?