Writing software is a complex job full of learning. We learn not only new technologies but also domains and avoiding disasters in production. From my experience, the best learning tool is fast feedback. Embracing it in all aspects of your development process will make your progress skyrocket.
Feedback as a tool
Feedback is a tool to make your output and you better. If you submit your code to a colleague, to do a code review he will point out the mistakes you did and, in the best scenario, he will help you understand the issues and fix your code. Both of you are gaining from this situation. Bad code was not pushed to production, you learned how to write better programs and next time there will be a third of the issues. If you would not get the feedback you might to found out the issues later either as a bug or as technical debt and the cost of learning will be much higher.
Feedback and current development practices
If you look at the current trends in software development, you can see that a lot of what is an everyday practice for us is some form of getting fast feedback. For example, writing tests. Without them, it is like playing a musical instrument without hearing it. You are almost sure that you are playing the right notes, but you cannot be sure. There is no better way to get fast feedback than by running a suite of good tests (okay, maybe Clojure and its repl driven development). Continues integration and continuous delivery allow us to ship software faster to get feedback from users and real-life situations as fast as possible.
The problem with receiving feedback
Receive and accept feedback is tough. Ego, fear, and expectations get in the way of receiving it. But I have some good news for you, as with everything you get better at it. You learn how to separate yourself from the feedback and take what is going to move you forward. For me, there were a few books that helped me with this namely mindset by Dr. Carol Dweck and Creativity inc. by Ed Catmull. Giving someone feedback is maybe an even bigger problem but I do not feel like having enough experience to write about it.
Conclusion
Getting feedback is an often big step out of your comfort zone. You may show someone something terrible but if you don't put your skin in the game it stays terrible. If you get feedback, you have the opportunity to make it better.
If you like this article follow me on Twitter https://twitter.com/rejmank1
Top comments (2)
Good writing. Empathy and kindness are key for positive human interactions, and code reviews are no exception. Shifting left the feedback (doing it earlier in the development process) is a practice that helps avoid unnecessary conflicts after too much effort was already put in a solution that not everybody agrees on.
Thanks Jiri --and you are spot on. I like to look at feedback as a gift (sappy but true). Feedback usually comes from a place of helpfulness and to make your projects even better. I can agree it is tough to not take it personal, but some of the best enhancements, bug fixes have come from feedback.
Code On Jiri!