When you are contributing to a large open source project, you’re rarely writing code just for your immediate team – unless you are working on an internal product of course. More often than not, you are writing code for people you have never met, in different time zones, with different levels of experience and different ways of thinking. Over time, those considerations tend to change your approach to development.
Recently, I have found myself asking questions like:
- Will someone understand why I implemented it this way six months from now?
Design decisions should always be discussed and/or documented in such a way that justifies and explains why they have been made. On a small scale, even the difference between using a “while” loop vs a “do-while” loop can entirely change how a system behaves. Leaving comments in code to explain complex areas is never unappreciated.
- Is this pull request focused enough for someone to review efficiently?
The other day, I requested that an external contributor refactor their pull request to my product’s codebase as it was very large and – although ambitious and appreciated – addressed multiple different areas of the product at once. Typically it is preferred (and more efficient) for PRs to focus on a single item or closely related set of changes. This makes reviews faster, simplifies testing and makes it easier to discuss and iterate on feedback. One way to circumvent this is to break larger PRs up into smaller, focused PRs so each enhancement can be reviewed and discussed independently and improvements can be merged incrementally.
- Have I made the codebase easier to maintain, or have I just solved the problem?
Sometimes implementing new features means refactoring old ones. It is often not enough to just patch up an error or bug, especially if it means introducing new complex code. Sometimes infrastructure or even old logic needs to change, be documented and explained, and this should be a continuous process.
*
Another thing I’ve come to appreciate is feedback. In open source, your work is reviewed by people with different backgrounds, experiences and perspectives. These experiences challenge your implementation and sometimes they suggest a simpler approach that hadn’t crossed your mind before. At Canonical, we peer review and pair program, and that forms part of our QA process when reviewing others’ work. It is an iterative process that ensures we assess outcomes against our specifications, while maintaining a high level of quality control and consistency across our Canonical products.
The goal isn’t to prove your code is right, but to arrive at the best solution together, and this shift in mindset makes me a more thoughtful engineer day by day.
What’s something outside of writing code that has made you a better engineer?
Leave a Reply