The Importance of Feedback

I decided to focus on the pattern involving feedback loops this week, because I saw it being referenced in many of the various other patterns throughout the text I browsed. Also, because it seems like to be a good apprentice, having lots of feedback to see what one is doing right or wrong seems like an incredibly important step.

The pattern is called Create Feedback Loops. The idea behind it is incredibly simple, but strong. Make sure to set up mechanisms that will give you concrete feedback on how you are doing. There are many various possibilities, from purely technical such as test-driven development to simply asking others for honest criticism of what you have done.

However, make sure the feedback is examined and the good feedback that can be implemented is taken, not bad advice that can set you back in the disguise of feedback. It is important to have positive feedback that encourages you to keep doing good things, and balancing feedback which discourages bad things.

I have realized the importance of concrete feedback implicitly throughout the years, but having it cemented as the important step it is and being explicitly aware of it, I feel, will make things going forward much easier for me. I have experienced the feeling of being completely lost many times and see how good feedback loops would have prevented many of these instances.

I was nodding my head the entire time reading the section on this pattern. Everything stated made sense and I could relate to. The personal story of Patrick’s situation was something I’ve felt many times in and out of software, where any feedback you get is vague at best and it feels impossible to know where you should head or do. Unfortunately, this was a situation I faced with some courses and professors, where after a discussion or question and answer session, I felt like nothing was clarified or it was even less clarified. These situations sometimes worked and sometimes did not, but I was always left with the sense that I did not learn much.

Going forward, I will attempt to avoid this from happening as much in the future as possible by using the techniques and actions the text suggests.

Software Craftsmanship

I tried to go into the Apprentice Patterns with an open mind, but this was difficult as my preconceived notions of an apprentice craftsman generally aligned with the old timey examples the first chapter described as not being what a software craftsman apprentice would look like.

The first chapter did a good job avoiding my worst expectations for the text, advocating for a return to past apprentice master relationships or some other ridiculous notion. These worries were not at the forefront of my mind, but they were at the back hoping they turned out to be unwarranted. Which they were thankfully.

The focus on being determined, hard working, and eager to learn and advance was definitely expected and aligned with what I believed a good software developer would be like. I agree with the assertion that people are not simply talented and skilled to begin with, it takes work to get there and continued work to maintain the level of skill achieved. Being talented or not is often seen as a binary value that you have or do not, stifling some who believe it is simply out of their grasp. I enjoy the text dissuading this line of thinking.

Being a software craftsman means to be skill centric rather than process centric is an idea that I’ve implicitly come to myself, but never really thought about in terms of consequences. The downsides of a skill centric field is petty obvious when it was stated, but I never considered it before. My eyes have opened somewhat and I feel like I will be seeing careers around me in terms of skill or process centric for some time.

When the text described the roles and differences between apprentices, journeymen, and masters it was about what I expected. It was somewhat vague, but that makes sense given how undefined things can be in the real world. What I found interesting was the mention of how some apprentice patterns would not work for a journeyman and that failure for them and masters cause much more harm than an apprentice’s. Failure is not discouraged for an apprentice, it is seen as a learning experience. So the limiting of options as one gains more responsibilities and failure becomes less acceptable was something I did not consider. Obviously as one gains more responsibility and experience failure should happen much less, but it is interesting to consider if the pressure of not being allowed to fail limits growth or not.

Overall, I am quite excited to keep reading the text. It seems to be geared specifically to people in my situation. Having several patterns that give guidance when I might not have any provides a nice safety net I can fall back on instead of guessing what works.

And So It Begins…

Despite the ominous title, this is an introductory post for my Software Development Capstone course for my last semester of University. Let’s do this!