Category Archives: Week 3

Your First Language

No matter the area, everyone must start from somewhere. In Apprenticeship Patterns, the author addresses this concern for learning to program in his patten “Your First Language.” Your first language will determine your career direction, and it is essential to make sure your initial language aligns with your desired career path. For instance, an individual who aspires to be a Game developer should learn C++, whereas someone interested in data science should learn python as their first language. For someone who wants to be a software developer, their first language is flexible and can solve as many problems as possible that their work demands. The author also suggests that tests should be used frequently while learning your first language to check your understanding of the language over time.

While reading this pattern, I reflected on how I learned my first language, JavaScript, using NodeJS. I personally related to the pattern’s recommendations. This pattern is beneficial for individuals who have yet to learn a programming language or are still on the fence about which one to dive into deeper. I found it interesting the pattern recommends focusing on learning testing libraries to check your knowledge of the language while you are also learning to program in it.

Doing this would be challenging at first but prove to be beneficial in the long-term because of how necessary testing is in the software world. I have created software in the past while completely excluding testing from the project, and I did this from lack of knowledge of how to test and not understanding the importance of testing long-term. If I had known this pattern earlier, I would have incorporated testing into my process of learning my first language.

I slightly disagree with the pattern’s suggestion that you choose your first language based on whether you have someone in your network who can act as a teacher to guide you with learning that language. I think it would be beneficial in some situations, but if someone cannot network with a person who knows about the language they want to learn, I do not think this should be a limiting factor. There are many online resources and forms that can act as learning opportunities that can stand in place of a single person who can act as a teacher or a guide.

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

Apprenticeship Pattern: “Your First Language”

This Apprenticeship Pattern deals with a beginner programmer trying to enter the field by learning his first programming language. The pattern suggests various ways the beginner programmer can increase his experience, including but not limited to: learning a programming language from a friend, reading books based on it, and or joining a community around that language.

One of the things I find particularly surprising that is mentioned in this pattern is utilizing “test-driven development techniques”. While I have used testing before as I was learning my first programming language, it may have helped me learn features about the language and development in general that I haven’t yet thought of. For instance, if I create a class and I need to test it, creating test cases allows me to break down a class that I understand and view it from a different perspective.

This pattern has somewhat changed the way I think about my profession. Much of the changes in my thought about my career have to do with an explicit acknowledgement from reading this pattern, especially in relation to things I’ve known but never completely acknowledged. Mastering a programming language really does make the most sense to me, and it is something I’ll recommend when others who want to get into programming ask me.

I do disagree with two parts of this pattern. The first is in relation to which programming language one should choose. This may cause difficulty due to the issue of a complete beginner not having appropriate context to the uses of a language, and thus if left alone he could make a decision that could limit his beginning programming experience, and thereby causing a ripple effect down his career. 

The select part I disagree with follows up from the first. If he decides to learn a programming language based on his friends, this may cause a similar issue. If he decides to learn JavaScript from his friends, which he could eventually master, he could have a hard time contextualizing other features present in other languages. Thus, even though the pattern mentions not to be pushed towards a “one-size-fits all approach”, learning a more general programming language like C++, though fairly dense, can give more context to other languages, from JavaScript to x86 Assembly. 

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

Concrete Skills

This pattern starts off with a strong quote by Pele McBreen by saying, “Having knowledge is not the same as having the skill and practical ability to apply that knowledge to create software applications. This is where craftsmanship comes in”. I agree 100% to this quote. Until I was a junior, I had no idea where to apply my coding skills I learned this far from classes such as cs140, cs101, cs242 or any computer science classes. Then I decided to think of some side projects I can do, or I can try to do, and the first thought was a discord bot. I did create a discord bot for a group of mobile gamers using java. The bot basically returned how much time is left for a game tournament, and the bot also greeted every new members that came to the group. This was a fun project, but it was not enough for me, so I decided to focus on a project which I can keep on building overtime. Something to enhanced my both frontend and backend skill, so in order to do that I made my own simple static website with the custom domain name of sandeshgurung.com. Now my primary goal is to add more content to my website while also showing my skills at the same time.

As for the pattern, it felt like what I need to read at the moment as I am applying for jobs, intern, or any contract jobs. The context is to get a hold of a talented team of craftsmen who can provide me with a better learning opportunities than I currently have. The problem is that no team or company want to hire someone who can slow them down or even can be any help to them at all. The solution is to acquire some concrete skills that would get me past the crude HR filters and managers. Some concrete skills examples can be writing build files which many open source frameworks such as Vue.js that we are using for our capstone project.

The best knowledge I got from this pattern is from the Action section, which basically said to get the CV from the people whose skills I respect. Locate their skills and identify which can be immediately useful on the type of team I want to join. Plan a project based on that skill and implement it.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern “The White Belt”

This apprenticeship pattern describes as how we as programmers are comfortable with the language that we are best at and then how we try to apply our knowledge to learning something else. In the end it is hard to learn something new that way. What we realize by doing this is that it is difficult to then try and learn something new, and then we may end up becoming stagnant in our growth. The white belt method tells us to forget everything we thought we knew previously and come into learning something new with the mindset of a beginner. Although we lose productivity in the beginning, it will end up being a big step in mastering something new.

One of the most interesting things I enjoyed while reading about this pattern was an example of how to reimplement a Java pattern into another language like Io and then into something like J. we can notice how the code can change drastically from one to another and yet at the end of the day they all do the same thing. This example is eye opening to showing how similar and different every language is and that we can’t just take the same knowledge we have in something and apply it to something else. We have no make sure we go in with a fresh mind and try and follow the new language’s nuances and set of rules and forget everything we think we should know instead of trying to apply it to something new.

This pattern is very insightful and applies to what I’m currently working on in class. We are attempting to learn how to code in React Native and I feel as though my growth in learning and the progress that I want to achieve is not what I want to. It might be because I’m trying to apply my skills in java to a front-end language and that does not mesh well whatsoever. I’m an impatient person when it comes to learning something new, but this pattern is a great way for me to keep in the back of my mind because progression shouldn’t come in an instant, it comes with slow and steady progress and constant repetition.

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.

Apprenticeship Pattern: Craft over Art

The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application’s appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: The White Belt

This week, I decided to look at the next apprenticeship pattern in chapter 2, “The White Belt.” This pattern describes the dilemma of a programmer being confident in their skills of a language but has reached a plateau in their personal development. This pattern offers a solution to those who feel that they are not acquiring new skills fast enough. After reading through the previous pattern, I’ve gathered that it is important to keep learning and honing your skills. And this pattern directly addresses an issue that one would encounter when doing so.

The solution provided in this section is to put aside your current knowledge when approached with new knowledge. While this will potentially affect productivity in the short term, it will allow time for new knowledge to sink in. In the pattern, it states, “wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” This can be applied to learning anything because it can be beneficial to approach something new with the mindset of a beginner. The example with Dave the therapist was an example of when the mindset could apply outside of learning code. Dave found that taking a “not knowing” stance when working with clients opened up a new door of unforeseen possibilities and solutions. He put aside his expert knowledge on the subject and approached clients with curiosity.

Another example that I would like to refer to is that of the 10-year industry veteran Steve. He mentions that after reading “Working Effectively with Legacy Code,” his codebase improved into a better tested, adaptable system that was more fun to work with. While Steve did not go into detail, it was interesting to know how much more a 10-year veteran could grow. I certainly don’t have that many years of experience, but when learning new things, we are all starting at this hypothetical white belt. For the most part, the languages I have learned thus far are all based on similar logic. It would be beneficial for me to take one of my existing programs and implement it in a vastly different language. Not only would it give me a chance to learn a new language and the idioms, but it could also improve my coding skills in general, as mentioned by the 10-year veteran Steve.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Your First Language

For this week’s blog post, I have decided to look at the apprenticeship pattern “Your Fist Language”. The idea of this pattern is when you first start your programming journey. This is when you only know one or tow languages. The main concept of this chapter is to isolate what langue you would like to use as your main language. According to Dave H. Hoover and Adewale Oshineye, the authors of the book, they say on this, “Pick a language. Become fluent in it. For the next few years this will be the main language you use to solve problems, as well as the default skill you hone whenever you are practicing. Making this choice is a challenge. It is important that you carefully weigh the options, as this is the foundation upon which your early career will be built.” (Dave H. Hoover & Adewale Oshineye).

When first reading about this pattern, it really grabbed my attention. At Worcester State we learn an abundance of different languages to be able to be prepared for the outside world. However, something that has always been a question for me is “What language do I stick with?”. What was cool about this chapter was that it said to have a main language under your belt, but it never said to toss aside the other languages. As an example, they talked about a job requiring a specific language to be able to be hired there. Rather than disregarding the job and looking for something else, they suggest making a toy application to learn a basic understanding of that language. Some of these toy programs will involve a problem to solve. Unlike a simple “Hello World” application, solving a problem will give you a more in-depth dive of the language. Another good thing to add to your toy application is a test class. Test classes always help ensure that what you are coding is spitting out the correct information.

With this chapter in the book, I agree with everything that they are saying about your first language. I loved how they talked about having a min langue but not disregarding the other languages you have learned or will learn.  It also made me consider more what will be my main langue when I go out into the field and what language I’m willing to put more research into.

Book: Apprenticeship Patterns, Dave H. Hoover & Adewale Oshineye

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

The Deep End

Months ago, I found myself standing in “The Deep End” since I wasn’t able to land any internship before graduating this year. The situation was exactly the same as how they described in the book, I needed to grow more skills, my confidence, and my portfolio of successful work, I needed to challenge myself with bigger works, projects, complex tasks, and teams, etc. The YouTube algorithm even made my situation worse by showing people about my age are “better” coders than me in my opinion. I was afraid that I did not do “enough”.

 Currently, what I really felt at that time was envious, seeing people better than me virtually is rough but seeing people who I know landed works while I carried them through classes is overwhelming. My resume, my ability, my confidence, all of them were kind of irrelevant at that point. I created an invisible time limit for myself to be successful, to this point, I still think there are pros and cons to doing it, the risk could be high but I take it.

Later, exactly in how they advise the action, I should instead jump into working on projects that I did not do to create a time limit for it, I’m willing to take more work than anyone in the team and fulfill my responsibilities to not only build my portfolio but also my skills and my confidence. Then, after a while, I will analyze my set of skills fit to what role in the industry and pick the right opportunity based on it.

Besides, when this post is online, I’m currently handling an internship and a capstone project in which I volunteered to be the Scrum master that instead does not make me feel overwhelmed but motivated, as I am learning new materials every day.

In conclusion, it likes how The Deep End was described in vol. 15 of “Diary of the Wimpy Kid: The Deep End”, which follows Greg Heffley’s summer story, a dramatic summer yielded great memories, things could be tough initially, but if I keep continuing on this track, hopefully, the result will be what I aimed.

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.

The White Belt

The apprenticeship pattern I’m going to be looking at today is called “The White Belt”, from chapter 2.

The use case for this pattern is when a programmer has reached a point in their development where the rate at which they learn new information has begun to decline. The proposed solution is to hold on to newfound confidence while setting aside newfound knowledge. This way the new knowledge has time to sink in before it is synthesized with old knowledge, allowing new information to flow more easily.

I liked the example brought up here of Dave, a therapist. He found greater success with his clients after approaching his clients with as few assumptions and as much curiosity as possible. I feel that this demonstrates that this is a useful general principle for learning, rather than just one for learning about technology. This is why I find this idea compelling.

Something I found insightful in a more practical way was the idea of suspending the use of idioms you are familiar with in favor of the ones that are considered “best practice” for whatever tool you are using. Even if you don’t necessarily agree with, for instance, the concerns that Java programmers focus on, understanding the community around a language is essential to understanding the language itself. “Emptying your mind” in this way can be especially helpful the more unfamiliar you are with the language you are using, like if you were moving from a procedural to a functional language, for example.

I think that with technology fields in particular, there is immense pressure to be perfect, or at least exceptional. It can be extremely difficult to sacrifice productivity for benefits that are not immediate, and even more difficult to risk looking like you don’t know what you’re doing. Still, this is a leap of faith one must take to be good at what they do. Having it said so clearly makes it easy to see my hesitation as kind of silly.

I think I’m also going to add the book mentioned at one point, “Working Effectively with Legacy Code”, to my reading list. Not much was said about it, save for the effect it had on one reader, but it sounds like something that I, personally, would be really interested in. 

Another thing I’m going to try at some point is the exercise about rewriting a program with different idioms. I want to take something very simple I wrote for practice once, like a program that converts between temperature units, and rewrite it in a completely different language with idioms that are totally unfamiliar to me. I’m not really used to caring about idioms in this way, so I feel like this is the next big step forward I can take as a programmer. 

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.

Reflection on the Breakable Toys Apprenticeship Pattern

The Breakable Toys pattern is about creating your own projects that allow you a safe place to experiment with new ideas and become more comfortable with your toolset. A project where you can try unconventional things to improve your skill, but where it doesn’t matter if they fail. The project they recommend for this is creating a wiki for yourself, to help learn multiple facets of design techniques.

I really liked this pattern and the idea that it promotes. Working on a rigid system that many people use, or whose functionality is necessary for the operation of your job, there isn’t really any room to try new things and grow. So having your own little workspace to try new things seems like a great way to build your knowledge in an environment that is completely your own. Like a chemist having a chemistry lab to experiment, it is important for software developers to have a place to experiment themselves. I also really enjoyed the idea of maintaining a project like this across different jobs, always having a place to try new things and to try new techniques when you are stuck on something. I think that implementing this into my own life will allow me to grow as a developer and gain new skills and insights that I would never have the freedom to do in a work environment.

The recommended “action” for this pattern is to build a wiki, and while I think this is a good example, I don’t think that that would work for everyone. So I think that if anything, I disagree with that specific recommendation, as I feel that depending on what is necessary for your work, a wiki might not need the tools that you need to work with or work on. So while I think it is a good example, I think that the individual has to come up with a project of similar scope that better matches what they need.

Overall, I think that this pattern is a very good piece of advice. Any profession can have difficulties and expectations that cause you to stagnate in your learning, but in the ever-shifting landscape of the software development field, this stagnation can leave you behind very quickly. So having your own personal project to experiment with things in will keep your skills sharp and keep you constantly learning and developing solutions to problems that can later be implemented in a work environment.

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.