Retreat into competence

The context of this pattern is that when you realize how little you know, when you get out of your comfort zone and try new things. I think everyone who has done programming has gone through this problem. When you are writing code, nothing works on the first try then you try again the next day, and it still does not work the way you want it to be, at that time you feel like you don’t know anything at all. Then after a couple tries, the solution starts to come to you and everything starts to make sense, then you connect every idea and make it work. Just when you feel like you know everything and move to the new issue/project then the cycle repeats, once again you are introduced to the vast reaches of your ignorance, and you are overwhelmed.

The solution to such problem is to take a step back to jump two steps forward like a slingshot in carnivals. As the pattern says apprenticeship is a roller coaster ride as you thrive to learn new technologies, leveraging your knowledge and creativity to deliver value to your customers but if you compare yourself to someone who knows more than you or is an expert in the field then you will feel terror of perceiving just how little you know of things. A pattern like this is relevant to people (such as myself) who have pushed themselves beyond their ability, where they are constantly trying to learn new things, one after another, and there will be a time when this pattern kicks in. When such things happen, you retreat back to your competence to regain your composure. Take some time to build something that you already know how to build then use that experience to recognize how far you have come, then use that recognition to boost your confidence. For example, pick something self-contained that you know really well and reimplement it to remind yourself of your own capabilities. There is also a way to prevent from overwhelming, you can accept that his pattern is only a short time fix. You can set yourself a time limit. For example, I will refactor this code for half an hour before I jump into making another function or adding another feature.

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

The long Road learning pattern

The long road learning pattern sets its premises on favoring rather than quick results cumulative progress. I believe that working towards a 4-year college degree and the tradeoff that comes with it puts us in that category. We all know that even after the switch from student to paid professional the road doesn’t end. In fact, one of the reasons, I decided to pursue a career in technology was the promise of perpetual learning that the field offers.

The author mentions the constant change in technology and a deeper intrinsic knowledge we developed over time to deal with them. In a sense I believe, he meant that as we acquire experience, we become more sensitive to patterns.  These patterns can help us become more agile in adapting to new tech as well as seeing projections of how they would unfold ahead of their full development. Regardless of how far we get we must not give into the ego and assume things with certainty we can’t guarantee.

We must watch for hardening during the long road. The author doesn’t offer any cautionary warning for this pattern, but I believe it warrants one. In many professions I see how the long road can become a trap to steer you away from self-development. It is extremely easy as you gather knowledge along the road to become a know-it-all. To me there are 2 versions of the know-it-all; the flexible version where one knows a lot but is open to change; the hardened version where one knows a lot and cannot change. I think it has a lot to do with egos, the flexible one is probably perceived by others as knowledgeable but does not care about the title itself so it makes it easier in the long run to reshape knowledge; and the hardened one sees itself as knowledgeable, the title is important so no exterior knowledge that conflicts with its own can be accepted. The hardened one should be avoided; professional life is about social interactions and the hardened one will become isolated or be avoided by others while the flexible one will flourish in a social environment and grow with it.

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

Post #3 for Apprenticeship Patterns: Rubbing Elbows 

Rubbing Elbows describes the benefits of developing relationships with other developers at your own level primarily. Working closely with others in a friendly, yet conscientious way is a skill set that is very important to develop. This includes working with peers and mentors, as well as those who are less qualified than you.

It is really important to have mentors. The book focuses on having one mentor, but I think there is room to have many. If you are lucky enough to end up in an environment where you are surrounded by many talented people, it is advantageous to you and to others, to gain information on subjects that will expand your career from anyone who is willing to help, even if it is just with a 5-minute conversation. Although you should learn from mentors, you can also be helpful to them in many ways. Letting them know you will follow up on minor problems they are encountering, or that you will do further research on what they are teaching you will help. Sending emails thanking them for their time, and briefly reiterating what they have taught, will let them know you are grateful, and serious about their advice. This will make them want to help you more in the future and will also make you appear to be a real team player.

The basic intent of the “Rubbing Elbows” pattern is to have you form relationships with fellow programmers at a similar peer level as yourself (Kindred Spirits). It describes the benefits (and difficulties) of working in “Pair Programming” situations, and will make your job more enjoyable and social, but it mostly will accelerate your professional development, as long as both developers are working to help one another. There are situations where you will be paired with someone who is just out to get themselves noticed, as well as those who are looking to take all the credit for shared work, so be careful who you decide to focus a lot of energy on.  

To expand on the pattern, I would also add that I think it is equally important to help those of your peer group who may be struggling on a given issue you know more about, and to help those who are less experienced as you. These people will be grateful to you for your assistance and may end up helping you over the months and years ahead far more than you would think.

This pattern is also applicable to those you meet outside of your job. Those you meet at conferences, training courses, and Computer Science related clubs, as well as those you “meet” online in forums like stackoverflow.com can be very helpful to your goals and could actually become long-term friends.

The bottom line is that you can learn from anyone, and you can teach anyone, as long as all parties are on-board with being respectful to each other as individuals.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

For our first sprint, our goal was to familiarize ourselves with the different components of a system that we need to work with and that we don’t know. Most of the issues present in our first sprint dealt with researching these aforementioned components, for instance, RabbitMQ, EKS, and Kubernetes. As such, most of our issues were researching the anatomy of what we’d be working with via AWS EKS. I believe our main difficulty was determining what we needed to research, and what was useful or not.

To get what did not work best out of the way first, some team members, myself included, missed the deadline on some of the issues. In my case, this was due to the fact that we are unfamiliar with much of what we’re researching, thus, the issue I dealt that I’m referencing with was denser than I expected it to be because it’s difficult to project precisely how long each issue would take, or if we need to split it up into several smaller issues1. 

What worked well was our team’s communication with each other in class, and in some of the issues. It took a few classes to warm up to each other. I think the descriptions and how we formatted our research also worked well. In general, we used markdown to break down our research into more digestible sections that made it easier to understand2. Another thing I thought worked well was the description of what we may be looking for in the issue descriptions. While difficult to be too specific, it helped as a starting point for the other team members to begin once they finally started on the issue3. 

As an individual, I think I could improve on meeting issue deadlines in a more timely manner. While I mentioned earlier that the issue was denser than I thought it would be, I also should’ve managed my time better, and started working on this earlier to fully understand the time it would take, so that I might’ve been able to mention it in the next class. I also think that I should’ve talked more through the GitLab Issues / Epics rather than other means. While I did communicate using the aforementioned means, it may be better to discuss more, especially as our future sprints will more than likely demand it.

As a team, I think we should institute a better application of rules throughout the issues. While writing this, I realized the issues implement markdown format differently than others4 5. I don’t think this is a big deal, but it may be better to implement some form of standard across the issues. I also think that we may need to communicate a little more via the GitLab Issues / Epics. In this first sprint, most of the issues were independent research that usually didn’t cross over into other issues very much, hence there was little need for communication between team members. However, given that the second and third sprints will involve deployment, it is both required and vital that we communicate on GitLab.

Evidence:

  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/13#note_848604859 – A note left by me explaining why it took extra time.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14 – An example of research using markdown to partition the different parts of research as mentioned above.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/4 – Example of an issue’s description that includes a brief description and several points of interest.
  1. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/11 – An issue description using spacing to separate sections.

5. https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15 – An issue using titles in markdown to separate sections.

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

Confront Your Ignorance

Continuing from last week, “Confront Your Ignorance” is also the next section in the book where I find some similar patterns to my current state with the context of identifying gaps in my skill set.

According to what was written

“There are tools and techniques that you need to master, but you do not know how to begin. Some of these are things that everyone around you already seems to know, and there is an expectation that you already have this knowledge”. 

The only difference is not everyone around me seems to know it, except the YouTube algorithm, but I should meet the team’s “expectation” to have my part working on time. The situation can be described as I currently have a sample to refer to my work, but I do not want to abuse it because if I do so, I learn nothing from it. It feels like I can understand everything in the sample, I’m still curious on how it was done and since the programming language is too versatile, is there other way that I can do it without “copying” the sample?! Since the sample has a good structure and is written in a comprehensive manner, I would happily learn it, but the code, I don’t think I can write it that good just by looking at the documentation.

I consider myself a competitive person and sometimes my curiosity makes me feel unsatisfied in many cases. I always want to be as good as that “person” in a particular situation and when I can’t, the feeling is quite uncomfortable. Hence, I think my biggest ignorance is trying to achieve too many things but not concentrating on a certain topic. A solution was given in the book, it’s also obviously the only way for me to get rid of my bad habit, which is to strive to learn each one, maybe in important order.

In conclusion, I think it’s not bad at all to have so many interests at the same time, but I should figure out which one I should prioritize learning it first. Back to my current problem, I think I would go over the commit history to see how it was initially done and proceed from there.

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

Craftsmanship Log #3 – Practice, Practice, Practice

               Many of us have heard or said the phrases “Practice makes perfect” and “Repetition is the mother of all learning.” Though I personally can neither define perfection nor learning, I can say that no one can gain expertise off anything they see once and never apply again in their lives. Even though we may understand a new concept that we learn at first glance, it is when we repeatedly work on it hands on that we can truly experience the nuances that are introduced. Continuous practice is known to help considerably during the learning process, as one works to internalize the knowledge that has been introduced to them. This is also a pattern introduced in the book “Apprenticeship Patterns” by the name “Practice, Practice, Practice”. Though the name of this pattern is rather straightforward, it is important to emphasize what makes this pattern and important component of the learning process.

               Simply put, “Practice, Practice, Practice” is a pattern that is meant to address an apprentice’s potential hurdles that may stem from neglecting to practice their craft hands on and on a frequent basis. As such, apprentices may not have a proper understanding of where their strengths and weaknesses lie, thus their learning reaches a point of stagnation. However, if an apprentice only takes the time to practice what they learn in a work environment, they may end up hindering their own growth since they add the stress of having no room for error on top of learning something new. As a solution to this hurdle, apprentices are advised to find exercises to practice on at their own time and pace and in an environment that treats any mistakes that come up as opportunities for learning rather than signs of imminent disaster. That way, an apprentice can take the time to properly learn and improve their craft. What may also help is communicating with experienced people that can point out any habits that may be counterproductive in one’s learning and provide the appropriate feedback that an apprentice may need.

               With that being said, I want to point out that I have not mentioned the words “programmer” or “developer” when discussing this pattern, even though I believe it is by far, in my own experience, the most crucial pattern stated in this book.  In fact, I personally try to get my peers, as well the people I help at my job, to espouse this pattern and incorporate it into their own learning process. Though I disagree with the notion that “practice makes perfect”, I wholeheartedly believe that actively practicing new knowledge in an environment that allows mistakes can do more to help an apprentice learn in the long run.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Be The Worst

Be the worst is an apprenticeship pattern from chapter four that focuses on surrounding yourself with people who are better than you in order to constantly keep improving yourself. The chapter argues that if you are the best in your respective group then you will not grow and improve as a person.

I whole heatedly agree with a majority of the points made in this apprenticeship pattern. From personal experience alone I know that this idea holds true. While in a classroom environment I am definitely not the best, but I am also not the worst. I tend to work with people at a similar skill level to me when I work on group assignments or in class work. While I still learn things in these environments, I know that I miss out on more nuanced knowledge that’s gained by experience. In an environment where most if not everyone is better than me, I could learn things from people that I would most likely not learn in a classroom environment. During my internship I was surrounded by talented programmers, and as such I was taught many different tips, tricks, and skills that I probably would not have otherwise learned.

Another thing I really resonated with in this pattern is the fear that being the worst in the team will result in lower overall performance or cause me to hold others back. This idea is daunting, but it also lights a fire under me and forces me to improve in order to keep up. One thing I do not necessarily agree with is the statement that joining a team as the worst member is selfish. I do not thing that is true, as long as you join that team with the intention of working harder than everyone else to keep up and improve. The team also may benefit from you joining, since because you may be inexperienced, you can potentially learn new ideas quickly and the team may be able to mold you to their needs as a result. This can be a win-win for everyone, you continue to improve yourself while the team gets to mold you to their needs.

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.

Apprenticeship Pattern “Concrete Skills”

This apprenticeship describes how even though we may be knowledgeable software engineers, the knowledge we possess may not be enough to convince others to work with us. Instead, we need to show that we have the ability to apply this knowledge in the creation of software applications. Teams most of the time don’t have the luxury to hire someone who can’t contribute to their workload. It is up to us to convince them that we can demonstrate our skill practically in the workplace. It will be beneficial to us if we are able to display our skills in being able to build in various languages and frameworks. As new graduates, when being picked by hiring managers, they are taking a risk on us and our ability in our concrete skills is what should give them confidence in being able to contribute to the team on day one.

What I’ve taken from this is that I need to contribute more time into honing my concrete skills to be able to show others who take a risk on me that I am in practice and that I am capable of providing for my team instead of being a hinderance. Being able to show that I am able to use my understanding of the knowledge I already possess and translating that into other aspects of software engineering is what I should be striving to do. They also explain that what I’ve done in past shouldn’t be overlooked and that the softer skill that I have attained really are bigger than what they seem, and that these skills themselves also help contribute to being a better software engineer in the workplace.

This apprenticeship pattern reminds me that being able to be hired by a company is a testament to my ability and not just being a graduate. In order for companies to trust me, I need to show them that I can use my skills to help the team and not rely on others to help jump start my progression. This pattern also reminds me that the skills that I have acquired in the early parts of my life should not be downplayed. They do provide others that I am capable of many different things and that they can translate to many parts of my job at the workplace. I normally tend to shy away from my accomplishments from other jobs because they’re not software related, but after reading this pattern, it gives me more confidence in being able to embrace those previous accomplishments and use them to my advantage.

From the blog CS@Worcester – Life as a CS Student by Dylan Nguyen and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

As my team moves on to our second sprint, I am reflecting on our progress so far. Our project, deploying LibreFoodPantry to AWS EKS, is new this semester. My group is essentially starting from scratch. As such, we spent most of our first sprint researching and compiling information about AWS EKS, Kubernetes, and other relevant tools.

Overall, I think my group did a very good job during our first sprint. Since it was mostly research, I think it was easy for our team to excel. We were able to complete all of the work we had laid out at the beginning of the sprint and now have a better idea of where our second sprint will lead. Everyone was very efficient and got their work done in a reasonable time. It felt like everyone was doing an equal amount of work; it didn’t feel like one person was doing the bulk of it. We all worked well together and were able to communicate when we needed to.

My team did struggle initially trying to break down the work we needed to do into smaller issues, and I can see this may be a problem going forward. No one on our team has extensive experience with AWS EKS, so it can be hard to tell what needs to be done and what is worth researching. I think this will get easier as we become more familiar with our project and how we want it to progress. But this did make it difficult to plan our first sprint.

Something I think my team could improve upon is communication, especially on Gitlab. Most of our conversations about our project were held either on Discord or in person. This sometimes makes it difficult to review what we had talked about afterward, and I imagine it will make it difficult for the group that takes over this project next to understand what we did. It would probably be more useful to have these conversations in the comments of a relevant Gitlab issue.

In addition to communicating more on Gitlab, something I feel that I personally could improve on is time management. I was still able to get my work done in a timely manner, I would not plan out my time well. I am not good at predicting how long a task will take me to complete. I would underestimate how much time a task would take and leave it until the last minute, or I would overestimate the amount of time it would take and wind up with nothing left to do. I want to plan my time more efficiently for the next sprint.

Contributions:

Look into how to set up AWS access for us – I worked on this issue to get our team access to an AWS account so that we could start learning the tool.

Research AWS EKS – This issue provides a set of resources for someone looking to familiarize themself broadly with AWS EKS.

Research and report best practices for Kubernetes – This is a listing of some best practices to keep in mind as our team begins to work with Kubernetes.

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

Apprenticeship Pattern: Draw Your Own Map

The pattern I decided to read is titled “Draw Your Own Map” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. This pattern was about taking ownership of your professional career as a software craftsman. We learned that in many jobs, you may get pigeonholed to do one particular thing when you may be passionate about learning or doing something different. This passage reassured its readers that they had options and didn’t need to feel trapped, or stuck. By spending some time reflecting  and drawing your own map, you can make career choices that feel empowering instead of limiting.

One of the most thought-provoking points that was brought up in this reading, has been mentioned before and I think I have highlighted in a previous blog post but I would like to reiterate it here because it continues to resonate with me. This pattern mentioned how sometimes it is better to “move into a less hierarchically impressive role in order to stay “on the map.””. Especially if staying on the map is, “more congruent with your goals and will lead you to greater heights in the long term.” This resonates with me because I want to make decisions that are aligned with my goals and beliefs in my professional career, even if that means making some temporary sacrifices.

As far as how this pattern has caused me to change the way I think about my profession, it has encouraged me to either make career choices that open up opportunities or help me  pick a specialization I am passionate and confident in. While my first job after graduation is likely going to be something to get my “foot in the door”, after some time in my first job, it is important for me to spend some time thinking about what the next best step is going to be. My first job is likely going to teach me a lot about what I like and don’t like and it is a place where I can see my interests developing as a software craftsman.

Lastly, I’d like to mention that there isn’t anything in this pattern that I disagree with. It has encouraged me to start thinking about my own map and it has made me peek at some new potential patterns for me to read next (e.g. Expand Your Bandwidth, Use Your Title).

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