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.

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.

Practice Practice Practice is an apprenticeship pattern that focuses on the idea that deliberate practice is the best and most efficient way to learn and master a craft. This apprenticeship pattern is similar to breakable toys, but it is more focused on the actual act of practicing rather than the consequence free ability to make mistakes. The pattern talks about doing challenging tasks repeatedly, and noting on what improvements and takeaways you have each time you complete the task. The authors liken it to a sort of programming dojo, similar to that of a martial arts studio, where repetition of motions without opponents is essential to excel in the martial art.

I absolutely agree with this apprenticeship pattern, and believe that practice is realistically the best way to actually learn to become a better programmer. While lectures at school are useful to learn about the subject matter, to truly understand it and begin to master it you need to be able to apply it yourself. I have first hand experience with this thanks to the internship I did last summer. While I do learn a lot in school, lectures and assignments only go so far. Being exposed to real world code and having to learn a lot on the job taught me a lot of practical skills that I otherwise would not have quickly learned. I was also surprised by how quickly I picked up on these things, and that even a little bit of repetition managed to ingrain new information into my head.

While I agree that this apprenticeship pattern is very useful, it can be hard for me to implement in my own life. If I am directed and given tasks to do then I will happily do them and learn new things in the process. The issue comes in when I need to self direct, and that can be difficult for me at times, especially with projects or activities that don’t necessarily peak my interest. For example, in order to practice for interviews I did leetcode questions as often as I could. While I did learn new things through the repetition that came from that, as time went on it became more of a chore and less of something I wanted to do and as such I began to do it less often. I hope to improve on this over time, and be able to stick to repetition for the sake of practice and improvement. Because while I can learn a lot at work, Ill have a harder time improving quickly if I also don’t practice on my own time.

From the blog CS@Worcester – Sebastian's CS Blog by sserafin1 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.

https://blog.devgenius.io/what-are-rest-apis-http-api-vs-rest-api-92c2fe2bb136

For this last blog post, I decided to pick this post on the same blog as the last one, blog.devgenius.io. Admittedly I am picking too many REST API blog posts but I thought this one was a good pick because I’ve never dove deep into why we use REST APIs and what they are as well as some other types of APIs. In this blog post titled “What are REST APIs? HTTP API vs REST API” by The Educative Team (which I assume is a team of authors) they go over HTTP APIs, REST APIs, when to use REST APIs, and what to learn next.

First, they go over what an HTTP API is. It’s an API that uses Hypertext Transfer Protocol as the communication protocol between the two systems. HTTP APIs expose endpoints as API gateways for HTTP requests to have access to a server.
They also go over common alternatives to the popular REST API: GraphQL API, Falcor API, and gRPC APIs. GraphQL APIs are the second most popular form of API and seeks to correct common problems with the REST API structure. It’s open-source and designed to hold data in a tree structure. Falcor API uses much of the REST API architecture with paths and references but automates much of the request structure. Lastly, gRPC APIs are a newer API based off RPC APIs. Almost all of the processing of gRPC APIs are done by the server in RPC architectures.

Next, they go over REST APIs. REST API stands for Representational State Transfer and is an architectural pattern for creating web services. REST APIs see widespread use by application developers due to how simply it communicates with other machines over complex operations. REST is a ruleset that defines best practices for sharing data between clients and the server. It then goes into architectural requirements to be considered a REST API: Client-server, Stateless, Cacheable, Uniform Interface, and Layered System.

Lastly, it goes into when to use REST APIs, when not to, and what to learn next. For when to use REST APIs, REST APIs are great for building general-purpose applications to be scalable in the future. As for when not to, REST is a helpful tool in your toolbelt and a good general rule to follow but it shouldn’t be your programming dogma. For what to learn next, you should learn other API types so you can recognize when a situation calls for a non-REST solution.

I thought this was a good blog post to dip my toes more into REST APIs and just APIs in general. When I was working on my homework, I didn’t really give much thought into the work but when looking into the concepts of the homework more, it’s actually interesting to learn about. I also chose this blog post because it went over other API types that I should learn about if I go into front end development and I thought that was a good takeaway from this post.

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