Category Archives: Week 13

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.

Apprenticeship pattern: Find mentors

This week I read the pattern “Find mentors”. In life, we all need a mentor who will train, and teach us what will become our knowledge tomorrow. Some examples: in schools, universities, at home, our mentors are our teachers, professors, and parents because they teach us and train us to become great people in the future and whatever we know today, it’s thanks to them and their sacrifice. But we have to keep in mind that tomorrow, we will also be someone’s mentor or leader.

In this pattern, the author is talking about seeking out those who have gone ahead of us and striving to learn from them. Everyone at some point has been an apprentice. Teachers, before becoming who they are, were students like us too and had mentors (teachers, professors) who made them who they are. Parents, yesterday were children too and had their parents who were their mentors/leaders and examples for them to follow. It’s a rule of life, which is we can only give what we receive.

To become great software developers, we need to surround ourselves with software developers who already have the knowledge and are willing to teach us and help us understand. Seeking help and knowledge from someone isn’t a sign of weakness, on contrary. That is something that a lot of software developers, even people in general don’t understand.

What I get from this pattern, is that in the computer science field, if we want to be the best or become better at what we’re aspiring for, we need to surround ourselves with people who have more skills than us in the domain that we want to master. Also, we need to keep in mind that we’re walking “The Long Road” and that no one knows everything. Even our mentors learn something new every day. The fact that they know more than us does not mean they know everything.

Our apprenticeship is unlikely to happen in isolation, and just as there will be people ahead of us, there will also be apprentices who have not yet reached our skill level. The other side of our search for mentors is that we must be willing to provide mentoring to those who seek it from us. Passing along what we have learned from our mentors is one way in which we can begin the transition to journeyman status.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

“Be The Worst”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

“Kindred Spirits”

From the blog cs@worcester – Dahwal Dev by Dahwal Charles and used with permission of the author. All other rights reserved by the author.

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.

Apprenticeship Patterns: Reading List

The ‘reading list’ apprenticeship pattern supposes a solution to a situation where you are finding books you want to read faster than you can get through them. There are lots of really good resources available for programming, and reading them is a great way to help you improve your programming skills. However, with such an abundance of resources, it becomes difficult to manage everything you want to read. The solution is, as is suggested by the name of the apprenticeship pattern, to maintain a reading list. This list should store both books you want to read and books you have already read. Hoover and Oshineye recommend storing your reading list somewhere public so that other people can see and learn from your list. Keeping a list like this for several years will allow you to analyze your reading habits and pick out spots where there might be gaps in your knowledge. As you work through your list, you can use the bibliographies of the books you read to add new books to your reading list. This can also help you narrow your research down into an area you take interest in.

I think this apprenticeship pattern is interesting, and I think it’s a great way to keep track of what you want to read. I think the advice to read books included in the bibliographies of books you thought were useful is really useful. I also really like the idea of being able to monitor your progress as you work through your reading list. I already kind of do this, just not exclusively with programming resources. I use a website to keep track of the books I want to read and the books I’ve already read. I like being able to see all of the books I have or want to read, because I know if I didn’t store that information somewhere I would forget all about it. It’s also really interesting to be able to analyze my own reading statistics like what genres I tend to read and what days I read more. I use it mostly for pleasure reading, but I think it would be useful to dedicate a section of my existing list to programming resources.

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

Apprenticeship Patterns: Chapter 3 Part 3

A Different Road

You find yourself tired and bored of your work. You have some personal projects to advance your skills that keeps you busy, but you find yourself needing to take a break. To diverge from the road you are on to either just rest for a while or to just see where it goes. Your career as a software developer is not what ultimately defines you. A Different Road describes a scenario where the road you have been traveling on in your programming career is not the road you want to travel along anymore. You might wish to spend more time at home and with your family. You might desire to train for a marathon. You could buy a bit of land, build a barn and become a farmer.

The road of your software development career never truly ends until you decide to end it and even if you do, you can always start back on it again. Just like riding a bicycle you never really forget something that you practiced frequently. So, take the break that you need. Buy that farm and become a farmer. Your career is not what really defines you, and maybe whatever you try will need some kind of optimization that your skill-set can solve.

Ultimately this pattern speaks to the idea of breaking the stubborn mindset most people find themselves in. It’s this mindset of having a path and having no other choice. The path paid your bills and you enjoy it to a degree. It’s hard to accept the idea that this thing you have been spending your time on isn’t right for you. To align with the road analogy, the road you have been traveling has been well paved and barely has any traffic. As you travel further and further you might find it gets even easier and has even more lanes and less traffic. You might also find that this road has potholes and traffic has only gotten worse and worse.

Recognizing when that road isn’t worth traveling on is easy to think about, but harder to act on even when it’s right in front of you. But unlike the road analogy, your skills and motivation are not a car. You can’t sell it and lose it, it can’t be stolen from you, and even if you don’t use it for a while it doesn’t mean it can’t start back up again. The thing to take to heart is do what you want to do, but also stop doing the thing you don’t want to do just because it’s your career.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

CS 448 Post #6

I finished the patterns I wanted to write about from chapter 4 and moved on to chapter 5, Perpetual Learning. Like the last few chapters, I to post about the first pattern of the chapter and then one of the last ones, so this post will be about Expand your Bandwidth. The focus of the chapter is on the topic of the lifelong journey of learning that is taken when you are an apprentice transitioning into a journeyman, which is a concept that was brought up in the first chapter.

The first pattern is an effective start to the chapter, as it is about how you can move on from lower level problems to higher level ones, and how you can expand your learning ability. The solution given to the problem is to find different ways to learn more than you may not have been using before, such as blogs, books, and other online resources. Because of how much technology there is in the world today, there are plenty of ways to find information online, and use different avenues of learning. I have found a lot of information online by either looking things up when I had questions or issues, or just by reading blogs and articles. I have looked online plenty of times when I needed help on something, especially computer science projects. I would search based on the error codes I was getting and try different sites to see if I could find a solution that worked for me. Using online resources have been very helpful to me for my work related to computer science, along with some other courses and activities.

I agree with the last paragraph of the solution that talks about deciding when you should start expanding, because while it is good to have all this information to learn from, you still want time to put that learning to use at software craftsmanship. You want to make time to continue working and improving yourself so that everything you are reading about and learning is beneficial to your work. I like that this problem brought more attention to the topic of this being a lifelong journey with continuous learning and development, while pointing out potential problems with obsessing over learning.

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

The Long Road

For this week’s additional blog post, I have decided to look at the apprenticeship pattern “The Long Road”. In this chapter you, are aspiring to become a master software developer. However, your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. In this chapter it is advised that you should focus on the long-term. Value learning and long-term growth opportunities over salary and traditional notions of leadership. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft. No business or technical domain is closed to you. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers”. (Dave H. Hoover & Adewale Oshineye).

This chapter was an interesting one to read. I liked how it talked about how this is a unique profession, and you will be doing it for some time if the passion is there. I also liked how it talked about how you shouldn’t jump ship right away if there is an opportunity away from software development. I don’t think that this chapter will stick with me out in the real world, however. I feel as though this chapter is geared towards people with a mind set of already leaving this profession.

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

Find Mentor

There is always a good teacher behind a good student and a good engineer needs a good mentor who will help sharpen the skills and knowledge of that person. There is a saying “if you want to go fast, go alone. If you want to go far, go together”. Together with the mentorship, the engineer will become skilled at his job and has solid fundamental knowledge in this field.

By learning from the best, we learn how to become one of them. The apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery. Every master used to be a student and no one is perfect. So keeping in mind that a master must be perfect is a misconception. It can be tempting to feel that way because they know so much more than we do. We must resist the temptation because we would not want to disillusion our mentor’s inevitable weaknesses.

The story about Dave finding his mentor shows us his journey. By sending out a random email to his mentor, Wyatt, he initially did not expect Wyatt’s response however Wyatt did. The effort was a payoff and he earned himself a mentor. What we could learn from this story is that we should not afraid to ask for help because sometimes what the other is waiting for is us asking.

Good mentors are not easy to find and not everyone is willing to open their arms and welcome us as amateurs. Plus, reaching out to someone that we do not know feels intimidating. However, the risk of being rejected is low but the payoff would be huge. Even though that person does not want to become our master but if we are consistent enough, what we could get back is a good friend. Besides taking in, passing along what we have learned from our mentors is one of the ways in which we can begin the transition to journeyman status.

How could we do that? One must wonder

Choose a tool, library, or community that has an active mailing list. Start small by signing up for the list but do not post any messages yet. Gradually, we will understand the values of the community and learn which of the subscribers are patient teachers. Seek out the members of this list the next time we see them and ask if they would be interested in providing us with some advice about the lesson they have learned. As I said above, we might get rejected but the valuable gift that one might earn is a good friend.

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