Category Archives: CS-448

Find Mentors


Find Mentors pattern is about asking for help while exploring the unknown. Every time we decide to take a new path – learn a new language, we do not know what is in store for us and therefore have no clue as to how deal with problems that we might face. The pattern recognizes that as new apprentice we will need help facing these problems and in reaching our goal.

The solution pattern provides is to learn under a master craftsman in the field of your choosing – a mentor. The pattern also realizes that as a novice it is difficult to identify a true master craftsman and therefore during the process of acquiring the new skill we will be guided by a number of mentors with diverse levels of mastery. The pattern states that it might be easy to find authors, bloggers, professional speakers, and developers in computer science field. However, there are two problems; first, they might not be interested in mentoring; Second, asking someone to be your mentor can be very intimidating. The important point pattern makes here is to have determination and remember that the risk of rejection is very low compared to huge opportunities having a mentor can provide.

The pattern also warns us about blindly following someone. We need to keep our eyes open to the mentor’s weakness and resist the temptation to believe everything they say. No one knows everything about everything. Therefore, we need to keep finding other master craftsman and keep polishing our skills.

Why I choose this?

Computer science is a very difficult field to begin with and then on top of it – it is an ever-evolving field. The amount of knowledge available is immeasurable. The pattern ‘Reading List’ helps us organize the books we need to read, which as we all know does not give practical explanation, real world connections or real time feedback. Moreover, to start our reading list and even to make sure that we are reading the correct books – we need to find someone we can trust – someone like a mentor.

Over the last four years I have been able to find a number of mentors. They have ranged from professors to my peers, family and friends to people in slack and discord communities. It has been an amazing experience. I have learned from them and with them.

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

Learn How You Fail


Those who don’t learn from their past mistakes, are doomed to repeat it. ‘Learn how you fail’ pattern states that failure is an inevitable part of any learning process. And if we have not experienced failure than we are either not pushing ourselves to our limit or we are making a grave mistake of ignoring our faults. The pattern provides a very clear and concise solution, self- assessment. We need to identify and be self-aware of patterns, conditions, habits, and various behaviors that resulted in failure. The pattern also points that once we are conscious of our faults, we are given an opportunity to fix them. It’s like the saying,’ the first step to any solution is recognizing that there is a problem.’ The pattern also lets us know that accurate self-assessment can help us define our limitations. Pattern lets us know that its okay to not excel at everything and accepting these limitations forces us to rid ourselves of all the distractions and reprioritize our goals.

Why I chose this pattern?

To quote Thomas Edison one more time, “I have not failed, I’ve just found 10,000 ways that won’t work.” This is a very powerful quote because if we don’t remember which road is incorrect, we might very well end up drowning.

‘Learn how you fail’ fits in perfectly after ‘breakable toys’, ‘Practice, Practice, Practice…’ and ‘Record what you learn’. “Armed with that self-knowledge…you allow yourself the choice between working to fix these problems or cutting your losses.” This is a very powerful sentence from the pattern. I have always been very self-aware of my limitations and therefore had my courses for the four years of my college well planned. Unfortunately, due to a fractured foot and a death in the family, I was operating at a bare minimum of my normal capacity. After a long and hard self-evaluating process, I concluded that I will not be able to finish both my capstone courses and even if I do, I will only be doing my bare minimum to pass the course and not for the learning experience. At this point, I decided to cut my losses- drop one of the capstone and do my best in the other one.

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

Nurture Your Passion

I decided to write on the importance of “Nurturing your passion” because as a senior who finished college and is going for the professional career, I think this pattern is a piece of advice. Being a great software developer isn’t something that happens over time. In contrary, it is time consuming, energy consuming and requires determination and sacrifice.

To become software developer, we will need to have a passion for software craftsmanship. Unfortunately, our daily activities often work to diminish this passion. We might be faced with demoralizing corporate hierarchies, project death marches, abusive managers, or cynical colleagues. It’s hard for our passion to grow when exposed to such hostile conditions, but there are some basic actions we can take to sustain it. Work on what we like. Find something at work that interests us, identify it as something we enjoy, and pour ourselves into it.

I have always said that loving what we do is what keeps us going forward and wanting to master I that specific domain of our professional life. When we don’t love what we do, we don’t even other putting the effort to master it or accomplish something great because our mind isn’t even there. Immersing ourselves I some of the great literature of our field can carry us through the rough spots when our passion is in jeopardy.

I think the best advice here is that if, as software developers, we find ourselves in a company that stifles or suffocates our passion, we need to have the guts to move on and go to for something that we love. This piece of advice is very relevant and important. I think finding a job that a software developer can at least partially nurture his passion is very important. We spend so much of our lives at work. So, it is very important to find happiness there, if possible. And when we don’t find it, have the courage and the positivity to keep looking until we find it because when we don’t love what we do, it affects our wat of working and also our mental health.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Stay in The Trenches

This week I have decided to write about Stay in the trenches. This refers to deciding to program even when the craftsmen receives a an offer that would pull him away from programming. Dave mentions that the minute the craftsmen stops programming, his skills will fade.

This has certainly been the case for me. In school there were semesters that brought me away from coding. There are many classes that are non programming and when I take so many of those non coding types of courses plus working part time, it was at times hard to find the time to code. So I could only imagine what would happen if I had a job where I couldn’t code every day. Especially with family obligations. I know that my uncle and folks that I have talked to in interviews mention that they don’t code anymore and that they miss it. So I completely agree that skills atrophy when the craftsmen does not use them.

Dave recommends finding alternatives to the managerial promotion. The craftsmen needs to figure this alternative out on his own and write down these rewards. This is something that I will figure out on my own as I have more work experience. I know that these days there are lots of oppurtunities for senior software engineers so I think that if I want to stay in a coding role I am confident that I this type of oppurtunity will exist.

This specific decision is a ways a way for me. But there are similar cross roads in the earler stages of my career. There are positions for new grads that involve different levels of coding. There are Quality Assurance roles that are part of the Software Development Life Cycle but it is not a role that is strictly coding. So it just goes to show that the apprentice will need to choose programming again and again. There are many roles in software that do not involve coding, and it is important to choose programming again and again. This is an important lesson that I will take into my career as I graduate and move into my career in software development.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

It happens to everyone to feel overwhelmed, confused, and realizing how little we actually know or that we’re working on a project that is actually not going well. Retreating into our competence and regain it is he solution to this problem. Sometimes, stepping on the side is a good thing because when we pull back, then it’s easier for us to launch ourselves.

In the pattern, the author Dave H. Hoover says: “An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.”. Wen reading this, we can understand that this is a normal and inevitable phenomenon along The Long Road. Overcoming the fear of your own incompetence is the bridge between Expose Your Ignorance and Confront Your Ignorance.

This pattern is most relevant for people who have stretched themselves far beyond their ability. If your apprenticeship has you taking reasonable-sized steps forward, taking on gradually increasing responsibilities and technical complexity, then you may not need to take shelter in this pattern. But if you are really struggling or are barely keeping your head above water in The Deep End, look for opportunities to temporarily retreat. Sometimes you need to take one step back in order to take two steps forward. From this pattern, I just understand that pressuring ourselves and feeling overwhelmed, or a project not working and feeling frustrated, stepping off and pulling back will help us go even far. I love the way the author explained and said that when we pull back, then launch forward, it is like a some from a catapult. I am pretty sure we have all seen catapult and the further back we pull, the further the stone will go forward. Same with software, when we feel like we can’t do it anymore, let’s pull back and retreat into our competence. That will be the way we will regain it.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

The Deep End

This is one of my favorite patterns which is “The Deep End” because it talks about the importance of leaving our comfort zone and jump into the dep end. I love how this pattern explains the importance of being open minded and ready to confront anything because nothing guarantees that we will always be in a domain that matches our skill level.

Waiting until you’re ready can become a recipe for never doing a thing. Growth only happens by taking on the scary jobs and doing things that stretch you. There are opportunities that we will or may end up having, but they might be out of our comfort zone. Risks are opportunities seen through the half-shut eyes of fear. Meaning that taking that promotion or foreign assignment when it’s offered, even if the very real possibility of failure is staring you in the face. Being prepared to fail and recovering from that failure opens doors that the timid will never see.

Even though we advocate seeking out the most challenging tasks we are capable of, we still need to remember that if the water level is above our head, it means we’re drowning. Even in Enrique’s example, where he was changing his life in a big way, he was still moving to a country where he knew at least one person and could speak the national language. It is our responsibility to offset the risks of this approach by Finding Mentors and Kindred Spirits who can provide help when we need it.

It’s also your responsibility to Create Feedback Loops, so that if the challenging project starts to spin out of control you can catch it and get help immediately. Applying this pattern should feel brave rather than reckless. Willing to go and confront the difficulties and being ready to swim until we finally find the way out.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Confront your ignorance

I was reading the pattern on “Confront Your Ignorance” and it talks about what to do when you realize that there is/are gap(s) in your skillsets that you need to work on and need for a daily work. Some people are scared to confront their ignorance because they hate thinking of themselves as ignorant and hide that side of theirs.

While reading this pattern of chapter two, confronting our ignorance is the best way to become better in what we do because we will actually improve our skills and master in what we will do. There are many ways to actually confront our ignorance: For some people, the best approach involves trying to get an overview by reading all the introductory articles and FAQs they can get hold of. Other people find that jumping straight to the construction of Breakable Toys is the most effective way to understand something. Sometimes others will be trying to acquire this skill as well, and by working together you can make better progress. At some point, with this ways, we have gained a satisfactory level of ability in this new area, and then we can decide whether it is more productive to dig deeper or turn our attention to the other gaps in our skillset.

This pattern is closely tied to Expose Your Ignorance, but implementing it is less of a challenge to your pride because it can be done in private, without anyone else ever finding out the things you did not know. We need to know that learning in public is one of the ways in which an apprentice begins the transition to journeyman. It’s a small step from learning where people can see you to teaching.

What I love about this pattern is that many times I love to challenge myself and go do thigs where I feel I need to confront my ignorance and learn. It’s a factor that everybody should have, especially software developers. This field requires a lot of practice and we need to keep in mind that it’s not everybody who knows everything in this field. We may have some skills but we also all have to confront our ignorance at some point.

From the blog CS@Worcester – Software Intellect by rkitenge91 and used with permission of the author. All other rights reserved by the author.

Apprenticeship pattern: Practice, Practice, Practice

This week I decided to write on chapter five about practice. This pattern really reflects the reality of life. Everything, if we want to master or succeed, we need to practice in order to get better every day. To improve, if you routinely practice something, the likelihood of you doing better on something is higher.

This pattern is telling us the importance of practicing and that the performance of our daily programming activities does not give our room to learn by making mistakes. But taking time to practice our craft without interruptions, in an environment where you can feel comfortable making mistakes. As software developers, we need to practice in order to grow our knowledge and skills. I love how the author says: “The key to this pattern is to carve out some time to develop software in a stress-free and playful environment: no release dates, no production issues, no interruptions.

The importance of practicing is that every day, there is a new thing that we learn, do something a little bit different each time an exercise is performed. As software learners, practice is our best friends, so are curiosity and determination. We can go far and become those great craftsmen if we put up the work and are willing to make sacrifices. Then, we will master and become thos great software development.

One thing that I will always remember is that we should never forget about The Long Road. That we should be patient and accept difficulties, so we can challenge ourselves and master in what we are doing.

In reality, regular exercise for software developers can help improve our brain, memory, problem-solving skills, and overall mental agility. Things that are rarely talked about but necessary in our daily lives, especially when dealing with complex problems such as developing new components, solving bugs, or even having architectural or difficult meetings.

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.

Retreat into Competence

Retreat into Competence is an apprenticeship pattern that focuses on the idea that when you find yourself in a situation where you are overwhelmed with new information, it is alright to withdraw back into something you are more comfortable with. By doing this you allow yourself to gain back your mental composure, and gives you the opportunity to reflect on how far you’ve come as a developer.

I believe this apprenticeship pattern is incredibly true and helpful, as I have frequently found myself in situations where I do not feel confident in my abilities and as a result I get overwhelmed and stop being productive. When I first started my internship last summer, I was expected to use Python as the primary language. Up until that point I only had limited experience with Python, so I had many moments when I felt like I was in over my head with trying to learn a new language and also meet deadlines for the projects I was working on. During those moments I would often get a pretty bad case of imposter syndrome, and start believing that I wasnt good enough for the job. What helped me push through this was a similar technique to what is taught in this apprenticeship pattern. Whenever i felt overwhelmed with a certain aspect of the project, I would go back to a part of that project I felt comfortable with and work to improve on what I already built. By doing this I was able to stop the mental block, and by working on familiar material I felt like I was making progress. This in turn helped me figure out issues I was having with other parts of the project and slowly push through them to finish everything up.

Since I have used this apprenticeship pattern in the past with success, I am almost certain to use it again in the future. Since I just graduated and am about to start my new career, I am sure plenty of situations will pop up where I again feel overwhelmed. When those situations arise, I now have a strategy I know will work, and I can rely on it to help me get through whatever issues might come my way.

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

Familiar Tools

Any project that doesn’t retread at least some old ground for you is one where you can’t effectively gauge how long it will take. This is the problem the authors identify in this pattern. The solution offered is essentially to have a set of tools you’ve already mastered and to get at least one of them in whenever working on something unfamiliar.

One pitfall the authors mention is the possibility of your tools becoming obsolete. If you’ve mastered something, it can be pretty uncomfortable to give it up, especially when the new alternative is something completely unfamiliar. This is why I think it’s always a good idea to be on the lookout for things to add to your toolbox.

Speaking of, I want to actually come up with a proper response to the action section in this one, for a change. The authors basically just ask you to reflect on what your toolbox is. I have a specific project in mind, which is a small game I’ve wanted to make for a few months now, but haven’t been able to with school.

Here are the relevant tools I’m familiar with:

  • The JavaScript programming language
  • The OpenGL standard (kinda)
  • Krita (an art program)
  • LMMS (a DAW)

The authors suggest five tools, but I can’t really think of another one that makes sense for this project. I think coming up with this list was clarifying in that it made me realize that I’m not entirely comfortable with most of the tools I want to use for this project. The project, for reference, will be a short narrative-focused game where a character walks around and talks to people. It will be embedded in a web page, which is why I’m using JavaScript.

JavaScript is probably the thing I’m the most comfortable with on that list, although only because I feel pretty good about procedural and object oriented programming in general. The other three things I’ve mostly only really dabbled in, particularly LMMS.

Something else I noticed writing this list is that there’s quite a lot that’s going into this project that isn’t covered by a straightforward list of tools, even if I were to take away all the non-programming parts of it. I think it highlights the fact that just learning the tools, while necessary to get things done, isn’t sufficient. You also need to apply them creatively.

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.