Monthly Archives: March 2022

Apprenticeship Patterns: Expose Your Ignorance

This week, I took a look at the ‘Expose Your Ignorance’ apprenticeship pattern. The pattern describes the dilemma in which your employer is relying on you to do a job, but you are unfamiliar with some of the required tools. This situation can be the result of many things, one of them is you are the only person that was available to do the job. The pattern proposes that you “expose your ignorance” when you need help rather than staying silent and learning on your own. It is potentially beneficial for everyone when you can present the problems you are having. Over time, it becomes detrimental to protect your pride and hide the fact that you don’t understand what you are working with. Not only does it prevent you from learning and doing work, but it also increases the pressure and workload for the team. So the best way to avoid all of this is to get comfortable with asking for help and showing off your learning ability.

As soon as I read through the pattern I could immediately relate to the problem described. In the time I have spent working, there were always a few occasions where I would be completely lost. And though it was embarrassing at first, it was always beneficial to ask for help as soon as possible rather than waste time getting nothing done. I could also see this potentially occurring in a sprint, where team members are all occupied with their respective issues, and you are left with a task involving concepts you aren’t familiar with. There is always the pressure to show competence when working in a team, but as stated in the pattern, asking questions will expose your learning ability to your team and can even help them gain new clarity about their knowledge on the subject.

The therapist’s story mentioned in ‘The White Belt’ pattern was mentioned again, which involved taking a not-knowing stance to better understand clients. But in this case of this pattern, it is not feigning ignorance, but exposing it to learn. I think the comparison between an expert and a craftsman was interesting: “experts will do everything they can to remain wedded to a single context, narrowing the scope of their learning, their practice, and their projects. Craftsmen, on the other hand, 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.” But as mentioned before, it is not the goal of an apprentice to become an expert, but a craftsman. I will continue to keep in mind that it is important to expose my ignorance.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

Learning Pattern Nurture your Passion

The main idea for this pattern is to help one maintain his level of excitement for the field. The author presents warnings of moments where one’s career can be the culprit of discouragement and discontent. He presents a few ways to remediate the situation some by which one could steer their environment to a better place. He doesn’t stop short of recommending leaving a toxic environment if nothing works. The drastic measure is something I would like to avoid because the reason I return to school was the result of it.

This pattern is linked to a lot of other very good patterns, and I am not surprised so many fit well with it. Nurturing one’s passion is the best way to achieve excellence in any filed. Particularly I feel that “Draw your Own Map” is very descriptive of I what plan for myself. I haven’t read this pattern yet, but I think it will be my next one. This support pattern, as explained within “Nurture your Passion”, states that one should know what it wants and pursue it. I like this idea because it removes the self-pity victim mentality away from the equation. This mentality can induce a state of paralysis that is not healthy and hinder you from accomplishing what you want.

My goal after school is to try to find something I am really excited about and maybe even sacrificing pay or title for it. The field of software technology offers the opportunity for a lifelong learning experience. It is so broad, intersects so many fields and industries that it allows for a vast array of choice in which anyone can find something they are passionate about. It also offers the opportunity to trade your convictions and passions for financial gain and we should be careful about that. Some of the things I hear the author talk about I think relate well to what I hear from the gaming industry where is said that they work long stressful hours, and their pay is not up to par to other types of developers. This is a good cautionary tale because most people probably go into this subfield for passion, but passion can become obsession, and that can be very unhealthy.

From the blog CS@Worcester – technology blog by jeffersonbourguignoncoutinho and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Stay in the Trenches

The pattern I decided to read is titled “Stay in the Trenches” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern spoke about how people often equate being promoted into a managerial role with success but how this can actually take you away from the craft of programming. The pattern goes on to talk about how we should work with our employers to see if they can reward us in other ways that keep us close to the act of programming. Next, the pattern discusses how it is easy to apply this pattern selfishly but that experienced developers will find ways to make choices that will help their co-workers as well. Lastly, this pattern ends with suggesting its reader to come prepared with alternative rewards in case they don’t like the rewards offered by their potential employers, especially if they take them away from programming.

The most thought-provoking piece of information I got from this pattern was the bit about how I should make choices that are in my best interest, but how those choices don’t have to be blind to the needs of those around me. It was interesting to hear this because in a pattern that I’m learning about negotiating and advocating for myself, I’m also being taught how I can still be compassionate to others on my team. This is refreshing to hear because it seems like developing can often be a cut throat and intense environment to work in.

As far as how this pattern has caused me to change the way I think, I would say it re-enforced some of the beliefs I had. In a way, I’ve learned first hand what this pattern has described. I started working in human services as a residential counselor and worked my way up to managing a group home on my own. I learned the hard way that by entering a managerial role, I did a lot less case management and had less time with the individuals I served than when I was a residential counselor. Because of this and some other factors, I decided to step down back to the role of a residential counselor which I personally find more rewarding. This realization I made is the kind of message I got from reading this pattern. If I am passionate about programming, I need to be mindful of the opportunities I may receive in the future and make sure they are aligned with my desire to be a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It was reassuring to hear something I have learned in life being echoed in this book, even though it was in a different career path.

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

Craft over Art

This pattern starts off with a strong quote by Richard Stallman who states “I would describe programming as a craft, which is a kind of art, but not a fine art. Craft means making useful objects with perhaps decorative touches. Fine art means making thing purely for their beauty”. And this quote hit me right in the chest because I wished I had read this quote way earlier, around sophomore year or so. At that year, I was just trying to learn programming while also struggling. At that time, all I could do was some cool stuffs in my own personal computer’s terminal. There wasn’t any time when I thought I should build something that is useful and also could be used by others. All I had in my mind was how to make this code work so that it looks cool in my own terminal.

The context of this pattern is that I am being paid to build something that will solve a problem of a customer. However, the problem is that although there is a solution, my customer’s problem represents an opportunity to do something truly fantastic and is a chance to impress my colleagues with something beautiful. The solution starts as, the things we build for customer can be beautiful, but must be useful. This pattern is developing the ability to sacrifice beauty in favor of utility if and when it becomes necessary. The more useful a piece of software, the more important it is that the software be high quality. But quality takes time. You will have to work toward a suitable level of quality by repeatedly making trade-offs between beauty and utility. Ken Auer also states a really nice and meaningful quote, “Working on real problems for real people is what hones the craft, not just doing it for self-satisfaction”. The action is to do something useful rather than beautiful. This pattern reminds me of an app I made in operating system class with Professor Shruti Nagpal. For that class, our final project was to make something from what we learned in the class. Since my parents kept on asking me what is the current dollar rate compared to Nepali Rupees, I decided to make a currency converter app for them. The app may not be used by many people, but when I think of something I did useful, that’s all I could think of, and I don’t hear my parents asking for dollar rates anymore.

From the blog cs@worcester – Dream to Reality by tamusandesh99 and used with permission of the author. All other rights reserved by the author.

Your first language

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race.[…T]he technical terms of any profession or trade are incomprehensible to those who have never been trained to use them. But this is not because they are difficult in themselves. On the contrary, they have invariably been introduced to make things easy.

—Alfred North Whitehead, An Introduction to Mathematics

The individual Apprenticeship Pattern detached from the book that I wanted to choose as the first one and discuss is Your first language. I choose to start with this pattern because it sounds so familiar to me.

Knowing programming languages has been way too early for me. And now I am studying here, ending the third year of my computer science major. But at the same time, I have done kind of the same major that was for Informatics. About eleven years ago, I chose to study programming because it looked so challenging as a major and that could have courses where I could have mostly learned. The first programming language I used to study there, was the c++ programming language. This course was really helpful for me as the first language, because it helped me learn how to develop operating systems, games, different browsers, and many other things. After the c++ programming language, some other languages I studied there, were Java, Unix Systems Programming, etc. These were programs that helped me a lot in relation to my major. But there was something different. Here firstly I had to choose Introduction to programming, which I think is the base for being a good developer, and then study other helpful programming courses.

I find somehow myself at the solution that Alfred North Whitehead has given on this pattern. He said that first pick a language and then became fluent in it. After some years, this language will be the main one we can solve problems. And I totally agree with this solution because as much as you work for something specific, as much fluent you will be in solving problems. One other solution that he has also given, is that we can also ask the most experienced and available programmer we know for some help. And at this point, I have been lucky. Not only here that I have my cousin, but even when I first studied computers in general in my country, I used to have friends that were more experienced with the programming languages and with whom we have the possibility to discuss different problems faced while programming. But still, I agree when A.N. Whitehead says that we don’t have to be completely dependent on experienced friends. I have always tried to take lessons from them about the problems I can’t solve and also learn from these mistakes.

To sum up, I think that working on programming languages is challenging at the beginning. But once we learn about it, and make that our own language, we will get used to that. It will become something we will like to work on and solve problems as experienced programmers.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Create Feedback Loops

A feedback loop is a continuous process in which you listen to and speak with each other or to another party then make changes based on repeated assessments. It entails beginning with humility, understanding that there is always space for development. It does not matter what level in the process can relate feedback to others can help solve many different problems or at least take the process in the right direction.

If you have an effective feedback loop, you’ve established a culture in which learning, growing, adapting, and curiosity is key to your growth plan, and no one makes decisions based on assumptions or hunches.

As we read the quote “PATRICK FINDS OUT WHAT HAPPENS IF YOU DON’T GET FEEDBACK.”

As I am paraphrasing what he said here. He didn’t have a strong understanding of the Oracle framework and how things were intended to work when he eventually got to writing on the main project. Because my immediate seniors rarely gave me comments, he ended up adopting code written by a senior on another team as the basis for the patterns in which his code was written. Despite his continual questions, he had no notion of what he was doing was correct. After a while, he realized that the way he was going about things wasn’t the best way to go about making apps, so he asked the guy he’d cloned why. He was fortunate that we were still in the “research” stage of our development process, which allowed him to repair the code he had written.

This reading is a perfect example of that happening every day in our interactions. I like this pattern because it touches a lot of great points that establish between the two parties. Feedback is great, either reinforcing or balancing feedback should be delivered in a way that creates a parallel to help improve in development.

As it says in the create feedback loop; Feedback that is reinforced pushes you to do more of something. The feedback that is balanced pushes you to do less of something. A system can be kept generally stable by combining the two types of feedback and making several modest modifications. Apprentices who succeed learn to establish conditions in which they may obtain data about whether they need to do more or less of an activity promptly and frequently. This frequently entails learning to express yourself and listen without interrupting.

From the blog CS@Worcester – Site Title by proctech21 and used with permission of the author. All other rights reserved by the author.

The White Belt Pattern

The white belt apprentice pattern refers to the part of the movie where the main character thinks they know it all, but instead suffer tragically in some way due to their ignorance. This pattern recognizes that now that you have some skills, the real journey begins.

Assumptions can sometimes be dangerous and can impede your learning. Many times, when I’m trying to learn something, I associate with how it can be like doing something else. While this can be helpful to get me to remember how to do something, this method can also leave out the realization of other possibilities that a certain strategy offers. For example, throughout experimentation with different ingredients and brewing strategies, today many different brews of beer exist. This wouldn’t be possible if these craftsmen didn’t take the time to forget what they knew about making beer already, otherwise they would have just crafted the same one beer repeatedly.

While I find the information in the pattern interesting, I really wonder if I can apply it in my own endeavors in programming. I become doubtful I guess because this is a new way of thinking about how to learn for me. However, I feel like the explanation of learning your second language is put perfectly in the book. The need to feel productive is a dominant urge that I have, but that need must be sacrificed sometimes to learn something new and improve upon my skills. In fact, the book says that this is the most productive way of doing this so in turn, I guess nothing is really being lost.

Becoming comfortable with not being great at something after being great at it for the sake of learning is something I need to get better at. Learning how to do things with my left hand will be helpful if I cannot do things with my right hand, although it would feel naturally uncomfortable to do so. While I am open to and applaud the idea of this pattern, I can see myself struggling to apply it in my own life.

From the blog CS@Worcester – You have reached the upper bound by cloudtech360 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.

Sprint Retrospective 1

To be honest, I think this first round of figuring everything out went as well as it could have. To start with what could be improved, I’d definitely have to say our team should establish much more concrete issues to deal with the specifics of what we prioritize for getting done. While we certainly got the gist of it as we were progressing, I was feeling quite lost in organizing epics and issues to be more to the point. A second thing that I specifically didn’t do well with was communication with the team. While in class we had no problems (in my opinion) and we get along quite well, but out of class I am egregiously bad at keeping up with messages. Thankfully, I don’t think it interfered too much with the work flow, but it certainly remains an important thing I have to remedy as I owe it to my teammates. In addition, I think the Scrum Master position was a little up in the air, as most of us were looking at each other for help with direction in our sprint. As a result, we all sort of pitched in where we could, and hopefully in coming sprints the role will solidify into a more acute position with specific responsibilities.

As for what went well, I think the team’s communication was much better than I was expecting. In some areas there was a bit of tension when it came to explaining a concept, or deciding what should get done first, but it was amicably resolved with no real issues. I personally enjoy working with everyone in the team, as everyone was ready to come to the table and pitch in. The only area of improvement I can really pinpoint is staying in contact with what each of us may be specifically working on at the moment. At one point me and a team member began to overlap what we were working on, which went on for a little longer than it needed to.  However, I don’t have much to say on this, as I think on the whole it went smoothly. The things that might need to improve I believe will just come with time as we continue to work on the project. 

As for myself, I think some members may not like me as much, as my participation could for sure improve, but that’s neither here nor there; I only say that to remind myself I need to be better. Another place I may need improvement in is with my explanations. I can be quite ramble-y with some assumptions about what others may believe, or already know. I don’t think in a condescending way, but only insofar that the gap in understanding of communication doesn’t help me to get my point across.  

As for some of my contributions, they are as follows:

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/8303274a7264a636ee71a2bc10ae57e4578b6806

Here is when I added a few schemas to the API repository.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9fe22f78eaa34a46c3cb32eedb7080bfe33b9bd5

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/71d797e318075cba6f1ded1bb31ceb0c4fcb7dd5

Here are a couple examples of when I added some basic files to get the API repository updated; I believe there are about 12 similar creations of basic files, but it would be repetitive to include them.

https://gitlab.com/LibreFoodPantry/client-solutions/nest/guest-information-system/api/-/commit/9412a5433a4e8adb9f617d0f892e5a879d1b2455

And finally, here’s an example of me updating a basic attribute file in the repository.

From the blog CS@worcester – Dummies that Code by howbrash and used with permission of the author. All other rights reserved by the author.

Craft Over Art

This week I decided to read “Craft over Art” from chapter 3. This chapter simply teaches us that as a craftsman, our prime focus should be to build something that serves the need of others instead of using a project for self-interests or to impress colleagues. This reminds me of most of the projects we are working on in class right now, especially the Thea’s Food Pantry. The focus is to build something that will serve the Worcester State Community.

I believe the benefit of doing something that serves the need of others is that we are doing something for real people. Seeing customers benefit our work, being happy with the product, use it and see it being successful is a great feeling of achievement. We see customers happy, satisfied and using something useful that will probably be there for a long period of time. Working directly for a client can also be stressful as there is a timeline that needs to be met, there are requirements, specifications, policies to follow and it is not always easy to satisfy every customer.

This is where I am bringing the beauty aspect. While reading the book, I understood that focusing on the usefulness rather than the beauty might only apply to a craftsman as he is still in the learning process, embracing his ignorance, taking the long road. Focusing on the beauty aspect of a project can be stressful, distracting and take away the usefulness which should be the priority. However, I believe in a more professional world, for a reputable company, being able to deliver both the value of a product and adding the refining beauty aspect is definitely advantageous. From my perspective, In the future, when I develop projects for customers, I will focus on the value and the usefulness it will bring to the community. However, one client is different from another. One community is different from another. Depending on where I work, if after getting to know the mission of the tech company I will work with and studying the type of customers we usually have, I find that beauty is something they want on top of the usefulness, I will want to deliver that and meet their needs. I think beauty is used nowadays to attract people even when the product itself is not well developed, has flaws and will not be durable. It is unfortunate that art to attract money is put first over craft to serve a community.

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