Monthly Archives: April 2022

Apprenticeship Patterns: Stay in the Trenches

Christian Shadis

In the apprenticeship pattern Stay in the Trenches, Hoover and Oshineye explore the importance of maintaining a development position in the face of success and the opportunity to progress into management. This is a very important topic, since many developers (and employees of other types too) have their careers reach stagnation once they make the leap into management due to their misconceptions about career progression.

This pattern is counterintuitive to me, as historically I have considered management positions to be the goal of any employee, and the thought of turning down a promotion would not seem to propel a career forward. Upon further reflection, the benefits of the pattern are more apparent. If a developer commits to remaining a developer throughout their career, they remove limitations on their potential growth as a developer and employee. They will continue to grow and evolve with the industry and become masters of their craft. Conversely, a developer who accepts a promotion into management may stagnate quickly. Management is a completely different occupation than development, and the recently promoted manager may find their skill set does not transfer. Similarly, the organization may not have much room for progression beyond middle management.

Remaining in a development position instead allows the programmer to spend their entire career mastering their development skills, increasing their capabilities and qualifications for more intense, higher-paid, senior-level programming positions. The programmer can advance and progress with development-based promotions, but staying out of management lends a significant advantage for attaining more prestigious programming jobs in the future.

I hope to use this pattern throughout my career. Once I had aspirations of progressing through management positions until I am high up at a large company, but progressing through management positions won’t be possible by virtue of programming skills – instead, a more attractive plan is to progress through the levels of development and engineering to finally land at a senior position. Not only will this maximize my potential as a coder, but remaining in a position interesting to me instead of stagnating in a more boring occupation will maximize my job satisfaction.

Reference:

Hoover, D. H., & Oshineye, A. (2010). Walking the Long Road. 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.

Sprint Retrospective 2

For this sprint we did much better as a group. Communication improved and we are comfortable with the project now. After the first sprint I was worried about how we would perform but now I am much more confidant in our abilities. I am excited for what we will achieve during the upcoming sprint.

Over this past sprint we have gotten the backend to work, added commitlint, updated config files and pipelines, and learned how to use RabbitMQ. I personally did the commitlint for the backend, frontend, and API projects, and worked on the pipeline. I am happy about how everything turned out, and I feel like I learned a lot about how commitlint and the gitlab pipeline works. When working on commitlint I decided it would be cleaner to work in a separate branch since I needed to push to gitlab in order to test my work. I am happy about how it worked in the frontend project, but in the backend I accidentally worked on the main branch instead of the commitlint branch. When working in the future I must always be aware of which branch I am working on and review my work before pushing, since you should not orphan public commits.

When working on the frontend I ran into a problem that was not present for the other projects. I found a solution on stackoverflow and made a comment about it. I am not sure that this is the best place to explain myself since I wonder if people will be able to find my comment in the future.

One thing that I am happy about is that I have increased my workload. I still want to do more in the future, but I am happy that I am doing more to help my group out. I think this is something we could all work on as a group. Most of our work is done in class which is ok, but we would get much more done if we all worked outside of class. One thing I think we could do to improve this is to schedule out-of-class work sessions where we would work for a few hours.

One thing that I think didn’t go well was branching. We made many branches this past sprint, and I do not think we used them properly. In my case, I made a useless branch since I did not use it at all. I feel as though using many branches, while useful, can contribute to confusion with our team and future teams. I do think we should be branching, but I feel as though we could do it better.

Overall, I am happy with the progress we are making. I am glad that the backend works finally, and I am glad that the gitlab project is coming along. I am excited for the upcoming sprint since we have almost finished refactoring, and we can begin working on new features. I am concerned about making new features since I do not have any ideas as to what to do, but whatever we decide to do as a group will be fun to work on.

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

Apprenticeship Patterns: Breakable Toys

Christian Shadis

In the apprenticeship pattern Breakable Toys, Hoover and Oshineye explore the effectiveness of learning through failure, and the dynamics of doing so in a workplace where failure may not be embraced. Essentially, they advise the developer to work on projects on their own time with the important distinction that they can safely develop without harming any other developers with breaking changes. They refer to these projects as ‘Toys’ because the developer should work on projects they find interesting or fun, which will make them more motivated to continue working on it.

This pattern, unlike some others in the book, is perfectly intuitive. “Practice makes perfect” is one of the more well-known clichés we echo, and this pattern is based on constant practice. In fact, much of the information I’ve learned about programming thus far has come from troubleshooting code I’ve written and figuring out why it doesn’t work. The only problem with constantly practicing a trade menially is a blurring of the lines between work and free time; however, developing projects of personal interest to the developer would make the practice far more engaging and feel less like work.

This pattern is not a particularly difficult one to implement, as developers are likely to build personal projects simply because they enjoy development. Yet if a developer uses their skills to build something they don’t care about, it only feels like work – instead, working on building ‘Toys’ feels more recreational and sustainable to implement in free time. To effectively use this strategy, the developer must emphasize the breakability of what they build and focus on using failures to improve both the project and their underlying development skills.

I hope to use this pattern throughout my career, but more specifically I plan to implement this pattern throughout my first development job. I will be exposed to many new technologies and frameworks in my new position. Using these technologies only at work would limit my comprehension of them. Instead, utilizing these new technologies in the failure-friendly environment of personal development projects will maximize my improvement as a developer.

Reference: Hoover, D. H., & Oshineye, A. (2010). Perpetual Learning. 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.

Sprint Retrospective #1

This blog post is about the sprint 1 retrospective. This is our first sprint as a third group in the Cs-448 class. The topic of the project that we will be working on, which was presented to us as a team is about LibreFood Pantry AWS Deployment. In the first moment, the professor sent an email as a beginning to present us that what group we would be in, who would be the members of our group, and most importantly what would be the project we would work on. That was our first familiarization with our team members. Working as a group for one project, I took it as a very positive thing. I really like when I share ideas with other people about a specific topic, and I also like when I take ideas from others from where I can learn too.

The first thing we as a team did, was that we first created the issues. After that, we shared the roles on what we will be working on. We had very good communication as a team and we also were really clear about the project. The issues I worked on were the Deployment Option for EKS and the other issue was research I did about the Microservices Architecture.

These were the two issues I worked on. In the first issue I had about deploying options for EKS, I tried to give some tips about deploying applications Amazon EKS in the cloud, also I tried to determine which deployment options for EKS we should be using. For my second issue, I mostly did research on what is Microservice Architecture, when, and how to use it, and most importantly the benefits that microservices have.

Working as a team on one project like this, looked like a little challenge thing for me. But at the same time, it helped me improve my acknowledgments. We as a team on this first sprint tried to share ideas, and give our contributions regarding the issues that we created. We had some struggles mabey in the first days we started working on the issues, but got the point. And I think that overall we have done a very good job as a team. We also tried to find other communication ways, like writing for any question or suggestion through discord, and also we have met each other virtually through zoom meetings. These helped us a lot as a team too. And hope that all other sprints will work better than we start.

The issues I worked on:

Deployment Option for EKS: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/15

Research Microservices architecture: https://gitlab.com/LibreFoodPantry/common-services/aws-deployment/general/-/issues/14

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

“Nurture Your Passion”

Passion is the devotion we invest in of our interest, could be a hobby, sport, or even a profession. Upon reading the book “Apprenticeship Patterns”. There are multiple chapters that are divided up into 35 patterns to give a breakdown of the broad idea of being a craftsman. For example, I have read chapter 3 “Walking the Long Road”, towards the pattern of “Nurture your Passion”. This pattern entails about keeping a strong leveled mentality. Going into our career field as a software developer which the environment would cause an impact on one’s passion. This pattern gives us an idea on how to tackle this situation. 

After understanding the purpose of this pattern, I saw it made sense to find multiple ways to help keep positive during workflow. The section of drawing your map caught my attention because whenever we have a certain goal, dreams, and needs it is separated out from our work goals, dreams, and needs. Two different lives which you try to maintain but eventually it outweighs each other which conflicts you. Personally, speaking we would rather just be selfish and accomplish our own goals and dreams. We are only human. But at the same time, we do not want it to conflict our mindsets when it comes to our profession.

For the type of action, they would want to conduct to keep our passion in check was to write up a list to control a conversation.  It is true you must keep a cool mind and keep your mind positive. But there will be days where things will not work out. For example, what if you had a bad day, the only it will do is put you in a funk for whatever reason It may be. Work related. Personal related. There are many factors you don’t have control like an environment or said workflow. 

I believe that I can take these steps but not all of them. I do agree that you must absolutely make sure the passion is there and do however to protect it because it what makes us motivated to stay concentrated. People are different and should be able to nurture their passion differently. Composing a list can help but nobody would like to compose one before work daily, that can be taxing. Sometimes you must be selfish, such as leaving work while the team are staying late. Just playing it by ear on a daily as it can shift constantly. A road we are set and take the necessary actions. 

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

Apprenticeship pattern: The Long Road

For this week, I decided to read on chapter 3, “The Long Road” which talks about the reality of software and the reasons that should be behind it. Many people probably have their own vision of computer science, and most of them are about getting the highest-paying job, just like the chapter describes it.

One thing that we need to understand with technology is that it evolves all the time and changes. We need to understand that the more technology constantly changes, the more our knowledge needs to be increased and developed. Technology/computer science is about adaptation, change, learning all the time because it will never stop improving and increasing, so should be our brains.

When the author says, “You should be prepared for the length of this journey”, it means that we should always keep in mind that as software developer, the expectation of working, learning everyday should be part of us. That is something that I learned while being a computer science major; that it’s an everyday school even for those who are done and those who are still in schools. When we aspire to become a master software craftsman, we need to understand the work taht is behind it and the devotion, dedication and time we need to invest in them. We need to value long-term growth opportunities and be open to new knowledge because that will be the only way to become better at what we do and improve the skills we already have and also, gain new ones. It’s a lot of work and will take time, but at the end, it’s our reward from working hard and giving everything we could to become great software developer. Success is part of it, and all the benefits taht come with the hard work, btu we should not think of them as the main motivation as apprentice.

From the blog CS@Worcester – Gracia's Blog (Computer Science Major) by gkitenge and used with permission of the author. All other rights reserved by the author.

Week 8: The Long Road

For this week’s pattern, I decided to read ‘The Long Road’ from Chapter 3: Walking the Long Road. The context of this pattern is that today’s society values quick success and overnight celebrities more than long term goals and success. Due to this, software developers are much different compared to veteran software developers and make the same mistakes they had made when they were inexperienced software developers. The problem of this pattern is that I, the reader, aspire to be a master software craftsman but my aspiration conflicts with what people expect from me, quick success. My guts tell me to take the highest paying job and first promotion I’m given and ignore slowly building up my skills. I thought this was pretty spot on of how society is today. Social media makes it so anyone can become an overnight celebrity which is probably one of the root causes as to why society is this way. Too much do we value quick cash and success, some people even expect it which is weird considering how hard it is to become an overnight celebrity. People need to take a step back and learn to have a long term goal and work towards your success instead of trying to get rich quick.

As for the solution of this pattern, it was basically the same as I wrote above. I should accept that I may be considered weird for thinking long term but I should accept it. I should also keep focusing on my long term goal, which is to become a software craftsman. By following the long term goal of a software craftsman, I’m able to become more skilled at learning, problem solving, and developing strong relationships with my customers. This is a good thing because, as mentioned before, people are too focused on getting rich quick and not focusing on building themselves up. By sticking to this, I won’t get rich quick like some of these people but I will be much more experienced, having built myself up long term and sticking to a goal. This is a long journey I’m not ready for but this will help me much more later in my life.

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

Concrete Skills

In approximately 6 weeks, I will become a new graduate student, and as I have not yet found an entry position for any company, it seems like I have no choice but to take any opportunity which comes first. Looking for a company makes me doubt that I am not good enough to qualify for any position and the waiting period is a bit frustrating and annoying.

An infamous reason that I heard from my friends is because I needed employers to sponsor me working authorization due to my international status. I was told that if employers see that option is on, the candidate’s document will immediately be excluded. Somewhat unfair but I will have a chance to verify it myself after earning myself working authorization and now I can be treated fairly by the applicant tracking system.

Besides, I think I made some mistakes in creating my resume initially that I did not include enough ability to show I am a good fit for the position. It is understandable that companies will not risk hiring someone who may not be able to directly contribute to the team’s workloads, even automate some simple manual tasks. Since my resume back then was poorly written, I failed to advertise myself to get the hiring manager’s intention.

Luckily, my action over the problem was kind of similar to what I read from the book, by collecting CVs from different people from the Internet and by hearing some tips and tricks from my friends on how to make my CVs better, I was able to rewrite my resume and checked it with different trusted ATS sites. Furthermore, my understanding on the subject improved considerably since then, so I can add more properties to the CVs. Comparing my initial CVs with my current one, it seems like I am now ready to reapply for every suitable position.

In conclusion, it could be tough getting to my first job, but as I started to be hired, it will be easier by then. Besides, I learned that I should put more preparation in my CVs, make a section to list every concrete skill that I have and related to the specified projects in the CVs.

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.

Practice, practice, practice

The people we know as masters don’t devote themselves to their particular skill just to get better at it. The truth is, they love to practice—and because of this they do get better. And then to complete the circle, the better they get the more they enjoy performing the basic moves over and over again.

—George Leonard, Mastery

The pattern I will be talking about in this blog post from the Apprenticeship Patterns book is the “Practice, practice, practice” pattern. What we can understand from the title of this pattern, is that practice is the solution to learning things in general and is the only way that can make things easier.

As George Leonard has described in this pattern, based on context to develop concrete skills in new areas, we will try our best to get better at the things we do. I totally agree with this context of trying to develop our skills. We always need to practice new things and not only the thing we have known better. It won’t help us for sure.

There is an expression in English that says: practice makes perfect. This expression is used for encouraging someone to continue to do something many times, in a way that the person will learn to do it really well. Specifically, this phrase means that if we practice something enough, eventually we will be able to do it perfectly. But George doesn’t agree at this point. He thinks that in fact, practice makes permanent. The only reason he says that, is because we need to choose the right thing to practice every day. And this thing, according to him, is the most important skill than repeating practice. I totally agree with him at this point. When it comes to practice, we have to know what we are doing and learn it in a perfect way. And then we need to try a new exercise to solve and then practice it. In this way, we can learn new things and at the same time, we can be able to solve whatever problem we might face.

That said, when I first started to work on programming I needed some time to fit in and learn new things. It was some hard and at the same time, it was slow and something that looked so difficult to be comfortable with.  But the good thing was that my school was a post-secondary and was based on practice. I did two years in a rowing practice and then we had a theory part. This was really helpful for us as new programmers. By practice, we learned a lot. And here I am after some years, practicing again for new programs and learning every day a new thing that can be useful in the future.

From the blog CS@worcester – Xhulja's Blogs by xmurati and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Chapter 2

Confront Your Ignorance

This pattern specifically covers an area of your skill-set or knowledge that you are not well-versed in. It challenges you to take the thing you are ignorant of that is relevant to your work or perhaps relevant to future work and invest your time to master it. The roundabout way of doing so is, as it describes, to pick the skill-set or technique and fill those gaps.

Seems simple enough but I felt as if this pattern is missing a bit of useful advice. Your personal growth when confronting your ignorance is more than organizational as the actions describes. It’s a matter of personal reflection and recognition. It’s definitely easier to say, “hey I know nothing about network communication”, and harder to recognize your own competency in network communication. The pattern does cover a bit of this, but it seems to focus far more in directly confronting easier problems.

I picked this specific pattern as it directly impacted how I worked during this semester’s sprints. In specific I applied this pattern unknowingly when I was thinking about working on a specific issue that related to using html. I have seen html code and references to it plenty of times during my college career but have never really used it before. I also overhead fellow classmates speak about it on rare occasions and mention building a custom resume styled website using html and other tools. I have had plenty of introductions and chances to learn something that is common in computer science, yet I have never taken the chance to learn it. At the start of the first sprint, I finally confronted my own ignorance around html and put myself into a situation where I would have to learn it in order to complete the issue. While I could have done this at any time it seemed prudent to place myself in a position to succeed at and implement to help motivate me to fill my gap in knowledge. This is why I felt like this pattern should describe learning how to identify your weaknesses a bit more as just knowing your weakness is quite different as confronting it is. One is merely a slight acknowledgement and the other lets you learn how to continually find your gaps.

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.