Category Archives: CS-448

Sprint #1 Retrospective

What Worked Well And What Didn’t:
After completing our first sprint and conducting our retrospective meeting, I would say that sprint #1 went really well. As a group, we were given three weeks to complete a total of thirteen different tasks for a total weight of 25, and only fell short of one for a total weight of 20 out of 25. What worked well with the team was that we all knew each other, allowing us to be comfortable with asking different questions or for assistance. Additionally, we were able to schedule weekly meetings whether virtually through Discord or in person. These meetings allowed everyone to be informed about project progress, issues, and next steps. Communication was a major successor for this sprint, further accelerating our knowledge within the project. For what didn’t work well, our timing of working on the project was slightly off. We gradually contributed but didn’t get the ball moving until the end of our sprint. I could understand this as some of us were unfamiliar with the functionality of GitLab and GitPod, and what was completed in the project. For the next sprint, working on the project little by little right when we start and understanding what we are dealing with, will provide us time to discover issues, figure out how to handle them, and complete our tasks in a timely fashion. Additionally, we should consider having a better review process to ensure everyone gets to review work.

Improvements As A Team:
To improve as a team, it would be great to further improve our communication. On days that we don’t have scheduled meetings, possibly posting an update on what everyone is currently completing, any problems they have, if someone needs something reviewed, and if they need help from another person on the team that may have knowledge on what they are working on could be beneficial. Also I believe we should begin working on our issues from the start rather than stressing and cramming everything all at once at the end of the sprint. We should also implement a better reviewing process.

Improvements As An Individual:
As someone who had just stepped into the project, I was unfamiliar with navigating through GitLab to find different things, what was completed within the project, and what needs to be worked on. After researching different things and searching through various repositories, I was able to figure this out. I was able to complete three issues individually and one issue as a group particularly working within the InventorySystem of the Theas Pantry project. My first issue was GitPod Dev Environment in InventorySystem/General. This involved having the Theas Pantry project work with VSCode in GitPod, rather than devcontainers. The second issue I completed was also GitPod Dev Environment in InventorySystem/InventoryAPI. I completed the same work to have VSCode work in GitPod rather than in devcontainers. My third issue was Move From ‘commands’ to ‘bin’ in InventorySystem/InventoryBackend. This issue involved changing the file name from commands to bin, updating all script paths to use bin, and ensuring pipeline stages like build, test, and release all functioned properly. I ran into an issue with the test pipeline for this specific task as files were missing. To correct this, I had to disable the test pipeline and plan on fixing this in the next sprint. The last issue I worked on was with my group, GitPod Dev Environment in InventorySystem/Documentation. We completed the same work to have VSCode work in GitPod rather than in devcontainers. To improve as an individual in future sprints, I would like to complete a little bit of work each day, rather than trying to just complete as much as I possibly can all at once. I spent a lot of time working on my issues and when something didn’t work, I’d burn myself out trying to figure out what the problem was. In future sprints, completing issues piece by piece can allow me to have a fresh mindset each time I work on the project and complete tasks in a faster, more efficient manner. Additionally, by completing a little bit each day, it can take away stress from time constraints and allow me to ask questions, get reviews, make changes, and improve the quality of my work.

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

CS-448 Sprint 1 Retrospective

Merge branch ‘jlee1999/vscode-issue’ into ‘main’ (4ca23d2d) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / General · GitLab

One of the problems I ran into came when combining issues within the same branch. For instance, within this one merge request to ReportingSystem General, there were three issues that were worked on which ruined the commit messages when squashing the branch. The commit messages would only reflect one of the issues being fixed rather than three separate commit messages that are associated with a particular issue.

Merge branch ‘jlee1999/gitpod-setup’ into ‘main’ (c2ec7bc6) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / Documentation · GitLab

This issue was in ReportingSystem Documentation and the task was to change the folder “commands” to “bin” to avoid any syntax errors within the code. This also required the refactoring of the code/files wherever “commands” was located so that it was changed to “bin”.

Merge branch ‘alexjs_linter_add’ into ‘main’ (6f9c803f) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / ReportingBackend · GitLab

This issue was in ReportingBackend and asked to add AlexJS linters to the pipelines. This required enabling the AlexJS test in gitlab-ci.yaml file so that the test would run through the pipelines when committing any changes.

Merge branch ‘jlee1999/alexjs-linter’ into ‘main’ (443debe1) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / ReportingSystem / GenerateWCFBReportFrontend · GitLab

This issue was also related to adding AlexJS linters to the pipeline of GenerateWCFBReportFrontend to check the indicated files for any problems.

Merge branch ‘jlee1999/gitpod_setup_branch’ into ‘main’ (636896d3) · Commits · LibreFoodPantry / Client Solutions / Theas Pantry / InventorySystem / InventoryIntegration · GitLab

This issue revolved around adapting InventoryIntegration to allow VSCode to work in Gitpod. There were some complications with this issue since this was the first issue I worked on and not all the pipeline tests passed when committing the changes.

For the first Sprint I think that there were a few things that went well during the process. I made sure that I would not get stuck on one issue for a long period of time so that way it did not hinder our overall progress through the other issues we needed to work on. A lot of the issues we were assigned revolved around the same thing, which made it easier to fix once solving the first issue in a repository. For example, setting up AlexJS linters to pipelines was required for us in multiple repositories in Thea’s Pantry, so once we figured out how to solve the first issue it was easy to carry over the same solutions to the other required repositories. The more I started working in GitLab and Gitpod/VSCode, the more comfortable I got with the layouts. This will continue to help through later issues and sprints as there is still more I can learn which will make it easier to fix different issues.

While there were positives to take away from my first experience in a Sprint setting, there were some things that did not work as well that hindered the overall progression of the project. At first, I forgot to create a separate branch when working on my first issue but then realized after committing the changes to the main branch. Luckily it was nothing too major that I was changing so it did not affect the entire repository. I personally would get caught up in too many issues at once and bounce around through multiple at a time.

I think the main thing that the team can improve on for the next sprint is more communication amongst everyone. The more communication there is, the easier it will be to identify what each team member is working on at the time. Letting each other know when there is a merge request to be reviewed will make it quicker to get through each issue and identify any mistakes that might arise in merge requests. As an individual, I can improve my focus on one issue at a time rather than working on multiple issues at once.

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.

CS448 Software Development Capstone – “Apprenticeship Patterns”: “Create Feedback Loops”

The part of the “Apprenticeship Patterns” textbook by David H. Hoover and Adewale Oshineye that I find myself flipping back and forth through the most is the fifth chapter, titled Perpetual Learning. I’m planning to depend on my skills in software craftsmanship to establish a stable career and earn enough money to finance my other pursuits in life, and consequently I need to think seriously about nurturing my foundational skills and refining my learning process.

I’m taking a course this semester that has me relearning C++, a language that I haven’t used in several years. I had been programming almost entirely in Java since beginning Worcester State University’s Computer Science program, and the material of this course is requiring me to jump right back into the deep end of C++. I find myself unsure whether my approaches to certain challenges are correct or not, as well as feeling more concerned with whether my code will compile instead of whether I am learning the tools of the C++ language effectively.

When I want to truly absorb some kind of knowledge, I’ve realized that I learn something best when I receive positive feedback when I demonstrate my skills properly and correctly. When I wanted to learn how to play the guitar when I was younger, the first thing I tried to learn was the start of “Breaking The Law” by Judas Priest. The positive feedback I got from learning that part was hearing sounds from the guitar that I was playing that sounded a lot like actual music! After that, I couldn’t stop myself from learning how to be a better guitar player because of how much I wanted to keep myself in that positive feedback loop. I kept learning, I sounded better, and the feedback loop has been growing more rewarding as time goes on. I’m confident that lots of other people can relate to this experience, even if the thing that they were trying to learn wasn’t music or playing an instrument. Being able to gauge your own progress through positive feedback benefits the learning process dramatically.

This pattern is concerned with creating that same kind of positive feedback loop within the context of software craftsmanship. Seeing the quality of your output increase in proportion to your effort in learning can be the fuel that keeps a programmer engaged in refining their craft. The pattern is introduced with a quote from Jerry Weinberg’s “Project Retrospectives”:

“We in the software industry are working with a more or less invisible product, yet this very invisibility only heightens our need for feedback.”

It feels difficult for me to decide “where I am” as a programmer without comparing myself to the people around me. That approach takes my focus away from my own growth however, and I want to avoid it. So instead, the solutions proposed by this development pattern include researching test-driven development and using interactive interpreters that can let the programmer catch errors and see outputs as they write code. The programmer also has the option to intentionally reach out and seek feedback on their coding process from peers and mentors, or by participating in pair programming. A given example of applying this pattern in the real world is asking the interviewer for a position that you were not accepted for why the company didn’t want to bring you on board. This is a more positive framing of what could be a rather upsetting situation, and an outside perspective can also give you insight into aspects of your work and yourself you hadn’t paid attention to.

The key to collecting all this data is to construct useful and actionable feedback for yourself. The pattern defines “useful feedback” as feedback that you can do something in response to that informs you whether to do more or less of a certain behavior. The textbook challenges the reader to put this pattern into action by identifying a metric in their working environment that they have the capacity to change and measure. Then, use the measurements of that metric to try and understand how your actions have changed your “working environment”.

Reflecting on this pattern has made me realize that I have rarely, if ever, sought out external feedback for projects that I’ve worked on outside of school. I’ll write code, compile it, and push it to my Github, but I’ve never made the effort to construct testing suites or seek external criticism from other programmers. These habits have enabled a feeling of doubt to sprout within me about whether my code could be adapted to perform a useful task, or whether I’m actually making any progress in my learning. I’ve started thinking about the advice proposed by this development pattern, and I’m going to take the time to read “Test-Driven Development: By Example” by Kent Beck, the reading material sourced in this pattern. I’m also going to research the features of Visual Studio, my preferred text editor, to see if there are any extensions that allow for the features offered by interactive interpreters.

I’m not sure that I understand the pattern’s advice about “gathering metrics to understand the effects of your changes to your working environment”, but the practical advice of using software tools to provide feedback as you work as well as inviting constructive criticism from others makes perfect sense to me. The pattern also urges the learner to put themselves in situations conducive to building these feedback loops. I think that some of the strongest fuel for those feedback loops are the relationships we create with others along our learning journey, and in the online realm of software development, I don’t think it would be hard to find a community of developers eager to forge and fully energize those feedback loops.

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

Sprint 1 Retrospective

Overall I think sprint 1 went well. I think we all did a good job of keeping each other updated and asking each other questions if we became stuck. We had times when life got in the way and work didn’t get done and we made sure to let each other know. We were also open enough to communicate with each other when we realized that issues may not have been merged for a long period after being reviewed. All of us displayed aspects of the original description of the culture we wanted in the working agreement: open-mindedness, honesty, respect, and accountability. We decided how much weight everyone should try to complete to divide the work evenly and fairly before the sprint started and we kept to it for the most part. 

I worked on 4 issues in total. I worked on one with the group and 3 on my own. The issue I worked on with the group was “Gitpod Dev Environments -InventorySystem/Documentation”. In this issue, we set up the files needed to configure the Gitpod Dev Environment for Inventory System Documentation and asked any questions we had to make sure the rest of the similar issues would go smoothly. The issues that I completed on my own throughout the sprint were “Move from `commands` to `bin` – InventoryAPI”,” Add AlexJS linter to pipelines – InventoryAPI”, and “Add AlexJS linter to pipelines – InventoryBackend”. The “Move from `commands` to `bin` – InventoryAPI” issue was a bit difficult because there was no build or test file. I figured out that I had to disable those two jobs for the pipeline to run. For both of the issues the lint.sh files weren’t created during the “move from commands to build” issues for the respective projects so I copied the file from a project that already had one. Because I knew that all of the linters that were included in the file also applied to each of the projects I worked on, I left those linter commands along with the command for AlexJS. However, I only enabled AlexJS in the pipelines for since the issue was only created to add AlexJS and we planned on adding the rest of the linters to the pipelines of the projects during sprint 2.

As a team, I think we did fairly well but we needed to adjust how we work to ensure there is evidence of everyone’s contribution on GitLab. Most of the communication was through discord which resulted in a good amount of the team receiving a poor individual grade for sprint planning. We realized this and decided to split up adding issues and weight for the sprint planning and backlog refinement for future sprints. We also did not rotate reviewing issues as we originally planned when creating our working agreement. In future sprints, we plan to set up a system that will ensure that there aren’t certain people who are reviewing the majority of issues. We aren’t sure if we would like to set time aside during our weekly meeting on Discord or set a system where one would just review the last issue in the “needs review” column. As an individual, I need to make sure I’m on top of my work throughout the sprint. Although life can get a bit hectic, I need to make sure I am pulling my weight for the team. I want to plan specific days where I work on issues to stay on track.

From the blog CS@Worcester – Live Laugh Code by Shamarah Ramirez and used with permission of the author. All other rights reserved by the author.

sprint 1 retrospective

This sprint, I handled the Gitpod Dev Environment implementation for the Reporting System, specifically for the Reporting Integration, Reporting Backend and Reporting API repositories. I also acted as the scrum master for the team, handling most of the logistics and communication with the product manager.

Gitpod Dev Environments: Import extensions via the .gitpod.yml file, set workspace settings via the .vscode settings.json file.

In terms of what went well, we did complete most of the issue weight (75% of the weight assigned for the sprint was dealt with). Speaking with my team members, we agreed that the meetings were productive and efficient, and we didn’t waste time on any of the meetings we had. I made it a point to not have meetings that could have been done over a short text conversation, and it seems to have paid off. We also agreed that the communication that did occur was quality communication.

While we completed most of the work for this sprint, there was still 25% of the weight left. This was entirely comprised of the Reporting System Deployment issues where we had to write docker-compose files to set up MongoDB local volumes. In talking with the team, we thought that the weight didn’t reflect the difficulty of the task. In retrospect, looking at the Deployment epic again I can see that there was a lot of confusion, not only because of having to read through documentation for Docker, but also because the initial task that was to be done before the implementation through docker-compose files (the actual mounting of local volumes from MongoDB) was not accomplished by another team, and was even removed from their sprint. This was excacerbated by the approach we took, where each one of us worked on issues individually without much assistance from other group members. This changed towards the end when two team members worked on the deployment together, but by then it was still ineffective, especially considering the uneven distribution of issues. It seemed like the weight of issues did make sense in a vacuum, but considering that I did all of the Gitpod Dev Environment issues for example, it was obviously very quick to complete 4 weight when the first 2 weight was done, because it’s an application of what I just did.

Another consideration: I think having one person (me as the scrum master) deal with a lot of the issue-creating and handling GitLab logistics was efficient, it didn’t lend itself to the most clear working environment for my team members that weren’t very well acquianted with the workflow. Details were located in epics rather than easily accessed directly in the issue that was assigned, and it made it more difficult to see what you were actually working on. In addition, it made it seem as though I did all of the work in the activity log when in reality it was a cooperative process, and the byproduct is that I end up with all of the credit as well.

For next sprint, we should better assist each other as necessary on issues when complications arise. We should assign weights more accurately based on our experience on the last sprint, and allow all team members to share responsibilities on GitLab, both for learning and to better tell what’s going on. As an individual, I should be more proactive as scrum master to really address problems as soon as they arise, rather than leaving everyone to their own devices as long as they check in. With these adjustments, I think our team will be able to perform much better in the next sprint.

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

Nurturing Passion in a Challenging Environment

Summary:

The pattern “Nurture Your Passion” addresses the struggle faced by software developers whose passion for their craft is hindered by the work environment. Often kept to “simple” tasks or faced with demoralizing conditions like corporate hierarchies or project death marches, developers find it difficult to maintain their enthusiasm. However, the pattern suggests several strategies to protect and grow this passion.

Reaction:

The pattern could be related to deeply with many software developers who have found themselves in similar situations. It highlights the importance of preserving one’s love for the craft amongst challenging circumstances. What’s really interesting is the acknowledgment that not everyone has the privilege to earn a living through their passion, making it important to safeguard and nurture it.

What’s Interesting and Useful:

The emphasis on working on tasks that align with personal interests stands out as a practical approach. By dedicating time to activities that spark joy, developers can reignite their passion and find fulfillment in their work. Additionally, the idea of seeking out like-minded individuals and immersing yourself in the classics of the field serves as a reminder of the rich heritage and community support available in software development.

Impact on Professional Outlook:

The pattern encourages a reevaluation of how someone approaches their career in software development. It makes individuals prioritize environments that support their growth and passion, even if it means diverging from conventional career paths. Setting clear boundaries and maintaining a sense of wonder about programming, as said by Paul Graham, becomes essential for long-term satisfaction and success in the field.

Disagreements and Reflections:

While the pattern offers valuable insights, some may find it challenging to implement certain suggestions, especially in highly demanding work environments. Setting boundaries and steering conversations towards positive topics require courage and confidence, which may not always be feasible depending on organizational culture and power dynamics. However, the underlying message about the importance of preserving one’s passion remains relevant.

In conclusion, “Nurture Your Passion” serves as a reminder that maintaining enthusiasm for software development is a deliberate effort, especially in the face of adversity. By embracing strategies outlined in the pattern and staying true to their passion, developers can navigate challenges and thrive in their careers.

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

The Long Road

In this week’s blog post, I will be discussing the “Long Road” pattern discussed in chapter 3 of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye. This week, I chose this topic for my blog post because I often worry about not being able to learn or grow more in my field, becoming stagnant because there is nothing else I can learn. Thankfully, this pattern dissuaded those fears of mine and inspired great confidence in my future endeavors.

The quote that this pattern opens with immediately puts much of my concerns about the limits of what I would be able to learn to rest. “‘How long will it take to master aikido?’ a prospective student asks. ‘How long do you expect to live?’ is the only respectable response.” In comparing computer science to Aikido, it implies that no one can possibly learn all that there is to know in computer science. Another quote from this section that makes me even more excited to be a part of this field mentions that for every step you make, the finish line is two steps further away. “For every step you take toward mastery, your destination moves two steps further away. Embrace mastery as a lifelong endeavor. Learn to love the journey.” While this may seem like a disappointing aspect of our field for many, the limitless opportunity for me to grow is why I love this field of knowledge.

I did not think it was possible, but further reading in this section made me even more excited and proud to be in computer science. “Close your eyes and imagine the strangest possible role you could be playing in 10 years’ time. Have fun thinking of the wackiest possible future for yourself. Then think about 20, 30, and 40 years from now. What kinds of experiences do you want to have tried? Imagine that 40 years from now, you are asked to write a short description of your professional history and the biggest influences on your path. Use the output from that thought experiment to help you plan your future career choices.” This quote had me thinking about incredible and outlandish possibilities in this field, which made me even more eager and excited to be in this field than I thought possible.

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches Individual Apprenticeship Pattern

This week I continued to read about Individual Apprenticeship Patterns for CS448 – Capstone and focused on the “Stay in the Trenches” pattern. This pattern emphasizes the importance of gaining continuous hands-on, practical experience in the craftsman’s chosen field(s) at all levels, even as they may advance within a company. It can be common as software developers move up to transition to more managerial roles focusing on handling teams and deadlines rather than hands-on coding.

However, doing so will inevitably and quickly result in deterioration of the craftsman’s coding skills. Instead of getting too caught up in theoretical knowledge or managerial roles early (or at any point) in a developer’s career, developers should ‘stay in the trenches’ and continue working on practical/coding problems to keep developing and advancing skills and expertise. By immersing ourselves in the actual work, we’ll learn from the day to day experiences and continue to grow in ways that upper level managers often cannot. 

Often, I’ve heard of upper level software managers spending most of their time on coordination, time/schedule management and strategy/design planning – from a craftsman’s standpoint, only code project strategy and design planning are particularly applicable. While it surely is far more abstract and long-term or larger in scale, developers who are working hands-on with code are still managing and accomplishing tasks and exercising their code strategy and design skills. So when considering that hands-on coders will also further several other skills related to their craft, these managerial roles seem like a clear downgrade in terms of job quality and day to day activities even if it comes with a pay increase.

This brings up the final major point of this pattern, which really stuck out to me – identifying other avenues and ways for craftsmen to advance within their company/career and be rewarded for high-quality performance. Some practical examples could include a simple pay increase, more involvement in internal strategy meetings/decisions, job-title shift/improvement, etc. There’s no clear or definite answer here, but individuals in this position are probably in good standing as the company is looking to reward them, and they should communicate and work with company management to find incentives and reward mechanisms that align with the goals of both parties. If not however, this pattern stresses the importance of staying on the craftsman’s path and considering advancement positions at other companies that are more flexible.

Sources: Hoover, Dave, and Adewale Oshineye. “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman.” O’Reilly Media, 2009.

From the blog CS@Worcester – Tech. Worth Talking About by jelbirt and used with permission of the author. All other rights reserved by the author.

“Concrete Skills”: Building a Tangible Foundation for Growth

Summary of the Pattern: The “Concrete Skills” pattern emphasizes the importance of acquiring skills that can be directly applied in a professional setting, particularly for individuals in the early stages of their career in technology. It advocates for the development of a portfolio of practical, demonstrable skills that make one a valuable team member from day one. These skills not only facilitate smoother transitions into new roles or projects but also enhance an individual’s employability and credibility within their field.

My Reaction: The straightforwardness of the “Concrete Skills” pattern immediately resonated with me. It serves as a pragmatic reminder that, amidst the allure of high-level theories and complex conceptual frameworks, the ability to contribute tangibly and effectively to a project is invaluable. This pattern has reinforced my belief in the necessity of balancing theoretical knowledge with practical skills that can be immediately applied to solve real-world problems.

Insights and Changes in Perspective: Delving into this pattern prompted me to reassess my skill set and identify areas where my capabilities could be seen as both concrete and valuable in a team setting. It has shifted my focus towards a more balanced approach to learning, where equal weight is given to both the acquisition of theoretical knowledge and the development of practical, hands-on skills. This realization has not only influenced the way I plan my learning goals but has also altered how I present myself professionally, emphasizing skills that can have an immediate impact.

Disagreements and Critiques: One potential critique of the “Concrete Skills” pattern might be its perceived emphasis on the immediate applicability of skills, which could inadvertently sideline the long-term benefits of foundational, theoretical knowledge. However, I believe the pattern does not dismiss the value of theory but rather highlights the importance of having a well-rounded skill set. It’s about striking the right balance between being able to contribute now and laying the groundwork for future innovations.

Conclusion: The “Concrete Skills” pattern has profoundly influenced my approach to professional development, highlighting the importance of building a repertoire of skills that are as tangible as they are valuable. It serves as a guide for navigating the complex landscape of technology careers, where the ability to demonstrate concrete skills can set one apart in a competitive field. As I continue to advance in my career, I am motivated to cultivate a diverse set of skills that not only underscore my theoretical knowledge but also showcase my capacity to contribute meaningfully to any team or project.

From the blog CS@Worcester – Abe's Programming Blog by Abraham Passmore and used with permission of the author. All other rights reserved by the author.

CS-448 Apprenticeship Patterns Chapter 2-6 Introduction

Chapters 2-6 in the Apprenticeship Patterns textbooks goes over the specific different practices and patterns that software developers use in order to grow in their field.

Chapter 2 talks about the values of “emptying the cup” as an apprentice. Embrace the beginner’s mindset with The White Belt. Overcome roadblocks with Unleashed Enthusiasm. Acquire concrete skills in specific technologies to explore advanced patterns. Avoid complacency by systematically broadening your tech skills. Expose your ignorance to focus on learning needs. Confront and flex your knowledge muscles. Take audacious tasks to learn and grow. Retreat into competence when overwhelmed, then gather yourself to ascend further.

Chapter 3 explains how many people are walking the same path even when they seem to be on a different path. In other words, the experts that know more than you in the work field went through the same struggles (walked the same path) as you are to get to where they are now. It explains the story of Dave as he continues his journey in software development with a sense of assurance. However, his interactions with highly skilled hackers in online communities and face-to-face collaborations with high level developers humbled him and fueled his desire to learn. As he delved deeper into side projects and consuming learning material, Dave realized the vastness of knowledge available and the continuous learning process inherent in software development. While there is a considerable gap between his skills and those of seasoned developers, Dave found solace in the shared journey towards mastery that all developers embark on.

Chapter 4 introduces the concept of letting go of perceived competence and allow yourself to recognize that there is way more to learn and more to travel down the Long Road. The rapid learner faces the risk of becoming complacent in their success within their current environment which could stagnate their growth. It is crucial for such individuals to acknowledge the broader landscape of opportunities beyond their immediate sphere and to remain humble in the face of their accomplishments. The focus should not be on surpassing others but on personal growth and improvement, recognizing that the journey towards mastery is ongoing and that collaboration and mutual support are integral to this process.

Chapter 5 emphasizes the concept of learning and, especially for apprentices, how it is critical these patterns be applied early on in their journey. The essence of apprenticeship in software development revolves around perpetual learning and effective communication. Apprentices must constantly seek opportunities to replace ignorance with skill, not only acquiring concrete technical abilities but also in developing the ability to learn itself. These concrete learning activities such as “Expanding your bandwidth” and “Breakable Toys” pave the way for deeper self-discovery, leading to the importance of reflecting on work. sharing knowledge, creating feedback loops, and understanding personal weaknesses to transition successfully from apprentice to journeyman and eventually master craftsman.

Chapter 6 talks about the constant time and effort that should be put into studying to further develop your learning curriculum. In today’s age digital age, access to vast amounts of information is easy, thanks to the Internet and handheld devices. While blogs and online resources offer valuable content, the wisdom found in traditional books by experts like Jerry Weinberg and Kent Back is irreplaceable. Incorporating reading into an apprenticeship is crucial for success, allowing individuals to construct their own learning curriculum.

2. Emptying the Cup | Apprenticeship Patterns (oreilly.com)

3. Walking the Long Road | Apprenticeship Patterns (oreilly.com)

4. Accurate Self-Assessment | Apprenticeship Patterns (oreilly.com)

5. Perpetual Learning | Apprenticeship Patterns (oreilly.com)

6. Construct Your Curriculum | Apprenticeship Patterns (oreilly.com)

From the blog CS@Worcester – Jason Lee Computer Science Blog by jlee3811 and used with permission of the author. All other rights reserved by the author.