Apprenticeship Patterns – Create Feedback Loop

Summary

Self assessment can be a very difficult thing to accurately accomplish. When learning a new skill, we may not be aware of our mistakes as we are making them. Creating an early and open feedback loop can be a very useful tool for identifying and mitigating these mistakes.

My Reaction

This pattern is very useful in that it teaches us to remember our tendency to overestimate our own aptitude. It even notes a correlation between our lack of real ability and the lack of perceived ability. This was an interesting concept that seems obvious in retrospect, but I found to be intriguing.  

Finding opportunities to get feedback involves being willing to hear both praise and criticism. This may be scary for some, but understanding and learning from our mistakes is worth much more than our fear of failure.

I had not considered the idea of stop energy. This is when feedback received does not provide constructive, actionable input. Instead, it is meant to stifle and discourage. This type of feedback is mostly about the person giving it and usually lacks any kind of real consideration about you or your current situation. Understanding how to identify the difference is important to maximizing your positive feedback loop. This was a new concept to me and it taught me a new approach to my future feedback opportunities.

There are two types of positive feedback that can be used to constantly adjust and adapt. This is the biggest take away from the pattern for me. The two type to consider are balancing and reinforcing feedback. They operate to push a system to relative stability and maintain longevity within that system.

Balancing feedback encourages us to do less of something while reinforcing feedback encourages us to do less of it. This is a very simple yet profound idea. The distinction between positive and negative feedback seems much easier to determine. This finer granularity within positive feedback is much tougher figure out.

Getting better at this takes practice. It takes understanding more that just what someone says but how it is said. It involves considering context and meaning. These things take time and are tough to convey in a book. I will try to use these lessons in my next project, assignment, or human interaction. There is always an opportunity to establish and learn from a feedback loop. Simply interacting with others and seeing what they think and feel is an example of one.

CS-448
CS@Worcester
Week-4

From the blog Rick W Phillips - CS@Worcester by rickwphillips and used with permission of the author. All other rights reserved by the author.

Use Your Title : Pattern 2

In this pattern, the author presents the issue of people getting moved into different roles due to their dedication to mastering their crafts and art.  usually when you become outstanding and put in time to better and help you team improve you begin to create a chain reaction of quality standards that either get matched by your peers who in turn become better programmers or you are put in a position to defend your processes and methods. ON the management level , this will serve as a sign that moves you to a leadership role or position in the company. It is at this point that the author wants us to understand that we do not need to conform to the pressure around us. As a software craftsman, you are to remain that and continually improve your craft without breaking into the distractions around you. we are not to allow ourselves to be controlled or changed by our title but we are to leave it at the outskirts of our consciousness. Once in such a position, do not be swayed by the positions descriptions and demands but instead use that as a gauge to assess your organization. If you were noticed due to you outstanding qualities, hard work and knowledge, it should serve as a sign for you to evaluate how well the organization seeks for growth and progress. On the other hand if you are not recognized although you are still exerting these qualities, that should also paint a picture of where the organization is headed. Everyone wants to be recognized when they do things that are deemed to be recognized so an organization that fails to recognize this often lose out on the talents of such a person. whiles companies that pay notice to things like that keep acquiring people of such traits. Another possible scenario that often results from this trend is the differentiation of both informal versus formal titles.Many times employees begin to grown into a positions of authority on teams, despite their formal title remaining the same. Growth into positions of authority booms with familiarity with the job, development of skills and an overall understanding of the specific companies processes and task. The more you understand, the more you can explain and the more you are familiar with a process, the better you understanding of it. 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2018-02-04 21:52:46

The “Expose Your Ignorance” pattern encourages software apprentices not to feign competence when they don’t know how to do something, but instead to nurture and showcase their ability to learn by admitting that they don’t. According to the writers, the problem is most likely to come up when your managers or team members assume or want confirmation that you know something. You can still reassure people in these situations, but with your capacity to learn instead of by being dishonest about your abilities. In this way you can build trust by showing you can be counted on to figure out how to do what’s needed, even if you can’t do it yet.

Exposing your ignorance doesn’t seem like such a difficult thing if there are no expectations of your knowledge level beforehand, but letting someone know you don’t understand something they thought you did seems almost unbearable, especially in a situation where your ability to do your job depends on understanding it. I hadn’t considered that I might be put under pressure to project an image of having knowledge in an area I don’t, so I’m glad to have some ideas of how to respond to it before it becomes an issue.

Another thing I hadn’t considered was the idea that becoming an expert is something to be avoided, or at least not the main goal. The authors explain that to be a software craftsman, you can’t become confined to a specific domain or skill. This is what naturally happens if you’re too afraid of exposing your ignorance to learn new things. Here too, the idea of having a greater goal to pursue is helpful to me. I would rather be a software craftsman than an expert in one area, because it would help me to keep my options open. Being good at only one thing also means you run the risk that the skill will one day become obsolete.

The advice to publicly post a list of things you don’t understand about your work surprised me. It seems like it would be a painful thing to do, but it does also seem like it would help you get used to putting this pattern into practice. It might end up something I try in the future.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Craft Over Art

This week I chose to cover “Craft over Art” from chapter 3. Craft over art is an essential piece to becoming an apprentice. When you are faced with a task, an opportunity to try something different and creative arises. Sometimes you have to sacrifice beautiful work in order to deliver a solid working project. Building… Continue reading Apprenticeship Patterns: Craft Over Art →

From the blog CS@Worcester – BenLag's Blog by benlagblog and used with permission of the author. All other rights reserved by the author.

Concrete Skills

The Concrete Skills apprenticeship pattern seems to give the assertion that entry level software developers should maintain a quality understanding of the “basics.” Employers can and should have the expectation that new hires can contribute in some substantial way, right from the gate. I feel this patterns’ context stresses the importance of understanding the fundamentals of programming, essential algorithms, and computer science in general. One of my main responsibilities as an undergraduate is to learn and maintain such fundamentals that any reputable employer should expect from any entry level software developer.

The authors describing this pattern do a great job of highlighting some pivotal “concrete skills” one should strive for as a newcomer to the field. For instance, it is suggested that gathering a solid understanding of one’s first programming language is a primary skill we should strive for. I realize that my first language (Java) is just the beginning of a myriad of languages I expect to be exposed to in the near future. I ought to practice Java to the point where I can roughly draft code for any rudimentary procedure at any given moment. My potential employers need to know that I grasp the basics of vital data structures and design patterns. I should strive for a solid understanding of these fundamentals to a point where I can just start shelling out code whenever it is asked of me. When I can do this to a point of solid understanding and self-confidence, this will be the day that I can say that I have done so by successfully applying the Concrete Skills pattern.

What I found most interesting about this pattern was the implication of the importance of learning how to play “buzzword bingo” to get your foot in the door as an entry level Software Developer. I must say I found this amusing in the sense that I pictured someone at an interview saying something like “…yeah I’m familiar with APIs, ASP, IDEs, J2EE, NPM, SQL, UML…” and all sorts of other alphabet soup. But at the same time, the term “buzzword bingo” was especially enlightening for me. Any quality resume/CV I’ve ever encountered for inspiration had similar keywords sprinkled throughout them. Thus I have set a personal task for myself to become familiar with such popular buzzwords to a point where I can at least explain them. Proficiency would be great, but I feel I can begin to apply the concrete skills pattern by at least researching more about these recurring buzzword terms. I feel this, along with striving and maintaining a solid understanding of my “first language” Java, are great ways to apply the concrete skills pattern.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

Emptying the Cup: The White Belt

In this stage of the Apprenticeship patterns, it gives us an overall idea of what it’s like to be an apprentice. In terms of learning different programming languages, especially if its a new language, it will be hard to learn it because you have prior knowledge on the concepts of basic programming actions. According to the Apprenticeship patterns, “we have to be able to put aside our past experiences and preconceptions to allow new knowledge in. This is especially difficult when trying to learn your second programming language, because it is likely the first time that you have to sacrifice productivity in order to improve your skills.” When you think you are knowledgeable in programming languages, you are unable to take in the maximum depth of learning you are expected to take in as well as limit the ability to discover new possibilities.  To put this in the modern work place, team members will always have a certain level of competency in the work that they do. Pride will be one of the factors that may be an obstruction to the team unless each of them are able to allow themselves to unlearn what they learn in order to learn new things in case problems should arise in the future.

What I found interesting about this pattern was how the metaphor “white belt” was used.

“Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.”

In my mind, I thought it made sense because as a true beginner, you know nothing at all to start off. To be taught at first, it is normal to think that the first way you learn would be the right way. At that point you allow yourself to learn, and therefore, you are able to discover possibilities you hadn’t known.

This Apprenticeship pattern was useful because it made me think of when I first learned my second programming language, which was Java. When I transitioned from C++, I thought learning Java wouldn’t be as hard as I thought it would. It ended up being harder because I wasn’t allowing myself to learn the full principles and rules of the language. I took shortcuts when I wasn’t suppose to, and I had to learn that the hard way as I struggled through learning it. Soon after, I took it step by step and allowed myself to learn it the right way.  I completely agree with this pattern because not only it applies to programming, but it can apply to anything you learn in life, and it starts by wearing that “white belt” first.

 

From the blog CS@Worcester – Ricky Phan by Ricky Phan CS Worcester and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Emptying the Cup (Chapter 2)

The authors began this chapter with a really thought-provoking story of a Zen master and a young philosopher. In this story, the young philosopher sets out to learn the ways of the Zen master but every time the zen master would begin to describe his own practices the young philosopher would cut him short and start talking about how he does things and how it might relate. Essentially, the Zen master is never able to complete any of his thoughts because the young philosopher keeps interrupting and talking about his own experiences. This goes on for a while until the Zen master goes to pour a glass of tea and he keeps pouring until the the cup is overflowing. at this point, the young philosopher tells the zen master to stop pouring to which the zen master replies, “If you come to me with a cup that is already full, how can you expect me to give you something to drink?”

I think that the short story about the Zen master and the philosopher is extremely relatable to learning how to become a software developer. In the field of programming its’s really important to approach problems with an open mind and to not disregard certain techniques or practices due to the fact that they aren’t familiar to you. By emptying your ‘mental’ cup and being upon to new ideas you will inevitably be much more successful in developing and honing down your programming abilities.

The authors go on to describe the best way to get your software development career started. They suggest that you choose one specific programming language and “become fluent in it.” Some of the things they proposed to get help get you started are using that programming language to build a “toy” application, trying to solve real problems using that language, and reading the language’s specification documentation. The authors recommend using tools like git to publish and/or contribute to open source projects. The benefits of contributing to open source projects include the fact that you can get feedback on your code and advice from experienced professionals that already know the language your learning. Overall, I’d have to say that they present some really good advice on how to get your programming career started and I wish that I had read this when I was starting out as it probably would have saved me a lot of headaches.

 

From the blog CS@Worcester – Caleb's Computer Science Blog by calebscomputerscienceblog and used with permission of the author. All other rights reserved by the author.

Unleash Your Enthusiasm

Unleashing your enthusiasm focuses on bringing enthusiasm to your new team.  It emphasizes approaching your new team with energy and readiness to learn as much as possible.  The book explains that a lot of new developers may be hesitant to appear too enthusiastic, thinking that the team that they are integrating into might not be welcoming to the new injection of enthusiasm into their work place.  Enthusiasm is infectious though and in just a short period your enthusiasm to work and learn will spread to the other team members and the overall work environment will rise.  I agree that this works not only in software development, but in any industry.  During my time in the Army there were plenty of days that were miserable at best.  No matter what the condition was though if you had a positive energy and enthusiasm it made the day a little easier.  When one person showed up with this type of attitude they were quickly berated and rejected by those who were determined to stay miserable.  Soon enough though the positive attitude spread to others and everyone had seemingly found what little good and joy there was to find that day.  Work then seemed easier and the day moved quicker.  No one could tell you any specific time or event that the change occurred.  The tone of the team just kind of changed as the enthusiasm spread.  I think that a high morale and enthusiasm for the job will greatly improve the overall morale and performance of the team.  I found the study from the aircraft carrier interesting.  The idea that new employees mixed with seasoned vets of the industry makes sense, but is often overlooked until it is brought up.  The vets share their experience with the new employees while the new employees are able to share the newer ways of teaching and question the way things have been done in order to change procedures if necessary.  When the employee is in the middle of these two extremes is where changes are made and new procedures and policies replace the old.  It’s important to for all to remember that this process doesn’t work without a mutual respect and open mindedness towards all.

From the blog CS@Worcester – Tim's Blog by nbhc24 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 Reflections

Reading the first chapter of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman”  by Dave Hoover and Adewale Oshineye, has so far changed the way that I look at being a new developer and the approach that I will take to growing. The quote that resonated with me the most was said by Marten Gustafson, he stated “I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing”. The previous quote in my opinion is the most important idea portrayed through the entire first chapter of this article, it applies to not only the apprentices, but also the journeyman as well as the masters. I think it’s very important to work with the attitude that there is always a better way because it keeps us from getting complacent and leads to many innovations, and because of this I will try to keep this attitude as I go through my development career.

The other key idea that this article taught was self responsibility. The classical apprenticeship pattern that they compared theirs to has a larger reliance on others (the apprentice has a reliance on the journeymen and masters for their learning). Though this chapter acknowledges that this will play a role in our careers, they make the argument that we should take control and and responsibility for our destinies. I found that particular part of the chapter very empowering because it stresses the fact that the responsibility falls on you. It tells me that I am responsible for acquiring the skills needed to advance in my career, and that I am responsible for finding the correct mentor when that is needed, and most importantly that I am the only one responsible for my successes and failures.

While a big part of the chapter stressed the idea of individual responsibility and growth, I really like how it demonstrated the link between this individual growth and that of the community and the craft itself. It shows that as you get enough skill to consider yourself no longer an apprentice, it is almost your responsibility to share your knowledge and ideas. As a developer you are going to be working in many different teams on many different projects, and you will be exposed to many other ideas, but you will also expose others to some of your own ideas. This exchange of ideas is in my opinion the best thing that could happen for the craft and profession as a whole, it ensures that things will not stagnate and is responsible for the many innovations we developers have had.  It talked about how as a master you are putting these skills and ideas under the microscope to improve the way that the community as a whole operates. That last sentence really summarized the theme of the chapter for me, I see it as saying something like even when you know almost everything about the craft (mastery) you still don’t know if this is the best way to get things done and that is something you have to investigate and try to improve on.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Thoughts on “The White Belt” apprenticeship pattern

The White Belt pattern arises out of an issue I’ve encountered — I’ve learned one language fairly well and have some practice with others that follow similar paradigms, but have found it to be more challenging to learn new things.  Tools, skills, and languages that are different from what I know don’t come as naturally as it seems they should.

This apprenticeship pattern seeks to solve that problem through a mindstate and a more practical approach.  It teaches the mindset of a willingness to feel like a beginner again, to fail and maybe look foolish in order to adopt a childlike ability to absorb knowledge.  More practically, it suggests a learning strategy: adapt a simple, known software project from one language to another, using the paradigms of the new language to their fullest rather than trying to write “Fortran in any language”.

As I said before, I have notice that I struggle more and more to acquire new skills.  Whether that’s environment setup, picking up new languages, or adapting to a different set of tools it seems to get harder as I learn more.  That doesn’t bode well for my mental plasticity, and this pattern provides a useful solution.

The most useful aspect of the pattern, for me, are what the authors calls the mindset of not knowing.  Of willingness to ask questions, start from the beginning (whether that’s following tutorials that feel beneath me, or finding help elsewhere).  Of taking a harder road to learn things right and come up with a better and more nuanced solution rather than patching together something that’s familiar and comforting.  This speaks to something I learned in a high school gym class: we learn and grow the best and most successfully just a bit outside of our comfort zones.  I need to push myself into the “learning zone”.

The action advice is also something that I can take away and use moving forward.  While I don’t have a lot of time now, I am interested in refactoring old projects into new languages as a learning exercise, to blend something that I know well already with something brand-new.

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.