Monthly Archives: February 2022

Unleash your Enthusiasm Learning Pattern

Being a beginner have very few perks so we must utilize them to their utmost extent. The authors make the point of arguing that the new guy has the ability to bring new life into a team that could perhaps have gone stale or that maybe could be improved by such addition. I must confess this learning pattern, or I would better describe it by calling it a resilience building pattern, is a pattern that can help with confidence building and narrowing the aim for purpose. When working with a team in an environment that is new, you don’t only confront with your team’s expectations of what you can do, but also with your own expectations on what you think you should be able to contribute. This ties well with something I think every student struggles with and may carry over to the professional struggles of transition called impostor syndrome.

I have read about impostor syndrome before repeatedly in quorums in which professional developers as well as other professionals talk about it or answer questions about it. I should say that the mere volume in which these topics appear in the wild is a telltale of what should be expected in the first few years of a developer. As a student we easily fall trapped by the illusion of being undeserving, when we grapple with the idea that we have much to learn still. Sometimes it is true that we are unprepared to complete a task or that some of the background knowledge needed for the task was under evaluated in the past and have become a barrier to present issues. But even on the eve of such failures we must not succumb to the temptation of self-assigning ourselves with the impostor role. The imposter would not put in the years of instruction and struggle to become the product of these experiences.

There are little cautionary tales in this pattern as well. This is something I think the authors were very smart to add. In the wild dealing with real world social interaction there can be no one fits all solution. Feeling out group dynamics while applying these tactics is very important. We all have the tendency to grow a little cynical over time so we shouldn’t be judging too harshly an individual or group’s receptivity. If we use just the right mix of the appropriate beginner enthusiasm, we can feel like we belong, or even better, like we have something to add.

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

Expose Your Ignorance

Honesty

People that hire you to work as a software developer rely on you to know what you’re doing. Recently graduates have no prior knowledge in the subject matter. What is the best way to start a career? Well, Expose your Ignorance by Apprenticeship Patterns by Dave Hoover and Adewale Oshineye have shared light on how these scenarios frequently happen in the real world. This chapter Gives guidance and ways to overcome those situations when it becomes absolute.

It’s important to know who you are. Not only knowing you are on a personal level but most importantly in your ability to learn and adapt to a new environment. This book is enjoyable, and all the patterns are great to read and give a deep dive into what we think we are comparing who we are. Reading a quote from Dave Hoover about A “NOT KNOWING” STANCE.” Explaining the difficulties as a professional and trained to be an expert, sometimes can find rabbit holes that require a different state of mind and honesty. There is a phrase from Dave quote that resonates with me is when he said “Your instincts tell you to hide your ignorance, to feign expert knowledge, but this only stunts your growth and inhibits the work you are trying to accomplish.” How often do we find ourselves in this situation? I can personally talk for myself. I have been exposed in the past for not knowing who I was but, rather, what I wanted to become. Doesn’t liking something such as to perform on a task does not make you qualify for something else or vice versa because you want to work on some projects does not make you expert knowledge. 

The pattern “Expose you Ignorance” is one of the most important patterns because it gives us a way of rethinking about ourselves. Sometimes we often try to impress the product owners, shareholders, clients, or the team members that we work within by saying things to please them instead of being honest. Knowing who you are can lead to honesty, will eventually set a framework for you in the future. People will respect you, they will want to be in your team, they will probably learn from just helping you and creating a better environment.

https://www.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch02.html#expose_your_ignorance

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

Apprenticeship Pattern “Kindred Spirits”

For this week’s blog post, I decided to review a chapter about a topic that I have thought about a lot. The topic that I am reviewing this week is the importance of mentors and finding kindred spirits. For those of you who does not know what a kindred spirit is, a kindred spirit is someone who shares your interests or attitude about a topic. I find this topic interesting because it is a topic that I have thought a lot about. In the past, when I was a Mathematics major, I felt like I had found a lot of kindred spirits. I used to spend a lot of time in the math lab and center solving math problems with these people. When I think back about those days, I view it as some of my most productive years in my undergraduate career. I used to be very studious and was very motivated to be in school. As people within the group graduated one by one, I found myself at a loss and became very unmotivated. This is why I found the first segment of the section interesting because it talks about the importance of finding kindred spirits in order to stay motivated. One line from that section that stuck to me was the line about the impact of having a relationship with a kindred spirit. Some relationships may be short but may make a major impact in a person’s life. This was how I felt about the relationships I formed when I was a math major. The time I spent with those people may have been brief but the time we did spend together did feel meaningful and I would not have had it any other way. One thing this chapter has changed is how I thought finding new kindred spirits. After the last of the group graduated, I tried finding other kindred spirits in those who were still there, but I did not feel that same connection. So, I have always tried finding kindred spirits by physical vicinity. I have always thought of myself as a follower so one thing that the chapter brought up that I never really thought is why don’t I just a start a group of my own. This thought was something that went over my head and is something I think I may consider some time in the future.

Another topic that the chapter talked about is the topic of group thought. I think this is a very relative issue that needs to be addressed when thinking about creating a group and I think there should be precautions in place to ensure that the group can still have healthy debates.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Breakable Toys

                We all grew up with a favorite toy at some point or another weather that be a doll, a car, bike, computer, lego, etc. At one point or another they may have broken in some way and when that happened you could either throw it out and be done with it or attempt to fix it or find another use for it. This is exactly the idea behind the breakable toy pattern described in ‘Apprenticeship Patterns’. As a software craftsman many workplaces will leave little room for failure and thus little room to learn from those failures. Many of us in today’s workplace are expected to know how to use tools given to us without time to experiment and fail to use those tools.

This aversion to failure often stunts the learning process in many people as failure is one of the best teachers there is. Being able to safely fail in a private space where you can learn from and fix your mistakes at your own pace is healthy to the learning experience. Breakable toys are essentially an implementation of a commonly used tool that you may be inexperienced with. This toy can be simple as long as it applies to your work, your life, and is pleasing to work on. As Hoover and Oshineye describe in ‘Apprenticeship Patterns’ you can create anything from a wiki page, to games, to even a calendar or even blogging software.

Creating a breakable piece of software that won’t affect anyone should it break gives you the opportunity to experiment without worrying about failure while reinforcing what you do or do not know about a certain tool, giving you a sandbox to play with to deepen your knowledge of said tool. Our toolsets are always changing as software craftsmen and being able to keep up with this quickly evolving trade is arguably the most important part of being a software craftsmen. I whole heartedly believe this to be a great place to create breakable toys as I have with my own website.

If you are turning up few ideas of what you can do then consider the idea left at the end of this chapter by Hoover and Oshineye. Create a wiki page for yourself, it can be about whatever you want and start as simple as being able to edit plane text documents. Over time as you learn more about Web Design, HTML, and other tools involved you may add features that will distinguish it from other wiki pages. Keep this breakable toy or create new ones as you learn, so long as you allow yourself to fail you can take advantage of it and enrich your own experience.

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Craftsmanship Log #2 – Recording What I Learn

I feel the need to underline that the patterns discussed in the book “Apprenticeship Patterns” do not exist in a vacuum, though conceptually they can be considered as independent concepts. In fact, it is possible, in one way or another, to utilize multiple apprenticeship patterns at once without realizing it. In my latest post, I briefly went over the apprenticeship pattern related to a programmer’s first language, aptly named as “Your First Language”. Looking back on my learning approach to C (my first programming language), I notice that my learning process included a combination of this pattern with other patterns named “Record What You Learn” and “Breakable Toys”, which former pattern I mentioned briefly in my first post about the book “Apprenticeship Patterns”.

As the name of the pattern suggests, “Record What You Learn” is a pattern that is mean to address a software developer’s (or a learner’s, regardless of the subject) potential negligence of making sure to keep a record of the concept’s that they may encounter during the learning process. Such negligence brings the risk of the developer losing important knowledge, thus facing issues when they encounter a problem, they need to solve for which they have an extremely vague idea, at best, of how to find and implement solutions.  In this case, a helpful solution to this problem is for the learner to begin developing and maintain the habit of keeping records of anything that they learn as they learn it, either on a blog or wiki. However, it is important for anyone who records their learning process in such a way to make sure that they actually utilize what they record continuously rather than simply dump their thoughts in a blog post and immediately forget what they were supposed to be learning in the first place.

In my own experience, recording what I learn either in the way of making private journals or code repositories has helped me in my learning process tremendously. On one hand, keeping an organized archive of concepts I have learnt, along with specific sources and examples (not too different from this blog), has made it easier for me to quickly go back and refresh myself on knowledge that I feel I can use for problem-solving. Moreover, going through the process of writing a journal of the things I learn helps me internalize new concepts much better, especially with respect to code. Perhaps this pattern is especially helpful for people like me, who need to write down what they learn since it is a much more helpful way of learning.  

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

Apprenticeship Patterns: The White Belt

Christian Shadis

2/26/2022

In the apprenticeship pattern The White Belt, Hoover and Oshineye explore the importance of maintaining a beginner’s mindset even when already a subject matter expert. They attribute this largely to creativity and open mindedness in problem solving: a programmer who is an expert in Language A should act as though they are a complete beginner in Language B to avoid their prior knowledge restricting them from learning all techniques and conventions of the new language.

The whole pattern seems counterintuitive at first, but a small example illustrates the concept more clearly. If a Java programmer wanted to join two lists together in Python, but by only using their Java knowledge, their solution would undoubtedly be far more complicated than a simple list comprehension that Python allows. Putting aside prior knowledge in favor of re-learning problem solving methods would allow that same programmer to utilize Python’s list comprehensions. In a more general sense, by ‘taking off the black belt’ and ‘putting on the white belt’, a developer can learn best practices and technically efficient problem-solving techniques in any language, which will further bolster their overall programming skills and employability.

This pattern also shifted my perspective toward my education so far at Worcester State. Over the past few years, I had found myself frustrated with the methodology of the Computer Science department, which I believe is rooted in giving students exposure to as many elements in the software development world as possible. My frustration lied in the fact that we, for the most part, didn’t do very deep dives on any language or technology. After reading this pattern though, I realize this approach was about showing us as many different things as possible to prepare us to do just what this pattern teaches: learn new technologies and languages as your career develops, rather than becoming a subject matter expert and looking at the rest of your development career through the lens of that subject.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern while I continue to learn Object-Oriented Programming languages, especially Python. Most of my OOP code has been written in Java, yet I consider myself fluent in Python. This is a clear example of letting my knowledge in Java prevent me from re-learning object-oriented programming in Python, which would harm my performance in a Python assessment or interview. In this case, and throughout my career, I will make the decision to set aside my knowledge to re-learn the fundamentals through a separate lens to enrich my understanding of the subject.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Emptying the Cup. In Apprenticeship patterns: Guidance for the aspiring software craftsman. O’Reilly.

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

First Sprint Retrospective

Christian Shadis

2/26/2022

This past week, my development team in my Software Development capstone completed our first Scrum sprint for the semester and recently had our Sprint Retrospective meeting. This was my first exposure to an Agile development environment, and thus I have many thoughts about the experience. In this post I will review my own contributions to the project, reflect on the team dynamics, and critique my own contributions and suggest strategies to improve my work in the next sprint.

The sprint got off to a rocky start since none of the six of us had worked in a Scrum environment, nor worked with Gitlab issues and boards, but we settled in quickly enough to complete nearly all the work we set out to for the three-week period. The most difficulty we had as a team was with the process of branching and merging – we had multiple instances of changes being made on main instead of in the branch and had a surplus of merge conflicts to deal with due to pushing outdated code to the main branch. Our difficulties can be attributed to lack of experience, but as a team we were able to overcome these difficulties quickly, and by the end of the semester had a much smoother process in place for merging code into the main branch.

As a team we communicated efficiently and were able to help each other with issues when needed. We divided work evenly such that no team member worked significantly more or less than any other member. We were also effective in the work itself, as nearly every issue agreed upon during the Sprint Planning meeting was completed.

The team has agreed to implement numerous changes in our workflow for the upcoming sprint. We have re-structured our merging process to make updating the main branch as seamless as possible: instead of approving changes to the code during class time, we will instead transition to having two team members approve any merge request before merging it. This will help prevent logjams of merge requests and will allow us to better utilize our in-class meetings. We also agreed to work on improving the efficiency of our standup meetings. In the previous sprint, we would often get sidetracked during the standup meetings and talk about code that was written or have discussion about implementation – we have resolved to instead keep the standup meeting as concise and focused as possible and hold all other discussions afterward.

I contributed to the team by creating the Documentation repository in the Foodkeeper group and populating it with the necessary files (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/1), by creating the index file in the API repository (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/24), and by creating the schema for the Category of a data point (https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/6). I also wrote several files of code for Issue 17, which wound up not being implemented (see below for further explanation).

There are several improvements I can make as an individual as well. I noticed my shortcomings in keeping the issue boards organized: I often forgot to move issues between labels, and at one point unassigned myself to an issue I had already completed yet not merged (Issue 17 mentioned above), causing a waste of time when another team member picked up and re-completed the issue. Keeping my own issues organized, properly labeled, and assigned is important to the overall function of the team.

I would consider the sprint successful overall. We had some rough patches in the beginning, but our team excelled at addressing problems as they came up. We are also producing work that all of us can be proud of. I am looking forward to the next sprint and further improving my capability of working in an agile development team.

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

Concrete Skills Pattern

For this week’s apprenticeship pattern, I did a reading on “Concrete Skills”. Concrete skills are a pattern that I feel like I am currently experiencing. Concrete skills is about acquiring and maintaining skills that enables you to be ‘trusted’ by companies so they’re more likely to hire you. Concrete skills are supposed to reassure future team members that you are capable of doing the tasks that would be assigned by you and wouldn’t need to be babysat during the process. These types of skills are considered to be the basic of any programing language or knowledge. These are usually tested when you are being interviewed by current software engineers at a company that are simply just testing your knowledge. A great solution to anyone who has this problem is to work on side projects and casually review how basic functions work in your chosen language.

My initial reaction after reading this pattern is that it is a reflection of what I am currently experiencing. Since I have limited experience in the professional field of software engineering, I am currently requiring hiring managers “to take a leap of faith” in choosing me to work at their company, as the book says. The reading was quite interesting and very useful. Interesting because I can relate to what it is talking about and useful because it helps me with my current job hunt and figuring out ways to tackle this issue. Even before reading this pattern, I’ve been trying to practice more concrete skills and building side projects that will help me with the journey of becoming a software engineer.

The pattern has not changed the way how I view my profession because I already had an idea of how HR and the process works. The hard part of any job is getting selected for the interview process and for me, since I have no real type of internships, it is much harder. I do however have that I’ve worked in companies with good positions but they’re not entirely “software engineering” related. Therefore, I am constantly practicing my skills and working on side projects that I can showcase on my resume and be able to answer questions that are thrown at me if I were to get selected for an interview.

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

The White Belt

For this week’s blog post, I have decided to look at the apprenticeship pattern “The White Belt”. This chapter talks about how you have gained a deep understanding of your first language and have become confident. However, you are struggling to learn new things and it has become more difficult to learn new skills. The main idea of this chapter is to wear a white belt and forget everything you have been taught thus far and learn from someone with a blackbelt. Dave H. Hoover & Adewale Oshineye, the authors of the book, say on this, “Wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way”. (Dave H. Hoover & Adewale Oshineye). As discussed in the text, when you take this approach in learning some new material this will accelerate your learning process tremendously. When you take this step towards ignorance, you can express yourself idiomatically and gain a far better understanding of your new knowledge. This way when you consider both what you learned and your old knowledge you have developed productive insights in both fields.

What I found interesting about this pattern was that it’s like what we learned in the chapter “Your First Language”. In that chapter it mentioned finding a main language but not forgetting about what you learned in the past. With this chapter we can apply both knowledges and expand on our main language. By being able to take a step back you can develop your skills in a way that I didn’t eve think about. Now knowing this knowledge, it has made me rec consider what I would be doing out in the real world at my profession. If presented with a problem that I have no past knowledge about, instead of trying to guess what the solution to it would be I can ask someone who knows, a.k.a a blackbelt, and expand my knowledge of the subject. With everything I Have learned I both chapters, this gets me excited to go out into the world and gain more knowledge to become a “blackbelt”.

Book: Apprenticeship Patterns, Dave H. Hoover & Adewale Oshineye

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this sprint I was working with a team of 6 individuals. With this group we decided to split into two teams, 3 people to work on the frontend and 3 people to work on the backend. During this sprint I was a part of the team working on the frontend.  Throughout the duration of the sprint, I found that this team dynamic worked well. This allowed us to divide up the work and conquer it as two individual teams. I feel if we were all working together and grabbing any task, this would have caused mass confusion and the likely hood of less work getting done. From a frontend perspective, I think having 3 team members to work on the frontend was the correct amount. I say this because in our repository we were working on mainly three different files. These files were our App.vue, id-input.vue, and register-form.vue. Due to this coincidence, we were able to give everyone a separate file to mainly work on.

In this sprint I only could find one thing that didn’t work well. This was assigning roles to current issues in the sprint backlog. With assigning roles, I found that a lot of old issues were left over from the previous class that were still assigned to them. I found this frustrating at first due to me not know my teams profile pictures and thinking they had assigned themselves to that role. Once I figured out their profile pictures that part of the issue subsided. However, I found that with my team as well every once and a while someone would assign themselves to an issue that I had already begun working on. This kind of issue could cause issues later down the road because if they were to push code like mine but different at the same time as me, it could affect the code.

Something that we could improve on as a team is switching up the team dynamic. I only say this as I know that the backend team has much more work to do then the frontend team. When we first started the sprint, the frontend was in okay shape. This being that we had files that were somewhat working, and we had issues that we could easily identify. With the backend however, they were given files and containers that were not working at all. At the end of this sprint the frontend team was able to have get all forms working for the most part and able to set up CSS styles. With the backend team they made great strides in getting the backend to work, but they still have got a lot on the product backlog. If we were to switch the team dynamic to 2 on frontend and 4 on the backend, I believe this would give the extra manpower to get a fully functional backend with rabbit mq.

From an individual perspective I believe I could improve on my commits. I am very prone to committing a lot of non-important commits. I feel as though I should try in this sprint to try and limit how many commits I send to the branch before my issues from the sprint backlog have been finished.

Sprint Commits:

Add Frontend image to Docker Compose: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/1edd0dd2761c6eca6b2658ac84b8ad9a9a0a6c8f

Update form on main branch: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b

Form update to newer form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/ca34a3f3d27dc958472fa556d4ab210d0afa656b & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/3d6e549feb1088c5704509b31d62a2d4d6f5a9e0

Fixed Submit Button on Register Form: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/78c425fbaa3a2db3dafb4ba383e31aeb86709c7b

Allow Data communication between Register-Form.vue and id-input.vue: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/93497903597726c44fb8aa5a662d8fdad0343151 & https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/9ccc74f09d3e5687b06d6752a0efcb17b90a81a7

Changed idnum from this.props to method call upon form creation: https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/131ab93c5f000b742052db31d0ff5aba95772223

From the blog CS@worcester – Michale Friedrich by mikefriedrich1 and used with permission of the author. All other rights reserved by the author.