Category Archives: CS@Worcester Blog

Concrete Skills Pattern

For this week’s apprenticeship pattern, I did a reading on “Concrete Skills”. Concrete skills are a pattern that I feel like I am currently experiencing. Concrete skills is about acquiring and maintaining skills that enables you to be ‘trusted’ by companies so they’re more likely to hire you. Concrete skills are supposed to reassure future team members that you are capable of doing the tasks that would be assigned by you and wouldn’t need to be babysat during the process. These types of skills are considered to be the basic of any programing language or knowledge. These are usually tested when you are being interviewed by current software engineers at a company that are simply just testing your knowledge. A great solution to anyone who has this problem is to work on side projects and casually review how basic functions work in your chosen language.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. Since I have limited experience in the professional field of software engineering, I am currently requiring hiring managers “to take a leap of faith” in choosing me to work at their company, as the book says. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to practice more concrete skills and building side projects that will help me with the journey of becoming a software engineer.

The pattern has not changed the way how I view my profession because I already had an idea of how HR and the process works. The hard part of any job is getting selected for the interview process and for me, since I have no real type of internships, it is much harder. I do however have that I’ve worked in companies with good positions but they’re not entirely “software engineering” related. Therefore, I am constantly practicing my skills and working on side projects that I can showcase on my resume and be able to answer questions that are thrown at me if I were to get selected for an interview.

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

The White Belt

For this week’s blog post, I have decided to look at the apprenticeship pattern “The White Belt”. This chapter talks about how you have gained a deep understanding of your first language and have become confident. However, you are struggling to learn new things and it has become more difficult to learn new skills. The main idea of this chapter is to wear a white belt and forget everything you have been taught thus far and learn from someone with a blackbelt. Dave H. Hoover & Adewale Oshineye, the authors of the book, say on this, “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”. (Dave H. Hoover & Adewale Oshineye). As discussed in the text, when you take this approach in learning some new material this will accelerate your learning process tremendously. When you take this step towards ignorance, you can express yourself idiomatically and gain a far better understanding of your new knowledge. This way when you consider both what you learned and your old knowledge you have developed productive insights in both fields.

What I found interesting about this pattern was that it’s like what we learned in the chapter “Your First Language”. In that chapter it mentioned finding a main language but not forgetting about what you learned in the past. With this chapter we can apply both knowledges and expand on our main language. By being able to take a step back you can develop your skills in a way that I didn’t eve think about. Now knowing this knowledge, it has made me rec consider what I would be doing out in the real world at my profession. If presented with a problem that I have no past knowledge about, instead of trying to guess what the solution to it would be I can ask someone who knows, a.k.a a blackbelt, and expand my knowledge of the subject. With everything I Have learned I both chapters, this gets me excited to go out into the world and gain more knowledge to become a “blackbelt”.

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.

Sprint 1 Retrospective

In this sprint I was working with a team of 6 individuals. With this group we decided to split into two teams, 3 people to work on the frontend and 3 people to work on the backend. During this sprint I was a part of the team working on the frontend.  Throughout the duration of the sprint, I found that this team dynamic worked well. This allowed us to divide up the work and conquer it as two individual teams. I feel if we were all working together and grabbing any task, this would have caused mass confusion and the likely hood of less work getting done. From a frontend perspective, I think having 3 team members to work on the frontend was the correct amount. I say this because in our repository we were working on mainly three different files. These files were our App.vue, id-input.vue, and register-form.vue. Due to this coincidence, we were able to give everyone a separate file to mainly work on.

In this sprint I only could find one thing that didn’t work well. This was assigning roles to current issues in the sprint backlog. With assigning roles, I found that a lot of old issues were left over from the previous class that were still assigned to them. I found this frustrating at first due to me not know my teams profile pictures and thinking they had assigned themselves to that role. Once I figured out their profile pictures that part of the issue subsided. However, I found that with my team as well every once and a while someone would assign themselves to an issue that I had already begun working on. This kind of issue could cause issues later down the road because if they were to push code like mine but different at the same time as me, it could affect the code.

Something that we could improve on as a team is switching up the team dynamic. I only say this as I know that the backend team has much more work to do then the frontend team. When we first started the sprint, the frontend was in okay shape. This being that we had files that were somewhat working, and we had issues that we could easily identify. With the backend however, they were given files and containers that were not working at all. At the end of this sprint the frontend team was able to have get all forms working for the most part and able to set up CSS styles. With the backend team they made great strides in getting the backend to work, but they still have got a lot on the product backlog. If we were to switch the team dynamic to 2 on frontend and 4 on the backend, I believe this would give the extra manpower to get a fully functional backend with rabbit mq.

From an individual perspective I believe I could improve on my commits. I am very prone to committing a lot of non-important commits. I feel as though I should try in this sprint to try and limit how many commits I send to the branch before my issues from the sprint backlog have been finished.

Sprint Commits:

Add Frontend image to Docker Compose: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/1edd0dd2761c6eca6b2658ac84b8ad9a9a0a6c8f

Update form on main branch: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b

Form update to newer form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/3d6e549feb1088c5704509b31d62a2d4d6f5a9e0

Fixed Submit Button on Register Form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/78c425fbaa3a2db3dafb4ba383e31aeb86709c7b

Allow Data communication between Register-Form.vue and id-input.vue: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/93497903597726c44fb8aa5a662d8fdad0343151 & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/9ccc74f09d3e5687b06d6752a0efcb17b90a81a7

Changed idnum from this.props to method call upon form creation: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/131ab93c5f000b742052db31d0ff5aba95772223

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

First Sprint Retrospective

Reflection on what worked well and didn’t work well
After having the Sprint Retrospective meeting with my group overall, I would say things went pretty well. The workflow of the group was simple and smooth, and both the frontend and backend development teams were able to make a lot of progress towards the project. Overall, we were able to get everything done besides 3 items on our issue board. The only issue we really had was our branches. While working on the project, we ended up making a lot of branches for different things we were working on. For example, in the backend we had a API branch, a jsdoc branch, and a test branch. Per the Product Owner, he said that this is fine, but we should be merging the branches to the main branch and delete the branches once they get deleted. This will prevent future errors as other developers work on this project and add more things to it.

Reflection on what changes could be made to improve as a team
The team worked pretty well. We divided the project up into two teams, backend and frontend. This allowed everyone to work where they were most comfortable with. From how the meeting went, everyone was able to communicate any problems they had with one another, and no one was ever afraid to ask questions when they needed help. Something that the team can improve on is probably be more vocal. Sometimes there may be a problem that a member has, and everyone is silent until one of the more vocal members speak up. It may be, because some of the members may not know the answer but overall, just being more vocal is what the team could improve on. Instead of saying “I’m done, here’s what I did”. Maybe they can elaborate on what they did, like if they had any problems that they had to fix on their own.

Reflection on what changes could be made to improve as an individual
From my perspective, the sprint went well. I was able to complete me task with very little difficulties. I will attach the work I did on the project at the end with a description. Since what I worked on was mostly what I learned from last semester it was relatively easy and straight forward. Only problem I had was when I had to figure out how to connect certain files. This was mostly because of how the previously team worked on the project. What I can improve on is probably be more active with other team members. What I mean by this is to give input on when they are having any issues or any type of problems.  

From the blog CS@Worcester – Michael's Developer Blog by michaelchaau 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.

Sweeping The Floor Learning Pattern

This pattern is very important it tells us how to begin the career switch from student to paid professional. It is a scary moment of unprecedented uncertainty. It helps us see with a clearer image that there are levels of expectation. These expectations are stratified to build a path to success. It also throws cautionary tales of getting comfortable doing the work at the outer layers of what’s expected.

This is very personal because everyone of us graduating will face the reality of a professional environment. I could not say that it will be harsh or easy. What I can say is that the expectations and anxiety that we generate ourselves is harsh. It makes me feel better to think that the professional world in general has a path in which one can climb, even if this path is steep. The great fear is that there is no path, the goal is the space station, and you don’t know how to build a rocket.

Putting my trust on the writers I expect this sweeping the floor pattern a practiced reality in real situations. I don’t believe there are any menial tasks. All tasks must be completed, and I wouldn’t mind if I had to do some of them or even all of them if it’s all I can do. I have used this pattern in my own life differently. When my car brakes I usually fix it myself because I can not afford the extra expense, this is something that I really don’t want to do. It takes time away from my studies, but it also helps me afford it. Some people say why should they pay a mechanic x amount for only an hour of work but the amount it would take a normal person without the tools and environment would much offset whatever savings they think they had. Most of the time I think if I had the money, I would pay double for a professional to do this for me.

You learn the cost of doing something by doing things you wouldn’t necessarily want to do. Sweeping the floor may begin with doing the easy undesirable work but it must progress into doing work you are uncomfortable with. Success in life comes when you accept uncertainty and never get too cozy as to be paralyzed by extraneous events.      

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

Find Mentors

Self-learning is one important quality of any programmer; however, self-learning is not always useful since the learner might not know what is waiting for them and if their approach is good or not. In this case, every learner needs mentors, those who already achieved what we are working on or at least, they have deeper knowledge about the topic that we are learning.

“Whether a beginner starts out with a training course or is self-taught, the first step on the path to software craftsmanship is finding a craftsman to apprentice himself to”

–Pete McBreen, Software Craftsmanship, p.96

From my own experience, I find this statement can’t be more accurate as I find myself learning more productive when I have mentors to show me what I should do compared to learning by myself. However, as in the book illustrated, as an apprentice, it can be difficult to tell who is truly a master craftsman. Therefore, an apprentice should follow a set of mentors that each one will show them a bit of a huge picture. And the set of mentors here counts not only “real” people who we should have already considered them as our mentors to learn, our friends and our professor, but also the active community we could find online to exchange information with people on it.

Besides, according to what was written in the book, an apprentice shouldn’t expect their mentors to know everything and get disappointed if mentors don’t know what we are seeking for as the current mentors could be other’s apprentice, we are all walking on a long road. Because our field is huge, a person who can guide us through 10 in-built React hooks may not be able to show you how to design the API route and vice versa, these twos are completely different topics and what we probably need is to master a specific set of skills that we desired; but it’s obviously the more we know, the higher opportunities we’ll have.

In conclusion, what I learned from this chapter is that I should find a community and actively communicate with other members there. Luckily, I found myself on a discord channel of one of the biggest Vietnamese tech forums, J2Team, having a community of developers exchanging lots of quality contents.

A channel in J2Team server

Now, I should consider posting my first message here and seeing where it will lead me to. 

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.

Unleash Your Enthusiasm Pattern

This week I decided to read about the apprenticeship pattern ‘Unleash Your Enthusiasm’. The meaning behind unleashing your enthusiasm is that there may be something that is holding you back. Just like the pattern says, you have so much enthusiasm that’s ready to be release. The example that the book uses, is that software developers, you will more than likely be working as part of a team. Usually when working in groups, there is something called a norm which is what everyone follows. No one tries to stand out or if they did, they would find themselves in an uncomfortable position.

My initial reaction to this pattern is that it can relate to more than just software development. It can be compared to the outside world. For example, who you choose to have as your friends. In my instance, I used to have a circle of friends I used to ‘confine my enthusiasm’. Eventually I learned that they were holding me back from furthering my life from being greater. Once I started being myself, things naturally got better for me. My life got overall got better ever since I hold myself back. Just like how some new software engineers that start their first professional jobs confine with the norms. They become held back because they don’t want to speak up and voice their own opinions which then results in them becoming an ordinary worker who doesn’t stand out.

After reading the pattern, it has definitely made an impact to how I view myself working in a professional environment. I tend to be a quiet person when working in teams but lately have been more active and more vocal in the teams I am in at school. By doing this, I believe it will help me get out of my comfort zone and allow myself to ‘unleash my enthusiasm’.

This pattern can be applied to not only for software developers, but to their personal lives as well. I would agree with what have been said in this pattern because the meaning behind it, is to just let loose your ambitions. In order to grow and further your career, you can’t become a person who holds themselves back. There are times when staying in the norm is okay, but overall, it’s better to stand out because that is how you will get recognized.

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

Digg Deeper Learning Pattern

This pattern is a great idea for a beginner such as me. It offers a way to complement the lack of knowledge that comes with the lack of experience. It should be used carefully because of the ease of wanting to just reinforce the skills you are already good at. Knowing a little on a lot of subjects will not help getting things done and knowing a lot in just one subject will get you just as far. The secret as I see it is to have a good toolbox and know how to at least hold each tool. As you need to pick up each of these tools you learn about them more in depth but not too much to hinder your progress. As you shuffle through this toolbox picking up things you need and not obsessing on one tool you build a hierarchy of depth in the knowledge of things you need most. We will handle the same tool more than once and every time we do, we should dig just a little more.

The author presents a more all in version of the dig deeper which I think is the philosophical normalized world idea. It would be nice if we had the luxury of tunnel vision and look for the PhD dissertation of the original design algorithm for every tool we use, but it is also the easiest way to fall into a deadlock. I find that in school it is very hard to get in depth knowledge on every subject as much as I want. Time and time again I see myself compromising and kicking the can down the road, because I do want in-depth knowledge in some subjects, but there are time sensitive co-responsibilities that need immediate attention. Although, as I said earlier, some of these tools that I want to understand better come up again and again over the semesters and I do indeed gain a little more ground on understanding them.

I believe the author is right when he says that we need to learn to dive into ever lower levels of understanding.  By lower I mean from specific to general and by specific, I mean not only the surface high level function you need. The author does throw a little caution which I also mentioned earlier. The risk of becoming what some call a one trick pony.  The balance is really hard to define, and it is very personal. I don’t have my own balance definition yet, but I hope that with time this too will come.

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