“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.

Hello, blog (mood-status: relax), writing this blog after coming home from work, finishing the exams, and submitting assignments. But anyway, on writing about this week-15. I am writing this as my “final” blog for the year 2021 for real. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Patterns & anti-patterns.

Patterns

Patterns are part of everyday language, but it’s essential to discuss algorithms to understand their importance in software engineering. An algorithm performs a daily task like sorting a list of items, storing data for efficient retrieval, or counting occurrences of an object within a data set.

 Algorithms are among the most used fundamental concepts in software engineering. It mainly highlights proofs of its solutions and its only code samples in obscure, ancient languages such as Algol or MIX Assembly. Despite much covered: singly- and double-linked lists, trees, garbage collection, etc. The details are hiding in problematic libraries, but the concepts are the same. These algorithms have remained reasonable solutions to common software engineering problems for more than five decades and are still going strong.

A “pattern” can be a general structure of an algorithm. In algorithm focus on a specific programming task, a pattern challenges beyond that domain and areas such as reducing defect rates, increasing code maintainability or allowing large teams to work more effectively together. Some standard practices include:

• Factories
• Pub/Sub
• Public-key Cryptography
• Agile
  

These are four common patterns in the industry; it ranges from highly technical to broader, more process-oriented points. Factories are very code-oriented, while pub/sub is more architectural. While public-key cryptography has general importance, libraries to support its operations are available for almost every programming language in everyday use, making it generally short of implementation.

At the other end of the expanse, “Agile” remains unavailable: a point and a tool among developers, project managers, and other stakeholders about precisely what it means and how it should be implemented. From Narrow or broad, technical or process-oriented, excellent working knowledge of these patterns is an essential component in a technologist’s toolbox.

What is an Anti-Pattern?

A “pattern” is a known-to-work solution to a common software engineering problem (anti-pattern). Anti-patterns do not incorporate the idea of failure to do the right thing, including options that seem right at face value but direct to trouble in the long run.

Note the reference to “a common response.” Anti-patterns are not a few mistakes; they are familiar and always followed with good choices. As with regular patterns, anti-patterns can be broad or very specific, and there may be hundreds to consider in the realms of programming languages and frameworks.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.

Hello, blog (mood-status: relax), writing this blog after coming home from work, finishing the exams, and submitting assignments. But anyway, on writing about this week-15. I am writing this as my “final” blog for the year 2021 for real. I decided to go on the Syllabus once again to look at the course topics. Then I choose the subject of the Patterns & anti-patterns.

Patterns

Patterns are part of everyday language, but it’s essential to discuss algorithms to understand their importance in software engineering. An algorithm performs a daily task like sorting a list of items, storing data for efficient retrieval, or counting occurrences of an object within a data set.

 Algorithms are among the most used fundamental concepts in software engineering. It mainly highlights proofs of its solutions and its only code samples in obscure, ancient languages such as Algol or MIX Assembly. Despite much covered: singly- and double-linked lists, trees, garbage collection, etc. The details are hiding in problematic libraries, but the concepts are the same. These algorithms have remained reasonable solutions to common software engineering problems for more than five decades and are still going strong.

A “pattern” can be a general structure of an algorithm. In algorithm focus on a specific programming task, a pattern challenges beyond that domain and areas such as reducing defect rates, increasing code maintainability or allowing large teams to work more effectively together. Some standard practices include:

• Factories
• Pub/Sub
• Public-key Cryptography
• Agile
  

These are four common patterns in the industry; it ranges from highly technical to broader, more process-oriented points. Factories are very code-oriented, while pub/sub is more architectural. While public-key cryptography has general importance, libraries to support its operations are available for almost every programming language in everyday use, making it generally short of implementation.

At the other end of the expanse, “Agile” remains unavailable: a point and a tool among developers, project managers, and other stakeholders about precisely what it means and how it should be implemented. From Narrow or broad, technical or process-oriented, excellent working knowledge of these patterns is an essential component in a technologist’s toolbox.

What is an Anti-Pattern?

A “pattern” is a known-to-work solution to a common software engineering problem (anti-pattern). Anti-patterns do not incorporate the idea of failure to do the right thing, including options that seem right at face value but direct to trouble in the long run.

Note the reference to “a common response.” Anti-patterns are not a few mistakes; they are familiar and always followed with good choices. As with regular patterns, anti-patterns can be broad or very specific, and there may be hundreds to consider in the realms of programming languages and frameworks.

From the blog Andrew Lam’s little blog by Andrew Lam and used with permission of the author. All other rights reserved by the author.