So this is a pattern that I’m entirely unfamiliar with, as I don’t consider my understanding of a majority of the material sufficient enough to be able to reliably pass it on to another person. However, the pattern immediately addresses this by noting that every little nugget of knowledge can be valuable to someone who might be unfamiliar with it. And as a result, that bit of understanding can thereafter be passed on again, and cascade from the little help that I might have given a fellow programmer. In some ways, it may even be more beneficial to learn tidbits from a peer, as the author mentions that we would be speaking the same language in terms of familiarity. 

While the pattern references the fact that people may not appreciate what you share, I wholeheartedly agree that properly teaching somebody else will solidify the techniques in one’s own mind. If someone is struggling but isn’t willing to hear what you have to offer, they need to improve over several areas in their own right. 

I find it fascinating that the author mentions to be cautious about what you share, as you might be stepping on the toes of a higher up, and unintentionally disclose something that was valuable to an employer. It’s certainly something I’ve never considered before and will take into account going into the future. I’m also glad he mentions the fact that sharing a lesson could be interpreted as conceited or aloof, because from personal experience I’ve lost respect for people like this faster than a Hello World program executes. All in all my takeaway is to temper what you say and read the room when deciding when or when not to share; quite the valuable lesson. 

In the Action portion, I don’t necessarily agree with the recommendations made. Of course there’s no problem with writing blog posts and sharing workshops, but I regard the most important lesson to be to think about how you would engage with someone treating you the same way, if you were approached by them in the same situation. Teach in engaging ways and foster curiosity in your peers, but only if they are willing to accept your olive branch. It’s ultimately a waste of time to preach at someone who isn’t really listening, and worse, judging you for engaging with them.   

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

My biggest takeaway from this is to simply build more things that don’t work, so later on I have the knowledge to make things that do actually work. The quote of the three ball juggler not attempting to push the limit to five balls during a performance is an analogy that really spoke to me in that regard. 

I think the idea of building a personal wiki would be a phenomenal practice for my growth, as I’m constantly forgetting general syntax or git commands that sometimes slow my production rate to a crawl. I built a game for another class that emulated the classic Flappy Bird from a few years ago, and getting that to function would have taken my ages and ages without the help from my groupmates. But reflecting on the experience now, the amount of times we broke that game and the thrill of being able to actually PLAY what I made was something I’d never experienced. Nor with any other art, as I’ve never been one to share any of the sparse create projects I seldom try to come up with. Reading this pattern has kind of put that creation process in a better context for me now, and I hope I retain that going forward as I expand my portfolio to apply for career positions in the future. 

I also like the idea that I own these broken things, but that they will stay with me wherever I go. Just because I can’t make something work at first, doesn’t mean years or months down the road I can easily slap on some extra padding and see how much I’ve grown as a creator. 

Reading on, the Action section really sums up everything that I just reflected on. Especially the wiki idea, which will be the first thing that I try to implement. I know I’ve kind of been harping on very similar patterns, as referenced in the See Also section, but I think this is the biggest area of improvement that I need to work on. For my last post I’ll be sure to expand into a more diverse pattern just to expand the repertoire, but I think it was important for me to recognize the importance of my harping on these specific topics.

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

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.