Category Archives: Week-2

The White Belt

This week I read the section called “The White Belt.” The quote goes like” As a rule, each step should have a feeling of entrance. This is the beginner’s mid- the state of becoming. “I like the title of this section The White Belt. I like it because I do Tae Kwon Do and when you first start off you are a white belt. That is where everyone else starts and no matter who you are we all start off as white belts. As you take classes you learn not just from the master (which is a black belt the highest of the belts) but you also learn from everyone else as well. Taking Tae Kwon Do classes we all learn from each other no matter what belt you are. This section of the book takes everything you know and tells you that you don’t know anything. Which is true because when you are learning you don’t know everything. There are times when you are working on a code and it becomes a 30 line code and you think you did it the best way however there are some people who can take that 30 lines of code and just make it into 10 lines and some can even do it with 1 line of code. Just like the example in the book that shows the different solutions of how to write the code that generates random numbers for the United Kingdom’s National Lottery. This also goes for the blackbelts because even though you may know a lot you do not know everything. Technology changes rapidly and then there are different concepts and people that are just better at doing certain things that you. So you should not stop the search for knowledge and we should continue to try learning from each other just like how a white belt learns from each other, their pears, and their masters. Everyone has their different skills and different strengths and weakness so that means when you work as a team they can help cover your weakness and improve your strength


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

The Importance of Feedback

I decided to focus on the pattern involving feedback loops this week, because I saw it being referenced in many of the various other patterns throughout the text I browsed. Also, because it seems like to be a good apprentice, having lots of feedback to see what one is doing right or wrong seems like an incredibly important step.

The pattern is called Create Feedback Loops. The idea behind it is incredibly simple, but strong. Make sure to set up mechanisms that will give you concrete feedback on how you are doing. There are many various possibilities, from purely technical such as test-driven development to simply asking others for honest criticism of what you have done.

However, make sure the feedback is examined and the good feedback that can be implemented is taken, not bad advice that can set you back in the disguise of feedback. It is important to have positive feedback that encourages you to keep doing good things, and balancing feedback which discourages bad things.

I have realized the importance of concrete feedback implicitly throughout the years, but having it cemented as the important step it is and being explicitly aware of it, I feel, will make things going forward much easier for me. I have experienced the feeling of being completely lost many times and see how good feedback loops would have prevented many of these instances.

I was nodding my head the entire time reading the section on this pattern. Everything stated made sense and I could relate to. The personal story of Patrick’s situation was something I’ve felt many times in and out of software, where any feedback you get is vague at best and it feels impossible to know where you should head or do. Unfortunately, this was a situation I faced with some courses and professors, where after a discussion or question and answer session, I felt like nothing was clarified or it was even less clarified. These situations sometimes worked and sometimes did not, but I was always left with the sense that I did not learn much.

Going forward, I will attempt to avoid this from happening as much in the future as possible by using the techniques and actions the text suggests.

From the blog CS@Worcester – Fu's Faulty Functions by fymeri and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2018-01-29 23:40:24

The “Unleash Your Enthusiasm” pattern from Chapter 2 of Apprenticeship Patterns was interesting to me, because I hadn’t previously thought about what an apprentice might be able to add to a team. I didn’t even really consider that there were things an apprentice could add to the team, apart from the promise of future skills acquired during their time as an apprentice. But according to this pattern, the enthusiasm of the beginner software developer is a valuable asset, as it sparks the enthusiasm of the more experienced developers on the team. The authors encourage you not to suppress it in an effort to blend into the status quo, and in fact assert that it’s an apprentice’s duty to bring their enthusiasm to the work. Moreover, apprentices are comparatively blank slates who are more likely to suggest creative new ideas that developers with more entrenched habits wouldn’t think of. These should be shared instead of held back out of fear.

I did disagree a little bit with their statements about unwelcoming environments, which seemed to undermine their overall point. The last thing someone who’s unsure about sharing their excitement needs is to have it suggested that they’ll be secretly looked down on for it. Even in groups that don’t seem hospitable to a newcomer’s enthusiasm, there might be more inconspicuous ways of introducing it. Maybe enthusiasm can be shared with individual team members that seem open to it. The group’s status quo could be slowly altered from more private morale boosts, but even if it isn’t, you’ve still shared your excitement with someone. And maybe that’s a bad idea for reasons that aren’t obvious to me yet, but as an apprentice with no preconceptions, it’s my responsibility to share maybe-bad ideas.

After reading about this pattern, I have no doubt that it will come to mind in situations where I feel self-conscious about my enthusiasm and suggestions. I’ll have the ability to recognize now that it’s one of the few commodities I can offer my teammates, and that it won’t last forever, so I ought to use it while I can instead of restraining myself for the sake of pride.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Study The Classics

In this post, I will be covering the “Study The Classics” pattern from chapter six. I chose this pattern because it’s title seemed interesting. This pattern is contained within the chapter that focuses on individuals who are not necessarily motivated by learning for a grade, but those who are motivated by knowledge growth. So, this… Continue reading Apprenticeship Patterns: Study The Classics

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

Your first language

This week I am going to write about the single pattern form the book which first starts off with “your first language” this pattern talks about people who first want to start to program or have very little experience programming so that only know one or two languages. In this pattern the problem that these people face is that they feel like they must write programs in a specific programing language and be up to the same standard as their teammates however they don’t know much or as well as the other people working in their group. This part of the chapter tells the readers that they should just pick a language and become fluent in it. No matter what language you choose the basic problem-solving skills that you get from it would be able to be used in other langue’s. One of the major tips that I believe works really well is that you don’t have to learn this language by yourself. Find someone who has mastered the language and talk to them about it. You should be able to ask them for tips and tricks about the programming language. Even though you don’t see them every single day if u see them once a week it can improve your knowledge of the language. Once you learn enough code to start writing your own stuff you can start running test, tweaking, and experimenting your code. With this you can learn what can break the code and learn the limit of the code. You also aren’t limited in learning the language you can also learn about how other people’s libraries work and over time you can test points to new library’s and see the functionalities of them. A really good advice that this pattern talks about is talk to people who have mastered multiple languages and get their input on how and why they choose whatever language to learn first. I like this pattern and what they talk about because with this people who want to start programming it isn’t something that you have to naturally gifted to be able to learn and understand. This shows that people like them struggles to learn these things and all they had to do was choose one program and find someone to be able to talk to about it. Everyone learns at their own pace and their own language so that way anyone can learn programming and its not hard to do.

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

Post #17

The subject of this blog post is the first chapter of “Apprenticeship Patterns – Guidance for the Aspiring Software Craftsman” by David H. Hoover and Adewale Oshineye.  I found this to be a phenomenal read and I am excited for what the book has to hold.  I now officially consider myself an apprentice software developer; I feel that I possess many of the values that Hoover and Oshineye use to define good software craftsmanship, which has reinforced and revitalized my feelings toward my field and abilities.

I really appreciated that this first chapter was devoted to defining key terms and concepts that will appear throughout the book.  I think these definitions will help me better grasp the concepts and and overall goal of the book, as I continue reading it.  I did not really consider myself an apprentice, until I read the definition provided in the book.  Marten Gustafson, an interviewee from the book, defines apprenticeship as being in the “state/process of evolving and looking or better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways”, which I believe is the state of mind that I am currently in.

Something that really resinated with me, from Hoover and Oshineye’s definition of an apprentice, was the part where they talked about the need to learn how you learn and grow effectively, and how this inward focus on yourself and your need to grow is the essence of being an apprentice.  Up until now, I don’t think I was allowing myself the kind of inward focus they are describing – which is something I want to change.  I now feel that I truly am an apprentice and, as such, I ought to be a little more focused on myself and my progression toward becoming the master developer that I hope to be.

I also really appreciate Hoover and Oshineye’s understanding that the readers of this book will come from all different kinds of situations and circumstances, and they often reiterate the fact that the purpose of the book is not to dictate the right courses of action but to shape your mindset to that of a good software craftsman – “Since most newcomers’ experiences do not resemble the ‘ideal’ apprenticeship, the modern concept of apprenticeship is mainly a frame of mind: you recognize that you are still at the beginning, even if you’ve been programming for several years, and you are prepared to take steps to create your apprenticeship out of the circumstances you are in”.  I really connected with this because, I have been programming for years and have never considered myself  a true apprentice – because I wasn’t.

I have realized that, even though I have a bit of experience, it does not by any means make me an apprentice or software craftsman.  But, I am now prepared to take the necessary steps to create my apprenticeship, and work toward not only becoming a master developer but a master software craftsman.  I am excited to continue learning from this book and I look forward to the journey ahead of me.

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

Pattern 1 : Your first language


This pattern talks about the biggest step for every “programmer”. I mean i can also say you need to take this step before you are given the title of a programmer. After reading the section above this pattern which addressed emptying your cup before receiving more, i found it very easily cohesive with the content of this pattern. Programming is almost like nothing you have done before. But its only when you begin to understand it, that you begin to see how in tune it is with things that we do everyday unconsciously.  I agreed with how the author addressed this chapter. Unless you open your mind to accept new understanding and insight, grasping the concept of programming as a whole becomes almost impossible. The only way to truly excel at this craft is to dedicated your entire life as a programmer to the cause of learning and improving everyday regardless of how much you know. because for all you know, a new language can erupt tomorrow and render your task and routine of today, obsolete. Everyday you sit down to program you have to be yielding to learn and grown because there can be a new framework that came out yesterday that can make your life a lot easier as long as you know how to implement it. To better implement new techniques and methods will ultimately depend on your understanding of the basics of programming. And your understanding of the basics and fundamentals can be attributed to your in dept understanding of your first  language and the tasks you used it for. But once you have acquired this knowledge do not allow yourself to be bound by this knowledge but instead use it as fuel to attain new heights in the programming world. Every task that you are able to complete or solve should fuel you to learn the next thing in line. Programming is one of those things that theoretical knowledge only goes a distant. Using the knowledge to build, solve and overcome new challenges broadens one’s understanding of the art and this is the path that leads to greatness. The learning curve of a particular framework or technology grows exponentially in regards to the task and problems it is used to fixed.

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.