This Apprenticeship pattern, “A Different Road” is about admitting to yourself if software craftmanship isn’t the career path you want anymore. I think that this is a very important lesson to be learned, because it is much more harmful to yourself, and others that you work with in your field if you stick through doing something you don’t like than if you either take some time away or change career paths entirely. By doing something you don’t like as a career, you are doing a disservice to yourself and others, because you most likely aren’t doing the best as a software developer as you could if you don’t like it, and others may notice that you don’t like it and that you aren’t doing the quality of work that you used to, or that it is less than acceptable.

I think that instead of changing career paths immediately if you aren’t enjoying it anymore, maybe a good idea would be to take some time away, and then return to it later and assess whether you still aren’t enjoying it or not. The reason for this would be to see if you just have burnout from doing it for a while, and then maybe the time away would fix that burnout. You could have burnout for a number of reasons, but maybe taking some time away would fix it by helping you clear your head, and then if you’re still having burnout then it might be time to seriously consider changing careers.

Ultimately, I think it’s best to not force yourself into a career you don’t enjoy doing, and that goes for any career path, not just software development. Not enjoying what you’re doing everyday means that you’re likely doing it worse than you would if you were enjoying it and will inevitably lead to unhappiness. In my opinion, it is much better to do something that you enjoy doing and something you’re passionate about than something that has better pay. Additionally, there will always be other opportunities down the line, meaning a temporary career shift doesn’t have to be permanent, and you can either continue doing what you are, or return to the old job if you’ve discovered that’s what you like best.

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

This Apprenticeship pattern, “Expose Your Ignorance,” is about admitting to others as well as to yourself the gaps in your knowledge. You must admit to yourself the gaps in your knowledge before you can admit it to others and begin to ask meaningful questions to expand your knowledge. I think this is really important to know because if you are unwilling to admit that you don’t know some stuff, then you will be unable to learn it, and furthermore unable to get help from others who possibly know more about the topic. Only by admitting that you have more to learn can you open yourself up to attaining more information, which will help you in the long run.

I think that this is especially important in the software development field, where there are constantly new technologies and tools to learn, and new information about emerging systems that you must learn to keep up with the ever expanding field on software development. If you don’t keep up by learning new things, and thereby exposing your ignorance, then you will quickly fall behind, and may be susceptible to being replaced at your job, or incapable of performing the tasks necessary to fulfill your goals.

I also think that this is applicable to many different fields, not just software craftmanship, where there are always new things to learn, and you must keep up to date with the latest information in order to do your job. One such example would be a doctor, where there is always new medical information coming out, and not knowing about it could be potentially harmful. Any person in a field such as this must be okay with admitting that they don’t know something, instead of pretending like they do and not learning new, important information. Admitting that you don’t know something, and exposing your ignorance, not only makes you seem humble to yourself as well as others, but it also helps others to assess what you do or don’t know so that they are able to help you in areas where you may need it, and you are able to help yourself in this way and by learning it on your own.

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

The context given here is that You want to get better at the things you do and you want to develop concrete skills in new areas. The problem is now that the performance of your daily programming activities does not give you room to learn by making mistakes. It’s as if you’re always on stage. The solution offered is to take the time to practice your craft without interruptions, in an environment where you can feel comfortable making mistakes.

Practice is important because it will get you to where you need to be. We talked about reading and going back to the classics as a way of getting you to master your craft but reading without practicing the acquired knowledge won’t really help. That’s why we believe efficient and deliberate practice methods not only help you learn faster but also help keep you motivated. Over time, this chain of exercises would hone your strengths and correct your weaknesses.

The book emphasizes that short feedback loops need to be incorporated into your practice sessions. While practice is good in theory, if you’re not getting periodic feedback, you’re probably developing bad habits. Over time, the need for constant feedback lessens as you grow as a craftsman, and is gradually replaced by your duty to take on the role of a senior apprentice, modeling good habits by practicing with less experienced developers.

I was very surprised by the following sentence: “Your grandmother may have told you that practice makes perfect. She was wrong. In fact, practice makes permanent. So be careful what you practice, and constantly evaluate it to ensure you haven’t gone stale. Choosing the right thing to practice every day is a skill almost as important as the act of repeated practice.”

The lines above shows that we could easily get comfortable and stop making concrete progress. Practicing is good but it has to be diverse to allow the growth to happen. The point is not to hone your memory, but to discover the nuances in even the simplest skilled activity. An easy to implement it could be as simple as finding an exercise in one of your old books and tweak it a little bit to make sure that it’s just a little harder than one you know you can easily solve.

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

The context of this pattern is that you are being enthusiastic about your passion to the points where it has open doors for you. The problem is such that there seems to be an endless stream of deeper and more fundamental concepts that are eluding you, despite the proficiency that you already have. The solution offered is to focus the thirst for learning on consuming as much of the written word as possible. Emphasize books over blogs as you construct your reading list.

The book emphasizes that reading the occasional research paper will stretch your mind and keep you in touch with the cutting edge of computer science, and also offers a source of challenging new ideas. Trying to implement these ideas will expand your toolbox with new algorithms, data structures, and design patterns many years before they reach the mainstream. An Important fact to remember is that Successful apprentices tend to focus on “long-lived books” and use the Web or experimentation to learn how the information has evolved and that’s why we should focus on going back to the classics. That being said, one danger of focusing on the classics is taking it too far and abandoning the more pragmatic knowledge and information that enables you to improve your day-to-day craftsmanship. Be sure to intermingle classics with modern, pragmatic books and/or articles in your reading list.

I really resonated with this because reading books hasn’t always been fun for me. Thankfully, the eBook and audio version of things have made it easier. I also like that they ended the pattern by the following: First, the trick is to keep up the momentum. After you’ve finished this book, decide now what your next book will be and make sure to buy or borrow it so that when you finish this book, you can switch immediately to the next one. Second, you should also try to keep a slim book with you at all times. This will let you use the little bits of dead time throughout each day (such as train journeys or waiting in queues) to learn. Third, Find the oldest book in your developer’s book collection and read that one first.

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

Breakable Toys

Success is often a tool used to measure how effective you are as a programmer, but this isn’t quite true. Failure is often referred to as the great teacher, as learning from mistakes that you make is great for improving yourself. The idea behind this is that if everything you make is bound to succeed every time then the process behind it might not haven hard. Things that don’t challenge you are not going to fail for you, but at the same time you are not going to learn anything from it.

This pattern is to take something, try to build it, and learn from your failure. You can be skilled and incredibly proficient in your strong suits but if you are not failing as you proceed you might not be challenging yourself. You might stagnate in your skill, and while you can be incredibly good at it, you still are not learning anything that is challenging you.

This particular pattern I agree with. Learning through adversity is often a great motivator. For some, time is an incredible motivator and through procrastination you have a literal time limit challenging you. For some, something new is an incredible motivator as it’s something utterly foreign and waiting to be explored. You should try something new to learn how your own skills are developing. Failure at first can deter you but taking this approach will teach you how failure will motivate you. You couldn’t succeed, but it doesn’t mean you cannot. You’ll find yourself thinking endlessly on that failure and seeing how others have succeeded where you failed will motivate you to think it has to be done. After all someone else has done it or likely created something like it. Take on a new library, build something that you never have before and let it break apart in your hands. Take the pieces and try building it again. In a sense you are letting yourself be broken by your broken project. Just challenging yourself will not be enough you have to learn from failure and learn how to fail. This pattern honestly should be called Breakable Self, as the learning portion isn’t the failed build, but rather using that failure to break a common mindset to succeed where you once failed.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

“Learning How You Fail” is all about realizing that you’ve grown in mastery but at the same time remain stagnant in other areas. Rather than trying to overcompensate for shortcomings, taking the same effort and seeking introspection instead seems to be more worthwhile. When I think about it that way it makes sense, although breaking out of the habits I’ve already formed will prove to be difficult.

I do agree with the sentiment of this pattern, but the thought of someone’s natural ability to either be great at something or bad at something comes to mind. Is it worth the energy to be less bad at a certain thing when you can excel elsewhere? At the end of the day, I guess that answer varies from person to person. But there is something admirable to say about someone who you’ve watched improve at something they were originally horrible at.

The “Learn How You Fail” pattern seems to be a preemptive strike of some sort. Figuring out how you will fail doing something allows you to do your best to steer clear of the pitfalls that lead you to your failure. Throughout my life, I have been one to make the same mistakes repeatedly. I’ve always said that I’m just persistent, and I am. But I would probably gain a lot more from my persistence if chose to analyze what had gone wrong, rather than to try and brute force my way through certain things.

The scenario painted in this pattern is to write some code that performs a binary search in a simple text editor and continue to fix the code until we believe it’s perfect. Once the code has reached our level of satisfaction, we also write test code from scratch. I think the point of this exercise is to realize that we ourselves may not be as perfect as we think we are. While I feel like this pattern can be applied to software apprenticeship, I feel like it’s more suitable “life advice”. Perhaps I’m not opening my mind enough and that’s a failure I could learn to learn more about.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 and used with permission of the author. All other rights reserved by the author.

In opposition to my personal experience with almost every other pattern, this is one that I very much struggle with. I have enthusiasm for certain things, but I find my motivation and discipline to be very shaky in my average lifestyle. This might have to do with personal mental health struggles and general disposition, and to be fair I’m still young enough to be unfamiliar with a passion I could truly want to pursue.  

To be completely honest, I believe this is the most difficult pattern for me to grapple with. I’ve certainly been involved with different types of projects where I was more enthusiastic compared to my other teammates, but they are few and far between. However, something that I can aspire to learn is the freedom of my enthusiasm as a “responsibility of the apprentice.” I find this line to be profoundly interesting, as I would have originally thought that the more experienced veterans embodied this type of archetype. Upon reflection though, I realize how mistaken I was, as innovators can’t be pigeonholed into time spent in an industry; rather the fresh ideas that emerge from newly aspiring minds are the most important part of the process. Regardless, I’ve learned that despite age or experience, a person who’s passionate about whatever they’re working on has (somewhat) the inherent obligation to innovate in the industry they work in. 

Unfortunately, I’m of the mindset that one should do the bare minimum to pass as a competent employee; I don’t know if this is because I’ve worked enough minimum wage jobs to understand the dynamic, or if I’m a lazy person inherently. Not to say that going above and beyond is a bad thing, but that raising the expectations eventually leads to a standard for most people that is unfair and not an expected level of engagement with the job. 

Anyways, with the last portion of the “Action” section, I see a true position where I’m lacking in my work ethic. I’ve certainly been in the place where I’ve declined to present an idea that may or may not be applicable to the project in question. It’s not that I’m reluctant to share, but more so I’m not inclined to add an argument/idea where it’s not necessarily necessary. I absolutely contribute where I think an idea may be beneficial, but in my experience it’s not worth the hassle to say something that could be thrown out with a disregard to the necessity of the point being made. Regardless, I’m certainly going to take this advice to heart and implement it in the future.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

I think this is some of the best advice that the Apprenticeship Patterns have to offer. Stagnating in the learning process is an incredibly difficult problem to resolve, as learning is such a unique process to each individual person. I learn quite differently from my brother, while he and I learn wildly different from my father. With such a discrepancy even within a family, I think this is a very poignant point to address. From a personal standpoint, I’ve certainly experienced this phenomenon to an extensive degree. My ability to intake new information varies drastically based on how interesting I find the topic.

As the author mentions, “Dave’s not knowing stance helped him to collaborate with the family to find solutions as a team.” I find this to be invaluable advice; maybe I’m a little jaded, but I believe most people have no idea how much they don’t actually know. The capacity of people to not understand how uninformed they may be on certain topics genuinely shocks me sometimes. Even worse, this type of person often thinks other people are wrong when they are woefully uneducated on whatever the topic may be. Apologies for ranting about this for so long; it’s genuinely one of the most frustrating things I find about the modern era. I blame the internet honestly. 

I don’t want to claim I’m an expert on people, but this is something common I’ve frequently observed in various jobs or interactions. To step off my high horse for a minute, I generally tend to regard myself as an idiot in most situations – not even as a self-deprecation thing. I find that humility in knowledge is one of the most valuable traits that anyone can have, in literally every situation. Akin to “not wanting to be the smartest person in a room,” I think there is, without a doubt, ALWAYS something that can be gleaned from a dispute or conversation. After opening up my biases or assumptions in some ways, my opinions have been drastically changed in ways I could have never predicted. Even if one is an expert at something, I find it incredibly important to maintain this white belt mindset.    

I realize I’ve definitely deviated from the original point of the pattern, but because I’m so adamant about this type of subject I felt the need to rant a little bit. Thanks for coming to my Ted talk. 

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.