We must learn how to learn.

Learning is ongoing, continual, without end.

 [L]earning about what we do not know is often more important than doing things we already know how to do.

—Jim Highsmith, Agile Software Development Ecosystems

This chapter focuses on continual growth as a developer. The problem scenario presented in the text is one where we have only a basic skill level of software development as it pertains to our day job. The author suggests that we should take a multifaceted approach to learning.

Some examples of how we can seek-out new knowledge and experiences:

  • Sign up for Google Reader (or another blog aggregator) and begin subscribing to software development blogs. With modern machine translation technologies, you do not even have to restrict yourself to those who write in English. You can follow Tim O’Reilly’s advice and track the blogs of what he calls “alpha geeks” across a variety of technology domains.[26] These people are not necessarily the best programmers, but collectively they tend to sense new trends years before the rest of us. Consider using your own blog to reflect on the themes you pick up from these bloggers.
  • Start following some software luminaries on Twitter and pay attention to what they are working on.
  • Subscribe to a moderately high-traffic online mailing list and try to answer people’s questions by reproducing their issues.
  • Join a newly formed local user group that is excited about a new technology. Do not just attend silently – introduce yourself to the organizer and offer to help.
  • Persuade your employer to send you to a technical conference. Even if they will not pay for you to attend, you can still read the slides on the website and download audio/video of the speeches.

Using multiple tools to acquire knowledge and skill-sets is one of the best approaches I have tried. It is the same if you want to learn a new oral language, you surround yourself with it and continually find ways to incorporate it into your daily routine. Immerse yourself in the topic continually, not just when you are at home sitting with a book. The ending of this chapter resonated with me as the author mentioned how simple it is to take this continual search for more and more knowledge too far. I have a (possibly slightly unhealthy) obsession with learning about a variety of unrelated topics that do not benefit my life in any way.

  When I hear of a new technology or topic that interests me, I become enthralled by it. Nothing else exists until I know as much as I can about it. Currently, my obsession is with 18650 Lithium ion batteries, particularly building my own packs. This pattern will prove to be helpful in my life reminding me not to get lost in the sea of interesting information and to also not lose my practical skills in life/development.

Retreat into Competence

The problem talked about in this pattern is being overwhelmed with how little we know. I have felt this way many times, pursuing a degree in compSci. There have always been students in my classes that are better developers than I. Whether they have been programming longer than I have, or they are not juggling school with fatherhood, home maintenance, cooking for five, cleaning, paying a mortgage etc.

The solution presented in the text is that we should occasionally retreat for brief intervals into the things we are competent in. Taking some time to build something in familiar languages and frameworks will help ground us in our abilities . We are warned however that going backwards can be risky, if done without proper planning. When going backwards, it is best to set specific time limits for yourself so you don’t get stuck in your comfort zone. We desire comfort and familiarity, but growth does not exist within your comfort zone.

All throughout my life, asking questions to better understand things I am somewhat familiar with or inquiring about things I am not familiar with, is something I have always done. During my time studying to become a developer, I have experienced this feeling of overwhelm from time to time, regarding my ignorance in computer science. Due to my passion for learning, I have sought support and guidance from professors and peers alike, without hesitation. Although this has benefited me greatly in the past, it could be quite useful to retreat for timed intervals doing something I know well and feel confident about.

The idea of setting time limits interests me because it reminds me of Pomodoros, which is something I utilize quite frequently. Setting a timer to work on “task A” and another timer to step back and take a break has been working well for me. Taking that break and using it to do something I am good at and know well could very likely give me the reassurance I need in respect to my knowledge and abilities as a developer. Maybe even developing something I feel competent and confident in would help me to ground myself as a developer.

The Tortoise Always Wins

“How long will it take to master aikido?” a prospective student asks. “How long do you expect to live?” is the only respectable response.

—George Leonard, Mastery

While reading chapter 3 of Apprenticeship Patterns, I stumbled upon the preceding quote. It resonated with me because I often get so caught up in aiming for perfection that progress becomes halted. Anything worth doing is worth doing poorly.  I have heard it said that perfection is the enemy of progress.  

This chapter focuses on the long road we all must travel to master our craft. The author talks about how we have all grown to desire immediate gratification, whether that be in notoriety, wealth, or the development of our skill. If we desire to become true craftsmen we must focus our attention on delayed gratification. Our skills will take time to develop, and the journey will be a test in endurance and patience. The problem presented in the text is of being stuck in a “golden lock” where our aim for further crafting our skill is at odds with our desire for a higher paying job. By taking the path less traveled “Robert frost” we can make all the difference in our development as craftsmen.

We must be patient and compassionate with ourselves along our journey. It is easy to get discouraged when we see how little we know in comparison to veteran developers or even peers. So long as we strive to continuously hone our craft, we can become the masters that future generations of craftsmen look up to. The long road means we do not grow into incredible craftsmen overnight. It takes long hours and is a slow process.  

When we take our time to mindfully develop code, asking questions about why and how code behaves the way it does, or why we approach problems a certain way, we deepen our understanding of not only the development process but our strategies for everyday living. We learn better problem-solving skills, we become more inquisitive into ways to efficiently meet the needs of ourselves, our families, and our communities. This is something I have struggled with as a CS major, trying to balance out good grades with deeper comprehension. Many students fall into the trap of just learning the information required to pass the class with a good grade, putting ourselves at a disadvantage. Our lives have only a finite amount of time, and sometimes we need to decide whether we should slow down and take time to comprehend the deeper truths of software development, even though it may take away from time available for studying the class materials.

If we desire to become true craftsmen rather than just working a 9-5 grind we need to recognize that the path we chose is neither easy nor short. Our field is growing exponentially with the constantly changing technological advances we are experiencing and will continue to experience. This path is not as straight and narrow as other fields, due to the continuous changing of technology. However, if we slow down and dig deeper asking the questions that lead to deeper understanding, we will see the commonalities that all software share, making it easy to adapt to the changing of software development. Traveling “The Long Road” can allow us to bring meaning and pride to our work rather than being another nameless cog in the machine for a corporation.

The tortoise always wins the race.

Learn How You Fail

Failing is unavoidable and it happens to everyone at some point. In reality, anyone who has never failed at anything has either stopped challenging themselves or learnt to ignore their own mistakes.

Your skills are progressing but you are still failing and have some remaining weaknesses. So instead of drowning in a sea of self-pity over previous failures, develop some self-awareness of your own patterns, habits, behaviors, and other factors that play a role in causing you to fail. When you are aware of yourself and the things that mess you up, you give yourself the option of either trying to solve the issues or cut your losses. You cannot succeed in all, and recognizing your shortcomings is critical because it allows you to actively recognize distractions and concentrate on your goals.

Accept that there will be certain stuff you aren’t very good at.

Once you learn to accept your failures you can set realistic limitations on your goals.

Often times I get irritated by the fact I keep failing, but if I accept it, my failures become learning opportunities. I can then seek out guidance and learn new skills from someone who knows more about code than I do. It is hard, honest work to admit your shortcomings and it will take a lot of failures, but I am confident that eventually, it will all be worth the frustration.

Breakable Toys

Experience is built upon failure as much as (if not more than) success.

Breakable Toys is about purposefully creating learning opportunities by pushing yourself outside of your realm of experience and designing and developing complete software projects on your terms. The concept of this pattern is one that I speak of frequently, in regards to many areas of life. The comparison of the jugglers was actually pretty insightful. It would not make sense to attempt something new, knowing you may fail without having practiced it first. As the saying goes, “Practice makes perfect.”, and this is especially so in software development.

Trial and error seems to be an obvious concept whenever learning something new. Although, it does not seem likely that one would have room for many failures in software development, as that would become costly. With that thought in mind, the suggestion to build your own systems on your own time – your Breakable Toys – is ingenious. Within that suggestion, one of the Breakable Toys given as an example in the book Apprenticeship Patterns is to create a personal Wiki page. The book mentions that in doing this, you can gain knowledge in web design, HTTP, concurrency and parsing. Not only that, but you gain experience and a growth in work ethic, confidence and pride in yourself and your work. An equally beneficial reason to create a personal Wiki page is that it is a perfect way to keep a record of what you learn.

Breakable Toys is a pattern I can see becoming one of the most useful patterns I’ve learned of thus far. With knowledge of this pattern, I am confident that with hard work and dedication – and more than likely a whole lot of screw-ups – my abilities and confidence as a programmer will progress. Going forward in this field, I fully intend to start building some of my own Breakable Toys in order to enhance my skills and broaden my understanding of software development. I would encourage other programming students and programmers alike to invest their time in building their own Breakable Toys.