Category Archives: Week 1

The Wonders Of Testing

Testing is an essential tool when it comes to software development. This week I listened to the podcast “Code Newbie Podcast”. In the episode “How to make sense of the testing landscape”, they talk about the importance of testing, and why people test, what kind of testing is done. They bring in Sergei Egor who is the CEO of AtomicJar. His company works with Testcontainers a java library that supports JUnit testing. The reasoning for looking into this episode, in particular, is so I could get more familiar with how testing works and its intricacies. The experience with testing my programs is very minuscule, and so having a veteran QA developer explain the little details of testing is just what I need personally.

Sergei goes on and explains that when discussing software, new features are being implemented almost all the time and so in order to make sure that those features work as intended, testing must be done. When working on a program, it’s fair to assume that the program must meet a certain amount of requirements and so testing ensures that all those requirements are met. The whole point of Sergei’s company is to optimize testing for software companies that don’t want to create miscellaneous code just to test a certain feature or task. The question that Sergei brings up is why can’t it be done through the backend of the program? And so Sergei’s company basically specializes in these software developing phenomena.

He goes on to explain different types of testing such as automated testing, performance testing, and the most popular type of testing which is unit testing. Unit testing is basically low-level and it will tests individual methods and functions. I’ve worked with unit testing in my previous computer science courses so I am most familiar with this type of testing. I would use unit testing in java for the most part. I had a project that involved me creating a banking account class, and basically, I had to create a JUnit class that would test all my methods such as my “getFirstName” method or my “getBalance”, so on and so forth. It would basically tell me if these methods succeed or not. When Sergei started talking about unit testing it felt very familiar with assignments I’ve worked on in the past.

When he started going into performance testing which is a test that evaluates the speed and reliability of an application, it made sense on paper but with my little experience, I began to struggle with how one may go about doing something like that. With the implementation load test as Sergei mentions, load tests are used to work the application to its full potential and record its response times and request counts as he goes on to explain. Something else that I found interesting while listening to Sergei is the question of why can the developers test the code so that the company doesn’t have to hire a crew of QA engineers. In Sergei’s words, he explains that many developers don’t want to think of all possible inputs for a program they would rather have an algorithm such as property testing do it for them.

Property testing relies on properties and makes sure that a program abides by those properties. It would be interesting to see this type of testing work with my mobile application which word recorded finance information- it would typically crash when inserting a record of payments occasionally and so having an automated testing algorithm such as property testing could have helped me figure out why my program failed in some instances. Automated testing would serve me in testing my programs and their functionality, running multiple tests whenever it’s needed.

Link to “Code Newbies Podcast” S18:E4:

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Self introduction

This blog documents my journey learning Computer Science (CS) concepts. Posts will be precise and summarized to make the entire process informative, enjoyable and worth your time. The CS discipline is constantly changing and I can’t wait to see what’s coming up next, hopefully we can keep up! Let’s explore together and brace ourselves for the journey ahead.

One more thing, I thought it would be good for me to give a brief background about myself so you can get the whole picture. My passion for technology started when I was young, about the age of four wondering about the person speaking inside our family’s radio and how they fit in there. These are some of the questions I wrested with and couldn’t imagine how tiny that person could be.

As time went on, so did my enthusiasm; this time it was anything electronic especially mobile phones. Back in my day, it was only adults who owned phones and they were mono colored specifically black with a green background. No apps had been introduced yet, the only capabilities they had were messaging, making and receiving phone calls, contact’s book and a few select games such as snake and Tetris. At any opportunity I had to hold someone’s phone, I went straight to looking for games and if I didn’t find any I was deeply disappointed.

Fast forward as technology grew, I decided that I would invest myself in understanding how things work and how they were made to work. In high school, my best classes were STEM especially Physics and Maths. It was fun seeing how different formulae would be used to solve computational tasks. I recognized that paying attention to detail was key to solving any problem. I self-proclaimed myself to be the family’s judge because I would take on arguments and apply logic to them and just like that it they were solved.

Another fast forward; no pun intended, I learned that Computer Science was the what I had been looking for all along. I was lucky my family was gifted a computer by a young adults Christian group from Australia. It was on this computer that I spent my days breaking and learning new things. Then, I got introduced to the internet and was mind-blown, then I learned about Facebook. Best thing at that time, I’m not sure about now.

I could go on and on but in the interest of time and my promise to keep this summarized, let’s stop here. Basically, I’m passionate about Computer Science and I would love to make a positive contribution to the human race through technology.

Thank you for reading my blog.

The post Self introduction appeared first on Velt.

From the blog CS@Worcester Archives - Velt by byaruhangamoses4 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.

Apprenticeship Pattern: Your First Language

For my first blog post on these patterns, I wanted to start with Your First Language. I have only been exposed to a handful of languages since starting my computer science journey. And though I have honed my skills somewhat in those languages, I am by no means a master at them. I can relate to the problem in the pattern, so I was interested in what it had to say. This pattern addresses those who are looking to start learning a programming language or those who feel their skills are not up to par with what a job is looking for. Selecting your first language could influence your future career, so it is important to choose a language wisely. The solution suggests choosing a language based on those around you, for example, an expert in the subject that can mentor you. Becoming proficient in a language involves building up knowledge through reading specifications and solving problems.

One of my main takeaways was to choose a language based on the people you know, specifically an expert. The other takeaway was to look at the community built around a language and see if you want to belong to that community. I found those two points to be the largest deciding factors when it comes to picking up a new language. For me, I would consider my first language to be Java since that was the first language that I learned at school. There were plenty of professors that aided in my learning process and the community surrounding Java is extensive. It would only make sense for me to continue learning about java and solving sample solutions until I consider myself fluent. I think starting a professional career is a bit daunting, but what the pattern explains makes a lot of sense. The only way to become proficient at a language is to do a lot of reading and try out problems myself. A work environment where you can call on a more experienced team member is also beneficial when it comes to learning a language. That being said, I don’t think there is anything I disagree with anything mentioned in the pattern, it more so emphasizes what it means to be a good learner.

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

Apprenticeship Pattern: Concrete Skills

The pattern I decided to read is titled “Concrete Skills” from chapter 2 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern starts off by discussing how hiring managers have no incentive to hire someone who can not directly contribute to a team’s workload. Hoover and Oshineye ask the following rhetorical question from a recruiters point of view: “If we hire you today, what can you do on Monday morning that will benefit us?”. In short, the solution to this problem is to develop and maintain some concrete skills. We learn that with time we will become less dependent on our concrete skills and get hired through the reputation we have garnered from notable projects. This pattern ends by giving the reader a recommendation on how they can begin developing some concrete skills.

The thing I found most interesting from the reading is that at some point in my journey I will become less dependent on my concrete skills. My portfolio and “deeper qualities” will be what matter more. This was interesting to me because in a section that stresses the importance of learning concrete skills in the beginning of my professional journey, I am still getting a message that soft skills are important. This shows me how there is an important balance of maintaining the hard skills I’ve learned in addition to being a team player, having good communication, being empathetic and having many other traits that fall under the soft skills category.

Overall, there isn’t anything that stands out that I strongly disagree with in the reading. As far as how this pattern has caused me to change the way I think, I would say that it has emphasized the importance of regularly updating my resume with technical skills since this is something many hiring managers focus on. Since there are plenty of skills I’ve been developing in school this past year, I took the advice from this pattern to heart and almost immediately started jotting down the skills I have started developing. I also started looking into CVs online for inspiration of concrete skills I want to develop and to add to my own resume.

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 Patterns: Exposing Your Ignorance

When previously looking at ‘Apprenticeship Patterns’ we discussed the importance of the pattern ‘The White belt'(You can read more about that here: That pattern focused on the importance of being able to set aside past experiences to learn something new. To build upon this we will be looking at the pattern titled ‘Exposing Your Ignorance’.

As we previously saw, it is important to always be learning, especially for software craftsmen who must always be prepared to learn a new language or technology stack for their current job. However, this ever-evolving profession presents a common risk that many fall victim to. It is far too often that we feel pressure to appear competent in front of our peers and our managers. People depend on us to be confident and deliver on whatever job is put in front of us.

You may feel pressured to give your manager reassurance that you know what they want, how to give it to them and when it will be done. But to do so will only be detrimental to your reputation in the long run if you cannot deliver. Instead, it is important to set aside your pride and be truthful with both yourself and your peers regarding your capabilities. If you want to reassure anyone on anything, do so on your ability to learn.

Dave Hoover, an author of this book worked as a family therapist previously and often took the “not knowing” stance when dealing with every new family. This feeling of not knowing would eventually become something that he grew attached to, as a reminder that he was in the right place, that he was learning something new and growing as a person.

To “Expose your Ignorance” you must embrace the learning process, you must have the courage to “Wear your White Belt” and commit to the learning process. Some don’t and fall back on what they are already familiar with. Those people generally become experts but this is not the goal of an apprentice. An apprentice will, by the end of their apprenticeship, have a solid grasp on a few different technologies they can use to create robust software applications. A master craftsman will have a handle on a myriad of different technologies and be able to create large, complex software.

One thing that is discussed in the book you can do now is take a sheet of paper, write down a list of 5 different software tools you do not understand. Post this paper in an area that you and anyone else can see it and update it as you learn more and your work changes. Setting aside your pride to do this can help prevent future pressure from causing you to act in ways that may be detrimental to you in the future.


Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Concrete Skills

This week I am writing about concrete skills. The apprentice pattern here is somewhat self explanatory. Concrete skills are what an apprentice can do for a company day one on the job. Some examples of conrete skills are basic web development, popular frameworks, and the standard library of the programmer’s language of choice. The problem is that an apprentice that has not proven himself may not be able to find a job. The hiring manager needs a reason to take a risk on this prospective employee. The solution is aquiring concrete skills. The author recommends that apprentices seek out guidance from developers they admire. And pursue 5 concrete skills on that developer’s resume. And build a toy project that demonstrates these concrete skills. I really like this idea. The author also mentions that a recruiter is more focused on the skills at this point in the journey, than the experience. Because the work experience is not software related.

I think that his is a very useful apprentice pattern. And I like that it starts before an apprentice starts getting paid to code. One thing I think could be improved is finding the important concrete skills from another developers resume. I think the more practical approach is to look at job postings to find what concrete skills are in demand right now. It is possible that a developer I admire has skills on their resume that are no longer in demand. One way that employers quantify an apprentice’s concrete skills is through a technical interview. This interview would involve basic data structures and algorithms. As well as the standard library of whichever language the candidate is interviewing with.

I have done a version of this apprentice pattern already. I have noticed that many companies hiring Full Stack Engineers are using React.js, so I decided to complete a React tutorial and a simple project over the Christmas break. I was able to but something new on my GitHub, and my resume. This process is a win-win because I am learning a concrete skill, and improving my public GitHub profile at the same time.

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

A Constant State of “Update”(ing): Using Apprenticeship Patterns to Become a Master Programmer

“Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been considered to be an acclaimed read by many of my fellow students. After giving the book a try, I can also see why it is such a big hit. In essence, this book speaks to programmers on a “relatable, spiritual” level on how to turn their passion for software development into a lifelong process of constant improvement.

To be honest, the most interesting part of the reading for me was found in Chapter 4: Accurate Self-Assessment. This is because it is instrumental to my learning style that I am “the worst of a group”, or that I am always in a zone that I need to focus on improvement. Throughout my college career, I have been the type of person to rant and rave about how “I’d rather get a ‘C’ and master two programming languages, than receive an ‘A’ and still show evidence of struggling with one.”

Considering my own views on how I work with software, I feel as though this book has been mainly a “rehash”, or a reinforcement of my beliefs. This is due to several factors, including the “Be the Worst” philosophy as mentioned in “Accurate Self-Assessment”; this can also be seen in “Chapter Two: Emptying the Cup”, where they state the importance of becoming extremely proficient with your first programming language.

Unfortunately, as amazing as this book is, I cannot say that I agree with every last line of its code. One spot where a “warning of disagreement” occurs is when “Chapter 6: Construct Your Curriculum” does just that – it tells me how to create my own study plan (outside of college classrooms and office hours). Perhaps this makes me contradict myself with my own “unorthodox schedule”, but I learn best when I don’t feel like it’s forced. Instead, my most efficient learning is recreational; it seems as though material sticks with me the best when I ingest it in the same way that one would ingest a juicy diary or a football roster.

For me, I found the chapter “Walking the Long Road” to be the most useful for continuing my career as a software engineer. This is due to the fact that it acts as a reason for using the philosophies found in “Accurate Self-Assessment”. By this, I mean that people (including myself) need to understand that becoming a master craftsman, and especially a master programmer, does not “just happen” overnight. it takes years upon years of grinding, of constantly “being wrong” and being challenged to find alternative solutions to problems.

Overall, “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” has been a fun, yet informative read. As mentioned before, I agree with most of the book; even in times of disagreement, I can see where the authors are coming from. I am looking forward to the applications of this book in my career as an aspiring software developer.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

Started From the Bottom, and It Only Goes Uphill From Here: How “Being the Worst” Is the Best Place to Be

It seems as though across several different environments, people have come to an agreement that “being at the bottom” actually isn’t as bad as one may make it seem. Rap music often makes references to “starting at the bottom” and “creating a grind for the paper”; Harvard University, despite its reputation for requiring high GPA scores, has an urban legend of “failing new students on their first semester”. Whether or not these previous statements are framed in facts or anecdotal assumptions, the idea remains that we as a society understand that “there is always room for improvement” – every day that you don’t make yourself stronger, you make yourself weaker.

This brings me to my first pattern of self-assessment from the Apprenticeship Patterns book: “Be the Worst”. In a sentence, the pattern explains that if we have nothing/no one to challenge us, then our knowledge level plateaus or even weakens; it is always a good idea to surround yourself with people that are better than you. This gives you the ability to learn from them and become an even greater programmer.

To be honest, I am glad that I started with this pattern. While I cannot say that it’s interesting per se (since I have always had this philosophy in mind), I can say that it is useful. I get where the book is coming from, and I would like to always be the “weakest link” as it ensures that I am in good, professional company.

As I stated before, the pattern has not really changed my way of thinking, since I have already held this idea of “being the worst” near and dear to me. However, I must say that it is nice to see a professional textbook reinforcing my beliefs – while it goes against the philosophy, being correct before a confirmation is a good dopamine rush. I also cannot say that there is much to disagree with, since the pattern hits every nail on the head:

  • Join a team in which “you are the worst”.
  • Work harder than the rest of the team; don’t “be a passenger” or have people carry you.
  • Provide as much help as possible, even if these tasks seem “menial”.

Could this pattern be an excuse for my procrastination at the start of this semester? Maybe – I think the “early start” didn’t help either (and some burnout from constantly taking classes to boot). However, in the end, I am glad that I have a great team to work with, and a bit of “set back” in order to keep myself on my toes for these upcoming classes. If this setback is my “rock bottom”, then I can only imagine how great it will be at the summit.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.