Category Archives: CS-448

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Sprint 1 Retrospective

In this post, I’ll be reflecting on my group’s first sprint towards developing an Identity Access Management System for Thea’s Pantry. Our focus in Sprint 1 was really to get a base understanding of Keycloak and to implement a basic framework that would allow us to integrate Keycloak with the pre-existing systems.

Some of my personal work towards that goal was as follows:

GitLab

  • Documenting our low-level issues in GitLab and assigning them accordingly. Epic

Backend

Frontend

  • Containerize the fake frontend in a way that allows it to interact with the backend for testing purposes. Containerization

  • Create a dummy frontend with buttons that send mock JWTs to the new backend endpoint for testing purposes. This frontend sends encoded JWTs that contain user roles, receives the encoded role from the backend, and redirects to one of three corresponding landing pages accordingly. Commits: 1 , 2

We got off to a relatively slow start, but this was to be expected in learning a fully new technology. None of us had prior experience with Keycloak, so brainstorming and researching how we might want to implement an authentication / IAM flow was not easy. After some initial barriers, something that worked incredibly well for us was taking the extra time to really break down the work into very small issues or tasks for an individual to do. It was a lot easier to “add an endpoint to the openapi.yaml file” and “create openapi schemas for authentication tokens” than to “create a fake backend that can handle token validation”. Breaking things down as a group really helped us isolate specific tasks with clear deliverables.

Something that didn’t work quite as well for us was our current working agreement. I feel strongly that our working agreement must either be modified heavily or adhered to with more focus. We could take some time to more clearly outline the expectations of each member of the group, which in turn will give us something to reference when we have feedback for each other. We can also improve our communication as a team; our Discord is relatively inactive, and it would benefit us greatly if we each contributed more to the Discord.

Something I could personally improve is my followership. Though we are obviously a team and all working together, a deliberate part of the exercise is to designate a Scrum Master for the sprint and to loosely follow the Scrum framework. I was not the Scrum Master for Sprint 1, and I have a tendency to step up into a leadership role when the opportunity presents itself or when I feel there is something I am able to contribute that is not already present. I think this has its place and value, but I think it is also detrimental in some ways to both the team (as it weakens the team structure) and to the individual designated as Scrum Master (as it removes the opportunity for him or her to lead). I can definitely work on being a follower when it is my turn to be a follower.

The pattern from the book that I’ve chosen to include here is Exposing Your Ignorance. The pattern describes how we all like to be seen as confident and competent and are therefore slow to ask for help when we need it, but the better way forward is to admit our inadequacies and put in the open all of our missing knowledge, as that is a quicker, more effective, and more honest way to deliver. I selected this pattern because I feel it would have been extremely useful to our group throughout the sprint; there were many instances where I felt we each should have asked for more help if we needed it, and instead we tended towards remaining silent so as not to admit that we were lost, even if that meant not completing the work we needed to. I strongly disagree with that method of tackling a problem, and I feel that if we had read this pattern, we may have been much quicker to admit to each other that we need help with X, Y, or Z.

From the blog Mr. Lancer 987's Blog by Mr. Lancer 987 and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns

This reading presents an insightful perspective on software craftsmanship, emphasizing apprenticeship, perpetual learning, and skill mastery. The concept of learning through mentorship and practical experience, as illustrated in Dave’s story, was particularly interesting. It highlights the importance of hands-on work, exposure to real-world challenges, and the necessity of a growth mindset in becoming a great developer. The reading has influenced my perspective on professional growth. It reinforces the idea that mastering something comes from deliberate practice, seeking out mentors, and embracing failure as a learning opportunity. I believe this is what makes a good developer. One point I disagree is the romanticization of craftsmanship. While the focus on individual skill development is inspiring, modern software development requires collaboration with teams. Balancing skilled craftsmanship with effective teamwork is important. In chapter 2, I find the story of the Zen master and the young philosopher was provoking. It talks about the importance of maintaining a beginner’s mindset, or “emptying your cup,” to fully absorb new knowledge. I think this is important in apprenticeship. The idea that experience can sometimes be a barrier to learning is interesting and that applies to many fields, including software development.

Dave’s realization that true mastery comes not from credentials but from continuous learning and engagement with a community of experts is highly relevant. The story also highlights the importance of humility in learning. Even the most skilled developers acknowledge that they are still learning, which serves as both an inspiration and a challenge to those just starting out. The idea that learning is a lifelong journey rather than a destination is a valuable takeaway. I resonate a lot with this point because I often feel like this is a lifelong journey of continuously learning and adapting to new technologies. In terms of how I work, the idea that certifications and formal training are only steppingstones, not the final proof of competence is true. I’ve learnt that while training can provide foundational knowledge, real expertise comes from practice, engagement with peers, and continuous learning. One thing that I found interesting was the analogy of “the big fish in a small pond”. It is a powerful way to describe the risk of complacency for those who learn quickly. It’s a reminder that achieving success in a limited environment may feel rewarding, but true growth comes from recognizing the wideness of the field and challenging yourself to bigger things. I’ve learnt that it’s important to stay challenged and continuously learn. It’s easy to become comfortable in an environment where your highly competent, but it’s important to seek out mentors that can further challenge you to be even better than you already are.

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

Reflections on Apprenticeship Patterns

While reading parts of the book “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman” by Dave Hoover and Adewale Oshineye, there were a couple points that stood out to me when reading and comparing to my own experiences and knowledge.

An important point brought up by the book in the first chapter is how understanding the logic behind why things are done allows people to adapt to unfamiliar problems. Knowing the “spirit of the rule” allows for people to create new rules as needed. This is a point I personally feel strongly about. Knowing what to do is, really, only an issue of understanding instructions. Having a knowledge of the reasoning behind different practices allows you to apply that understanding to other problems.

Programming is a great example of this. It’s easy enough to follow a guide on writing code to follow some specific function, however, good developers will put effort into understanding how the code works, and will be able to replicate what they know later, or apply it to different situations. Someone who only knows the specific steps to writing the code doesn’t understand how it works, and most likely won’t be able to apply their experience outside of that specific use-case.

Another interesting point that I personally hadn’t considered was that apprenticeship in software development is much better approached as a mindset, rather than a formal form of schooling. The book describes that newcomers will have to “create their own opportunities for learning” in the working environments they find themselves in. I’ve understood that it’s important to have a desire to learn more than what may be expected, but the perspective of creating your own learning experiences, outside of more standardized curriculums but within the same environment was interesting.

This point also carries over into the beginning of chapter 3, where one of the authors describes how after connecting with other Perl developers, he was impressed not just by their knowledge, but by the speed at which they were still learning. Symbolically, the stacks of certificates and qualifications would become buried under book printouts and notes; the desire to learn more taking precedence over hard skills and qualifications that one can accumulate.

Both points culminate in the idea that being a great developer doesn’t mean having countless certifications or even being able to write code well. This is a good foundation, and great software developers usually fall into this category, but what makes them great is the understanding that there is more to learn and the desire to expand their knowledge and experience that sets them apart from the pack.

References:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns Guidance for the Aspiring Software Craftsman Dave H. Hoover Aut; Adewale Oshineye Aut. O’Reilly, 2014.

From the blog Griffin Butler Computer Science Blog by Griffin Butler and used with permission of the author. All other rights reserved by the author.