Author Archives: sohoda

Craftsmanship Log #8 – White Belt

Although I tend to speak rather broadly about certain apprenticeship patterns, nonetheless many of the patterns I have written about in this blog do apply to the field of Software Development. After all, the book, from which these patterns have originated from, that I have been reading for the past few months is more focused on programming than any other craft. This is the reason why this particular pattern applies to my learning process of Software Development which, ironically, I realise that I have not applied to the degree that I thought I have when learning other programming languages. In fact, a significant part of the learning process is to “unlearn” pre-existing knowledge and approaching learning a craft in a “blank slate”. This notion corresponds to a pattern titled “White Belt” which, though it may seem ironic, it is in fact a very significant pattern.

When a developer faces the need to utilize this pattern, it means that their pre-existing knowledge may be interfering with acquiring new knowledge and skills more challenging, or even impossible. When it comes to programming languages, the know-how that one may be holding on from learning and mastering their first programming language may impair their problem-solving approaches. Oftentimes, they may be expecting to see tools or concepts from one language they already know that are completely non-existent in the language that they are learning. Moreover, the potential differences in syntax can also throw an apprentice off when learning a new language, thus it is easy for us to hit a roadblock simply because the solutions we may want are (or so we think) simply not there. As such, a way to avoid this roadblock is to simply approach the new language that we are learning as its own thing and with a clear state of mind.

Usually, I tend to say that I like or agree with a pattern because in my own experience I tend to utilize such patterns in my own, perhaps roundabout way. However, this pattern is the first that has made me question my own approach to learning, which is contrary to this pattern. I often tend to look for “common ground” between my pre-existing knowledge and the new knowledge before me to “save time” and get to “the good stuff” faster. In a way, this pattern hurts my pride as a software apprentice. And, in all fairness, it should. It is important for me to acknowledge that flaw in my learning process and instead wear the white belt when I pick up a new programming language to learn.

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

Sprint Retrospective #3

As the third and final sprint for the semester, and with that my involvement with the N.I.C.E project, has come to an end, it is time to reflect on the progress that has been made, as well as what has changed with respect to team and personal work compared to the previous two sprints. The difference between this and the previous two sprints is that this sprint was the proper beginning of actual implementation of the features that we had been brainstorming as a team over the previous two sprints. With this being the case, we were no longer at the stage where we struggled to find some footing regarding the project’s infrastructure; we had actually begun laying the foundation that this project will be based on. In simpler terms, this is the sprint where we were no longer working on spike solutions, but actual source code. This meant that we were overall working with a more hands on approach to this project.

Though admittedly not perfect, this sprint proved to be the most productive sprint both in terms of actual productivity, given how we had to work over 42 issues, and well as individual and team growth. During this sprint we as a team had a much clearer direction in what we thought needed to be implemented, as well as how we would approach said implementation. This meant that members of both the Docker and the Source Code groups were more independent, which helped make some very good progress. That is not to say that all team members were working in complete isolation – on the contrary, there was by far more communication taking place across both Gitlab and Discord between team members during this sprint. This was especially prevalent in the Source Code team, which I was part of, as I made time to meet independently with my fellow team members to discuss or collaborate on certain issues. In my case, I was assigned to work on the following issues:

1) Implement file parsing to implement a question into a card component
2) Implement a method to make multiple copies of the single question preview component
3) Implement the component that contains a single question preview
4) Build a page that shows previews of the questions for the interview
5) Fix the visuals for the card components on the question previews

Sadly, we did not manage to implement certain issues exactly as we had envisioned them either due to bugs occurring or due to lack of time, though we still managed to make some satisfactory progress despite it all. Moreover, unlike the second sprint, there has also been improvement with respect to time management during meetings, something that we had reflected on and had problems with in earlier sprints. Though there were still cases were the conversation would veer off topic, we as a team were more conscious and thus put more effort into returning to our topic of discussion. This was also affected by our documentation; given that we begun to put more effort into documenting the development process into the appropriate issues on Gitlab, it has been easier for team members to be on the loop and communicate any misunderstandings outside of meetings. Moreover, I feel like my own working process has improved as a result, especially my weakness in properly gauging an issue’s proper weight. During this sprint, I feel like I have improved in taking the proper care to dissect and break down a goal into smaller goals so that implementing a feature is easier in terms of what steps need to be taken towards implementation, as well as seeing how my issue could be connected to another team member’s issue. Thus, instead of panicking to implement a vague issue, I noticed that I made better progress by implementing smaller and clearer issues.

As I mentioned, this sprint was by far the most productive sprint for the course. Though there may have been some occasional flaws or problems in productivity, these flaws were not as significant when compared to the second sprint. Overall, as a team we have noticed that we had finally gotten on a steady and clear path.

Direct links to issues:
1) Implement file parsing to implement a question into a card component:
2) Implement a method to make multiple copies of the single question preview component:
3) Implement the component that contains a single question preview:
4) Build a page that shows previews of the questions for the interview:
5) Fix the visuals for the card components on the question previews:

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

Craftsmanship Log #7 – Digging Deeper

One thing that the field of Computer Science is rather notorious for is that, for new learners, the entry level may seem incredibly low for someone who is interested in pursuing programming in any degree. Given the abundance of freely available resources for learning programming languages, this should not be that much of a surprise. It is easy for someone to find a tutorial online on how to implement inheritance in JAVA, with such tutorial presenting this concept through some oversimplified example. This, in and of itself, is not a bad thing; it is important to learn things in smaller steps. However, some software development apprentices may take to simply memorizing the knowledge they acquire and how to simply implement the tools available to them without much understanding, thus acquiring only a superficial understanding compared to a deeper, more thorough understanding, which in the future may become a habit that can interfere during the development of bigger projects. This situation is introduced as a pattern titled “Dig Deeper”.

What this pattern means for an apprentice developer is that, oftentimes, they may have found themselves in part of the development where their technical knowledge at that point in time may seem to be lacking because the superficial knowledge they have gained during the learning process was not sufficient to provide meaningful contributions in a project of a larger scale, especially in a professional environment. For example, someone who may be working on deploying a web-based application may run into this pattern. The apprentice, though they may know a bit about how REST APIs may work, they may still find themselves struggling because the project they are working on presents concepts that are impossible to cover in a simple tutorial. The apprentice may know how to implement functionality on the backend, but have neglected to get a  deeper, understanding of how such functionality may impact the frontend. Thus, when something in the frontend fails because of the backend, the apprentice may provide a solution that in the long-term does little to solve that problem. Overall, an apprentice who, regardless of their proficiency in their area of expertise, does not take the proper care to understand how such expertise may interact with other areas can hinder the long-term maintainability of a project, as well as have a negative impact on the apprentice’s own learning process.

While it is impossible to be an expert on every single concept and tool that exists ,not only within one’s area of expertise, but also for every single area that may constitute a bigger project, it is still important to take the time to gain a deeper understanding of how other areas work in conjunction to one’s expertise.

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

Craftsmanship Log #6 – Craft over Art

In many crafts, an apprentice’s main goal is to gain the experience and knowledge necessary to succeed in the craft of their choosing. Whether it is art or programming, an apprentice goes through the process of learning not only what techniques exist in their craft, but also how to acquire the techniques they learnt to achieve their goals. Though I personally cannot speak about art due to having no prior experience, I can say that in the field of programming I am aware that I will often be tasked to work on creating solutions for people. What I am also aware of is that we may almost never be on the same page regarding what customers want and what I may think is best for them. Though I personally may want to give a customer a product of code that balances functionality and aesthetics, it is this focus that may hinder the development process rather than help it. This situation is an apprenticeship pattern referred to, aptly, as “Craft over Art”.

A craftsman may encounter this patterns when they are put in a situation in which they are tasked with creating a working solution for a customer, though they may use this opportunity to show off their knowledge of the craft rather than applying the appropriate skills in order to create something viable and useful. In the case of a software developer, the craftsman may choose to put more emphasis on aesthetics by implementing functionality that may look fancy rather than using the proper functionality and techniques in order to deliver a working product that meets the customer’s specifications. Some developers may fall into this pitfall because, they believe, that the quality of the product is best shown only through how “fancy” the implementation looks and not through how the final product itself performs. This pitfall may be especially evident in software development, where the product itself may have to be maintained by other developers in the long run but may struggle with by virtue of how the original developer approached the implementation in the first place.

Though I personally may want to show off my skills by making programs in a creative way or to refine an existing piece of code by implementing fancier algorithms or optimizations, I understand that there is a time and place for that, oftentimes away from the professional environment. In fact, I strongly believe that having useful code to work with as soon as possible is far more important than having code that looks fancy and intricate that fails to deliver on its specifications.

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

Sprint Retrospective #2

Now that the second  sprint of the Naturalization Interview Confidence Environment project has ended, it is time to yet again reflect on the progress that my team and myself as this sprint’s Scrum Master have made thus far. Moreover, it is also time to reflect on what went right on wrong during this sprint, both in regard to what we as a team decided to improve upon based on what we discussed during our first retrospective, as well as what new obstacles may have shown up during the second sprint. It is important to note that in this sprint, unlike the first, the team had a sense of direction as to what needed to be done. For comparison, during the first sprint we were more concerned with determining what development framework we would need to use for the project while in the second sprint we had somewhat begun the development process of the project as well as creating the infrastructure for development. Though some progress may have been made, this sprint did not prove to be as fruitful as the last.

In this sprint, we as a team had planned on working on 36 issues across 5 epics. Moreover, for this sprint, the main team was separated into two sub-groups with one working on creating the application itself while the other worked on creating the Docker development infrastructure needed for future development. The application development group, of which I was a part, was tasked with implementing the following functionalities:

as well as other functionalities that would be necessary, such as ways to navigate between the aforementioned functionalities. I was primarily tasked with implementing the reading portion of the application (as linked above), meaning I needed to implement the necessary functionality for a user to be able to see previews of the questions that are to be included in the application, as well as interact with each question separately. Though I was tasked to implement a specific functionality, I was still expected to help my teammates of the application team in the case they needed assistance with their own task, as well as provide support to the Docker infrastructure team.

          Though, admittedly, the breaks that occurred during the sprint contributed to hindering the structure of our productivity, as well as certain tasks taking much longer to work on than we had anticipated, there was still some progress regarding the infrastructure aspect of the project which continues to be worked on and improved by the responsible team members. Some problems that we had noticed in retrospect are mostly related to our management of time both during and outside meetings. As a scrum leader I still had issues managing our time during meetings such that there was a balance between allowing all team members to express themselves fully as well as using the meetings to outline what progress has been made and what progress needs to be made. Moreover, though we as a group acknowledged that documentation is extremely important, there was still lack of proper documentation and clarity in issues, which contributed to the improper time management of our meetings since there was more focus discussing what each new issue actually meant, thus meeting discussions wound up being somewhat disorganized. On a positive note, however, our approach of “Divide-and-conquer” from last sprint was crucial in helping the team establish who would do what tasks, either regarding the application or the infrastructure. Moreover, there has been substantial improvement regarding documenting what is being discussed during meetings, with certain issues having the appropriate context needed to ensure proper communication of our goals and progress between team members.

          As detailed above, while this sprint had its flaws regarding productivity and time management, there was still some progress made regarding development and infrastructure. While we all, as a team, acknowledge that some mistakes from the first sprint were still present in the second sprint, we are all still willing to learn from such mistakes and improve our own productivity and communication.

Direct links to issues:
1) Build a page that shows previews of the questions for the interview:
2) Learn how to use commitlint/conventional commits for the Application source code:

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

Craftsmanship Log #5 – Learning how I fail

               I mentioned in a previous post that, essentially, failure is as much an important factor of the learning process, at least for those who use the mistakes they make as an opportunity to reflect and properly understand the new knowledge that they may have gained. This means that our learning process has helped us, in a way, adapt our way that we approach problem solving so that we may avoid falling into any pitfalls depending on what we are needed to work on or properly utilize any techniques that we may have picked up for the right situation. However, no matter how diligent we are in our learning, we all have certain strengths and weaknesses that play a major role in each individual apprentice’s learning process. This situation is elaborated in the pattern titled “Learn how you fail”.

               Now, it is important to understand what is really means to “fail” in this case. This patter is not about an apprentice being unsuccessful in their craft and giving up without putting the proper amount of work to improve. Rather, it is about an apprentice’s acknowledgment of where their weaknesses related to their craft lie, which weaknesses does one feel they are worth working towards mending, as well as how to approach their craft in such ways that their weaknesses do not interfere. When one needs to learn how to fail, what they are really learning is developing the self-awareness that is needed to further hone their craft. While being an expert on a specific concept may be convenient, turning into a one-trick pony because one is complacent in what they are good at and do not feel like taking the risks necessary to improve their craft will do an apprentice more harm than good in the long run. An example from my own experience (though not CompSci related) that comes to mind is from my job as a tutor; while I am familiar with all the mathematics courses I am expected to know, I am aware of my weaknesses in the way I tend to communicate certain concepts to others. Through experience, I learned how exactly that weakness manifested so that I would make sure to change the way I would communicate my knowledge to others.

               Though gauging how far we have progressed in our learning process based on the number of our successes may help us in building up confidence to continue honing our craft, it is important to acknowledge and admit our weaknesses, as well as knowing which weaknesses are worth improving or avoiding provided we take the necessary risks.  

From the blog CS@Worcester – CompSci Log by sohoda 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.

Craftsmanship Log #3 – Practice, Practice, Practice

               Many of us have heard or said the phrases “Practice makes perfect” and “Repetition is the mother of all learning.” Though I personally can neither define perfection nor learning, I can say that no one can gain expertise off anything they see once and never apply again in their lives. Even though we may understand a new concept that we learn at first glance, it is when we repeatedly work on it hands on that we can truly experience the nuances that are introduced. Continuous practice is known to help considerably during the learning process, as one works to internalize the knowledge that has been introduced to them. This is also a pattern introduced in the book “Apprenticeship Patterns” by the name “Practice, Practice, Practice”. Though the name of this pattern is rather straightforward, it is important to emphasize what makes this pattern and important component of the learning process.

               Simply put, “Practice, Practice, Practice” is a pattern that is meant to address an apprentice’s potential hurdles that may stem from neglecting to practice their craft hands on and on a frequent basis. As such, apprentices may not have a proper understanding of where their strengths and weaknesses lie, thus their learning reaches a point of stagnation. However, if an apprentice only takes the time to practice what they learn in a work environment, they may end up hindering their own growth since they add the stress of having no room for error on top of learning something new. As a solution to this hurdle, apprentices are advised to find exercises to practice on at their own time and pace and in an environment that treats any mistakes that come up as opportunities for learning rather than signs of imminent disaster. That way, an apprentice can take the time to properly learn and improve their craft. What may also help is communicating with experienced people that can point out any habits that may be counterproductive in one’s learning and provide the appropriate feedback that an apprentice may need.

               With that being said, I want to point out that I have not mentioned the words “programmer” or “developer” when discussing this pattern, even though I believe it is by far, in my own experience, the most crucial pattern stated in this book.  In fact, I personally try to get my peers, as well the people I help at my job, to espouse this pattern and incorporate it into their own learning process. Though I disagree with the notion that “practice makes perfect”, I wholeheartedly believe that actively practicing new knowledge in an environment that allows mistakes can do more to help an apprentice learn in the long run.

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

Sprint Retrospective #1

               As the first sprint of the Naturalization Interview Confidence Environment project I have been assigned to work on has finally come to an end, I think that it is time for me to look back on what my team and I managed to achieve, as well as reflect on what I think went right, what went wrong, as well as which of my actions I believe may need to be adjusted before the upcoming sprint begins. Initially, I was somewhat fearful that we would be off to a very rocky start, given how the project itself was borderline non-existent due to the lack of code or repositories from the get-go, meaning that we as a group started work from square one. However, such fearful sentiment had soon dissipated as the sprint went on and more work began to be done. That is to say that, for such circumstances, I believe that this first sprint was an overall positive experience, given the people that I was assigned to work with in my current group.

               In this sprint, my team began working on 40 issues across 8 epics, with around 29 of them being resolved by the end of the sprint. Though everyone was assigned issues to create and populate needed repositories, everyone’s main focus included looking for and learning what Native development framework should be used for the project, in which case I was involved with Ionic Angular. I was involved in the following issues (not including duplicated issues):

               As I mentioned previously, the first sprint overall went fairly well. Given how our main focus was to choose one of the three recommended frameworks that we had found (React Native, Flutter, and Ionic React), we were divided into three sub-teams of two members, with each sub-team studying a specified framework. Such dividing tactic worked very well for us, as each team could learn one framework and communicate their findings, such as what they believed would work well for the project. Overall, our method of dividing work among individual group members or sub-teams seemed to work very well for us, especially evident on the topic of choosing a framework because everyone was great at communicating their perspectives. This is also due to the fact that, even though we may have not worked with each other before, we still had some very good chemistry that made communication much easier and more productive.

               However, what did not work well for this sprint was the fact that we, as a group, were lacking on the aspect of properly documenting what takes place during meetings. Though our meetings in class were productive, we do not have any records of what was done or said during the meeting except for some issues posted on the issue boards, and this lack of documentation may bring some difficulties to people who may work on this project in the future. As for myself, I admittedly felt like my time management skills for this sprint were not exceptionally great, given how I devoted disproportionate amount of time and effort into learning Ionic Angular in a somewhat selfish manner, as if I wanted to learn this framework as part of a hobby rather than as part of the project.

               Regardless, this first sprint was off to a very good start, all things considered. Of course, there are some aspects that we have all agreed that we need to really work on as a group, namely the aforementioned lack of documentation of our meetings. Thus, we may need to develop a strategy that can help us keep a proper record of each meeting without breaking the flow in a distracting manner. As for myself, I will definitely need to improve on my time management skills and learn to devote the appropriate amount of time on tasks that need to be done and further learning of React Native.

Direct links to issues:

  1. Scope for the Ionic framework:
  2. Create demo app in Ionic Framework:
  3. Add a file to the “Documentation” repository:
  4. General Resource Collection:

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

Craftsmanship Log #2 – Recording What I Learn

I feel the need to underline that the patterns discussed in the book “Apprenticeship Patterns” do not exist in a vacuum, though conceptually they can be considered as independent concepts. In fact, it is possible, in one way or another, to utilize multiple apprenticeship patterns at once without realizing it. In my latest post, I briefly went over the apprenticeship pattern related to a programmer’s first language, aptly named as “Your First Language”. Looking back on my learning approach to C (my first programming language), I notice that my learning process included a combination of this pattern with other patterns named “Record What You Learn” and “Breakable Toys”, which former pattern I mentioned briefly in my first post about the book “Apprenticeship Patterns”.

As the name of the pattern suggests, “Record What You Learn” is a pattern that is mean to address a software developer’s (or a learner’s, regardless of the subject) potential negligence of making sure to keep a record of the concept’s that they may encounter during the learning process. Such negligence brings the risk of the developer losing important knowledge, thus facing issues when they encounter a problem, they need to solve for which they have an extremely vague idea, at best, of how to find and implement solutions.  In this case, a helpful solution to this problem is for the learner to begin developing and maintain the habit of keeping records of anything that they learn as they learn it, either on a blog or wiki. However, it is important for anyone who records their learning process in such a way to make sure that they actually utilize what they record continuously rather than simply dump their thoughts in a blog post and immediately forget what they were supposed to be learning in the first place.

In my own experience, recording what I learn either in the way of making private journals or code repositories has helped me in my learning process tremendously. On one hand, keeping an organized archive of concepts I have learnt, along with specific sources and examples (not too different from this blog), has made it easier for me to quickly go back and refresh myself on knowledge that I feel I can use for problem-solving. Moreover, going through the process of writing a journal of the things I learn helps me internalize new concepts much better, especially with respect to code. Perhaps this pattern is especially helpful for people like me, who need to write down what they learn since it is a much more helpful way of learning.  

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