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.

Confronting my Ignorance

This pattern is called “Confront Your Ignorance”. The scenario it is meant to address is when a programmer has gaps in their knowledge that interfere with their work. More specifically, they want to master skills and tools, rather than simply be adequate, yet are unsure of the first step towards that goal. Finding the first step or even admitting they need to find the first step is difficult, particularly in environments where there seems to be an expectation to just have already mastered things.

The solution provided is simple. Pick something you need to learn and then learn it. While it sounds simple, it is easier said than done.

An important skill that I have only recently started thinking about, which this pattern touches on, is the ability to know when you’ve learned enough about a subject and that it’s time to turn your attention elsewhere. Without mastering this skill, one might still go out of their way to study something on their own. In the absence of any clear goals, they may simply give up whenever they get sick of it. This is something I used to do a lot, and it led to situations where I had taken time out of my day to learn something, but the knowledge itself was too incomplete to be useful. I wouldn’t go so far as to say that it was wasted time, but I think it could definitely have been better spent.

Different people have different approaches that best suit them for filling the gaps in their knowledge. Something I think is pretty important for me is to figure out what my ideal approach is. I have some ideas. For example, I think I tend to prefer concrete examples, hands-on involvement, and at least a general understanding of how the whole system works. Figuring out what works for me in more specific terms would be a good idea also.

I tend to struggle to seek help from peers. In this pattern, the authors suggest working together to learn things, which is something I think can be fun, productive, and worth trying.

One of the core ideas here, which I will talk about in a future post, is the idea of two extremes when learning, which need to be avoided. In one, ignorance is kept totally private, creating an atmosphere where not being proficient to begin with is extremely discouraged. In the other, no attempt is made to prevent one’s ignorance from interfering with a team’s project. Straddling the line between these is another skill that I haven’t really considered before, but should probably get good at sometime soon.

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.

Sprint 1 Retrospective

The first sprint for Software development capstone class was believed to a successful event. Our objective was based upon the epics given to us and broken down to smaller issues to tackle the epics. Our team’s goal is to create new repositories for the backend and API. The nature of this sprint was to make sure the backend and API were setup with their schemas, endpoints, and dev containers to be running toward our next sprint we going to formulate.  Throughout the sprint we did a successful job at setting up the infrastructure and revisiting the previous semester assignment from Software architecture was a major help to us to progress at a steady rate.

There were some issues that our team that we came across our sprint that we struggled and affected our productivity and time management. First, whenever we conduct our standup meetings, we tend to get sidetracked and off topic, one person over speaks another person and bot waited till the end of the meeting thus making us waste our meetings and lose track of time. Second, as we learn more on GitLab and its functions we had many problems with repositories and understanding the merge requests as well as its purpose. The team was stuck upon making the appropriate comments to make a record of what we have discussed during the standup meetings or in general if needed for the next team to look through. Third, making unnecessary repositories, this is what we really struggled with because once we were working the API and we made a repository to accommodate each issue we had, sometimes we accidently work on each other repositories and created a workflow mess and had to revert the commit we made to detangle the situations that occurred.

To be sure we don’t have these issues reoccur, we had made an understand on the major conflicts we have faced to be squashed towards our future sprints. We agreed that for our standup meetings is to be respectful and allow the person to finish speaking their side and wait for all questions till we are finished. To make our own repositories in general to reduce confusion when we are working on our own issues and committing them to the correct repositories. Applying up to date comments in the issues we create and after our discussions to keep a record. 

Other than my team’s performance, there are improvements I want to make towards myself. When I was making one of the schemas for the API repositories, I had trouble on making one myself and had to ask a teammate and do research on a detailed explanation of it and to compose one. An issue like this one could’ve been done in a class period, but it took me two because of it. Backend is a weak point for me and to squash this fear is to resort to the previous classwork and material. As well as do massive amounts of online research to completely understand how to about be implementing the backend which is required for the next two sprints. Another improvement I can make is that for the issues I create are too broad and vague to understand, had some of them revised to be more meaningful. 

Sprint 1 Issues


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

The Pattern Of Enthusiasm

I think an apprentice should portray acts of enthusiasm for whatever they are aspiring to learn. I’ve found myself to have copious amounts of enthusiasm for learning how to program and becoming better at it. The issue I run into is finding ways to express that enthusiasm. I get giddy when I think about becoming a great programmer and I certainly wouldn’t want to rub anyone the wrong way because I came off as too much. My current composure and body language around others suggests that I am complacent, although I’m screaming with impatience on the inside. But I wouldn’t want to come across as apathetic for what I’m doing either. As I’ve been skimming over the different patterns in the Apprenticeship Patterns book, there have been many sections that made me feel like the authors were speaking directly to me and this pattern of enthusiasm is no exception.

The authors seemingly think that while being enthusiastic for your craft is an amazing thing, blindly expressing your enthusiasm can actually hurt an apprentice more than it can help them. With this in mind, it is important to curb your enthusiasm to an extent because you do not want to let the excitement you feel for the craft lessen because you don’t want to feel like a nuisance to others around you. As the authors put it, the excitement one feels is “a precious commodity” and I could not agree more.

The sense of discovery can be extraordinarily exciting. It is probable that individuals in well established teams are used to their routines, making discovery likely, but not exactly exciting. The authors mention that this sort of thing is predictable. Developers are always looking for better ways to getting “painful” work done more efficiently. This sounds more like searching for a sigh of relief rather than completing an exciting endeavor, and having with a hyper-passionate apprentice around probably makes tasks like these more grueling.

Finding a team that encourages your enthusiasm is important. An apprentice should be able to recognize a teams dynamic and see where appropriate to show their enthusiasm. If the team doesn’t seem like they would appreciate their apprentice’s ignorance, the authors recommend finding different strategies to nurture your need so that it does not jeopardize your opportunity to learn. However, if the team is open to bright and new fantasy driven ideas, the apprentice may offer new life to the team and boost morale.

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.

The White Belt

A sample is essentially a way to “attack” a trouble in a recursive way. It is at its strongest when its utilized productively repeatedly. You need to pick out a sample you use so you can talk about it barring repeating.

One sample that I located fascinating and had continually desired to practice however in no way may want to be “Rubbing Elbows”. It essentially talks about discovering any one type of like a mentor. I can align that to me working at Dynamic and having Javier and my coworker with me. Talking about fascinating stuff, studying from them, etc., being an apprentice. I have discovered that being an apprentice can lead you to locate new human beings and new approaches to examine stuff in a better, faster, and smarter way. Being humble and leaving your satisfaction apart is an ought to on this sample as you´ll be possibly getting to know that what you knew is wrong, or you´ll on occasion research from anyone youthful than you, as are my case. But at the end, the intention is to turn out to be a grasp and this may also take time. All this can relate to some other sample known as “The White Belt”, which essentially says that you must hold a beginner’s thinking regardless of your expertise. Wearing the white belt is essential as it will “foster a mindset of recognize and curiosity that opens up unexpected chances and solutions”.

Wearing the White Belt will maximize if you Unleash Your Enthusiasm. This sample talks about having keen human beings studying what they are involved in, in this case software program craftsmanship. It urges to ask the dumb questions. This is now not solely essential for the apprentice however for the group as it will supply curious surroundings stuffed with questions, discussions, etc. Again, this sample is intently intertwined with Expose Your Ignorance. This sample is unsafe in isolation as if you are afraid to make the dumb questions, it will generate a way of life the place mastering and failure are unacceptable.

Overall, if you can break this pattern down into 6 easy steps. We don’t realize it, but we tend to do these habits day to day without knowing:

  • Pattern: The White Belt
  • Context: You have competences in a programming language, have recognition and are competent in it.
  • Problem: Acquiring new skills seems harder. You stopped growing.
  • Solution: Wear your black belt-go back to not knowing anything and start over. Get a not knowing stance, unlearn what you learn, and you will open the door to more knowledge.
  • Action: Unlearn something-pick up a new paradigm, programming language, technology you’re not familiar with.
  • Connected Pattern: Breakable Toys Practice, Practice, Practice Reflect as you work

From the blog CS@Worcester – The Dive by gonzalezwsu22 and used with permission of the author. All other rights reserved by the author.