Monthly Archives: February 2022

Reflection on the Long Road Apprenticeship Pattern

The Long Road is meant to temper expectations. It lays out the path to mastery of software development as one of lifelong learning, and not one of chasing wealth or position. It is about taking jobs and opportunities that will help you continue your journey to gain more experience and knowledge and to prioritize this over promotions and salary raises. It is about finding the knowledge at the heart of software development.

I think that not only is this pattern good advice to software developers but offers good life advice as well. I personally believe that life is about the journey and that new experiences and gaining more knowledge is far more important than gaining more monetary wealth. I don’t care too much about money in general and I think that having this mentality about moving forward in my career lays out a life that will leave me a lot happier and more content when it comes time for me to leave it all behind. I didn’t get into computers to take a middle management job, I came here so I could enjoy what I do and get really bloody good at it. I just found the part about growth over wealth to be such a good way of looking at software development, and I think is kind of the opposite of why a lot of people get into it. I feel like a lot of people get CS degrees because they want to make money, and not so much for the love of the craft, and I think that’s just a path to disaster. I hope I’m wrong, but if you can learn to love the journey I think you’ll have a lot more fun along the way.

However, I do disagree with the notion that this pattern (and this book, as they say) is not However, I do disagree with the notion that this pattern (and this book, as they say) is not for people that want to take different paths. I think it is entirely reasonable to believe that even those who don’t want to continue a software development career for their entire lives still want to master the craft and continue their development journey even if they choose not to continue down a career in it. There are many people who don’t pursue full-on careers in software development, but still love coding and want to continue to grow their skills. Hobbyist game designers or developers are out there, and I think that that choice is completely valid and that this pattern still applies to those that choose something else. I just don’t like the gatekeeping nature of that comment in this pattern. Mastery does not necessitate a career in development. Do what you want, and enjoy the journey.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

Your First Language

For the following few years this could be the principal language if you`re requested to remedy a hassle and it dictates a programming language, permit the force closer to. If you`re pursuing a process that calls for a selected language, construct a toy software for the use of that language, ideally an open supply undertaking so it is straightforward for the distinction among a hassle taking mins or days of your time.  This enables to floor your studying in fact and offers essential manner to enhance this revel in is to are seeking for out possibilities to create comments languages have higher gear for comments than others, however no matter the language, you may take a few steps to installation a studying sandbox to test in.  Many languages offer equal empty Java elegance open in his IDE while he wishes to mess around with an unexpected API or language function: Once you`ve found out sufficient to in reality begin writing code, test-pushed improvement strategies to the recognition of test-pushed improvement, you`ll be hard-pressed to discover a language that don`t hesitate to put in writing easy assessments to test your information of the language, or simply to make yourself familiar with the checking out framework.  Eventually, you’ll move from simply writing studying assessments to writing assessments that look at your real code in place of your information of language constructs and APIs.

Over time, you’ll discover that there are numerous different strategies past easy unit checking out that use the pc to the following is a dialogue of studying to assume in a different way through studying a brand-new language, by the way the quality manner analyzes a language is to paintings with a professional in it.

I fully agree with Your first Language pattern. Especially with creating feedback loops to help gauge your progress. I know for myself personally; I like to look back at code that I may have changed to see where I improved on and where I need to improve. Also, by reaching out to a team member that may be stronger in set language is also a good resource to utilize. However, as stated in the text, I agree that as a programmer, you do not want to make it a habit. Although seeking help is a great tool to learn, being dependent on that resource will hinder your ability to grow as a programmer and understand the material at hand.

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

I found it very interesting reading about the journey to becoming a Software Craftsman. I think that many of the principles discussed here are relevant not only for people in software development, but for people in all walks of life. The base principles can be applied for anyone learning anything, and they’ll still hold true. For example, it discussed “emptying your cup” before trying to pour stuff in as a metaphor for not relying on old information when doing something new, to view new information on its own as to not transfer old habits to new skills. I think that this is a great skill for learning anything because it’s always a habit to fall back on what you know rather than expanding your knowledge to something new.

Something that I found interesting was the book’s lesson of seeking enhanced knowledge opportunities over enhanced pay opportunities. I think this is a very important lesson is today’s world because even if you do take a higher paying job, if you don’t keep up with the latest developments then you’ll fall behind and likely be replaced by someone who is keeping up. Also, seeking enhanced learning opportunities will likely lead to enhanced pay opportunities, but the same can’t be said for the other way around. For these reasons, I strongly agreed with this lesson, and I think that it’s a really important thing to emphasize because it’s often something that people either don’t learn or learn too late.

This ties into what I found in the reading that changed my opinion. Previously, I thought that the “correct” path was to get as many certifications as possible and to have an impressive looking resume even if you aren’t actually proficient in those things. The reading changed my opinion to the view that knowledge is more important than certifications, and even if you do have an impressive looking skillset on paper, that doesn’t mean that you’ll be good at a certain job or task.

However, one thing that I disagreed with was that some information must be learned from books, and that the information online can’t compare or replace the old information found in books. I disagree with this because I think that these days there are so many great resources online to learn software development, even from just things like YouTube. I think that you can find the people with more knowledge than you that the reading emphasized as important online, without ever even opening a book.

Lastly, I think that the most important chapter is chapter 4, on accurate self-assessment. I think this because without accurate self-assessment, you won’t be able to improve or pick up new skills or knowledge. The first step to improving at anything is admitting that there’s more to learn, or that you could be better at certain aspects of something. If you think that you have nothing to improve upon, then you’ll never expand your knowledge or skillset.

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 journey of a Software Craftsman 

In past years, various crafts, like blacksmiths, and more recently plumbers and electricians have followed a process where a craftsman’s skills were developed over 3 basic stages. When just starting out, an apprentice is taught the basics of his craft, and earns their keep by doing menial tasks and odd jobs, along with a basic wage. After becoming more adept at their craft, they “graduate” to journeyman. Since their skills are now more valuable, they then can do the work of a journeyman. They are now in a position to keep learning from the masters, but also to be in a position to teach what they have learned to new apprentices, and are then given responsibilities and compensation to reflect their new status. Eventually, when they have learned all that they can from their mentors, they become masters in their own right, and are positioned to start their own business.

This can be correlated to the growth of a software developer. The Computer Science college student in combination with their first few years as a developer in industry are equivalent to being an apprentice. My first title was Junior Programmer. The names have changed so much over the years because of the growth of the industry that specific titles are almost meaningless when compared over the years, but one of many potential titles for apprentice may be Entry-Level Software Developer. When they reach the equivalent of a journeyman level, they may have progressed forward to having a skillset of Software Engineer, Database Analyst, Mobile Developer, or may have jumped into a management position. In any case, they have either directed their career path or grown into a certain role where they are now in a position to be competent and valuable in their “craft” and may be rewarded financially and socially rewarded for their efforts. Whichever of the hundreds of possible fields they may have climbed to, they are hopefully still learning from their “masters”, peers, and most importantly, their own self-directed educational path. The “master” title could be correlated with Senior Software Engineer, Software Architect, or many other roles. The most important factor at this point is that they still keep learning.

The Apprenticeship Patterns book is a comprehensive guide to not only how to grow in your career, but also to continue to love to do the work. It explains well the soft skills that are necessary to be happy, productive, socially respected, and egalitarian in your career. Worrying about how much money you make or being the best on your team are common goals but need to be considered less important then being a life-long learner in a field you truly love. Who could ask for more?

The book then proceeds through 6 chapters that describe Zenlike wisdom on ways to smooth the transition through the journey. Emptying the Cup was particularly important for me. I tend by nature to be impatient at times, and not to listen well enough. This is a particularly important one for me keep practicing. I also like the advice from Walking the long road. I never expected I would every surpass the knowledge of Linus Torvalds, but I do realize that my life’s journey may produce positive results in a direction that helps the software world, as well as keeping food on the table.

1. Dave Hoover and Adewale Oshineye. 2009. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman (1st. ed.). O'Reilly Media, Inc.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Read Constantly

This is the first in a series of short blog posts I will be making about the book “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye, discussing individual patterns from the book. This week I am looking at the pattern called “Read Constantly” from chapter six.

The scenario this pattern covers is one in which a programmer is feeling overwhelmed by new information. This is happening even in spite of a good amount of proficiency and enthusiasm. The proposal here is to read constantly in order to catch up on old developments in the field and stay ahead of new ones as much as possible. This also means prioritizing denser sources of information such as books or occasional research articles over things like blog posts, for example. The authors also suggest keeping a small (and thus easily portable) book on your person at all times to read whenever you have downtime.

I don’t really read as much as I would like to. It’d be good to do more reading, especially about the software field, so I think that is useful advice. I have some issues with the framing of this pattern, though.

I don’t fully agree with the outlook of “catching up” to people like Linus Torvalds, who the authors namedrop here, or with how the authors view people like him. I don’t think, taking Torvalds for instance, that he got where he is purely through effort. This isn’t to say that he’s lacking in talent in any way – rather that he got where he was through a combination of being a highly motivated person and being in the right place at the right time in the industry. I don’t think you can make up the latter part through sheer effort alone. I view it as sort of like the lottery – it’d be nice, and you could increase your chances by buying tickets regularly, but it’s misguided to have winning the lottery as a goal when it’s ultimately out of your control.

I think it’s good to read more, of course. I just don’t agree with constant reading specifically as a way to stay “competitive” in the software industry. I do not have the background to make this kind of claim, but I also suspect there’s diminishing returns when you try to cram as much information into your head as possible.

Having read this section, I think I will actually read more, or at least make some effort to. I’ll also probably try to read more about programming and technology specifically. I just don’t think I will take it as far as the authors recommend.

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

Apprenticeship Patterns Chapters 1-6

When reading “Apprenticeship Patterns” one thing really stood out to me: I am a beginner developer. Despite being a senior in college, I still have much to learn. I had considered myself a competent developer who can teach myself new skills, but the breadth of skills available to a software developer is so wide that I could not see everything if I tried. There is so much more to software development than learning how to code, or how sorting algorithms work.

One thing that I am excited to do is learn from more experienced developers. Programming is such a creative skill that there are infinite ways to do the same thing. A solution that I think is elegant may be clunky and inefficient to a master developer, and vice versa. A master could identify a dead-end project months before I could, without the effort needed to actually try and develop the project. A master could recommend the best course of action for any given task, I would try the first thing that came to mind only to realize it was the wrong method.

These skills aren’t taught in college; it is not possible to. These skills are developed through years of experience and trail-and-error that college cannot possibly provide. Before reading “Apprenticeship Patterns” I thought that I was ready to develop software. After, I realize that I am ready to learn the craft. College has prepped me with the baseline knowledge I need to understand what journeymen and masters will teach me.

Another thing I like about “Apprenticeship Patterns” was the idea that the primary instructor in my life is me. No one else can force me to learn and get better. It is my responsibility to pursue higher knowledge, really listen and think about what others have to teach, and have an open mind to difficult and foreign tasks. Staying in your rut and only doing what you are good at is an easy way to stay mediocre. As an apprentice, it is my job to break out of that rut and try new things. Only by trying new things and being uncomfortable can I truly grow as a developer.

From the blog CS@Worcester – Ryan Blog by rtrembley and used with permission of the author. All other rights reserved by the author.

Your First Language

This week I chose to write about “Your First Language”. The problem laid out in the beginning of the chapter is that the apprentice only knows basic knowledge of a few languages. This is a problem I have spent some time thinking about. But it is difficult for me to pick, which language I want to fully dive into. I have programmed in Java, JavaScript, C#, C++, and Python. I know the Java standard library better than any other language’s library. And I know the data types, and data structures better in Java as well. Java is what I learned in Intro to Programming, and Data structures. Java is also what I use for coding interview prep. Many of my peers are language Evangelicals, but I feel like a man without a country. I have never built anything in Java, that wasn’t an academic project, or a coding interview problem. I have used JavaScript and C# do build web apps. With all of this being said, I knew I needed guidance from this design pattern.

The author suggests that the apprentice choose one language to solve problems with. And stick with that language for years. And that his first language will be the basis on which he solves problems. For me, I think I am going to let fate decide. Whichever language I need for my first job, that language will be my first language. Many entry level software job postings just say ” “proficient in one modern language” and the assessment can be taking in any language. The author suggests that the apprentice seek out an expert in the language, so he learn from the expert. When I am on the job, I will have access to experts, and a lot of time to learn. For now, I will keep practicing LeetCode in Java, and build web apps in JavaScript for this course. I don’t have time for much else. But this design pattern has made me realize how important having a strong foundation in one language is, and I am eager to start working towards that goal.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Be the Worst

After looking at the list of Apprenticeship Patterns, the one titled “Be the Worst” caught my attention. I was curious as to why you would want to be the worst. After all, conventional wisdom would suggest that one should try to be the best. However, after reading about the pattern, being the worst is a way to become better. The pattern explains that you should aim to constantly surround yourself by developers that are better than you. By doing so, you would give yourself room to grow. Being in a strong team gives you an opportunity to learn the effective techniques, tips, and methods that stronger developers use. The goal is not to constantly remain the worst, but rather, to work hard to climb your way up from the bottom and become equal to the other members.

However, there are a few risks with being the worst. One of these risks is feeling bad about yourself and your skills. Being the worst member of the team means you are not up to par with everybody else, and that could lead you to become even less productive. Another risk that you could run into is dragging the team down. Being the weakest member, some teams might not tolerate your weakness for long, especially if you do not put in the effort to constantly improve and hone your skills. If you fall too far behind, then you risk getting fired. The way to avoid these risks is to make yourself useful by doing explicitly doing menial tasks and by developing concrete skills to increase the amount of your contributions. Rapid growth is what these teams want to see, and it is likely why you were hired to join them.

I think Be the Worst is a useful pattern. It gives a clear idea or a method as to how developers can grow professionally and actively hone their skills. While there are risks involved in being the worst, it can be avoided with a strong drive to improve and be a contributing member. The potential benefits of this pattern are immense and it should be something that every apprentice developer should look into.

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

Apprenticeship Pattern “Your First Language”

This apprenticeship pattern describes how we should approach our first language and how develop our craft in it. The greatest and simplest way for us to master our first language is to tackle real problems to solve. It is beneficial for us to practice problems and code that provide feedback to us with an example being using a print line function to see what we’re getting from specific functions and methods from maybe certain APIs. These test-driven results really teach us to take small steps in developing code and to take a step-by-step approach to testing out assumptions on what we’ve written. We also should always try to learn from more experienced peers. They can help provide insight into some of the nuances in the programming language we are trying to learn.  Also, don’t shy away from focusing on what you’re not good at, try to branch out of what you’re comfortable with and try different types of coding outside of your comfort zone.

What I’ve taken away from this is to try and solve real situational problems to help us learn how to code. A lot of times as students, we tend to just try to get assignments done without truly understanding how certain parts of our code work. We are just learning our first programming languages and are never forced to understand how to use certain things for specific situations. That’s where I believe that using mentors to our advantages work very well. We are able to ask them for help to help us understand the reasoning behind why we use certain things.

This pattern has been insightful into the basics of how to approach my first language. I personally shy away from the things I am weak in and tend to focus more of my time into what I’m good at. As a software engineer, I shouldn’t be scared to tackle problems that I’m not comfortable with but now feel as though I should go back and revisit what I’m not comfortable in. I should be able to use my resources and the people around me to begin to get better at what I’m bad at and to use test driven results to help bridge the gap with what I’m bad at. If I do not understand something, there are always ways to get around and to better myself.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

The White Belt

As I started looking into the list of patterns, “The White Belt” hit the nail on my head as the problem illustrated in this pattern looks like what I’m currently facing, or have been facing against for a while I would say. I think the first time I found myself in a “wrong place” with programming was in a Hackathon back in spring 2021.

The situation was my teammates were all having Java background so we decided to create an Android Application using Android Studio so everyone can write code in Java. However, things began to feel strange as we started, Java here is not what we were familiar with actually, the coding concept is different as we have to understand what we need and find out the right documentation according to the problem, something that we were not supposed to do initially, but it’s impossible to change the project now as it might collapse team spirit. Therefore, I had to wear the “black belt” and learned the hard way to figure out how to implement features in a short period of time. The repository that we were working on that time if you want to check: OPCredit

This project damaged my thinking more than it improved my knowledge as I feared that my personal development has stalled because I can’t write Java while Java is my first programming language. According to the solution and action indicated in the book, I ameliorated the situation by learning basic JavaScript, I was impressed by how less complex the code is compared to Java while doing the same thing. Then, as I proceed to learn its frameworks, and from ES5 to ES6, in my view, this is one perfect instance where you shouldn’t suppose to already know what will be implemented, but to be neonate and accept the concept.

By the time this post is online, I was learning CI/CD and Docker, something that is not related to my first language as I will have to understand what is happening in the Command Line Interface to give the container the correct solution. This time, I will wear “The White Belt” even more carefully to not only learn what I have to learn but also to practice how to use this belt for future progression.

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