What 150 Change Requests Taught Me About Writing Quality Code



Writing professional code requires a lot from a software engineer, from maintaining code quality to ensuring your software is reliable enough. There can be a lot of pressure to deliver on time and to standard. In this article Omotola Shogunle writes about what this experience has taught her.

You might be shocked at the number, but yes! I received 150 change requests in my Pull Request on GitHub for a feature I was building for a client project. This article is a reflection of what that process taught me.

1. Vulnerability with Code Critique 

When people talk about imposter syndrome, it is likely linked to the feeling of being a fraud or not being sure of how much knowledge you have. This thought can be 10x when you have been given the task to build a feature but are not sure how well your implementation works.

Does it cover all edge cases? Is it stable enough? Can other parts fit? How do I know this is the right or best approach? etc.

Asking other developers to review your work is a very vulnerable place to be because they might absolutely rip it to shreds. This process taught me to be more comfortable receiving constructive criticism. Yes everyone likes a pat on the back and praise. But I have experienced the most growth when there has been something to critique or do better. So being open to feedback, good or bad, was the first lesson I learned.

It’s okay if my first attempt was not great, and it’s okay if I didn’t even think of the changes requested. What’s important in this process is, is the reviewer empathetic and patient. Are you willing and open to feedback?

2. Writing Professional Code Is No Child’s Play

Software is a big part of most industries. It is a crucial part of a company. It is attached to millions and millions of money in profit. If the customer is experiencing technical issues, they might be at risk of losing a lot of money.

In University, we were taught about code security, maintainability, reliability and scalability. These concepts were ingrained in our brains. In reality, it is much more than understanding what this means. Every day as software developers, we try to ensure that these concepts are followed, so the client at the receiving end can run their businesses.

You might not be aware of how critical or influential your code contributions might be. In the grand scheme of things, it’s important to take ownership of your work. Being proud of the quality of the software you produce. Following processes within the company so that your code will be delivered to the same standard at least 95% of the time.

3. Review Your Work First

I can not stress enough how significant this is; you might not be able to get someone to thoroughly review your work, but taking a quick glance to adjust nuances like code formats, comments, documentation blocks, and code styles will be helpful to allow the reviewer to focus on more critical things like code quality, efficiency and maybe suggest a different approach.

Reviewing my work first helps me think of what I have done from the perspective of a critic. This makes any team member an indispensable team player and shows that you actually care for the work you are doing.

I was not able to always catch all the flaws in my code, but I imagine it’s probably better I tell myself to fix the things that allow more time to be wasted in fixing obvious issues.

4. Understanding Theory Is Great, But We need Practice

Understanding software engineering concepts are great but knowing when to apply them and why is even better. Building this feature was a constant iteration of what I know and what I needed to choose to solve the problem. Evidently, not all my judgement of the `right approach` was right, but this is where the vulnerability in allowing others to review my work comes in handy. Ask yourself constant questions, like:

  • When is the right time to abstract a function?
  • Use a plugin?
  • Throw and handle an exception?
  • Introduce composition?
  • Create a factory?

This is also where good documentation comes in handy. In practice, I was able to make mental connections between what I know and how it solves my problems. When documenting, I had solid use cases for when a particular concept is a better approach than another. I was really grateful for this experience because that is what makes a real engineer, not just knowing about these concepts but also when, how and why they should be applied in a certain way.

5. We can’t Compromise On Quality

I have worked in a company where the culture is ‘Ship first, deal with the potential problems later. This approach is the opposite of where I currently work, ‘Don’t ship, until it’s good enough. So everything from how your code is written, to testing your code changes in different developer environments, and running continuous tests is the norm. This process makes me proud when a feature I built finally makes it to production.

It means it’s stable enough for the clients to interact with – tune in a happy dance. I could list reasons why compromising quality is not a good idea, but that will be stating the obvious. Going through the process of making sure everything meets the standard is hard, and sometimes can be boring because as human beings we enjoy immediate feedback. In hindsight, I think the gratification of a job well done is better than facing several production issues and unhappy clients in the future. Has this impacted the number of features I have been able to get my hands on in the last couple of months?

The answer is yes! But the impact is far greater.

Don’t compromise on quality, it doesn’t only affect the end-user, it affects your daily engineering life. My mantra for this is: I would rather spend time solving new problems, than scratching my head over old ones. This process for me wasn’t all merry, praise and filled with insightful revelations, there was also struggle and doubt. I learned a lot of this both personally and professionally, and I hope this will help junior developers be more open to the process for growth and not too critical of their own process.

About author

Thank you for reading this piece, if you found this interesting and would like to connect or ask more questions, feel free to connect with me here.


Join SheCanCode for a day of ideation and coding at our Financial Inclusion Power Hack! Spend the day coding solutions that will help tackle financial...
Join SheCanCode for a day of ideation and coding at our International Women’s Day Power Hack! Spend the day coding solutions that will directly help...
The article delves into the extensive capabilities of NumPy, a critical numerical computing library in Python. It provides a comprehensive NumPy cheat sheet, covering essential...
The article provides a comprehensive dictionary of common coding languages, offering insights into their key features and diverse applications. From Python's versatility to Swift's role...

This website stores cookies on your computer. These cookies are used to improve your website and provide more personalized services to you, both on this website and through other media. To find out more about the cookies we use, see our Privacy Policy.