Monthly Archives: March 2022

Unleash Your Enthusiasm

Back when I was a kid (actually until now), I have been really into playing video games. It could be the reason why I chose Computer Science in order to be able to create games, a popular reason just as many of my colleagues. I somehow was able to land a spot at Ho Chi Minh City University of Technology, a flagship in technology teaching and research activities in Vietnam, after the high school graduate exam.

By the start of the school year, I had nothing but excitement, my only experience was some rough foundations of Pascal taught in high school and I barely remember anything from it. On the other hand, my colleagues were students from the very top high schools with a program concentrating in what they desire, which were mostly computers and the others had extra programming courses outside the class. Besides, the program was designed for students who already had experience with programming since the syllabus of my programming introduction class is a C++ class consisting of both functional and OOP methods with two huge projects. As a result, I was totally “destroyed” in this intro class while my colleagues, having a hard time, but managed to get through it.

Since my excitement was demolished, I had a hard time thinking about my major choice. I did not have any problem doing the required calculus, linear algebra, physics classes but my computer introduction class was a disaster. I was not able to unleash my enthusiasm, I did not know what it was, what I did at that time was grinding myself painfully to be “better”. In my opinion, we tend to be afraid of discussing or expressing something we are not familiar with, and for my case, I cannot show my professor my problem because of it.

After a few years since then, I would say that the syllabus for that intro class was still overwhelming for new students. However, for students who already had their based knowledge before taking that “intro” class, it’s a good opportunity for them to review before going into the main courses. If only I knew how to inject my excitement into my work to ask my professor about my problem, my learning would have been much better, wouldn’t it?!

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.

Craft over Art- blog 6

For this week, I read the pattern of Craft over Art. This pattern occurs when beauty takes precedence over utility. However, as a craftsman, you need to make your crafts become useful instead of beautiful.  One of the most important factors of being a craftsman is accepting that you are not an artist. Your job is not to create beautiful and fantastic things to satisfy your artistic creations. Your job is to create a craft which can serve the needs of others and meet the minimum standards of quality. The higher the quality, the more time it takes. Each level of quality always require the trade-off between beauty and utility. So, you have to know what to do with the customers’ requests; and you must be able to balance their desire on the products by telling them what to prioritize in a particular period of time. Moreover, as a craftsman, you need to ensure that you are always willing to deliver the best products to satisfy your customers’ needs. That willingness does not depend on your current feelings or inspiration because you are not an artist, you are “supposed to earn a living at your craft”.

In my opinion, I totally agree with the idea of this pattern, Craft over Art. I like this pattern because it is practical, it tells me what I have to do to create value as a craftsman, which is to make my crafts useful, not beautiful. If you are an artist, you have to create beautiful things for people to admire your creations; but if you are a software developer, who will admire your creations, but useless? When your code does not even work, how will people know the beauty of your creations.

Therefore, I always prefer a simple program, “fifty-line game that makes someone smile”, over a complex program, a million-line game but unplayable. I have also used this pattern when starting to learn something new. My real life example is that when I learned to write a game in python language, I chose the simplest game to imitate and learn from. That is because I know exactly what my goals are. I just want to understand all the basic steps to write a game. The simpler the game, the easier it is to learn. I chose to learn the basic but useful for my understanding instead of the complicated stuff but I learned nothing from it.

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

CS 448 Post 2

For my next post, I wanted to move on to the first problem in chapter 3, The Long Road. I liked this problem because it deals with a situation where you are stuck between wanting to continue learning more about computer science and improving your skill at it, and moving on to “the highest-paying job and the first promotion you can get your hands on”. It comes down to this because it can take many years to master your skills, and you may never fully master them because technology continues to advance and that there is so much to learn.

The quotes at the beginning of the problem, and the problem itself support the idea that improving yourself at and even mastering something will likely take your whole life. Apprenticeships, such as computer science in this case, are journeys that are based on long term growth, and improving yourself is meant to be the main purpose of what you do. I can see that specifically with computer science, trying to completely master it may never be possible because not only is there already a huge amount of technology in the world to learn and work with, advances are constantly being made. While this means that there will be plenty of jobs and responsibilities for computer scientists, there may also never be some kind of finish line in terms of mastering computer science and technology. However, the same could be said for other fields of learning because advances are also being made in those fields that may or may not be linked to technology, and we always have our and other people’s experiences to learn from. There is always more to learn from, and computer science is just one example of that.

One more thing I want to mention and that I liked is that it is reinforced multiple times going over this problem that the path of focusing on mastering skills over your whole life is not the only path. Other paths for computer scientists such as settling in on a job like tester or project manager, entering jobs early in your life, or even leaving the field and going into other fields are also valid. These paths are not the focus of this book, but there are not wrong paths to take either.

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

Apprenticeship Pattern: Confront Your Ignorance

Last week I took a look at the ‘Expose Your Ignorance’ apprenticeship pattern, and this week I will focus on the ‘Confront Your Ignorance’ pattern. This pattern is closely related to the last. Once you have become aware of the gaps in your knowledge, you will need a way to address those gaps. It may seem overwhelming to try to learn skills that you are expected to have in the first place, but this pattern provides insight on where to start. In the previous pattern, you are advised to write down a list of things that you don’t understand fully, and then you can begin confronting your ignorance. Start with one skill, tool, or technique at a time, and educate yourself on the topic. There are many different approaches in doing so, including reading documentation and FAQs, building ‘breakable toys,’ and consulting with ‘kindred spirits.’ Once you have reached a level where you can comfortably work with said skill or tool, you can decide whether to continue honing your skills, or move onto the next item on your list.

I like that they have separate chapters that focus on exposing and confronting your ignorance. While both topics are related, they are entirely different hurdles that need to be leaped over. The pattern also mentions the balance between exposing and confronting your ignorance. Confronting your ignorance without exposing involves  learning in private potentially due to fear of criticism. Doing this only encourages that mindset that failure is not an option. On the other hand, you can expose your ignorance without confronting it. This can involve not taking action against your ignorance, which is also detrimental in a team environment.

Like I said in last week’s blog post, it is always best to recognize what you are unfamiliar with and take action as soon as possible. This is especially true in a professional setting, where things need to be completed in a timely manner. Thinking back to my first two years at Worcester State, I don’t remember asking for help often, which was definitely detrimental to me. Now, I am more open to the idea of looking into topics that I don’t have a strong understanding of and reaching out to classmates for help.Moving forward, I would like to continue practicing applying these patterns. Especially now that I am working in a team, it is important to not overly rely on them or drag them down by confronting my ignorance all the time.

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

Nurture your passion

There is a saying that “if you love what you are doing, you will never work one day in your life”. Software engineer/developer is a job that requires patience and passion. Without passion, people would easily give up their work.
As I mentioned in “Sweep the Floor”, we need to willingly work the job that no one else would do as we first start to learn and to improve our knowledge. But there is a side effect to that. The side effect is that we work in an environment that stifles our passion for the craft.
In whatever situation, we would always need to look back, take a moment to think of our true passion for software craftsmanship. To become an excellent developer, we will need to have a tremendous passion for what we are doing. However, under some circumstances such as deadlines, corporate hierarchies, or bad management. It is hard for developers to grow under those conditions.
Finding something at work that interests you where you pour time and effort into it. Considering some extra time outside of work to build some Breakable Toys to help expand the knowledge. As Paul Graham said: “The key to being a great hacker may be to work on what you like…To do something well you have to love it. So to the extent that you can preserve hacking as something you love, you’re likely to do it well”. If we do something with love, eventually things turn out really. We build better software with great quality.
Start a weblog and read blogs. Write about the topic that interests you. Doing that also not only helps you to learn new techniques and technologies but also could become your side hustle. Participate in online forums such as Stack-overflow by answering questions that others might have. Read thoroughly others’ answers to learn more about the material with different approaches.
To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This means in some situations you leave work early, walk out of a meeting that becomes abusive, adjust your attitude, and refuse to distribute your code if it does not meet your minimum. Eventually, the result could be bad for pay raises, promotions, kudos, or popularity. But keeping these boundaries helps to keep your passion strong.
Needless to recite what I have said in the beginning about passion. In my opinion, passion is the only thing that keeps you moving forward, eager to learn, and the desire to explore. You would not need to work a day in your life if you work with passion.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

If At First You Don’t Succeed… Sprint, Sprint Again! (Sprint 1 Retrospective)

INTRODUCTION: Looking back on this sprint, I can say that our group has performed quite well. better than expected, honestly. Perhaps I have an irrational fear of “events always going haywire”, but at least this phobia keeps me well aware of the situation (“on my toes”, you might say).

Considering the activity found on our group’s gitlab project, we can see that this sprint has consisted mainly of research write-ups, alongside some minor work for the frontend, backend and API of the IAMS.

POSITIVE FACTORS: Here are some factors of the sprint that I believe went well:

  • Our group had satisfactory distribution of work.
  • The group was able to present a “proof of concept” demo that met specifications for the current sprint. Examples include a basic frontend/backend/API system.
  • A lot of research was done during this sprint; our group was able to learn a bit about Kubernetes, VUE, Node.js and other software that is crucial for the IAMS.
  • Keycloak has not been set up, but a plan has been made to get it running by the end of the second sprint.

NEGATIVE FACTORS: Here are some factors that I believe can be worked upon:

  • The group seemed to struggle with suggestion a proper amount of weight for each issue. Specifically, we seemed to “underestimate” the difficulty of certain issues (such as setting up a Kubernetes distribution). In short, the group often weighted issues as easier than they actually were.
  • I feel as though having “more concentrated roles” within the team would be beneficial. While we had two teams (coding and research) led by a scrum master, I feel as though we can have “individual” roles. Applying roles such as “Quality Assurance”, “Presentation Director” and “Merge Coordinator” would help make a better team.

TEAM IMRPOVEMENT SUGGESTIONS: In order for the team to improve, some suggestions that I would improvise include:

  • More communication. While our group had used discord and gitlab to an impressive extent, I feel as though there can always be improvement. Additional communication can give us a better idea of our current position in the project, as well as create solutions for the next steps forward.
  • Enforcing the “Scrum Structure” more properly. This is an extension of the previous criticism (“More Communication”). In addition to standup meetings, the group should be engaging in a “Daily Scrum” meeting every day, (regardless of class)

SOLO IMPROVEMENT SUGGESTIONS: Personally, I feel as though my team worked spectacularly. If anything, I believe that I was the worst one on my team (following the Apprenticeship Pattern: “Be the Worst”). In order to improve upon my own performance, I believe that I should look at the following shortcomings:

  • Dedicate more time to the work. Unfortunately, while I am busy with other factors (such as work, other classes, and so on), this is not an excuse. This project is meant to be treated as though it is a paid job; the performance delivered should reflect a similar quality.
  • I would also like to reach out to LibreFoodPantry staff, as well as other groups, more often. Communication and cooperation are key factors to creating this massive project; each group creates their “piece of the puzzle”, and then it will all be fit together towards the end.
  • Finally, having a greater understanding of my role (such as “Coder”, “Quality Assurance”, and so on) would be crucial to future work. As of this sprint, I seemed to dabble on various topics without concentrating on anything in particular; this can lead to messy, unfinished work.

Most importantly, I would like to point out that this retrospective blog was posted late (it was meant to be done before the start of Sprint 2). This, in itself, is an error that needs to be rectified in future sprints – timeliness and containing work within the sprints is essential in order to keep the project from falling apart. It’s okay if work carries over to another sprint, but that usually needs to be planned from the get-go.

All in all, the first sprint never goes perfect. No matter how hard one tries to make it go right, something always goes wrong. The point of this lesson (and by extension, this class) is to ensure that we look back on these errors; we then perform research on them so we can modify our work habits. All of this is done to ensure that the mistakes don’t occur again in future sprints. As I look forward, I will do my best to enforce these new policies.

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.

Read Constantly

This Apprenticeship Pattern is about constantly reading books pertaining to the subject of computer science as to supplement your real-world hands-on experience and as to not stagnate your learning. By not only learning through on-the-job experience or personal project experience, and having a few different routes of learning, you enhance your overall knowledge of the subject. This way, you also avoid stagnating your knowledge, because if for your job you are repeating the same or many similar tasks, then you aren’t really learning anything, or are just learning very little. This is because when you do the same thing over and over, you don’t really have to think about it anymore, and a lot of it is just automatic for you.

By reading constantly, you are actively engaging your brain to focus on new material. The great thing about reading is that you can do it anywhere, and at any time. Anytime you have spare time in the day, it is easy to just read for a few minutes and learn something. Also, by not reading it for very long periods of time, you avoid losing focus on the material, and instead can focus on the material in shorter, more manageable bursts.

I really like this suggestion because I have a lot of trouble sitting down and reading something for long periods of time. With your phone, computer, tv, etc. there are many distractions that draw your attention away from whatever you’re trying to focus on. This can make actively trying to read very difficult, but by doing it in whatever free time you have, you can avoid the distractions and help focus on the reading. I much prefer reading, or anything that requires sustained attention, in short bursts rather than long marathons. In short bursts I can ensure that I keep my attention on topic, but the longer I do it the more my attention dwindles.

The only thing I disagreed with was the suggestion to only read books, and not blogs or other resources. While I do think that maybe being online and not having a physical book may increase distractions, I also think that there are many great educational resources online that are invaluable. In my opinion, the thought that some things must be learned from books is outdated and could maybe even hinder learning. Everyone learns in different ways, so by suggesting that everyone try to learn from books doesn’t make sense to me.  

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

Sweep the Floor

Everyone starts from somewhere. Nobody knows what they are supposed to do when they first start to do something at their new jobs. They start from small tasks with little experience to more challenging tasks with better experiences in knowing what they should be doing. Gradually, they become an expert and do their job better. “Sweep the Floor” shows us how developers should lower their expectations when they’re fresh out of college and take on simple tasks rather than picking up experiment ones.
The problem shown in this section is we are pretty much unsure of our place in the new team and the team would not know what to expect from us. This might cause bad consequences due to under-performance and bad communication. The solution for this problem is to willingly take on volunteer work. This does not mean taking on any kind of work but should be the work that improves our understanding of the team, the work, and gain experiences. A great method is to show that we could do a high-quality job even it does not seem to matter in some way. An example of this is one famous for his work as Uncle Bob Martin who volunteered to come into a room and took out the trash. The task seemed unfair and jaw-dropping for such a developer, but this job brought him admiration and devotion. However, acquiring an easy task does not mean that we should skimp on quality which might lead to trouble later.
Another problem is that some people think they are better than others due to their educational background. The hard truth is at the workplace, that does not seem to matter much. Workplace and school are contrasting when it comes to real life. You might do good in school but it does not guarantee you would do as well at your job. Having better education means higher expectations for you on the first day.
Yet, there are consequences for taking on an easy job. We might become the team’s gopher who get assigned the tasks that no one else would do. From that, we are unable to take on more challenging assignments. The better way is to advocate for yourself and look for every opportunity to prove yourself worthy with higher-level work.
After all, we should take on the tasks that everyone complains about, do it and do it well. Because that is the only way to show people that the can-do attitude and exceed people’s expectations.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Breakable Toys

In breakable toys of Apprenticeship Patterns, the authors clarify that developers should have room for failure, and failure makes greatness. Good experience is built upon failure as much as success like in the saying “Rome was not built in a day” which means there is no overnight success. Mistakes are made, but learning from mistakes is a way to help us gather deeper knowledge and also aid us in collecting further experiences.
What was interesting in Breakable Toys was the close bridge between learning and failing. Failure is part of a software developer and without failure, there would not be a great developer as well as great software. What I agree is developers should be given space where they can seek out failure to train their mindset and to develop their practical involvement. The example was Steve Baker (a teenager working in Nova Scotia), people looked upon him as a leader and an expert within his small development organization. Thus, he could not afford to be wrong and obviously could not walk away from his people who were depending on him. The solution that he later found out was using a breakable toy. Breakable toys were the tools that he used to help him learn by failing.
What I have learned is that when implementing the breakable toys pattern, I should make the system relevant and useful to my life as an apprentice. The examples were building my projects such as a to-do list or expense tracker. At first, the solution would somehow be overengineered and failed. Yet, these are the type of projects that were designed to be backslid without any bothersome. They are used to develop my ideas and techniques and could be a disaster but that is a part of learning. By building these projects, they give me a deeper understanding of designs, data structure, and language. Furthermore, not giving up on problems would help me eventually get them right. Beyond constructing things myself, consider team efforts as one of the alternative ways of learning.
The point that the authors try to make in this chapter is by building things will help developers learn better than listening to plain lectures. Allowing space for failures is a way of improving and expanding knowledge as well as experimenting to learn deeper and to understand thoroughly.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #4 – Breakable Toys

The most significant part of the learning process as a software developer is putting the knowledge that I have acquired over time into actual, practical use and create something tangible that is a good representation of what I have learned. While it is important to have a good grasp in the theoretical aspect of my craft, it will do me absolutely no good if I do not actually exercise the skills I have acquired, especially when I need to use them in a professional environment. However, it is not just the act of simply practicing any acquired skills that is important. What is also important is to know how to properly apply the skills in real situations. For example, simply knowing how to code in theory is simply not enough on its own, it is also important to experiment with the acquired skills as part of their learning process. In this case, the pattern of “Breakable Toys” is introduced.

When a developer chooses to utilize “breakable toys” as part of their learning process, it means that they are working on personal projects that, although they are detached enough from a professional environment so as to minimize the risk of failure, they have enough functionality so as to maintain the realism of working on an actual project that needs to be delivered. Essentially, a developer creates a functional project on which they can experiment on and use any potential mistakes that may occur along the way as valuable ways of reflecting on or enhancing their learning process. The developer gets to reap the benefits of hands-on experience with none of the risks of  that would come up if their inexperience were to result in failure while working in a professional space. However, it is important to note that “breakable toys” in programming does not mean that the practice that you put on is discarded immediately after a developer has a better understanding of the problem they practiced on. Rather, “breakable toys” that are broken should also be recorded with the same importance as spike solutions that work flawlessly.

This particular pattern is a favourite of mine as it combines the pattern of “Practice, Practice, Practice”, which I always enforce in my own working career ad-nauseum, as well as the pattern of “Record What You Learn” since even small projects that were made on a whim may still be valuable enough to return to later. However, a significant aspect of this post’s pattern that aligns with me is the focus that it puts on actual hands-on experience, which is more valuable to me than endlessly reading documentations that I may never utilize.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.