Category Archives: CS448

Apprenticeship Patterns Chapter 1 and Chapter 2-6 Introductions

While there were certainly many important concepts presented in the first chapter of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman and the subsequent chapter introductions, I felt that the increasing level of conceptual involvement made the earliest sections far more fruitful in regards to spurring introspection. It cannot be overstated how well the logical flow of concept presentation is and how the breakdown into sections (Context, Problem, Solution, and Action) allows the reader to take the somewhat abstract elegant concepts and ground them in personal and actionable terms.

An example of how this played out: as I read the introduction to Chapter 2 – Emptying the Cup – I found myself having just digested a well-crafted opening but somewhat hazy about how the previous material would be of substantial use to me. To my pleasant surprise the authors had anticipated this and conveniently delivered me a whole section titled, “Context”. The section read:

“You are just starting out and have only a shallow understanding of how one or two programming languages.”

Indeed, it was so! The “Problem” section then provided what occupational or educational stumbling block I may be facing, followed by a tremendous helping of sagely advice to overcome the aforementioned problem, peppered with technical examples and some relatable anecdotes from the authors themselves. It concluded with a section appropriately titled. “Action,” which provided the hard-hitting actionable steps that, deep down, every person facing a self-improvement regimen knows will create an amount of existential friction surpassed only by its constructive value. Due to all of the above I found myself absolutely loving this book and can imagine it becoming a staple source of wisdom and motivation to come.

Speaking of existential friction, my favorite quote from the assigned reading was actually not in the assigned content but rather the “Audience” section before it. The quote reads, “[E]ven people with a decade or more of experience—particularly those who may be struggling to navigate their careers—will find inspiration and perspective to counter the siren call of promotion to management,” spoke to me because at my last job I spent many a night fighting with inept management only to open my phone on my lunch break and gaze in despair at my Quora feed littered with horror stories of talented principal engineers being given the axe because they had become too expensive to employ, wondering if they should have relinquished their craft and made the jump to management instead. For full disclosure this not some Marxist indictment of the labor aristocracy; I have been both the employee and the manager in my life and may one day find myself on the managerial side of the coin because I genuinely do believe that I am a strong mediator and leader. But the introverted tinkerer within me grasps firmly at any notion that it is possible to succeed largely based on the merit of my toiling and not the bureaucracy of corporate telephone; if this book is to be believed then it seems the inner tinkerer may have a leg to stand on.

From the blog CS@Worcester – Cameron Boyle's Computer Science Blog by cboylecsblog and used with permission of the author. All other rights reserved by the author.

Finishing Up The Patterns

The final pattern I will be writing about from Apprenticeship Patterns is “Retreat into Competence”.

The “Retreat into Competence” pattern describes how to solve the problem of when you begin having issues as you start working outside of areas you are comfortable in.

I like the ambiguity of the opening quote by Robert Pirsig, I find that it is comforting while being vague at the same time. I agree with the quote about not knowing where I currently am but what I’ve done so far seems to make sense to me. I like the idea and I think I need to think more about what I’ve done so far as a computer science student to find what my “pattern” is so I can use the advice Pirsig seems to suggest and apply my own “pattern” going forward.

The topic that the pattern covers is something that makes me think about what I’ve learned as a computer science student as I am reaching the conclusion of my work for the major. In particular, it makes me think back to a conversation I had with Dr. Wurst and especially when he mentioned the fears of not knowing enough as I approach graduation.

I particularly connect to the idea that the pattern mentions of a deadline problem. The deadline problem was something that I thought would happen on Monday with my work on the UpdateGuest project and I wasn’t completely sure if our group (and I) would be able to finish our project before our review meeting. Additionally, I was having a hard time figuring out how Angular worked towards the end as I was trying to finish the issues I needed to for the project to be done. I got past the problem though with the help of my teammates and one awesome article my teammate found which helped us to get our Angular form implementation working.

I think the advice offered in the pattern is important and I agree that it is good to occasionally remind yourself of what you’ve learned and what you can already do, especially when you can’t solve a problem you are working on.

I found the “Retreat into Competence” pattern to be a fitting final pattern to write about as I finish up my work in the software development capstone course and as a computer science student. I am making it a goal to finish the rest of the patterns in the Apprenticeship Patterns book over the summer as I have found the advice to be helpful and I am curious about the remaining patterns as they are frequently mentioned in the current and previous patterns I have read.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Improving as a Developer

Today’s first pattern in Apprenticeship Patterns is “The Deep End”.

“The Deep End” pattern describes how to avoid getting stuck at the same level of being a developer and how to take risks to improve yourself.

As far as the “Context” area of the pattern goes, luckily, I don’t think I’m in a “rut” right now. Currently I’m still learning about lots of new things and tools at the same time and although I would like to make more progress, I think I’m still moving forward.

The “Problem” section makes more sense to me than the “Context” area and I agree, and I would still like to improve my knowledge and keep on learning about the tools I am currently working with. I agree with wanting to have additional projects I have worked on for when I apply for a job and I would like to have these shown on my GitLab account.

I think the part of the “Solution” for the pattern that describes “Waiting until you’re ready” is one of the most relatable parts of any of the patterns so far. I agree with that statement and I feel like I should just start learning new tools or adding work to a project instead of continuously waiting until I really feel like doing it. I feel that I should schedule regular times for learning or working on implementations to help avoid the problem of not feeling ready.

The example provided with Enrique’s email is especially impressive. I don’t think I’m quite ready to do something like Enrique did, however I do think that the email illustrates the success that following the pattern can get you and that there was a lot of value in including it.

Answering the “Action” questions I think the largest project I’ve worked on as far as team size goes is with my current work on the UpdateGuest project. As far as size goes, I think my own personal project might have the most amount of code (although the size may be tied close with UpdateGuest). I think the idea of different project “metrics” is interesting and I think some other useful ones could be total time spent working on a project and how automated the project is as far as CI/CD goes.

I think that the pattern offers valuable advice, especially with avoiding a “rut” and I would especially like to think of more and keep track of the different project “metrics” as I continue to work on old and new projects.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Final Sprint Retrospective

Yesterday was the last sprint review for the semester and the conclusion of my work on the UpdateGuest project (at least as required for my software development capstone course).

During this sprint our team worked on putting the whole UpdateGuest service together.

This sprint I helped to review many of the merge requests associated with my teammates branches and I worked on both making decisions and helping implement the Angular form for our frontend.

Specific issues I worked on this sprint are:

I think our team did a really good job this sprint. As Dr. Wurst commented yesterday, our team did really well this sprint with communicating and looking back at the different issues and merge requests from this sprint, I completely agree. Additionally, I was very impressed and excited about the work we accomplished during Sunday when the team met on Discord and worked together to rapidly implement, review, and merge different features.

I think that some things could have gone better too for our team. This includes improving when we work on our issues and working on issues ahead of deadlines, along with having everyone on the team working on reviewing merge requests.

There are a few areas I think I could improve on personally. This includes improved time management and keeping track of overall project progress. This was almost a problem for our team as we had a very last-minute meeting the day before our sprint review to finish our implementation of the frontend and make it work with the backend. I take responsibility for this and I should have setup a meeting to work on this much earlier than Sunday morning, especially as this was suggested by my teammates earlier in the week. Another area I want to improve on is consistently working on issues. This sprint there was a week where I didn’t do any of the work I needed to do for the project and that undoubtedly didn’t help, along with also waiting too long to work on issues. Finally, another issue I would like to improve on is finding a balance between reviewing others’ work and working on my own implementations. This sprint in particular I found that I spent a lot of time reviewing and learning about my teammates work. While I do think this was helpful and led to more refined code getting merged, I think it led to me spending much less time on my own implementations, which I am not as happy about.

Some of the areas I think our team could improve on if we were to continue working together largely relate to some of the issues I could personally improve on. I think both personally and as a team we could further improve on our ability to refine issues and improve on how we estimate the weights for issues. This problem specifically occurred with the implementation of the Angular form where I think it took a lot more time and had more issues than we originally anticipated. Additionally, I think our team could improve on keeping track of overall project progress for meeting deadlines and maybe work towards setting estimated deadlines in all issues with times and dates for issues to be completed. Again, this would help to avoid a last-minute meeting where a lot of work needs to be done in a single day to finish features (or the project). Finally, I think that everyone in our team could work on reviewing more merge requests so that this work is more evenly split and gives others (including me) time to work on their own features.

Overall, I am very happy with the progress our team made during this final sprint and I am especially impressed with how everyone worked together Sunday to finish all of the features we needed for this project to be in a good and working state.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

How to Learn about New Tools

The second Apprenticeship Patterns pattern I looked at today is “Confront Your Ignorance”.

This pattern explains how to improve your knowledge in areas you aren’t as experienced in. The pattern also provides possible drawbacks of focusing too much on self-improvement.

The “Context” and the “Problem” sections of this pattern are relatable to me currently. I can clearly see that I have a problem with my knowledge of Angular and I need to learn more about this in order to develop frontend applications. I do somewhat disagree with the part of the problem area that says I “do not know how to begin”. I think at this point I have a decent idea of how to learn about new tools. Although maybe it is correct as I have still yet to feel like I have a good understanding of Angular after trying to learn more about it.

I do like and use both of the suggested methods for learning about new tools. Usually I like to read documentation and introduction guides on a tool’s website, but I also like to follow along with example projects. Additionally, I have found that watching a video tutorial series (mainly on YouTube) on a particular topic can help a lot with learning about something new. This is how I learned about a lot of the backend tools my team used this semester and I am especially a fan of the YouTube channel one of my teammates found. This suggestion is something that I feel should be included in this pattern as I have found this method to be one of the most valuable ways of learning about new tools, especially if there isn’t much documentation for it.

If I had to pick only one thing to learn more about it would be Angular. This is something I have consistently been trying to learn about for a while, ever since I first learned about it, and it has been something I’ve tried to improve on this semester but I am still not satisfied with my knowledge with this tool.

I did find the provided downsides to be the more intriguing part of this pattern as these are points I wouldn’t have thought to be in a pattern about how to learn new skills, but they do make sense after reading about them.

I do think that this pattern provides some good general information about learning about new topics, but for me I wish it was a bit more specific as I find that I was familiar with most of the information provided in this pattern about learning about new tools.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Value of Asking Questions

This morning’s pattern in Apprenticeship Patterns is “Expose Your Ignorance”.

This pattern helps explain to early developers how to get over their initial lack of knowledge in the field by asking questions and seeking out knowledge and the importance of doing this instead of pretending to know everything.

To me this pattern and especially the “Problem” area feels very relatable right now with where I am this semester, especially with another attempt at learning how Angular works.

I do find that this pattern provides me with some valuable reassurance, and it is more comforting to know that this problem happens to other people.

Lately with my work this semester I have apparently been following the advice this pattern gives and trying to ask others in my group for help when I don’t understand something that I have been trying to do. This is important in our group, especially as different team members in our group have their own areas of knowledge from what they’ve learned this semester. Reflecting back on this more I wish that I asked more questions (especially during meetings) and focused more about how something works instead of just the solution as this would have had a far greater benefit in increasing my knowledge.

I agree with the idea that answering questions helps to understand the problem better. I can think of many times this semester where I either asked questions that helped find errors in something or when answering someone else’s question made me think more about it.

I do like the idea that the “Action” section presents, although it does feel somewhat exposing to visibly have on display things I don’t know. I am trying to think of a good digital place to put something like this, perhaps on my GitLab account. As I’ve probably alluded to in my posts so far, I think my top items (although this isn’t five items as the pattern suggest, these are things that are particularly holding me back) with my current work would currently be: Angular (and specifically forms), HTML, and Jasmine (this is especially a rather new one for me). I would like to refine this list some more and pick more specific topics to work on learning in each one of these broader items.

This pattern provides helpful knowledge and helps explain the importance of learning from others. Again, as I said before in my previous post, I wish I read this pattern earlier as the ideas presented in this pattern would have improved my learning this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Helpful Advice for Seeking Employment

Today’s chapter in Apprenticeship Patterns is “Concrete Skills”.

This pattern provides an overview to the idea of more specific skills developers should have as they start their careers.

I think that this pattern serves as a good introduction to this topic. This pattern seems especially relevant to where I am now as I will soon be looking for employment after graduation and this is a good general reminder of things that software development managers are looking for.

I like and agree with the idea of creating a project for demonstrating your knowledge of the skills that you have acquired. This is what my team has been doing for our work so far this semester on the UpdateGuest project and I, along with my teammates, think this helps to cement the knowledge gained when learning new tools and languages. This pattern serves as another good reminder that this is also something I want to do more of with my personal project and I particularly want to start moving away from using languages I already know to learning and improving my abilities in these “concrete skills” with new and different tools that I am more unfamiliar with. I specifically want to get better at some of the examples mentioned in this pattern including web design and JavaScript, along with Angular as these three things seem like important requirements for developers now.

Although I think this pattern provides helpful information, I do wish that this pattern was more specific and detailed. I believe this pattern could benefit from expanding upon the information it offers. I also think that it would benefit from including an example CV showing how these skills are listed and defined on a real document. After reading this “action” section, I am now curious as to what the most important skills are for a starting position in the DevOps field and if I already know any of these skills. Again, I think this section could benefit from suggestions as to where to go to look for these besides people you may know.

Altogether I did find this pattern helpful and a useful reminder of what the most important parts of a resume are for a software developer. This is true especially as I move on to creating and refining my own resume in preparation for getting my first job in the software development field.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

The Benefits of Being a Beginner

This evening I continue my reading of Apprenticeship Patterns with the third pattern titled “Unleash Your Enthusiasm”.

This relatively short pattern describes the benefits and possible disadvantages, along with how to handle the “enthusiasm” of being a new developer.

I both agree and disagree with both of the areas of this pattern that describe the “context” and the “problem”. In my current situation and from my memory of the time I have spent in the software development courses so far, I have found that the professors I have worked with and learned from can have more “enthusiasm” than I do. I think that this is one of my favorite parts about taking this track of computer science was getting to learn from people who enjoy the work and learning as much or more than I do. I think this was specifically the case last summer with my work on the LFP community which really helped to motivate me to contribute to it and kept me going. At the same time, I also agree with the idea this pattern presents that a rather unenthusiastic group can bring down the mood of someone excited about being new to the field.

I do understand the rather unfortunate idea of only being excited about projects outside of regular work. I personally find this to be true and that although I usually enjoy working on my project, it is not just because of the topic or the self-interest, but also because of the freedom allowed in the workflow when you work on your own project. I think this point about a group’s attitude while working is something I want to keep in mind when I begin looking for a job as a software developer, as I would prefer to have a job where everyone enjoys the work they do and encourages this passion in each other.

Overall the quality this pattern describes seems like one of the best perks of being new to this field. I do worry that for me this quality will diminish over time and I hope that I haven’t lost it already before I’ve even started. I think that this pattern does a good job of pointing out this quality of a beginner’s enthusiasm and that it is something I want to work towards keeping now that I am more aware of it.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Learning how to Learn

Tonight I am continuing with my reading of the Apprenticeship Patterns with toady’s pattern being “The White Belt”.

This pattern helps to explain how to get over the obstacle of learning and implementing new information after mastering “your first language”.

This pattern feels applicable to me as I feel this is the stage I have reached with the first language I learned. I particularly connect with the problem area that describes a difficulty with learning new tools as this is something I feel I am beginning to run into (especially with Angular) while learning new tools for my work on the UpdateGuest project.

I do think that I try to take the approach mentioned in this pattern of forgetting what I know when learning new tools, but I think that now I am more consciously aware of the value of this I think it may further help with how I learn.

I also agree with the point this pattern makes about being afraid of looking bad when trying something new. I recognize that this has held me back in some of my work this semester as I did not want to commit code that I was unsure of. With the help of this pattern, I realize that I need to get over this fear and not let it hold me back.

One of my favorite parts of this pattern is the example code. I appreciate how the beginning of this is in Java, as this makes it easy for me to understand and it makes the comparison more meaningful. The real beauty of the example is how the multi-line Java snippet is condensed into one small line in the J implementation. This vastly condensed (and somewhat strange to me) implementation really helps me to appreciate and understand the point this pattern makes of needing different approaches when using new tools that are unfamiliar from what you already know. This example makes me want to take up this challenge of learning something that is new and completely the opposite from what I already know.

For me, I read this pattern at a great time, and I even wish I had read it earlier this semester as it could have helped me with my work developing for LibreFoodPantry. I am going to make a point of keeping this pattern (and the cleverly quoted advice from Yoda in The Empire Strikes Back) in mind as I continue to learn about new tools this semester.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.

Beginning the Patterns

This evening I began my reading of the patterns in Apprenticeship Patterns, starting with the first pattern “Your First Language”.

This pattern provides guidance in selecting the first programming language you will learn as more of a beginner and the importance of this first language. The pattern also explains how to move on from this first language to learning others.

I liked this pattern as it let me reflect about my overall usage of Java, the first language I truly learned as a computer science major. Reading this pattern has made me question my usage of this language and particularly if I over-rely on it. I am also wondering if this is the best language to continue using or if I should switch to another language as my primary programming language.

I agree with the advice given of picking a real project for helping to learn a language. This is what I would like to do more of with my side project, and I would like to use this project more for learning new tools and languages.

I liked the idea of using tests as a way to verify your comprehension of a language, instead of just testing the code. I particularly like how this idea is a different approach to thinking about testing and its usage and how to use testing when starting out with a new language. This point is definitely something I want to keep in mind when I learn new languages.

Additionally, I liked the idea of picking languages according to the knowledge the people you know have. With my experience, I agree with this sentiment and I think there is a lot of value in having someone you can go to that can help you get back on track with coding problems. At the same time though I do somewhat disagree with this idea and I think that someone should decide on which language to learn based more on the availability and quality of the resources available for learning a tool or language. The reason for this is that I would prefer to have a reliance on resources rather than having to rely on someone else.

I further agree with the notion of getting “stuck” in the first language you learn. This is something that I am afraid of doing, especially with the longer I use Java as my primary language.

This pattern has helped me to reflect on my current knowledge and usage of programming languages. It has increased my wanting to learn a new language and I will keep it in mind as I switch to learning and using new languages.

From the blog CS@Worcester – Chris' Computer Science Blog by cradkowski and used with permission of the author. All other rights reserved by the author.