Expose Your Ignorance

Next week, my second Sprint will start. My team worked really well last Sprint that we met all the initial objectives; however, the context was we reimplemented something that we’ve already known or heard about, which only needs a bit more searching in order to fully commit the work. This second Sprint we are going to have lots more “abstract” topics, materials that we weren’t familiar with, so I expect we might get frustrated, overwhelmed when we come to it.

This situation might somewhat be similar to what I’ve read in the “Expose Your Ignorance” section, the only difference is that I’m not in a nine to five working environment. Per description from the book, we have been brought in some projects that we are unfamiliar with some of the required technologies; but team members believe that we can deliver because we have a deep understanding of the business domain or some other aspect of the technology stack being used in a team, or perhaps we are the only person available to do the job. In my view, learning and implementing what the team needs while carrying their expectations is difficult, especially when it is something that we have no experience in.

Finding myself falling into this issue in no time, I might consider taking the solution written in the book which is to show my teammates that the learning process is part of delivering software. Therefore, knowing how to learn the technology effectively is important because I should know which part of my current project will need this and go straight to documentation with relevant information on it. Furthermore, asking questions, instead of hiding our issues, exposes it to everyone in the team because no one will be annoyed when we show them what we cannot do, instead, not telling them that you are having problems is what keeps the team behind.

Luckily, I consider myself a bit “figurative” when it comes to asking questions since I don’t mind asking anything that I didn’t understand. Compared to myself 3 years ago, it’s a huge difference as I was that shy guy hiding my weaknesses, I find learning is much more efficient when I can ask everyone what I don’t know, of course, after a period of time thinking and testing and implementing. Having questions is a good practice, but it doesn’t mean that we should ask without already researching it.

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.

Sprint 1 Retrospective

As we just completed our first sprint, my overall thought is that we did very well, and we have learned from our mistakes. One of the things we did well was that we spit up the work evenly. Everybody had an issue they were working on at all times. And as a group, we agreed that we each did a fair amount of the workload. Another thing that went well is that we completed all of the issues we set out to, from the beginning. Another thing that went well was the merging workflow. With the exception of the first week of development, we were able to complete issues, and merge to main with minimal merge conflicts. How we were able to do this, was making sure we had the most current version of main, before commiting, and making sure to stay within the scope of the issue while coding. Overall I am pleased with our performace, but there are some things that did not go as well, and could be improved upon.

One thing that did not go as well was our communication in GitLab. We were mostly discussing our issue in person. So the discussion within the issue descriptions were not showing the entire story of an issue’s development. We were also relying too heavily on discord, instead of using GitLab comments. On a related note, many of our issues in GitLab were not named clearly. We also had issues that were created in the wrong project. Our naming conventions in general need to be standardized moving forward. We can also improve on only having one person working on an issue at a time. There are a few things we can improve on outside of GitLab communication.

One unrelated thing we can improve on is keeping our stand up meetings to the alloted 15 minutes. I know that this is very important in the real world. We can achieve this by staying on topic, and by not interrupting each other. As a group we have discussed how to improve moving forward. But in order to work effectively, I also need to consider how to improve as an individual.

One thing I can improve upon is staying on task when working on issues. In independent projects, or larger academic projects I did not use issue based Scrum development. So I could jump from one method, class, or subproject to the next, as I realized I would need them. This is not an effective strategy for large, group based development work. During our first week, I had to review a yaml schema, and I decided to validate the yaml, using node modules. I ended up spending an hour doing work that I was not assigned to, and made changes to the branch outside of the issue. This was an important lesson for me, and something I will avoid moving forward.

Issues completed:

Add Standard Files to API repository: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/3

Add Paths for CookingMethods and CookingTips: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/16

Test Class Template for Backend: https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/19

The issue that stood out the most to me was creating the Test Class template for the Backend. It was really interesting to learn about Unit testing in node. We are using J Unit in CS443. So it helped me solidify that knowledge to see unit tests written in a different programming language.

From the blog CS@Worcester – Jim Spisto by jspisto and used with permission of the author. All other rights reserved by the author.

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.