Category Archives: Week-14

Apprenticeship Patterns: Confront your Ignorance

The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

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.

Software Apprenticeship Post #4

Today I will be focusing on the Apprenticeship Pattern “Use the Source”. This pattern talks about reading other people’s code to learn by their example of how to do things, so that you have a solid foundation of where to go when you actually start writing the code. As if your code disagrees with your intentions, it will never work.

The pattern also talks about how the “Practice, Practice, Practice” pattern will only reinforce bad habits if you do not know any good ones to practice by. This is important as habits can be hard to break, so it is best to start with good habits rather than bad ones that you may need to break later on.

A good idea is to start by reading code for applications and tools that you use every day and learn by their example. This helps you learn how the other programmers code, and helps you understand the thought processes that create the infrastructure of the programs and tools that you use. Another good idea is to download open source projects, downloading them from the current version of the source code, using source control, to learn the history of how it has changed and so you can learn how future changes are affecting it.

You can then also try to refactor the codebases to try to understand why the programmers made the choices that they did, and also any consequences there might have been if you were the one writing the program instead. This helps you further understand the projects, and it also helps you to build the projects as well.

However, during your exploring you will eventually come across some decisions you may disagree with. It is important to ask yourself if the developers knew something you did not, or vice versa. It is good to realize that maybe there were things outside of the developers control that required them to make those kinds of decisions.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.

Kindred Spirits

During the job interview that I have had. There is one question that I ask most recruiters which I believe is essential for job seekers who are looking for their first job. Deciding whether to work at that company, the question about the culture of a company is important. I think that if a company with a toxic culture and working environment, it would discourage the employees. There is this saying by Paul Graham “Nothing is more powerful than a community of talented people working on related problems”. In this “Kindred Spirits”, the author thinks that organizations’ cultures that encourage software craftsmanship are rare which I also think is true. Every day, tech workers complain about the working culture in big tech, that it’s not how they think it was when they first applied for the jobs, and that their jobs demand more time than just 9 to 5. So, I think that having a good culture is not only good for employees but also makes sure having better productivity.
The solution for those people who work in toxic culture is to be in frequent contact with people who are walking a similar road. Therefore, we should be able to seek out people like ourselves who are also looking to excel. The long road is not a road that anyone walks alone and especially in our early career, we should have a mentor. On the other hand, the culture encourages a safe environment for exploration and learning, a culture that does not limit its employees in what they should learn and that they can feel free to show each other what they’re learning to tend to attract more talents. Having no obligation to follow others’ lead would interest workers to explore and not be afraid of risk-taking. However, despite the benefits of a community of like-minded folk, we should be aware of groupthink. Avoid the questions that shock our community. Try to be respectful and use intellectual thinking to keep the community healthy. The culture and the community around us can be measured in the way it reacts to new ideas. Whether it embrace the idea after the intensive debate and experimentation? Or the ideas are quickly rejected? The most value we can provide service is defending it against those who believe that marching in lockstep is the price of membership.
To be able to do so we need to join the community where the people we work with, the blog we read, and the ideas we are intrigued by are respected. We can create our community but don’t be too strict on the ideas and topics too early. Advertise anywhere that software developers in our area might see it. Over time, these would pay off, as the group becomes larger and energetic enough, it will sustain itself even when we are not there. That’s when we have a community, good culture, and a non-toxic environment.

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

“Practice, Practice, Practice”

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

Practice, Practice, Practice…


The pattern is about emphasizing the importance of practicing our skills, coding in this scenario, to become the master in that particular skill set. The pattern states that we need to keep practicing every time we try to master a new skill. The pattern also recognizes that our work life balance does not provide a safe or stable enough environment for us to keep practicing. The solution provided by the pattern is that we organize our days. To join people, face to face or online, and to practice coding or other skills as part of a community. The pattern also points out that we need to make time and create safe & stress-free environment, because if we are not in a relaxed state then we will not be able to learn from our practice.

Why this pattern?

From the first year to last year, I have been using and writing codes in Java language. Entire semesters have been dedicated to learn and practice Java concepts. However, in a span of few months, I had to learn languages like python, R, JavaScript; frameworks like Junit, mocha, and many other things like VS code, Node.js, docker, R studio, Jupiter notebooks, etc. Therefore, I may not have mastered Java completely, but I am definitely far more confident and competent in Java than any of the things I have learned in the last year. Its like Bruce Lee said,” Practice makes perfect. After a long time of practicing our work will become natural, skillful, swift, and steady.”

Where I disagree:

To put the practice of practicing over and over is far easier said than done. Over the last few months, I have been swamped. Unless I start polishing my skills when I am eating and using the restroom, I do not see a way I can manage a time schedule where I can successfully complete my workload and carve time out for practicing.

The problem with community practicing or group learning is that every has their own schedules. It is next to impossible to co-ordinate meet times and even if that some how works out, different people want to work on different set of skills.

The point where I disagree the most is that while working in this safe and personal environment, we have almost no help or oversight. If we are stuck on some problem, it will be difficult to find help; or worse we keep practicing the wrong way without anyone there to correct us and now we have wasted all this precious time.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Sustainable Motivations

The ‘sustainable motivations’ apprenticeship pattern discusses the realities of beginning a career in software engineering. In the process of developing your skills, you may be stuck working on projects with obscure specifications and fickle clients. This work can be, as Hoover and Oshineye describe, “rigorous, sometimes tedious, sometimes exhausting, often frustrating, and frequently overly chaotic or constraining,” and it may start to wane on your motivations. The trick is to not become wrapped up in your motivations; you should recognize that some days will be harder than others. You should not be driven by a single desire; if you are motivated only by money or a desire to build your reputation, you might burn out and lose that motivation. Your motivation should also come from wanting to master your craft

I thought that this apprenticeship pattern was really interesting. I think it highlights how easy it can be to become disheartened with your work, especially if you are not properly motivated. It can be devastating to invest time and money into a career you wind up losing interest in, and it is helpful to see advice on avoiding this.

I like the suggestion to have multiple motivations for working; obviously, if more factors are motivating you, you are less likely to lose interest in your work. The suggestion to, in addition to your other motivations, be motivated by mastery to avoid stagnating your skillset seems very useful. I also like the advice in this apprenticeship pattern to maintain a good balance between your work and your life. I think a healthy work-life balance is so important; your work should not demand so much of you that you are unable to enjoy other parts of your life.

I don’t agree with the first example discussed in the ‘solution’ section of this apprenticeship pattern. The person in this example hates the programming that their job requires, but they like the money and the reputation. The solution to this example is that they endure the job until it improves. I think this solution sounds absolutely miserable. I realize this is not as realistic a suggestion as it should be, but you should probably switch professions if you hate performing the main task your profession requires.

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.

Familiar Tools- blog 9

This week, I read a pattern called Familiar Tools. This pattern happens when you feel hesitant to let go of some familiar tools that will soon become obsolete at some point. Through this pattern, I can understand that everything has two sides, even familiar tools are not an exception. As the author said, familiar tools can help you solve problems quickly, easily beat another candidate in an interview or increase your productivity at work. However, if you stick to what you already know and ignore the changing of the world, your career will be in jeopardy. That is because over time, many new tools will emerge and some existing tools will become obsolete and lose their effectiveness. If you cannot throw away a part of your toolbox to discover something new and update your toolbox regularly, then it is like you are wielding a sword to battle in a world where everyone uses guns. There is no way for your existence in that world. Therefore, to solve this problem, besides constantly looking for new tools to update your toolbox, you need to face the challenge of giving up some familiar tools that will soon become obsolete to reclaim space for other new tools .

In my opinion, this pattern is really not difficult to implement. In other words, as an apprentice, I understand that it takes a lot of time to learn and get used to a tool, so letting go of what you are already an expert on can be described as feeling loss. However, I wonder what if I keep a tool that I will no longer need or use in the future? Or what if I use a tool I am familiar with, but it does not help me; on the contrary, all it does is make me feel like every problem is suddenly getting harder and I cannot solve any of them? For myself, those familiar tools have now become obstacles in my long career path. So, I never hesitate to replace outdated tools from my toolbox with new ones. In my opinion, throwing away my familiar tools, it may not be something I can choose, it is something that I have to do to advance my career.

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

The Long Road

The pattern I’m going to look at today goes like this: Our culture is fixated on success to the detriment of true understanding of the work behind it. Consequently, there is pressure to abandon the craft at the first opportunity in favor of chasing success. The authors argue that you should push past that pressure, with the understanding that if you keep at it there’s no one you can’t eventually surpass.

I think the initial point about how our culture values fast, seemingly effortless results is insightful. In my experience, this is a pretty significant hurdle to get over to get good at anything. It can be difficult not to compare yourself to an imagined prodigy out there.

Broadly, I think it’s good to set your own goals, rather than chase illusory culturally-defined ones. I already have my own goals in mind that aren’t exactly things everyone wants, although I have a slightly different outlook than the authors here.

I think the authors, although probably not intentionally, frame things that everyone should expect from full time employment as either incidental and unworthy of consideration, in the case of money, or even a form of failure, in the case of retirement. If it were up to me, I would be content to do any type of work, with honing my software skills as a passion project. I unfortunately need money to live though, and the easiest path towards it is to leverage my interest in technology. The authors seem to view the need to make a living as incidental and irrelevant, but I don’t really think it’s harmful to your skills to not dedicate your whole life and career to honing them.

The authors also have a kind of competitive edge to their idea of personal development, suggesting that through devotion to honing one’s craft it becomes “realistic rather than vain to think about surpassing people like Donald Knuth or Linus Torvalds.” First of all, I don’t think realism and vanity are mutually exclusive. And furthermore, I don’t think this is really a healthy attitude to have. Why should you care about your skill relative to other people? How would you even be able to tell that you’re better than someone? Speaking from personal experience, I think the need to be better than other people has the potential to be really harmful to your own development. At least, it was for me. To “surpass” someone isn’t really a concrete, actionable goal, and I think it’s illusory in the same way as chasing success in general. I think it’s better to instead focus on what you actually want in your life, and on the people in it as much as possible.

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

CS 448 Post #7

I continued through chapter 5 and wanted my next post to be about the pattern Share What You Learn before moving on to chapter 6 because it interested me most out of the other patterns. The previous patterns and chapters have mainly been about our own growth and journey, so it was interesting to read about how we can help others grow. While some patterns partially touched on this by talking about teamwork, this pattern isn’t about working with others and improving yourself and them, instead it is about you becoming one of the sources of research for others to learn from. Overtime as you grow and learn more, you will have more that you can share and pass along to others who want to learn from you. This can be done by starting a blog, making a book, or some other way that you can share your experiences and work. The blogs that I and other students have been writing is an example of that too. I like that it was also mentioned that even the people sharing with and teaching others also learn from those experiences, similar to teamwork. It was also important for the book to mention that some things should either not be shared, or should be shared by someone other than you depending on what it is, like personal information or secrets.

One experience that this reminds me of is when one of my teachers in school would ask about my work, specifically math in this case. The journal I worked in for that class would sometimes have messy work when I was going through the math problems, and I wasn’t thinking much about how the work looked. The teacher for that class mentioned to me that others may want to see my work and learn from it, whether it be other students in the class, or even other people who may come across it after I’m done, so I should try to make the work more easy to understand. At the time, I didn’t think anyone would want to look through my work or think that it would help. Part of that was doubt in what I was doing. I’ve been considering it more in recent years, especially after reading through this book, that others will want to see my work and that some people may learn from it.

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

Retreat Into Competence

The problem being discussed here, like many others in this book, is something that I think is intrinsic to any kind of professional development. It’s the sensation of being out of depth in your work, a feeling that creeps into your thoughts, slowly atrophying your confidence.

At first glance, it seems like something that shouldn’t matter. You either know what you’re doing or you don’t, right? Why should your feelings about yourself play a role? That’s how I used to feel, and I also used to be pretty abysmal at putting in the work to get anything done, whether professionally, academically or personally. As unpleasant of a reality as it is to deal with, we are not machines that can churn out code like a printing press so long as things are physically working. Something I’ve learned the hard way, which this article touches on, is that you need to be firing on all cylinders emotionally as well as physically in order to actually do your best.

The solution proposed here is to prioritize something you know specifically for the sake of rebuilding confidence, rather than simply productivity. This could actually mean sacrificing productivity in the long term, but the feeling of competence is critical. Even if you don’t think this would work on you, you’d probably be surprised.

You will not be an expert at every problem. The key to building your expertise is to connect things you can do well to things you can’t, and sort of expand your understanding from there.

For example, I struggled quite a bit with Thea’s Pantry when I was getting started with it. The whole ecosystem of tools seemed extremely unintuitive to me. The turning point for me came when I realized that everything my project was doing started with running the index.js file, similar to how in most programming projects you have a main file where the execution begins. First, I started familiarizing myself with Node.js, the runtime for the project. Then I started looking at the other tools we were using, listed in the documentation, and trying to see how each fit into the flow of the program, like how external libraries fit into a more conventional application. This took time out of my work, but that time was critical for building my understanding.

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