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?
