Apprenticeship Patterns: Confront your Ignorance

The ‘confront your ignorance’ apprenticeship pattern talks about what to do when you have discovered a gap in your skillset that you need to fill for your daily work. Though you have identified this shortcoming, you aren’t sure how to begin overcoming it. Hoover and Oshineye recommend selecting a single skill, tool, or technique and working actively on your understanding of it. This can be done in any number of ways, such as by reading introductory articles or constructing breakable toys. You should choose a learning method that works for you. Once you are satisfied that your knowledge has been sufficiently filled in, you can decide to either continue pursuing this topic or move on to another gap in your knowledge. This pattern should be used in tandem with the ‘expose your ignorance’ apprenticeship pattern. Confronting your ignorance in public as well as private encourages an environment that is more tolerant of failure. Focusing too much on developing your skills in private may pull you away from your actual work, and it may become an issue for your team. On the other hand, focusing too much on the ‘expose your ignorance’ apprenticeship pattern may become obnoxious to your team members and prevent you from doing anything meaningful about your lack of knowledge. At the risk of coming off as either arrogant and unwilling to work or passive and unwilling to learn, you must strike a balance between these two patterns.

I think this apprenticeship pattern is really interesting. I have always found it useful to study topics that I feel I am weak in private; it’s nice to be able to focus on learning in a space I don’t need to worry about how that lack of knowledge makes me look. Learning in private can only get you so far, however. It is important to also communicate with people with more experience and who can help you better understand the topic you are pursuing. I think as Hoover and Oshineye suggest, this pattern would be especially useful when employed alongside the ‘expose your ignorance’ apprenticeship pattern. I do agree that these should be used within a reasonable amount. There is no point in expanding upon a skill if it is going to ruin your daily work.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Expose Your Ignorance

The ‘expose your ignorance’ apprenticeship pattern addresses the issue of you not being completely comfortable with the technologies your work requires you to work with. Your impulse may be to lie to a customer in favor of appearing competent, but you should curb this impulse. Instead, you should be honest and open about your knowledge or lack thereof and focus on your ability to learn. Asking questions is a good way to let people know that you are both needing and willing to learn. Asking questions of your team may also help your team recontextualize and reunderstand their own knowledge. Your goal should be to expand your knowledge to a variety of topics, especially while you are still new to the profession, rather than focusing on becoming an expert in a handful of technologies. It is important to be able to recognize areas in yourself that could use improvement. It is similarly important to expose those areas and work on learnig from them, rather than hiding them.

I think this apprenticeship pattern has some very useful advice. I think it is great advice to admit your knowledge in an area is lacking and use that as a chance to learn. Hiding your lack of knowledge in an attempt to save face and spare your pride is unwise and will succeed only in stunting your learning process. This is something I try to work into my daily life. I used to be very scared about coming off as incompetent for lacking in a given area, but I find it is much more rewarding to admit that I am weak in an area and use that as an opportunity to expand upon my knowledge.

The only thing I disagree with is the action that Hoover and Oshineye suggest taking. I don’t know if posting a public list of things you don’t understand will help you better yourself, I think it is just going to make you look weird to your coworkers. I think it would be more useful to keep a private list of things to work on, and just keep that list in mind in discussions with others in case the opportunity to develop your knowledge presents itself.

From the blog CS@Worcester – Ciampa's Computer Science Blog by robiciampa and used with permission of the author. All other rights reserved by the author.

Stay in the Trenches

The pattern I’m looking at for this post is titled “Stay in the Trenches.” The problem outlined here is that success in programming has a tendency to pull you away from programming. The authors quote Pete McBreen, who says “as soon as a person stops practicing, her mastery fades.” This is a pretty succinct description of the problem at play here.

In this pattern we are introduced to a new skill, which is using increasing positions of authority to construct your own work environment in such a way that you don’t fall out of practice. It’s something I had really never considered. Even though I’m used to being complimented on my programming skills, I had never really imagined stable work in software development at anything more than an entry level. In retrospect, I’m not really sure why.

Unlike some of these patterns, I think this one is a lot harder to disagree with. It doesn’t offer many opinions on what honing your craft entails, only noting that you need hands-on practice to stay good at the job, and exploring ways of staying in that practice.

I appreciate the suggestion to leave an inflexible workplace rather than continue on while your practical ability atrophies. I’m not really sure if I’m on the same page with the authors most of the time, but this sentiment in particular is one I am pretty strongly on board with.

The only thing I’d add is that I think it’s a little narrow minded to think just of one’s own development of their craft as an individual negotiating with various employers. Aside from making it easier to negotiate, another benefit of organization between software developers that I think would benefit them uniquely is that it could be an enormous opportunity for the refinement of software as a craft in general.

Rather than the same debates happening over and over on an individual scale, we could come to shared conclusions and move forward as an industry. It would also be nice to have proper training the way most trade unions have, rather than kind of soaking things in on your own alongside a college course or some random tutorial you found online.

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

Sustainable Motivations

In this section, we recall that the best motivation for programming is enjoying the activity itself. However, real life work conditions tend to get in the way of this enjoyment. The solution proposed here is essentially to stick it out for the sake of your long term goals.

I liked the quote from David Hoover at the end. I think it’s a pretty apt description of what it’s like to have fun doing meaningful work. I also really liked the brief description of Obie Fernandez’s career, in which he became much more successful and talented by diversifying his skills. As someone with a lot of different ambitions, I find it pretty aspirational.

As far as how this has changed my thinking, I’m not really sure how to or even if I want to integrate this idea into my career. This is mainly because I don’t really know what I want to do, exactly. I think I might want to generalize it a little more.

My takeaway then would be to have more general goals that guide the specific ones. I don’t think that’s really a good way of explaining it but I don’t really have anything better.

What I mean by that is trying to connect general things I want, like financial stability or a reputation for talent, with actionable goals and actual things I can do. I tend to struggle with tunnel vision sometimes. It usually takes some thought to recall that the class I hate isn’t just what I do day to day, but also part of my degree. While I think what I’ve said above sounds kind of trite, I do feel like this section has helped clarify my thinking.

I’m also not sure if I agree with the dichotomy the authors give here, of writing easy, fun code versus writing difficult, but financially rewarding code. It seems pretty backwards to me. Personally, I think solving difficult problems is the most important and most rewarding thing a programmer does. When I imagine a terrible, unrewarding software job, I imagine one with no difficult problems. A position where the only thing to do is stitch together various APIs with no room for creative solutions or much thought at all.

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

“The Deep End” Apprenticeship Pattern

This pattern compares the rigorous process leaving your comfort zone in a programming work environment to learning how to swim in the deep end of water. But it is a little more intense as it explains the scenarios of the water and your ability to swim. There are going to be job opportunities that might in fact be out of your skill level.

There are also jobs that might be out of your skill level but not out of your reach. Meaning, if you can reach the skill level with hard work and determination, you should go for it. Just put in those extra hours for however long it takes at the new job to catch up. But also, you need to be able to recognize your own abilities. If you can’t reach, there expectations consider other options.

The pattern includes strategies on what you should do if you find yourself struggling to keep yourself afloat in an environment filled with deadlines that you are struggling to meet. It really tries to touch on the possibility of the worst. As in, if you were hired and you are struggling to meet project deadlines. What should you do? That is what this pattern really tries to break that down how to take one step back and regain.   

I thought this pattern was extremely thought provoking. And really instilled in my own anxieties about my future in the field. What path do I want to dedicate my next year, my next five years, my next ten years? This pattern changes the “Long Road” into the “Intense River”. And I am trying to figure out what river I want to kayak on. Will I be safe going down an intermediate river? I need to create skills that will allow me to adapt.

This chapter also causes me to address my own faults and indiscipline’s. The Software field the way I see it requires a true passion to get better every day. I am all for that. That is exactly the type of thing I need to do something for the rest of my life. It is extremely exciting, but the severity is certainly no joke. I have a lot to improve on to contribute to some of these amazing things we are seeing today.  

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

My Third Sprint: A Lesson in Legacy

                With the ending of my last sprint in my capstone class I have completed my first of many cycles of development. Throughout this series of three sprints I have gained a better understanding of what I can expect of myself and how I can begin to improve my performance in an actual working environment. This last sprint, like the previous two before, taught me new concepts that I had not previously considered when going into the sprint. Throughout this sprint, especially in the last two weeks, the mains idea that stuck out to me was that of legacy, and what our group leaves behind for those who are coming next.

                When beginning this sprint, I had first focused on what was laid out during the planning session, involving the implementation of docker and containerization in general on to our identity access management system. The system worked when running on the operating system without any overhead so the next step was to get it working with docker to later be adapted to the Kubernetes clusters being used to host the Libre Food Pantry system. On the second of three weeks into this sprint, it had occurred just how close we were to the end of our journey and I began looking at the other spring backlog items. The one that struck me as most important was working on refining existing tutorials within the GitLab repository for the next group of developers to be easily able to get up to speed on what has been done and what needs to be done.

                As in previous sprints, time estimation, while once again improved, was a problem for us. This was especially noticeable as the end of our journey loomed closer.  While we had not gotten as much done as we would have liked to, we had made a concerted effort to condense our findings into the important information and save it to the GitLab repository for future groups to pick up on.

                Our group was tasked with creating a presentation for the end of the semester and this helped us to filter unnecessary information and include only the most important parts that applied to the project at hand. To go along with this I myself had even created a tutorial video that exemplified all of my own findings which would allow new groups to create a secured application with key cloak. Despite being a basic webpage, it is better to start with this than with nothing like our group had.

                As a group we can still improve not just on our time allocation but also our recording of information. Being able to properly record our finding as we make them is important in allowing both the group and future developers to have easy access to pertinent information regarding this project. I myself could have made this a focus as I performed research from the very beginning and would have had a library of information for it.
                Aside from this however, I still have a long was to go in making an effort to communicate with my peers. I often find myself “suffering in silence” whenever I run into a roadblock and, just as before, I tend to withdraw and become distant which benefits no one at the end of the day.

                Overall however I can say with certainty that there is a foundation here for future developers to work on. Our legacy will have an impact on future progress and provides a point for future groups to jump off of in order to finish what we started. The updated ReadMe created in the repository will hopefully hold useful information to users that takes away from the research that would have been spent on getting key cloak working in the first place.

GitLab Contributions: README.md · KeycloakWithoutDocker · LibreFoodPantry / Common Services / Identity and Access Management System / Keycloak Research · GitLab

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

“Study the Classics” Apprenticeship Pattern

Summary:

This pattern is based on newer programmers that have not had as much experience in the field not having reference to earlier works that were instrumental in the development of the field of software development. The newer programmer will have less reference in understanding the context of how things are the way that they are in the industry, and will be surpassed by his colleagues who know the literature and understand laws and phrases used.

What I find most useful about the studying of classics in a field like software development is emphasis on trends of the industry. Programming languages and projects can come and go, but if classic literature can be used regardless of the time period that is read it implies that there is general education that can be done that transcends simple programming or development.

This apprenticeship pattern has somewhat changed the way that I think. I know that I would probably have to learn terminology that is important to software development, especially when working with teams. This apprenticeship pattern has, at the very least, made me more interested about learning classical literature in the field. Although on the other hand, it seems a bit difficult to me to disambiguate which type of classical book to read, and which type to not read. The pattern references “When you pick up a book and the first thing you wonder is how out of date it is, you’re reading the wrong kind of books”, but I’m not entirely sure how to come to that conclusion. Although I’m assuming that I can gain proper reference via an article.

I do disagree with this pattern a little bit. Studying a lot of classical literature seems to me like a dedication that can take a lot of time and energy. I think if I want to expand my education on classical matters such as Brooke’s Law, it may be more beneficial to read a second hand source that aggregates classical laws and their contexts rather than reading some of the classics cover to cover. While my view here might be ignorant since it is only based on this short pattern, it is the impression that I get from it.

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

Sprint Retrospective 3

The third sprint for my software development capstone class was on an honest note a bumpy road. The purpose of the sprint was to start the next level implementation of creating test files using mocha and chai and also making sure the API is validated and can be bundled properly. Through the first part of the sprint, the team has been very productive in keeping up with the issues we made for ourselves. After Spring break, our productivity started to plummet since we did not accomplish issues the following, we did not have our class meetings.

As for my team members and I, we have faced great issues that we started to come across that stumbled all of us. Due to facts of, lack of knowledge, merge requests, and was not able to accomplish all our issues for the sprint. First, when it came to merging requests, I admit we have gotten better at how Git operates. But when it came to approving the request assigned to us. We had a pile of request that was not merged and had to spend our class meetings squashing all of the time to keep the main repository up to date as soon as possible. Secondly, our productivity has plummeted since our spring break, we did not have to work on anything which was completely optional. However, the following week there was no class reunion and I made no effort and treated it like another extension of spring break. Third, as I gained a deeper understanding of the problem, I didn’t know how to deal with some of the issues. The other issues couldn’t be resolved and were interrelated, so we had to address them in the next final sprint.

Our team decided not to undermine our productivity. Especially if the third sprint is the last race in the podium category. We decided and wanted to be more active and help each other in the workspaces when there are things we don’t know or understand. Talk about gathering information on all the advice our professors can give us to put us on the same page.

As for me, I have done good things, but of course, I could have made better improvements and made a better contribution to our team. I wanted to know more about how the Mocha and Chai tests were implemented. However, I have decided to do more key pieces to solve the problem. However, in the next problem, we will use one or more of the problems we created to create a more robust test file that will pass all tests. Talk to team members who have done an extensive research to see if they can help you with modifying and implementing test files that have already been created. At least the experience provided.

Sprint 3 Issues

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

Sprint-3 Retrospective

Sprint 3 was a bittersweet moment for us. We were proud of the progress we had made. On Gitlab, we officially had tons of content regarding Keycloak. Including multiple branches of code, research written in our own words, and documented tutorials. As well as demo apps we successfully secured with Keycloak. But it also signified the end of our work in the class. We now had to allocate our attention to preparing the next class to continue work on the project. Which meant, a decline in our progress to the final product and the end of our work in teams. Which saying goodbye isn’t always so easy.

                Our first Sprint required us to provide massive amounts of research. Which made Sprint 3 smooth sailing. From the start we were geared to creating documentation. Therefore, many of our issues in Sprint 3 was not anything new for us. We had to continue making documentation. And that’s what we did. We wanted to get the next team on the same page we left off on as soon as possible. So, the team worked to create documentation explaining how our tutorials worked, and how to get them to work on any machine. We also wanted the next team to skip a lot of the speedbumps we came across. There was so much information I personally studied during all three Sprints that was not important to our team’s issues. Not that the information wasn’t good, it just wasn’t important for us. And it slowed much of our process down. Having that in mind really set Sprint 3 up in a way that left us feeling like we need what we needed to do.

I created documentation for our team’s history. ( https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/documentation/-/blob/main/History.md ) As well as documentation for Docker Compose File Examples ( https://gitlab.com/LibreFoodPantry/common-services/identity-and-access-management-system/keycloak-research/-/blob/main/Docker_Compose_Examples.md )

                For things I could have done better? Communication is extremely important. I was really locked in on this “Deploying Keycloak on AWS” tutorial during the beginning of the Sprint. I came across a couple speedbumps during my run, and I was awfully silent about it. That was a big hurdle to attempt alone, and I didn’t ask anyone for help. Not only did I neglect this information from the team, but I ended up abandoning that tutorial entirely. Which ultimately burnt my time and wasn’t beneficial for anyone. This is something I need to work on with myself for the future. That was a huge over-estimate of my own ability. And instead of being open about it, I was silent. At the time I was just sorry that I was not successful in completing the tutorial. But now I feel sorry that I simply was not communicating with the team during that time. For myself, I can’t let that fly. I need to be better.

                As for the team? I truthfully don’t have much to critique. I think my team is a great group of students and I am thankful for their work this semester. We always found the time that worked for everybody to get together and get the work done. Of course, we could always have better communication. But I only say that because I saw it happening within myself. This was honestly the most open and communicative team I have been a part of. Something that could’ve helped us a little more. Probably taking more advantage of screensharing software. I feel like watching things happen live on someone else’s screen could’ve been beneficial. I don’t think we did that enough.

From the blog CS-WSU – Andrew Sychtysz Software Developer by Andrew Sychtysz and used with permission of the author. All other rights reserved by the author.

Sprint retrospective 3

Here in sprint 3, things seemed to have progressed smoothly with the project in that we have finished most of what we have added in the product log although there were some areas of difficulty. The cohesion of the group has improved with better communication on what is to be done and the planning together seems to have gotten better. There are still improvements to be made but overall, the project is in a good state right now. The presentation also seems to be going well and should be alright. The quality of the sprint overall seems to be up and is providing good results.

On what has worked well, we have managed to get to the end of the semester and be able to finish a good amount of work on the project. We added more calls to the backend and continuously updated the API with new changes. The backend is set up with the proper semantic versioning. The android nest tester is functional and everything that we have built looks to be solid. The communication in the group looks to have improved as people communicated on what they did and were working on more than in previous sprints. The team also seemed to have gotten together more often to work on issues. The group stuck to what was planned pretty well and followed the timeline agreed upon. The issue board moved along more than the last sprint, issues were moved across the board compared to last sprint where nothing was moved until the last day.

On what has not worked well, there was unfinished work at the end of the sprint that now has to be sent over to next semester. This means that we have made mistakes during our planning on the difficulty of the work on the issues. The planning of getting the presentation done also could have been better. There probably should have been more dedicated time to get together and figure out the presentation as it felt a bit odd at the end figuring out what topics to do.

We could improve as a team by firstly, we could have worked together more regarding the issues regarding key authentication that we were unable to implement. There could have been chances to get together and try to figure out what was wrong and get it done by the end of the sprint. We could also improve as a team in our planning and plan more effectively on what can be done this sprint. We also could have been more planning with the presentation and knowing what exactly what portion each member was contributing with.

I could improve personally by putting in more of my input and getting my ideas out there. I also could have contributed more on different issues within the project. I also could have done better with working together with the group members such as when we were working on implementing the range call where it felt like backseat coding and I could have contributed more.

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