“Don’t repeat yourself.”
It’s a well-known engineering mantra that encourages developers to avoid duplicating a line of code, as this makes maintainability more challenging. And it also happens to be one of Peter Purwanto’s guiding principles, defining his unique approach to engineering.
The senior software engineer at Edmunds shared that he has embraced this idea wholeheartedly since the start of his career, resulting in code that is clean, abstracted and easily maintained.
So what are the benefits of this engineering ritual? According to Purwanto, this practice has led to a myriad of improvements, including better balance between throughput and code quality, positive product evolution and, ultimately, greater outcomes for his team as a whole.
“This approach helps me and my team meet engineering and business needs in a well-balanced manner,” he said.
Below, Purwanto shares more about his approach to engineering and the difference it has made for both himself and the rest of his team.
Edmunds’ marketplace enables consumers to shop for new and old vehicles, discover their vehicle’s value and read reviews to guide their car-purchasing decisions.
Describe one of the principles that differentiates your unique approach to engineering.
I always take the lifecycle of the code I write into account, balancing between writing minimalistic, clean code and code that’s readable and easily maintainable by others in the future.
For example, I align with the tried-and-true engineering advice to balance my “Don’t repeat yourself” programming tendencies with the concept, “Avoid hasty abstractions.” I’ve been embracing this principle since the start of my career, and with our companywide focus on code quality as well as my organic interest in this topic as a part of my professional development, I’ve been able to polish and instill it as an effective habit in my day-to-day life.
What differences did you notice after you adopted this new principle in your work?
I initially struggled to effectively apply my principle to balance throughput and quality for building and reviewing clean, abstracted code that’s easily maintainable for business and engineering practices on the team.
I started off by spending a disproportionate amount of time focusing on code quality beyond what’s necessary, which slowed throughput. However, now that the principle has been put into practice more effectively due to my new habit, I’ve obtained much more of that balance.
For example, I now weigh the relative business priorities and deadlines of a given task against the significance of potential optimization opportunities I may want to apply and present. If the significance is relatively minimal but the business need is much more urgent, I’ve learned to relegate it as a technical debt item. In return, my team and I hold regular technical debt meetings to review and prioritize such work to keep it reasonably managed and addressed in a timely manner.
Ultimately, I’ve noticed positive differences in both the feedback I’m getting from my engineering managers, product owners and peers as well as from our flourishing product evolution and quality.
“I’ve noticed positive differences in both the feedback I’m getting from my engineering managers, product owners and peers as well as from our flourishing product evolution and quality.”
What does this approach to engineering help you and your team accomplish?
It gives us the flexibility to reduce technical debt without jeopardizing our velocity and launch targets. It also helps avoid overengineering and unnecessary launch delays.
Moreover, I’ve found that some of the other engineers on my team share my desire to emphasize code quality while also experiencing similar challenges with overengineering and potentially reduced throughput. Through my learnings and establishing this new habit, I’ve encouraged other engineers to adopt the same balanced principle and participate in the practice, thus benefiting our entire team.
