Apprenticeship Pattern – Sweep the Floor

This pattern really focused on the idea of your value as the new guy in a fresh team environment. Each party has no idea about the other’s techniques, patterns, thought processes, or communication abilities. While you’ll naturally get acclimated to the team through experience, it’s always a good technique to pick up some of the menail, but important work. It should show the team that you’re willing to pitch in, and if you take your time to make that menial work look stellar, then that’s an even better indicator of your talent and value to the team. It warns of becoming the team’s “gopher,” which I would say is a valid caveat; I guess I would prefer to think that most people are more professional than that.

For the majority of the pattern, I wholeheartedly agreed with this advice. It should garner comradery with your peers, and an improved understanding of the project – I would apply this to any sort of team effort in general, because if the members operate in good faith then it should promote the team to be a more effective unit (theoretically).  The only thing that I have a bit of a disagreement with is the assertion that you might be relegated to that menial work by default, after trying to sweep the floor for too long. I’d say as long as you engage with teammates about where they are on the project, ask questions, and actually learn from those conversations, you should be at least relatively qualified to work on more challenging tasks. On top of your understanding of the different project parts, I’m confident your peers will recognize your engagement and welcome you to cooperate with different or more challenging content.   

Finally, I can understand the sentiment that one won’t appreciate the bigger picture of the project, or would get uncomfortable attempting new types of work outside of their comfort zone. These are very different problems, and require a good amount of introspection to address in my opinion. I’m going to look at the referenced patterns near the bottom to see if he elaborates further.

I think the most important lesson I got from this pattern is not to make yourself useful initially, but make everything that you tinker with is as close to your best work as you can get it. Who knows who’ll be impressed?

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

Apprenticeship Patterns: Chapter 3 Part 3

A Different Road

You find yourself tired and bored of your work. You have some personal projects to advance your skills that keeps you busy, but you find yourself needing to take a break. To diverge from the road you are on to either just rest for a while or to just see where it goes. Your career as a software developer is not what ultimately defines you. A Different Road describes a scenario where the road you have been traveling on in your programming career is not the road you want to travel along anymore. You might wish to spend more time at home and with your family. You might desire to train for a marathon. You could buy a bit of land, build a barn and become a farmer.

The road of your software development career never truly ends until you decide to end it and even if you do, you can always start back on it again. Just like riding a bicycle you never really forget something that you practiced frequently. So, take the break that you need. Buy that farm and become a farmer. Your career is not what really defines you, and maybe whatever you try will need some kind of optimization that your skill-set can solve.

Ultimately this pattern speaks to the idea of breaking the stubborn mindset most people find themselves in. It’s this mindset of having a path and having no other choice. The path paid your bills and you enjoy it to a degree. It’s hard to accept the idea that this thing you have been spending your time on isn’t right for you. To align with the road analogy, the road you have been traveling has been well paved and barely has any traffic. As you travel further and further you might find it gets even easier and has even more lanes and less traffic. You might also find that this road has potholes and traffic has only gotten worse and worse.

Recognizing when that road isn’t worth traveling on is easy to think about, but harder to act on even when it’s right in front of you. But unlike the road analogy, your skills and motivation are not a car. You can’t sell it and lose it, it can’t be stolen from you, and even if you don’t use it for a while it doesn’t mean it can’t start back up again. The thing to take to heart is do what you want to do, but also stop doing the thing you don’t want to do just because it’s your career.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

CS 448 Post #6

I finished the patterns I wanted to write about from chapter 4 and moved on to chapter 5, Perpetual Learning. Like the last few chapters, I to post about the first pattern of the chapter and then one of the last ones, so this post will be about Expand your Bandwidth. The focus of the chapter is on the topic of the lifelong journey of learning that is taken when you are an apprentice transitioning into a journeyman, which is a concept that was brought up in the first chapter.

The first pattern is an effective start to the chapter, as it is about how you can move on from lower level problems to higher level ones, and how you can expand your learning ability. The solution given to the problem is to find different ways to learn more than you may not have been using before, such as blogs, books, and other online resources. Because of how much technology there is in the world today, there are plenty of ways to find information online, and use different avenues of learning. I have found a lot of information online by either looking things up when I had questions or issues, or just by reading blogs and articles. I have looked online plenty of times when I needed help on something, especially computer science projects. I would search based on the error codes I was getting and try different sites to see if I could find a solution that worked for me. Using online resources have been very helpful to me for my work related to computer science, along with some other courses and activities.

I agree with the last paragraph of the solution that talks about deciding when you should start expanding, because while it is good to have all this information to learn from, you still want time to put that learning to use at software craftsmanship. You want to make time to continue working and improving yourself so that everything you are reading about and learning is beneficial to your work. I like that this problem brought more attention to the topic of this being a lifelong journey with continuous learning and development, while pointing out potential problems with obsessing over learning.

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

The Long Road

For this week’s additional blog post, I have decided to look at the apprenticeship pattern “The Long Road”. In this chapter you, are aspiring to become a master software developer. However, your aspiration conflicts with what people expect from you. Conventional wisdom tells you to take the highest-paying job and the first promotion you can get your hands on, to stop programming and get onto more important work rather than slowly building up your skills. In this chapter it is advised that you should focus on the long-term. Value learning and long-term growth opportunities over salary and traditional notions of leadership. No one is so far ahead that you can’t match their skill level given the decades you will have to hone your craft. No business or technical domain is closed to you. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“This pattern is not for people aspiring to become CIOs or project managers, or filthy rich. Along the way, it is not unlikely that you will take on roles of power and responsibility or find yourself quite wealthy. However, these roles and benefits are not the main motivation of the successful apprentice—they are merely by-products of a lifelong journey. And rather than counting the days to retirement, the craftsman will willingly and joyfully work into her final decades. We don’t want to give the impression that everyone must follow a single road (see Draw Your Own Map) or that this is the right road for every software developer (see A Different Road). Some people leave development permanently and become executives, testers, salespeople, or project managers”. (Dave H. Hoover & Adewale Oshineye).

This chapter was an interesting one to read. I liked how it talked about how this is a unique profession, and you will be doing it for some time if the passion is there. I also liked how it talked about how you shouldn’t jump ship right away if there is an opportunity away from software development. I don’t think that this chapter will stick with me out in the real world, however. I feel as though this chapter is geared towards people with a mind set of already leaving this profession.

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

Find Mentor

There is always a good teacher behind a good student and a good engineer needs a good mentor who will help sharpen the skills and knowledge of that person. There is a saying “if you want to go fast, go alone. If you want to go far, go together”. Together with the mentorship, the engineer will become skilled at his job and has solid fundamental knowledge in this field.

By learning from the best, we learn how to become one of them. The apprenticeship will be supervised by a series of mentors who possess varying degrees of mastery. Every master used to be a student and no one is perfect. So keeping in mind that a master must be perfect is a misconception. It can be tempting to feel that way because they know so much more than we do. We must resist the temptation because we would not want to disillusion our mentor’s inevitable weaknesses.

The story about Dave finding his mentor shows us his journey. By sending out a random email to his mentor, Wyatt, he initially did not expect Wyatt’s response however Wyatt did. The effort was a payoff and he earned himself a mentor. What we could learn from this story is that we should not afraid to ask for help because sometimes what the other is waiting for is us asking.

Good mentors are not easy to find and not everyone is willing to open their arms and welcome us as amateurs. Plus, reaching out to someone that we do not know feels intimidating. However, the risk of being rejected is low but the payoff would be huge. Even though that person does not want to become our master but if we are consistent enough, what we could get back is a good friend. Besides taking in, passing along what we have learned from our mentors is one of the ways in which we can begin the transition to journeyman status.

How could we do that? One must wonder

Choose a tool, library, or community that has an active mailing list. Start small by signing up for the list but do not post any messages yet. Gradually, we will understand the values of the community and learn which of the subscribers are patient teachers. Seek out the members of this list the next time we see them and ask if they would be interested in providing us with some advice about the lesson they have learned. As I said above, we might get rejected but the valuable gift that one might earn is a good friend.

From the blog CS@Worcester – Hung Nguyen by hpnguyen27 and used with permission of the author. All other rights reserved by the author.

The White Belt

Summary:

The white belt pattern is about learning new things. We have mastered one language or area, now it is time to learn another because being an expert in one language or area does not allow us to grow and widen our capabilities. Pattern recognizes that sometimes despite working hard and giving our 100%, it does not lead to success. We need to recognize that different areas require different methods and approaches which may be drastically different than what we already know. Solution that pattern provides for us is that sometimes we need to clear our minds and start from zero.

Why this pattern?

Ever since freshman year I have been learning Java. First, we did intro to programming, then data structure and then testing in Java using Junit. Along the way I did a little bit of C, python for data analysis, and JavaScript, CSS, etc. for projects last semester and capstone. While working on this stuff I realized I kept using concepts from Java and messing up the code. Even while using mocha and chai testing framework, I kept using testing concepts of Junit. Due to this almost every time I had to revert the code, go read the proper documentation, come back and redo the code.

White belt pattern teaches us to re-assess our knowledge. It teaches us that as computer science students there is always knowledge out there, we can learn and help ourselves grow. As Elon Musk said, “Biggest mistake smart people make is believing that they are smart.” And to learn or acquire new knowledge and skills we need to start from square one. We cannot build a skyscraper on top of another skyscraper. We need to start below the earth, lay down a good foundation and then build on it.

White belt pattern also teaches us to be brave. I personally get nervous and anxious nowadays when it comes to learning a new language like python or JavaScript, software like docker or Kubernetes, services like Gitlab or AWS, etc. Pattern recognizes that sometimes it is painful to start from the bottom but tremendously crucial in accelerating the learning process. Mastering the new language or area is far more important than the short-term loss of productivity.

Where I disagree:

I might be nitpicking with the technicality of the word ‘unlearn’ but I do not think we need to unlearn what we know to learn new things. We do not need tear down a building to build another one.

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Retreat Into Competence

For this week’s blog post, I have decided to look at the apprenticeship pattern “retreat into competence”. The idea of this chapter is that you, a software developer, are beginning to realize how little you know, or that you have taken on a new challenge that is not working well in your favor, or your having problems with both. Due to you realizing how little you know you begin to get overwhelmed with your ignorance. The solution to this is to pull back and launch yourself like a stone from a catapult. You need to retreat or take some time away from your task to re collect yourself so you can come back to the task stronger than before. According to Dave H. Hoover & Adewale Oshineye, the authors of the book, they say on this,

“An apprenticeship is a roller-coaster ride. You will experience the thrill of learning new technologies, leveraging your knowledge and creativity to deliver value to your customers. But you will also experience the heart-in-your-throat terror of perceiving just how little you know compared to the craftsmen and experts you meet along the way. It can be overwhelming, particularly when a deadline is looming or when you’re dealing with production issues.” (Dave H. Hoover & Adewle Oshineye).

This pattern is most relevant to people who have stretched themselves to far thin to be able to concentrate on the task in front of them anymore. However, by pulling back you do have the chance to launch more forward than you have been able to before. Note however this pattern does come with risks as if you forget to launch back forward or don’t have the desire to there can be repercussions. I liked this chapter as I am a person who can get stretched thin very quickly and am not able to bring myself to walk away for a bit to recollect myself. I liked that this chapter talked about both the pros and the cons of using the pattern. This will be something that will stick with me while I’m in the field because I am prone to being stretched thin and will sit there and still try to figure out the problem for hours. By walking away for a bit, I will be able to launch forward.   

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

Sprint Retrospective 2

What worked well:

Creating branches and merge requests was smoother compared to previous sprint. We were communicating more through comment section of issues leading to better documentation on Gitlab. We were able to come up with a system for merge requests where two people who did not create the merge request would review the code or changes and then third person would write the comments indicating the author and merge the branch into main. We were able to evenly split work and issues between team members so one person was not burdened with one type of work. Even with delays and having to learn new language and concepts we were able to complete the sprint.

We also created issues for contacting AWS and IAM team members (links below). We contacted both team members via discord and tagged them to comment section of the issues that contained questions we had for them.

Personally:

Most important one is that I did not limit myself to issues only assigned to me, I was able to go over work done by my teammates and keep myself updated with new code as well as the flow of the project. API was completed so we had moved on to Backend. I created data file for cooking methods. This was difficult in its own way because we were not using MongoDB for this project. After researching backend already provided, I was able to figure out that we needed to use axios and USDA URL to call data which would return list of cooking methods or cooking methods based on its unique ID. I then wrote a main function to check if I was getting list of all cooking methods and it was successful.

Even with some setbacks, I was able to grasp the basic concepts of the new JavaScript testing framework – ‘mocha’ and JavaScript testing library ‘chai’. Since the data file and paths were completed, I created cooking method test file. With help from Jim this one completed in a week. Npm test verified that all test files were passing.

Things that did not work well:

The spring break and two consecutive cancelled classes pushed us back a little and we had a little problem getting back in sync. We were still having problems communicating and setting meetings outside of class time. Merge requests started to slow down; partly because of introductions of news framework and library – mocha and chai, verifying others work became difficult; partly because merge requests started to fail due illegal naming conventions in commits. Issue names also needed to be more descriptive with more details in sub descriptions. Issues were also not properly linked to their respective epics. We were stuck in a lot of places where we needed help from professor, and we should have been more pro-active in that situation.

We also did not hear back from the IAM and AWS team.

Personally:

I wasted a lot of time researching and reading documentation on my own instead of working with my team or asking help from professor. Also lost a lot of time figuring out how to run npm and npm test. My merge requests kept failing I was not able to figure out the reason until Dahwal pointed out that I was not using conventional commits. I kept up with other people’s code but did not get an opportunity to write an endpoint myself.

Links to some issues:

Start conversation with IAM team

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/14

Start conversation with AWS team

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/15

Test file for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/general/-/issues/2

Create Data File for Cooking Methods

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeper-newbackend/-/issues/4

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 1

What worked well:

Creating issues was as expected; We were able to have open communication within the team and we were helping each other in how to create issues, connect them with epics, assigning team member for work and for reviewing.

We were helping each other figure out using git again. Dahwal introduced me to Github Desktop application which made the whole process of adding files, committing branch, push branch, creating merge requests, creating new branch and switching branches fairly simple.

Personally:

I had to revise scrum techniques and how to use the scrum board but with the help of team quickly grasped the concept again. I was quickly able to assign issue to myself in the API part of the project (links to the issues below). Most of the code was very similar to homework project from last semester therefore was easier to complete. I created src folder with path, responses and schema subfolders. I created schemas for view, product, shelflife and EvoError. I had to do good amount of research on OpenAPI and also on regex for patterns and format for different schemas within the schemas like min, max, temp, etc.

What didn’t work so well:

Figuring out workings of git took longer than expected. Brushing up on scrum and trying to use scrum boards proved harder than expected. Communication in the beginning was limited to only class time, which proved to be a big obstacle in this sprint. We also ran into a lot of problems with merge request, where they were unsuccessful due to being behind on commits, improper branch creation and not having a clean working tree in general.

Personally:

I had a lot of time used in git bash until Dahwal showed me GitHub Desktop application which really helped me save a lot of time. I had to do fair amount of reading of OpenAPI documentation in trying to figure out proper patterns and formats and even after that I needed to ask help from team members and professor. I also confined myself to only issues related to schemas and did not get opportunity to create paths for the API.

Improvements:

The most important issue we need to deal with is communication. We need to meet outside class time or at least meet via discord in video calls. We need to attach issues created to appropriate epics and understand how weights work and its assignment. We also need to communicate difficulties or problems we faced regarding issues in the comment thread sections instead of only using discord. We also need to come up with a system of approvals and merge requests so most of or class time is not spent approving and merging requests.

Personally:

I need to communicate with team members working on issues similar to mine so that we can set some conventions. For example, my schemas, branches, commits and merge request had slightly different naming convention than others. I also need to keep up with emails, discord messages and other notifications and respond in timely manner. Most importantly I need to make an effort to keep myself updated with issues I am not assigned to and keep up with the flow of code.

Links to some issues:

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/1

EvoError

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/foodkeeperapi/-/issues/2

Product Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/10

View Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/12

Shelflife Schema

https://gitlab.com/LibreFoodPantry/common-services/foodkeeper/food-keeper-backend/-/issues/11

From the blog CS@worcester – Towards Tech by murtazan and used with permission of the author. All other rights reserved by the author.

Sprint Retrospective 3

This last sprint I feel as though I went backwards. I am not too happy with my results. I spent the majority of my time working on semantic-release for the backend, frontend, and api branches, which I was only able to partially complete. Reflecting on this sprint, I should have absolutely given up and started work on something else. If I had given up someone else might have tried, and one of my team members might have had a different way of approaching the problem and solved it. If I were to look at this optimistically, its good that I messed up in class rather than in a real job. I was also able to write my findings in the issues I was working on so that the next student to take up the issue won’t be starting from scratch.

When working on the backend and api branches I was getting errors that did not make sense to me. I believe that there is something wrong with the repositories since that should be the only difference between the backend and api. I communicated this in my issue descriptions.

If I had to say something good about myself I really do like my issue descriptions. I am not sure if it will be helpful for the next students, but I really hope it is. I even tried to suggest possible solutions I was thinking of. I knew that I had to try hard to write good documentation because when we inherited this project from the previous group, there was little documentation for us to go off.

Something I think my team could have done better is to check in with each other more often. Sometimes I did not know what my teammates were working on, which is something you never want when working in agile production development. We slacked off on our daily standup meetings; if we didn’t I could have communicated my struggle with semantic-release. We could have made more of an effort to perform out standup meetings correctly, and I know that would have definitely helped me, and probably others as well.

Something that I could have done better relates to communication as well; I could have asked for help. I am not sure why, but throughout my struggles with semantic-release I did not ask my group for help at all. I did ask other people, but if I had gone to my group they would have known about my problem, been thinking about solutions, and they would care about fixing it since it directly relates to them. For whatever reason I kept believing that I could solve it myself since I got it working on the frontend, but now I realize this was a mistake.

I am not going to lie to myself; I did worse this sprint compared to sprint two. I think it is important to look at your own work objectively and critically in order to improve. Like I said before, I am grateful for this learning experience while still in college. I know that an employer will expect me to make mistakes, but I am not the kind of person to be satisfied producing sub-par products. I will do my best to learn from this experience and try to not repeat the same mistakes in the future.

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