Being Wrong and Thinking Right

Nobody will have the right answer all of the time.

As an apprentice, I have been driven to learn as much as I can, do better than my absolute best, and make as few mistakes as possible. The first goal should be the only goal. The second is noble, but likely overkill and a slippery slope towards burnout. The third is a complete waste of effort. Why avoid making mistakes when part of the learning process is learning FROM mistakes? I suppose it's a defense mechanism of sorts. I want to do well, but there's a very human part of me that is afraid I might not.

Having a life-long history of self-reflection, I've come to frequent realization that I shouldn't be concerned about making mistakes. Repeating mistakes, however, is an ongoing concern. Repeating a mistake means I likely didn't learn enough from that last time I made it. The more aware I am of past missteps, the less likely I am to follow the same line of thinking. That's a somewhat idealized what of viewing it, which is why I still include "making few mistakes" as an inadvertent goal in the list above.

It's an impulse, not a plan.

I try not to view "doing well" or "repeating no mistakes" as primary concerns. The best goal I have is to hold on to every last bit of value from the learning I do every day. The hope is that the other things happen as a result. However, it's not a plan. Time spent concerning myself with the end result is time stolen away from working to achieve that end. Despite my best efforts, I do have bad habits to which I occasionally resort. The important thing is to keep moving forward.

A Feedback Loop

I enjoy getting feedback on projects, especially as they are progressing. Getting criticism after completion, while very much helpful and always welcome, is not nearly as beneficial as hearing where things are or are not working as a given project is taking shape. Oftentimes, the best advice to receive on a project is the advice that keeps you from heading down the wrong path. While it tends to circumvent the "learning from mistakes" aspect of the learning process, the time saved avoiding big mistakes can be more valuable than the lesson learned from realizing those mistakes.

Still, I don't always push myself to seek feedback when it would be very beneficial to have. This is something on which I need to work. I spend five days a week surrounded by brilliant people who are willing to share their valuable insights when they are able. It's easy to hesitate to ask for help. The novice needs to get over the fear of looking foolish or intruding on a craftsman's valuable time. Asking questions shows a willingness to learn, which is a desirable trait in developers of all experience levels.

Responding to Feedback

I make a point to choose the most accurate words to reflect what I'm thinking or feeling. Sometimes, I get it wrong - hopefully not too often. When it comes to receiving criticism, some see it as a one-way discussion. The corporate environment has traditionally been notorious for this. The less-liked managers tend to have a habit of treating the giving of feedback as a lecture. "This is what you did wrong. Now don't do it again." In these cases, there isn't much room for discussion. Their underling is supposed to take the lesson and leave.

At the other end of the spectrum, there are those who see it as defending their work against those who seek to destroy it. Every bit of input or criticism is met with fierce resistance, defending both bad and good decisions alike. These engagements tend not to give the unreceptive employee much in the way of learning. The same can be said for the supervisor. However, he or she may very well end up learning more than they wanted to about the person whose work was being critiqued.

Feedback should be treated as a resource. A person can take advantage of it, or simply disregard it. It is up to the receiver to evaluate it and determine how to respond. That is, if a response is warranted at all.

Criticism in Perspective

Having gone to art school, I have experienced the thickening of the skin in the face of criticism of my work, as well as the work of others. Not all criticism has merit. Some of it has no grounding in reality, but may still be insightful. Even the most direct, open-minded, and applicable feedback can be of little use if it does not consider the intent of the artist. The lesson to learn here is that, when it comes to projects with creative license, most criticisms are subjective, and all of them are subject to their own criticism.

In software development, the presence of creative license is minimal, if it exists at all. The art of writing code is indeed creative. However, it follows a technical line of thinking that is guided by several decades of inspired and widely-applicable principles. Even more than that, the success of the code can be measured, whereas the same cannot be said of pure art. This means that criticism is significantly more objective. The intent of the developer is more aligned with that of the supervisor and with that of the client, whether they realize it or not.

This also means all criticism should be considered, whether it mirrors the reasoning of the developer or not. It might not be advantageous to implement the suggestions in such feedback, but it should always be weighed against the principles of good design and the needs of the application being developed.

Knowing where to find the greatest value in your work, and within the input of your peers, is only as important as knowing how to apply that value back into your work, and back to those peers who first shared it with you.