Apprenticeship Pattern – Expose your ignorance

The apprenticeship pattern “Expose Your Ignorance” refers to the scenario in which you’re assigned a project but you are unfamiliar with some of the technologies that are required. Under the expectations of your colleagues, you may feel pressured to hide your ignorance so as not to seem incompetent as a developer. The best course of action, however, is to tell people the truth.

I can see why people might be uncomfortable with the idea of exposing their ignorance. However, I think that anyone who is more interested in actually becoming a better developer rather than focusing on what kind of developer they’re perceived as would be able to agree with this pattern. Sure, you could choose to pretend that you have the knowledge to complete any task already and then try to learn those technologies on your own, but there’s no guarantee that you’ll be successful. If you promise to deliver something and then later have to admit that you’re less knowledgeable than you initially let on, then you’re going to end up worse off. By admitting that you’re inexperienced with certain required technologies and asking questions, you’re able to show that you’re capable of learning while also being able to learn much faster with the assistance. One common phrase that I see commonly used is to “fake it till you make it”. I don’t doubt that there are some people who will look down on you for exposing your ignorance, but as long as you continue to focus on learning as effectively as you can, then you’ll be much better off in the long run.

One of the things I found interesting in the excerpt was to write down five things that you really don’t understand about your work and to put it where others can see it. This is definitely an extreme way of exposing your ignorance, but if people who see it are able to answer your questions and cross off an item on the list, then you’ll improve far faster than if you were to try to do the research alone. I’m not saying that you shouldn’t try to solve problems on your own, but it’s in everyone’s best interest to seek advice whenever they feel like they lack knowledge.

Sprint Retrospective 4

For this sprint, my team and I continued our work on trying to mock the server aspect of the project so as to give other teams a way to test their code. We had followed the tutorials on nock to make sure we understood the way that it worked and how we would have to translate it over. However when we went to the AMRS code to try to find something to try to mock we ran into some problems. Going through the code, there is a lot of moving parts to each element with the program which made mocking just one thing look like it may not be possible. Not only that but almost everything we found looking through the code, returned html responses from the ng-AMRS server they have set up already. For example one of the main things we looking into mocking was the patient-creation-resource part of the simple App, since it seemed to be one of the smaller files and less requirements/calls to other classes. In trying to mock one of the methods from this, this is where we started to feel that this may be a little too high of a task for us without the AMRS server itself. I feel as though if we had access to their already made server and could have just mocked the tests at that point we would have had much better success. There were just too many moving parts to each thing for our current way that we planned on mocking to be realistic. During this sprint though, I feel we were able to work more on the project and were actually making headway till we hit the wall on what we could actually wind up mocking. At the end of this sprint we also started talking about the possibility that we might not be able to achieve what we set out to do originally, so we also started looking at the bottom navigation bar element that still needed to be completed. We chose this as our backup and I had started to get some of the smaller stuff out of the way for that. I have gotten together all of the CSS and HTML components for the bottom navigation bar with what was provided from Greg Schmidt on the Zeplin app. Since this seems to be the direction we will be heading in the next sprint I felt it was smart to try to get ahead on some of the smaller/easier stuff. What I will need to be looking into and finding out how it works is the button elements that Greg Schmidt wants and how I can recreate them.

Apprenticeship Pattern – The Long Road

The apprenticeship pattern “The Long Road” is a pattern for those aspiring to become master software craftsmen. For these people, the path that should be taken differs from what is expected from them. Rather than trying to climb the wealth ladder by taking every promotion you can get and enter a less programming-oriented role, you should continue walking on “The Long Road” by focusing on learning and long-term growth.

This pattern is really interesting because it’s a path that focuses entirely on honing your craft rather than salary. I’m sure most people would jump at every opportunity that offered them more money, regardless of what the job actually entailed, so long as they considered it a “step up.” This is a different, legitimate path to take, but it won’t necessarily be the same path as the one to master software craftsmanship. It’s entirely possible that in the long term, focusing on learning and long-term growth would get you “further” down the path of mastering software craftsmanship.

I’m still not entirely sure if it’s the path that I want to take, as it’s difficult to pass up short-term gains. It’s easy to say that you want to walk the long road, but when facing a fork in the road it may be hard to continue. Although, I’ve heard many stories of people who took a higher paying job only to end up regretting it due to lack of growth, poor work-life balance, boring work, etc. That being said, I don’t think that I’ve experienced the industry enough to decide what path to walk. So it’s difficult to say whether I agree or disagree with the pattern, but focusing on improving yourself would likely not lead you down the wrong path.

Imagining strange roles that you could be in 10, 20, 30, or 40 years from now and what you did to end up at those points is an interesting exercise that I think would help people figure out what they want to do in life. Obviously it’s not necessarily guaranteed that you would have a breakthrough from just thinking about it, but you might realize that you don’t like the path that you’re on right now or maybe your dream role has an entirely different starting point from where you are now.

Apprenticeship Pattern – White Belt

The white belt as an apprenticeship pattern is what it sounds like. You are at the beginning of your journey and have a deep understanding of your first language. The problem arises when you are struggling to learn new material and it is harder to piece things together than when you started learning your first programming language. The author relates the solution back to Star Wars quoting Yoda, “You must unlearn what you have learned”. By doing so, this accelerates the learning process because you don’t try to relate things back to your current language but instead connect neurons together when trying to understand the new concepts you are learning.

I agree with the many things the author taught in this apprenticeship pattern. That too is how I learn new tools and technologies on my own but on the other hand, I always try to relate it back to my strongest, most knowledgeable language, and see if there are similar concepts and if there are ways to carry out a task more efficiently.

Sprint Retrospective 3

In this week’s sprint, we reviewed videos provided by Greg Schmidt, detailing what he wants from us to complete. From these we were able to see the possible directions, we as the team, could take to completing some of these story tasks. Our team, team Tapmah, was split between designing the bottom navigation bar or working on mocking the server for the project. Ultimately, we decided that we should focus on mocking a server that all groups could and would need to use to test that there aspects of the program are working. One utility that Andrew found that we have started to explore the use of is Nock, a mocking tool that is used for test modules which rely on http requests. When Andrew found that, I started looking into how this mocking works, finding several videos on Youtube which helped. It was through these videos that I found out about a feature of “mocha” called hooks, which is something that I had not seen previously. These hooks allow you to define code that will be run before or after each test suite, which is how we will be able to mock these servers. Learning about this mocking will definitely help me in the future with project, now having this knowledge. Knowing about this now and looking back at previous projects done with API’s I feel this knowledge would have helped me in testing some of the features I had tried. Also during the week I had looked at the video’s by Greg Schmidt about possible items the team may need to “mock” when other teams start requiring tests for their contributions. Some examples of things that will need to be mocked by the team will be the navigation points for the bottom bar, patient list, separate form selection, and multiple tabs. Each of these items will need to have a mock test to know that they are working as intended, without requiring an actual server to be getting replies from. Another bit of information that I found while doing all this research, as coding work has not really begun much yet, is that something like does have its downfalls with things like if the http response is complex.

Apprenticeship Patterns – Sweep The Floor

Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.

Apprenticeship Patterns – Record New knowledge

Hi everyone and welcome to another CS 448 Software Development Capstone blog. Today blog topic is about one of the individual apprenticeship patterns which happen to record what you learn. I wanted to read more about this pattern because I can relate. Ever since last semester I been writing many blogs and didn’t fully understand why I was posting them. At first, I thought this method of recording what I learn was to help us research more information and writing them as blogs would help us understand the material better. After reading this, I realize that it’s just more than blogging once per week. I understand that recording our journey helps keep vital resources, makes our journey explicit, and can be helpful to many others. I feel like after reading this individual apprenticeship pattern I will change the way I work because all this time I was blogging, I didn’t really blog for purpose and just blog because it was assigned so I think I will be more efficient when I blog now. I also picked up a new idea from reading this pattern which is to have two journal that is private and public. I can use the public for sharing what I have learned and gaining feedback and the private one for me, to be honest with my status in programming. I do agree that it best to have both because of the perks that each offer. I like when the record what you learn pattern state that Dave was constantly posting his journey for years and eventually, he had tons of resources that he then later uses later in his career. The reason why I like this statement is that it makes me more motivated when posting these blog assignments because I know that eventually, it will come in handy one day in my career. All in all, I felt like this individual apprenticeship pattern, record what you learn is very informative. I learned that every apprentice should keep a journal for their journey and try to write every day as one day it will help others and even help themselves.

Sprint Retrospective 2

During this sprint there was not much for me and my team to get done other then getting the program to be able to work on all of our computers. I feel as part of this sprint was also combined with the first sprint, hence why we still trying to get the program to still work. At first there were several issues for all of us, with all of us getting a massive amount of errors when we first tried to “build” the program. It was during this sprint though that I was able to educate myself further on things that I had started to learn last semester with Angular design and testing of code. One of these errors that this program presented when we were first trying to get it to start was a problem of “circular dependency” which was one problem my program was having building. After looking for sources on this and learning about it I found it was essentially because in the files of the program, multiple files are depending on each other but had not been imported/exported properly(source). Another problem that my team and I had thought could be the problem for some people’s program not building was their version of NPM, or rather the dependencies they had installed with their current version. While everyone else in my group was on nearly the most recent version of NPM, I was still running on version 6.4.1. Yet I did not have issues with NPM because I believe I had installed the correct one with correct dependencies in the previous semester for CS-343. I had issues that my team couldnt help with because we were not experiencing any of those issues from a mac. I feel that this being the first time I had worked in a “scrum” type environment was interesting, having only just learned it in CS-348. Despite all being individually working on getting the program working, as a class we all worked together to try and solve each others problems. When one person would find a possible fix to an issue they would share it, and then through the collective effort someone would find a fix. Going into the next sprint though, something I will be looking for more is a better understanding of the goal of the sprint. This past sprint felt very scattered still with some people not being able to get their program working still at the end of the sprint.

Apprenticeship Patterns – The Deep Ends

For this weeks blog post I will be looking at the pattern called “The Deep End”. The context behind this one is that taking small safe steps leaves you unsatisfied and you are beginning to fear that you may be in a rut. Instead of diligence that could attain the next level you are in a rut where bland competence eventually will decay into mediocrity. The problem with this is that you need to grow your skills, confidence and portfolio of successful work. Challenging yourself with bigger things like bigger projects, larger teams and more difficult and complex tasks, new workplaces and more. This will again help you grow as a developer instead of settling for a rut. The solution to this is to jump in at the deep end, taking it head on almost. Waiting until you are “ready” can turn into a disaster or a pattern of never doing anything. When offered a higher profile role or a more difficult problem grab onto it with both hands take it head on. Personal growth will only occur if you are doing something out of your comfort zone and doing things that stretch your boundaries. This of course will have its risks without a doubt. If you get it wrong and way in over your head you could drown. But thankfully in the business there are many places where you can take risks without destroying your career if you were to fail. These risks are opportunities that will help you grow. It means taking a foreign assignment when its offered, even if the possibility of failure is staring in your face. Acting on this will be extremely beneficial to you when in a rut. Thinking of the biggest projects you have worked on and then writing down the answers to these questions pertaining to the difficulty of other projects is a good way to start. Using metrics to measure every project, in a sense, of your own projects. I find this pattern to be very on par with the be the worst mentality. In a sense you are putting yourself in an environment that may or may not cause you to fail miserably but if you succeed you will grow immensely.

Apprenticeship Patterns – Rubbing Elbows

My blog post this week will be on the chapter “Rubbing Elbows” of Apprenticeship Patterns, in which the reader is encouraged to seek out working with another fellow software developer. The basic thought behind this is that if you develop software alone you can reach points where your learning can stagnate, and cooperative work can get you to learn things in new ways. One very important point that the author made was the aspect of “micro-techniques” (small ways one developer has found to handle certain problems or situations) and how important learning them from other developers can be. This is important to me, and should be to others, because I feel I had to figure out how important those “micro-techniques” are first hand. When I first started working with software I was very independent, not wanting other people’s help. But, the longer that I have worked with software, and just worked in general, I have found out how important it is to see problems and fixes for them from other people’s perspectives. Towards the end of this pattern, the author again points out this importance of being able to see problems from others points of view, even if in the end you do not agree with another person’s perspective. One thing that I found interesting, and wound up doing more research into, was the idea of pair programming. The idea behind this programming technique is to have two programmers work together on one terminal with one programmer writing the code, while the other reviews each line written. This approach of matching a journeyman programmer with an apprentice I can see being very effective way for both the apprentice to gain critical knowledge and for the journeyman to progress further towards becoming a master by passing on his knowledge. One downside to implementing this technique with pair programming that the author points out is that the apprentice may often feel lost, but I feel this can be combined with another one of the patterns(Expose your Ignorance). In essence I feel that as the apprentice in this case, you have to be humble, acknowledge you won’t know much, and to ask a LOT of questions. Don’t ask just  one person these questions too, but ask other’s the same questions to see their perspective on the same problems.