Author Archives: Brendan Lai

Week 13: Reading List

For this week, I chose to read ‘Reading List’ from Chapter 6: Construct Your Curriculum. I thought this pattern would be a good last pattern to read about now that the semester is ending. This chapter consisted of mostly patterns that are useful for post undergraduate stuff and things to reinforce in your head moving into your software career. So, for the context of this pattern, after becoming proficient in your first language (another pattern), you begin to look around and see the vast sea of info. I found this relatable as there is so many different languages in software programming and so many different technologies that accompany it as well, there is a lot to learn. However, with that in mind, I think that just makes me wanna learn about a lot of the different languages and technologies since software development is so vast.

For the problem of the pattern, you are unable to keep up with the amount of books you need to read. I thought this was kind of a weird problem, if you reach this problem, you probably aren’t managing your time well and need to readjust your curriculum in my opinion. However, the solution tackles this problem similar to what I was thinking, managing your time better. The solution is to maintain a reading list, this isn’t to only manage the books you read but also to reflect on past reading habits and you can use this info to construct a path on what to read next and what to focus on. I thought this was pretty clever, I wouldn’t have a reading list for that purpose, I would just use it to manage my reading habits. The solution does come with caveats though, it’s difficult to implement this pattern without having a deep understanding of your topic in order to figure out which books to read and the order. Ultimately, I think this pattern relies on having a deep understanding of what you want to learn about and what rabbit holes to go down in order to become more proficient at those topics.

For the action, you obviously create your reading list, however you keep it under source control and up to date. Pretty simple action to do, it’s just finding out where to start and what to read that is the hardest part of this pattern.

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

Week 11: Create Feedback Loops

For this week, I chose to read the pattern ‘Create Feedback Loops’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, finding feedback on your progress. I chose this pattern because chapter 5 had the best info to digest, in my opinion, because I’m at that stage in my software craftsman career that where these patterns are the most relatable to me and will only prove to be more useful to me as time goes on. The context for this pattern is, not being able to tell if you’re unaware of how unskilled you actually are. By being unaware of your skill level, you are worse at assessing your own skills and when you do receive feedback, it’ll come as a surprise to your self assessment instead of a support mechanism to help you improve. I thought the context of this problem was spot on, the Dunning-Kruger effect came into my mind when I read this, sometimes people are too falsely confident of their own skills and clearly haven’t been told their real skill level on a certain subject matter. Ever since I became aware of the Dunning-Kruger effect, I’ve been trying to be more open minded to discussion and debate if I’m wrong on something.

For the problem of this pattern, it says your self assessment is only relative to the abilities you used opt have, you will always lack objectivity. I was not sure what this meant at first and I still don’t, however the next few parts that it describes I can relate to. It describes how being in a above-average team will make you feel like a superstar when in reality you’re more of a back up dancer, and how being on a below-average team will make you feel complacently smug. I can relate to this because in class, the backend team for the guest info system, they are definitely gonna go far in life as software craftsmen, I feel like they know what they’re doing which in turn makes me feel like I should know what I’m doing but, I’m just a back-up dancer.

For the solution of this pattern, you want to create mechanisms to regularly gather more or less objective external data about your performance. You will also want to be able to process the raw data from these mechanisms in order to get useful feedback about yourself. Honestly, the solution for this pattern was kind of confusing at first, I didn’t understand some of the mechanisms described but I’m sure in practice it is better than it is described.

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

Week 10: Practice, Practice, Practice

For this week, I chose to read the pattern ‘Practice, Practice, Practice’ from Chapter 5: Perpetual Learning. The name is pretty self explanatory as to what the pattern will be on, practicing. I originally chose this pattern because it’s something that we need to reinforce within ourselves in order to get better at something, for coding especially. This is something I still struggle with due to my lack of drive and motivation but everyday is another day to push myself. Any way, the context of this pattern is wanting to get better at the things you do, to develop concrete skills. Again, just looking at the title gave away the context of this pattern, but that was it.

For the problem of the pattern, it is being unable to learn from your mistakes due to the performance of you daily programming activities, you feel like you’re always on stage. I assume this is in context of a job, but I haven’t experienced this problem yet so knowing about it ahead of time is going to help me down the line. For the solution of this pattern, you want to be able to practice without interruptions and in an environment that makes you comfortable making mistakes. This seems like an easy solution but in practice I’d imagine it’s hard. The solution also mentioned having a mentor to watch you over your practice and provide feedback. This is something I’d be interested in doing but I lack the humility to have a mentor watch me and provide me feedback, I’m always trying to do things on my own. I also dread looking at feedback because I feel I always mess something up, but I believe a pattern in the one of the previous chapters mentioned to put aside your ego, so I’ll have to go look at that one again.

Finally, for the action of the pattern, something I don’t write about often but I thought it would fit here, is to read one of the books that was previously mentioned in this pattern and take an exercise from it or make one yourself. The exercise should ideally be slightly harder than you can easily solve. You’ll then do this over 4 weeks and record your solution every time and over the 4 weeks you should observe how your solutions evolve. I thought this was an interesting take on practicing coding that I’ve never heard about. I usually just one and done exercises but repeating a exercise really cements it into your head so I’d imagine this way is much more beneficial to me.

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

Week 9: Sweep The Floor

For this week, I chose to read the pattern ‘Sweep the Floor’ from Chapter 4: Accurate Self Assessment. This chapter is on, as you can read from the name of the chapter, accurate self assessment. I did another pattern from this chapter not too long ago but I think this chapter is easily the most relatable for me at least. For this pattern, the context of it is that you are a new apprentice on a project. I chose this because I could relate this back to when we were first starting our group projects and getting into our teams. It was a foreign experience to me since I hadn’t had an internship yet or anything of the sort. For the problem of the pattern, it revolves around you being unsure of your place on the team and the team is unsure of you. This was relatable to when we first started, we didn’t know each other and our work flows. Luckily, we were doing Scrum so we had a leader basically ease us into things. Additionally, the problem also is wishing to find a means of contributing to the team’s work, earning the team’s trust and growing as a craftsman.

For the solution, it followed the same approach as most of the solutions in this chapter were. Pushing yourself to do tasks in order to grow as a craftsman. With this pattern, the solution was to volunteer for simple, unglamorous tasks. This is ‘sweeping the floor.’ Doing tasks that are mandatory to the program’s success such as maintenance reports, bug fixing, code review, etc. I thought this was interesting because my approach to getting trust from a team is doing the hard work first in order to show I know what I’m doing and to show that I won’t let them down. However, this approach seems more personable than my approach and much simpler, on paper, as well. This solution does come with caveats though, as mentioned in the solution. One problem is you may become the team’s gopher, this means being condemned to doing menial tasks no one else will do. I, for one, don’t think that’s a big problem but I guess it depends on the person and their ambitions. Another problem is that you may find yourself intimidated by doing anything other than sweeping the floor. I can kind of understand where this point of view comes from but for me, I don’t think it would be much of an issue transitioning between hard tasks to relatively simple, menial tasks.

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

Week 8: The Long Road

For this week’s pattern, I decided to read ‘The Long Road’ from Chapter 3: Walking the Long Road. The context of this pattern is that today’s society values quick success and overnight celebrities more than long term goals and success. Due to this, software developers are much different compared to veteran software developers and make the same mistakes they had made when they were inexperienced software developers. The problem of this pattern is that I, the reader, aspire to be a master software craftsman but my aspiration conflicts with what people expect from me, quick success. My guts tell me to take the highest paying job and first promotion I’m given and ignore slowly building up my skills. I thought this was pretty spot on of how society is today. Social media makes it so anyone can become an overnight celebrity which is probably one of the root causes as to why society is this way. Too much do we value quick cash and success, some people even expect it which is weird considering how hard it is to become an overnight celebrity. People need to take a step back and learn to have a long term goal and work towards your success instead of trying to get rich quick.

As for the solution of this pattern, it was basically the same as I wrote above. I should accept that I may be considered weird for thinking long term but I should accept it. I should also keep focusing on my long term goal, which is to become a software craftsman. By following the long term goal of a software craftsman, I’m able to become more skilled at learning, problem solving, and developing strong relationships with my customers. This is a good thing because, as mentioned before, people are too focused on getting rich quick and not focusing on building themselves up. By sticking to this, I won’t get rich quick like some of these people but I will be much more experienced, having built myself up long term and sticking to a goal. This is a long journey I’m not ready for but this will help me much more later in my life.

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

Sprint 1 Retrospective

For Sprint 1, I mainly worked on the frontend of the guest info system. In our group, we split our team into two teams, one for the backend, one for the frontend. This is how we operated until the end of the sprint. We found that this way of splitting the work between the two groups worked well. I don’t think there were any issues with how this worked. I think my only criticism would be that I wouldn’t know what the backend was doing but that was mostly due to us only now starting with stand up meetings. Also, could be due to the fact that we mainly communicated between our own groups. This is a issue I think we could fix, I also need to work on my communication skills more because I sometimes find myself lost at times with what we’re doing.

Another thing that worked well was how well we adjusted to Scrum. I think our Scrum master, Vien, was a really good leader and was the leading factor as to why we did well with this framework. He helped set up everything for us and set the structure for how our team should work and what we should do. He was also very helpful and considerate with me when I would be stuck on something or one of us had an error with something, he would try to figure out what the issue was.

This sprint, I think I could’ve done a lot more, although the work for the frontend was kind of scarce and were minor fixes. For the frontend, we just needed to refactor mostly in this sprint and format it in CSS. CSS seemed the hardest and I wanted to work on it with another team member but he ended up formatting it all alone so I ended up not being able to work on it. Again, this was a communication issue from me since I didn’t tell him I wanted to work on it collaboratively. He ended up doing a great job on the CSS formatting, it almost looked like what we wanted it to look like, a Google Forms page.

As for me, I definitely could’ve done more. The amount of work I did compared to my other frontend team members is definitely lacking and you can see it in the commits. I’m also definitely the weakest coder in the group and it’s very evident. I am trying to learn more and more as I go through the sprint and being in this group encourages me to learn more and become better. In this next sprint, I’m gonna try to do more work, maybe even some of the harder issues like integration and deployment. On a more positive note, I think the group I’m in is a great group of people and is motivating me to be a better coder because this would be similar to the type of work I would be doing when I go into a software dev job.
Here, I merged a branch to refactor the register form template into the main branch.
A small change to change the id-input into vue.
Here, I moved id-input.vue from main into our refactor branch, keeping most of the code.

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

Week 7: Be The Worst

For this week’s pattern, I chose ‘Be the Worst’ from Chapter 4. I initially chose it because it caught my eye and I was going in order of chapters with the patterns I chose. I thought it would describe in detail to be the worst of your team but it was actually the opposite. The context is after unleashing your enthusiasm, which I assume was a pattern before this one, you take every opportunity to learn new skills. As a result, you outgrow your team and possibly your entire development organization. This was much different from what I originally thought this would be about, I thought this would be to think yourself as the worst to get better as a software craftsman. It kind of follows that pattern of thinking though, basically surrounding yourself with better developers. This in turn, will motivate you to be a better developer and have room to grow as a developer. I thought this was an interesting point, I mean this is something that I sometimes think about and is actually something I’m experiencing right now. I’m in a team that I feel like are all better developers than me which in turn makes me want to be a better developer because sometimes I feel so lost when in team discussions. This pattern really stuck with me because I related to it a lot. I just need to find the motivation to be a better developer, I need an extra push because just a team of strong developers won’t push me hard enough to find that drive to be better than I was yesterday. The pattern also mentions Breakable Toys and Reflecting as You Work as patterns to go back to because they are particularly important if you are the worst on your team, which I am. I guess I’m gonna check those out after this pattern, maybe even write about them. Honestly though, I feel like this pattern kind of reinforces impostor syndrome, which I found out is pretty common amongst developers and probably is common in STEM related jobs, but at least with this book, it puts out a solution for you to follow.

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

Week 4: Apprenticeship Pattern, Craft over Art

For this week’s pattern, I chose ‘Craft over Art’ from Chapter 3. The title is self explanatory but I’ll still explain it anyway. The context is you are being paid to build something that will solve a problem for a customer. Simple enough context but the problem, solution, and action have much more material to learn from, usually the context just lays out the groundwork for these. The problem was you are given an opportunity to do something fantastic, although these is already a proven solution. So, originally I chose this pattern because I learned last semester in Intro to Astronomy about Occam’s Razor, also known as the principle of parsimony or the law of parsimony, is the problem-solving principle that “entities should not be multiplied beyond necessity”, sometimes inaccurately paraphrased as “the simplest explanation is usually the best one.” (from Wikipedia). Since then I’ve been a fan of just favoring the simplest solution to something instead of an overly complex solution. However, I haven’t been putting this into practice as I’ve been overthinking too much on problems in my life that could be solved so much more simpler.

For the solution, it kind of can be summed up to the first line in the solution section, “Focus on delivering value to your customer
over advancing your own self-interests.” As a programmer, you don’t want to have a app that pushes the boundaries of CS and has a million lines over a simple app that will satisfy someone with much fewer lines. I believe I already have this kind of thinking for many things, I’m too much of a practical guy but sometimes I overthink way too much and coding is one of the things I definitely overthink in so I think this is a good solution to my bad habit.

As for action, find an opportunity to do something useful rather than beautiful. The action wants me to look back and think of when I chose artistry over utility. I can already remember of a time I overthought something way too hard, it was in software testing class and I tried making such a complex program for something that didn’t need to be overly complex. The program could’ve been just a few lines instead of the program I had thought out of in my head which was way too many lines. Anyway, I thought the action was fine, it seemed more like a common sense solution but I’d imagine they have to write these actions out for people to read because sometimes people don’t know common sense.

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

Week 2: Apprenticeship Pattern Chapter 2

For this week’s reading, I decided to read the pattern ‘The Deep End’ in Chapter 2: ‘Emptying The Cup.’ The context was taking small safe steps has led to unsatisfactory progress and has lead to not a plateau, but a rut. In a rut, it’s worse than a plateau, your competence decays into mediocrity. The problem is you need to progress your skills, your confidence and portfolio. Already, I began to relate to this pattern because I’ve fallen into the trap of being complacent with my skills and not ‘honing my craft.’ It’s a pretty bad place to get stuck in, I really would not recommend falling into this trap. For someone like me, it was really hard to get out of this spot in my life, even now I still feel like I’m plateauing, maybe even in a rut, but the first step to preventing this is to be proactive and push yourself.

The solution was practically the same thing I just said before, to push yourself, jump in the deep end. Basically, try to take the high risk high reward tasks in life that will significantly push you toward a higher knowledge is how I interpreted this pattern. Pushing yourself too hard will only set you back and you won’t have a significant enough takeaway from that high risk task you did. To which I agree with, although I can’t say that I have put
into practice this solution in my life yet. I have been too complacent for too long, it was only recently that I decided to try and push myself. The mental setbacks with myself make it very hard to push through and gain that knowledge that I seek but can’t perserve to but every day I try to tell myself that this is the day.

As for the action for this pattern, it basically says to write your projects down in a chart to path how your career is moving in complexity. At least,
that’s how I saw it. To be honest, I didn’t know what the action meant, I thought it was a second solution but after reading this it kind of makes sense to me but
I still don’t understand it. Perhaps I should put it into practice to see how my progress is going.

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

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions 

For this post, I was assigned to read Chapter 1 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye, and the introduction portions of Chapters 2-6. I thought the portions I read were an interesting read and nothing like I’ve read before. It was an interesting take on the journey of programming and below are my first impressions of every chapter.

Chapter 1:

  • Interesting subject matter, introduces the concept of apprenticeship and the background behind the word apprenticeship and what it means
  • Wonder why they decided to make the idea of improving your skill as a programmer compared to medieval apprenticeship but it makes sense. You go from apprentice to journeyman to master which is kind of like beginner to proficient to expert (even though I’d argue expert is very hard to get to).
  • Apprenticeship is supposed to be a way of honing your craft of programming/coding and to become a software craftsman.
  • Focus on yourself and your need to grow as an apprentice to a journeyman seems to be the general goal of apprenticeship.
  • The quote from Pete McBreen stuck with me, I feel like beginner developers aren’t trained well and are taken for granted, that’s why there is a scarcity of good developers.

Chapter 2: Emptying The Cup

  • Good intro that had me hooked as I reading it because I had no clue what was happening
  • At the end I finally got what the story was about basically, I have to put aside my ego and learn to accept failure, which is hard for me admittedly since I have too much pride.

Chapter 3: Walking The Long Road

  • This intro could be described as the journey to master, the company gave the image that Dave was very qualified in his field but then he met hackers that knew more than him and that motivated him to learn more.
  • It’s a good reminder that we are all constantly learning and ‘walk the same road.’

Chapter 4: Accurate Self Assessment

  • The intro has the same message as chapter 3,I agree with the message though, to not be complacent with your programming skills and to always try to learn something new and become better than you were yesterday.

Chapter 5: Perpetual Learning

  • The intro is reinforcing the same idea again of staying on that ‘long road.’ also, a lot of these patterns are ways to break bad habits which are good considering I have too many bad habits when it comes to programming and learning.

Chapter 6: Construct Your Curriculum

  • The last intro tells me to make my own curriculum which I think is hard for me personally since I’m usually reliant on someone to guide me.
  • Also, mentions that books may hold some knowledge that can’t be found on the internet but man it is hard for me to sit down and read a book but I’m sure one of the patterns is to break that habit of not being able to sit down and read a book.

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