Software Engineering teams often consist of differently skilled engineers. Some predominantly task-driven, focused intently on delivering the next ticket without much regard for larger product vision. While efficiently shipping features is essential, failing to see the bigger picture and lack of ownership of our code can have far-reaching consequences.
This article explores what happens when developers lose sight of the larger picture and how cultivating self-review skills plus a sense of ownership can elevate both the product and the team's efficiency.
The Tunnel Vision Trap
The Problem: Developers are often racing against the clock, ticking off tasks on their to-do lists, and before they know it, they've lost sight of the bigger picture. Many junior and mid-level developers, eager to demonstrate their value, may rush to finish tasks quickly. This haste can lead to coding errors, missed opportunities to enhance efficiency, and failure to meet user or company requirements. But this isn't just a challenge for less experienced developers; even seasoned professionals can get caught in this trap too. When deadlines loom or familiarity breeds complacency, the most experienced developers can find themselves tangled in the weeds, overlooking crucial aspects of the overall project architecture or user experience.
So, how do we combat this all-too-human tendency? One effective answer lies in mastering the art of self-review.
The Self-Review Imperative: Wearing Different Hats
Self-review is more than just a quick step before submitting code for peer review. It is a crucial skill that sets exceptional developers apart. When done well, self-review encourages developers to look at their code from different perspectives and think critically about it. This ability to detach from recently written work and approach it with fresh eyes is crucial for code quality and overall product success.
Think of it as a habit to cultivate: one that could dramatically improve the quality of the code and reduce the time spent going back and forth during peer reviews.
Here are two fundamental perspectives developers should adopt during self-review:
1. Wearing the Customer Hat: "If I Were a User"
Engineers often get wrapped up in the mechanics of writing code, losing sight of how it affects the user and their product experience. You unlock some utility by wearing the customer hat and thinking about or using the product like the end consumer. By adopting the mindset of a customer during self-review, the developer can see their work through the lens of the end user, asking the following questions:
- Does this feature work as I expect it to?
- Is the user experience smooth across all devices (e.g., mobile, tablet, desktop)
- Are there edge cases that could break the feature for users?
- As a user exposed to other similar products and experiences in the market, how different does the feature behave?
This "customer hat" forces the developer to focus not just on functionality but also on usability. It helps them understand that writing code isn't the goal - improving the user's interaction with the product is. For example, if a feature is supposed to allow users to submit a form, the developer should walk through the flow as if they were the user:
- Is the form accessible?
- Are error messages clear?
- What happens if the user submits incomplete data?
Developers begin to see the product's practical, day-to-day use by stepping into the customer's shoes. This shift in perspective helps catch issues that might not surface until much later in the process, when the cost to fix them is far greater.
One practical practice I use to reinforce the customer perspective in my daily work is to take a break after coding a feature - perhaps by going for a walk. When I return to my desk, I find it easier to put on the "customer hat" and critically evaluate my work.
2. Wearing the Peer Hat: "If I Were Another Developer Reviewing This Code"
Another powerful perspective in self-review is that of a peer or colleague reviewing the code next. Instead of just checking for functional correctness, the developer should ask:
- Is my code clear and understandable?
- Could another developer quickly review my work?
- Have I followed best practices and maintained clean code?
Code isn't just for machines - it's for humans, too. Writing code others can easily read, maintain, and extend is as vital as ensuring it works. When developers review their work with the mindset of another developer, they're likely to catch unnecessary complexity, vague variable names, or large, unmanageable functions that make the code hard to understand.
One helpful strategy here is to take a break before self-reviewing. After taking a break from the code, it becomes easier to approach it with a fresh perspective, as if it were written by someone else. Detaching from the emotional investment in the code allows developers to review it more objectively, similar to how a peer would.
Teams that adopt this mindset have more efficient code reviews. Reviewers should provide feedback that adds value instead of just catching fundamental issues that should have been caught earlier. This workflow improvement can reduce the time spent on code reviews. Reviewers can focus on more complex architectural or functional considerations rather than simple fixes.
Building the Self-Review Habit
Developers aren't always naturally inclined to step back and review their work with these critical perspectives, but like any skill, it can be cultivated over time. Here are some practical steps to help developers build the habit of effective self-review.
- Create a Self-Review checklist
Just like a QA checklist, developers should have a list of questions to run through before submitting their work. For example:
• Have I tested this feature across all relevant devices and screen sizes?
• Have I written clean, understandable code that others can maintain?
• Does the code achieve the desired outcome without introducing regressions?
• If I were the user, would this work as expected?
By formalizing these checks, developers are reminded to take the necessary steps before pushing code for review. Over time, this becomes second nature, leading to fewer mistakes and a smoother development process. - Encourage breaks between writing and reviewing
Encourage developers to step away from their code before reviewing it. Even a short break can help shift their mindset from "author" to "reviewer." When they return, they'll find it easier to spot issues they might have missed in the heat of coding. - Use metrics to promote accountability
Tracking the number of review comments related to avoidable issues (e.g., incomplete testing or unclear code) reminds developers to take self-review more seriously. This data can pinpoint areas for improvement and help developers understand the tangible benefits of adopting this practice. - Regularly rotate developers in code reviews
Have developers regularly review each other's code and encourage feedback on improving their self-review practices. Over time, they'll become more aware of what peers look for, and that insight will help them improve their self-review process.
Conclusion: Why Detachment is Key to Code Quality
The ability to detach from one's work and look at it through different lenses - whether as a customer or a peer - is a crucial skill for any developer. It allows for more objective self-review, leading to fewer bugs, cleaner code, and a smoother user experience.
In a product-driven environment, especially where user experience is paramount, this shift in perspective can significantly reduce the time spent on code reviews and bug fixing while fostering trust among team members.
Great developers don't just write code - they ensure that what they've built is solid, maintainable, and works across all intended devices. The first step to achieving that is taking responsibility for their work and embracing self-review as a vital part of the development process.
Encouraging a mindset of ownership and detachment through self-review improves the individual's skills and strengthens the overall product and team.
By consistently asking, "If I were a customer, would this work?" and "If I were another developer, could I easily understand this?" developers will ultimately deliver higher-quality code with fewer frustrations.
This shift won't happen overnight, but by fostering a culture where self-review is valued and providing developers with the tools and strategies to see their work from multiple perspectives, we can transform how teams build products and improve both the user experience and the development process.
Would this strategy work for you or your team?