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.

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.

Concrete Skills

This pattern is something I’m personally invested in, as the feeling of imposter syndrome is incredibly hard to shake. Depending on the career path I eventually go down, I plan to get as familiar with whatever basic techniques and software that the project will be using. I’ll undoubtedly be inexperienced and unprepared, but to demonstrate a basic level of competency with the most basic of the workload, I want to be as proficient as possible with the fundamentals. My biggest fear would be what the pattern refers to as “day care,” as I would loathe to be babysat in such a professional setting. On top of this, I thought the comment that one’s concrete skills are basically what get your foot in the door was quite insightful for someone like me lacking any sort of hiring experience. I’m also very grateful that the pattern lists a few of the concrete skills with examples like understanding of open source frameworks or basic web design. 

In addition to stressing the importance of the concrete fundamentals, the pattern also goes on to explain how your reputation can be based on the credibility of your portfolio. As you grow from being the new guy into a successful developer, your work will speak for itself and shatter that initial requirement for consistent fundamentals. While the former is still important, you won’t have to work nearly as hard to prove your utility to a team.

For the Action portion of this pattern, I’m certainly on board and will implement this in my future job searches. While considering a few different professionals, there may be consistently noted discrete skills in the CVs, so that could be a great skill to implement regardless of the career path. On the other hand, some of those skills may be niche, but hyper specific to the type of job you’d like to apply to in the future. The pattern recommends regularly examining your own CV and implementing a similar kind of honed skill set for the specific position you may be applying to. On top of this, I would say that engaging with professionals or colleagues in this manner would work to bolster professional relationships, which could lead to advances down the road if they reflect on your tenacity. 

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 pattern really focused on the idea of your value as the new guy in a fresh team environment. Each party has no idea about the other’s techniques, patterns, thought processes, or communication abilities. While you’ll naturally get acclimated to the team through experience, it’s always a good technique to pick up some of the menail, but important work. It should show the team that you’re willing to pitch in, and if you take your time to make that menial work look stellar, then that’s an even better indicator of your talent and value to the team. It warns of becoming the team’s “gopher,” which I would say is a valid caveat; I guess I would prefer to think that most people are more professional than that.

For the majority of the pattern, I wholeheartedly agreed with this advice. It should garner comradery with your peers, and an improved understanding of the project – I would apply this to any sort of team effort in general, because if the members operate in good faith then it should promote the team to be a more effective unit (theoretically).  The only thing that I have a bit of a disagreement with is the assertion that you might be relegated to that menial work by default, after trying to sweep the floor for too long. I’d say as long as you engage with teammates about where they are on the project, ask questions, and actually learn from those conversations, you should be at least relatively qualified to work on more challenging tasks. On top of your understanding of the different project parts, I’m confident your peers will recognize your engagement and welcome you to cooperate with different or more challenging content.   

Finally, I can understand the sentiment that one won’t appreciate the bigger picture of the project, or would get uncomfortable attempting new types of work outside of their comfort zone. These are very different problems, and require a good amount of introspection to address in my opinion. I’m going to look at the referenced patterns near the bottom to see if he elaborates further.

I think the most important lesson I got from this pattern is not to make yourself useful initially, but make everything that you tinker with is as close to your best work as you can get it. Who knows who’ll be impressed?

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