As programmers, many of us tend to be critical thinkers, by nature. We still need to widen your horizon. And mine.
It’s no good just churning out the same old stuff, repeating what we were told, or read about, from earlier times. We need to use our brains to consider new ways of doing things, clearer, faster, robuster. Perhaps the way we usually work/think works fine most days, but perhaps there’s a better way. We need to ensure our minds remain open to new ideas and to challenge our existing ones. As programmers, one way we can do this is by using code reviews.
Extending the horizon
Code reviews are a way to encourage knowledge transfer, identify bugs and faulty or slow processing, and to improve the code base. Code reviews are not the place to engage in political shenanigans. Essentially this is intuitive, but many people manage to violate professional standards of online behaviour (or office politics) by engaging in silly point scoring instead of focusing on the job at hand. The job is to improve the code and we do this by eliciting feedback from other team members. This does not mean to obey the commands or suggestions of others unthinkingly. This does mean to rationally consider what other people are saying and to consider their statements in the light of what makes sense. Does it make sense?
Just because I wrote some code, or hold a particular opinion, does not mean this is the best way to continue. Personal ownership of code or thinking “my way is the only way” in a group environment is the death knell for collaborative working and for healthy feedback. Used well, code reviews (open peer discussion) can help us to identify flaws in our ways of thinking and programming, and move towards a better understanding of the technical issues as well as the ideas behind our solution/s.
Try it yourself, get some feedback from outside the echo chamber of your mind. Engage others in meaningful discussions of your code and your thought processes. Identify what needs to change and embrace that change.