Author Archives: gkitenge

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.

Sprint retrospective #3

This last sprint has been different from the other two. This was our last and we needed to talk and communicate well with the team and know exactly what to do for the last sprint. We started by talking about the issues that we created in the past sprint that we did not finish and then after that, talked about the plans we had for sprint planning 3 and the new issues that needed to be created.

The issues that I have created and worked on are: “Discuss Integration with Inventory System”, “Research Kubernetes from AWS Team”, “Backend: Create HTTP calls for Database”, and “Research: How to deploy RabitMQ on Kubernetes”. These issues were put under the status “done” because we had all the information needed. I did not really have time to work on the first about discussing integration with the inventory system from the other section but my teammate Mike Morley talked with them and gathered all the information needed. I did work on Kubernetes, actually, 90% of my time working on it.

I talked with the other team too, but did my own research and gathered all the information I needed. One of my Teammates Andrew Sychtysz talked with the Scrum Master from the Kubernetes team and also did his own research on the same issue as mine. The more information we have, the better. Kubernetes have a lot of interesting articles, but with them, I felt like the information were very broad and too much, so I decided to watch videos/tutorials. I did watch a lot of videos and learned a lot about Kubernetes and I am planning on sharing all that I know on GitLab.

The other issue about Rabbit MQ, I did a lot of research on it because for some reasons but since it was not part of our project, the professor said to abandon that issue. But I am deciding to talk about it at least because I do have a lot of information on RabbitMQ that I found interesting and did watch some videos and read articles.

As individuals, we did work and completed what we were supposed to do. Some issues still need reviews, some will be put back in to open section for those who will work on this project next year. As a team, we all contributed and were there for each other whenever we needed help. For example when Mike Morley helped discuss with Inventory System from the other section because I was not available to do that. Also when Andrew helped with Kubernetes, or when I and Lena Viazmitinov worked on the backend. We might not finish the project but we did work and have all put up with the work.

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.

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.

Apprenticeship pattern: Be The Worst

I was reading the pattern Be The Worst which actually explains how it is important to take a step back and improve our skills as Software developers. Sometimes we hate being surrounded by people who are smarter, fast learners than us because we feel a sort of complex of inferiority to think that we’re not better than them and can or will never be. That is one thing that I struggled with personally because instead of wanting to be with people who had more experience, and skills than me, I would rather be with those who are not stronger than me to feel more skilled than them.

Reading this pattern made me understand that sometimes, being the worst in a team (meaning that you do have skills and knowledge but they know more than us) helps us grow a lot and improve even more than what we already have.

One thing that I think all the Software Developers have is that they all have a competitive spirit, which is not bad at all but it just pushes them all to want to be all equal and want to feel stronger, smarter than others. We all want to be good and the best at Software Development, but we need to understand that to be good, we need to surround ourselves with the good ones and learn from them, their experiences, skills, and knowledge.

One thing that we need to keep in mind is that those people who became stronger, smarter, and best at their work (Software Developers) were like us too and surrounded themselves with the best and had to feel/be the worst at some point of their life. We don’t become good at something without sacrifices, determination, and dedication.

One part of this pattern that I loved was mentioned in this pattern is that making mistakes is not a problem, but also that there are fewer chances of making mistakes because other members of that team will help prevent that to happen. It’s only when you work on your own that you will see how much your team increases your productivity and realize how much you have learned.

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.

Apprenticeship pattern: Sustainable Motivations

The more I read this book, the more I understand about software and how it works, the things, and sacrifices to make to become that person we see in us every day and turn it into a reality. This week I read about “Sustainable Motivations” and while I was reading, one thing that I understood is that all the motivations that we have are good but we need to define our priorities from our most to our least and then go from there. Many times in the computer science field, I felt like giving up because sometimes I will think that I need to get into something else and most of the time it is when things get very difficult and challenging. And it’s true that most of the time, not just me but also any other programmer thinks first about the money behind the work and that keeps us even when sometimes we don’t want to keep going. It is true that when I think of what I want to achieve, I love what I am doing even more and go for it. One thing that I learned is that when we define our motivations, we need to go with what really makes us happy and want to continue, keep going because that is what will help us align with walking The Long Road. We need our ambitions not to be first about money but what we want to achieve in the technology field and master it/them. This pattern helped me to be more aware of my future decision and what I really want to do it, so I don’t find myself trapped because I want to enjoy what I will be doing to the fullest and master whatever I will decide to do.

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.

Apprenticeship pattern: The Long Road

For this week, I decided to read on chapter 3, “The Long Road” which talks about the reality of software and the reasons that should be behind it. Many people probably have their own vision of computer science, and most of them are about getting the highest-paying job, just like the chapter describes it.

One thing that we need to understand with technology is that it evolves all the time and changes. We need to understand that the more technology constantly changes, the more our knowledge needs to be increased and developed. Technology/computer science is about adaptation, change, learning all the time because it will never stop improving and increasing, so should be our brains.

When the author says, “You should be prepared for the length of this journey”, it means that we should always keep in mind that as software developer, the expectation of working, learning everyday should be part of us. That is something that I learned while being a computer science major; that it’s an everyday school even for those who are done and those who are still in schools. When we aspire to become a master software craftsman, we need to understand the work taht is behind it and the devotion, dedication and time we need to invest in them. We need to value long-term growth opportunities and be open to new knowledge because that will be the only way to become better at what we do and improve the skills we already have and also, gain new ones. It’s a lot of work and will take time, but at the end, it’s our reward from working hard and giving everything we could to become great software developer. Success is part of it, and all the benefits taht come with the hard work, btu we should not think of them as the main motivation as apprentice.

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.

Sprint restrospective #2

For this second sprint, we did have good communication with my team, and also we had progressed a lot in our organization. We came up with new techniques to work on the project, divide tasks, and also we were meeting every week on Thursdays and Saturdays to talk about what we have done so far, what needs to get done before the next class, what needs more help and support from the other teammates. I personally took a lot of time trying to find a solution on how to make Keycloak work on my computer because I had a lot of issues with that. All my teammates have been able to make it work on their computers, but mine was still causing issues. So, because of that, I did not spend too much time on the rest of the tasks like working on Docker for example, which made it hard for me to complete that issue before our sprint review. One thing that I noticed during our second sprint, is the fact that we were all one when it came to knowing what to do and were always available to help one another whenever someone is stuck or is having difficulties doing part of the project. After having my Keycloak running, then I started focusing on the other issues I had to work on.

So, the issues that I assigned to myself were first to make Keycloak run, but also to create basic Kubernetes/ Docker Container with Keycloak, deploying Keycloak on AWS Kubernetes.

I got Keycloak working on my computer after having George help me to figure out the problem. Once it started working, I also tried to create a docker container with Keycloak and see what it will do. I am still working on this issue, but there have been improvements compared to the last class. Also did some research on how to deploy Keycloak on AWS Kubernetes and put both under the status done because there was nothing else left to do with those issues. But since I am still working on the Docker container issue, I moved it back to the product backlog and include it in the next Sprint planning on Monday. I also did some research on RabbitMQ and how to deploy it on Docker/Kubernetes. It’s not really part of our project but I thought it was necessary because we were going to work with another team that will actually need Kubernetes and RabbitMQ. I did not put too much of my time into this issue but I did find some good links.

As an individual, I think this sprint two went way much better than sprint one. For the first one, I was still getting familiar with the project, still not close to my teammates and I was not contributing at all (creating issues, writing comments, fixing issues,…). In this second sprint, I actually worked on what I did wrong on the first one and improved it for the second one. There was more communication with the team, and I was more involved (sharing ideas with others, creating issues to help go forward with the project,…) and that was just very helpful for me and my team.

I still need to improve some things like being more active on GitLab, posting important information, writing/responding to comments, making changes/and fixing issues. It is very helpful to have a person in the team that always make sure that we are all on the same page and that we’re all getting closer to put goal. Mike has been a great help for the team when it comes to making sure that we need to get things done, issues, and what needs to go where (sprint backlog, in progress, needs review,…). I am also planning on being more vocal in class and sharing more opinions and ideas to help the team. I am looking forward to the next Sprint on Monday and seeing how it goes.

Links to the GitLab issues that I worked on:

RabbitMQ links:,git%20repository%3A%20helm%20install%20mu-rabbit%20stable%2Frabbitmq%20–namespace%20rabbit

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.

Apprenticeship pattern: Expose your ignorance

I was reading chapter two on “Expose your ignorance” and got so caught up to it. When working with my team this semester, if there is something that I learned is to ask questions and not be afraid to show my “ignorance” like the book calls it. Sharing and exposing myself helped me understand that we should never feel less smarter than others just because they know better than we do, because learning and knowledge is open to everybody and it is not impossible to reach their level or even better, surpass them.

It can always happen to be caught up in the middle of a project that we do not know anything about. Some people might, and some might not. In that situation, we should let our ignorance awaken our curiosity so we can easily ask questions. People in general hate being seen as ignorant because we always want to show that we have knowledge, experience, skills required for the position or project. So, because of that, we find ourselves faking our knowledge and skills just to impress others. But software development does not work like this, it’s either we know or we don.t because the more we try to hide our ignorance, the more we’re sinking ourselves; And there will be a moment when it will be hard to get out of that place we got stuck on our own.

I love what the author said about the runner: ” She’s not training to have strong legs; she’s training to run. Like the motivated developer who after working on a Python for two years achieves a deep knowledge of Python, the marathon runner’s strong leg muscles are a means, not an end”. Craftsmen need to have the courage and humility to set aside their expertise and wear the “white belt” as they pick up an unfamiliar technology or learn a new domain.

One of the most important traits that a craftsman can possess is the ability to learn, identifying an area of ignorance and working to reduce it. As, software developers, we should not run away from knowledge and being shy or scared to expose our ignorance is not doing anything god to us. I am proud of asking questions and showing that I don’t have or I barely do have knowledge about a certain domain. And it is something that I do even with my team. When I am not familiar with something or don’t know how to do it, I just ask and the one that have the answer will provide it to me and help me understand. This is how I increase my knowledge and skills.

This is where “The long road” will take place. By exposing our ignorance, and then confront it. We will spin the missing threads much more quickly than we will by faking it in order to appear competent. And let’s remember that while we are exposing our ignorance, we are also exposing our team to our learning ability.

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.

Apprenticeship pattern: Unleash your enthousiasm.

I decided to write this week on chapter two, about “Unleash Your Enthusiasm”. I was reading this and got very interested because it is something that has been an issue for me for a very long time. The excitement that we have when having ideas and want to share them with others is huge, but then we feel like we might do too much or that it’s not good enough and end up not sharing it at all.

I have found myself holding back many times from sharing ideas, my thoughts. In this case, it goes both ways: when I find myself holding back because I have more enthusiasm than my colleagues do, but also when their ideas sound great and better than mine and I step back because I feel like they’re doing better than I am. But reading this pattern made me understand that there are never bad ideas in computer science. All ideas are good, we just better them, but there are no bad or nonintelligent ideas.

As software developers, we have to understand that there is no way we will be working on our own. The fact is we will be working as teams, we will have to share our thoughts, ideas and work all together as a group. So, feeling that we want to share whatever we have, we have to go for it because we can always bring something unique in our teams, some unique attributes to our groups as well as our enthusiasm.

That is why it is important to have a team that is all excited and enthusiastic because when the morale is low, or teams are not welcoming the newcomers, we will definitely feel uncomfortable and would not like to share our enthusiasm. One thing I understood is bringing our ideas and passions will add intelligence and diversity to the team.

Being in a team with people of different levels of experience is very important because they can always help others improve and get better. But also, those who have a low level of experience compared to others in the tram, should not feel intimidated. It might be hard, but we should feel free to share and be open-minded to learn and become better at what we do.

Also, it is very important to have that person in the team who makes us feel comfortable and is willing to help. They will help us get along with the team and feel more comfortable talking. I did it in my software development capstone; I knew some people in the team, and others I just met them. In the beginning, it was hard but then, I decided to open up to the one I knew before and he made me feel comfortable. After feeling comfortable sharing with him, he helped me feel comfortable sharing with the team too because he thought my ideas were awesome and encouraged me.

Never keep our ideas and enthusiasm for ourselves because we might lose the opportunity to bring something great and unique to our team, make a difference, and also learn from the experience.

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.

The white belt

Today, I decided to read about “The White Belt” in chapter 2 of the Apprenticeship Pattern book. Basically, this chapter talks about how learning a language and becoming good at it can make us feel confident about what we do; until we have to learn another language that comes to challenge us and question our knowledge. Speaking of the white belt, it basically is trying to make us understand that even if the black belt leads and knows the way, the white belt will have no choice but to follow and learn the way.

The solution gives a clear explanation of what is the white belt and how it is important to unlearn what we have learned in the past and start fresh. By learning a first language, we can practice and get familiar with it. It might make us feel like we know everything until we have to learn a second language that comes to question our knowledge and understanding of the first. It does not mean that we do not know the first language that we learned, but we have to combine and sink both languages and approach it with a mind of a beginner. One thing that I learned from computer science, is that we learn every time. We will never acquire the complete knowledge of coding, programming because there will always be improvements to make, new challenges to overcome and surpass.

Jerry Weinberg said: “In order to climb, you must leave the sure footing, letting go of what you already do well and possibly slipping downwards into a ravine. If you never let go of what you already do well, you may continue to make steady progress, but you’ll never get off the plateau.” What I love about this quote is that we need to understand that in programming, getting off our comfort zone (e.g. meaning letting go of that language that we perfectly know and mastered) and possibly slipping downwards into a ravine (meaning taking the risk to try a new language and not be afraid of the challenges, difficulties it may bring) should not scare programmers. It changed my way of thinking and what I learned is that to be a good programmer, we should be ready to face any challenges. A programmer cannot stay and remain in his comfort zone because he is scared of the challenges and difficulties another language might bring. Then, he will never learn and improve his skills, he will continue to make steady progress without going any further.

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.