Studying the Classics

For this weeks Blog Post I will be looking into the pattern known as “Study the Classics” where one is but to study the classics. The context behind this one is that you are self-taught or valued skill training over theory. The problem that would arise from this could be experienced people collaborating with you are constantly referencing concepts that they have assumed you read. But since you are value practice over theory you may have skipped over this reading/research. This will of course cause some problems, perhaps nothing serious but will lead to some confusion between the two parties. A solution to this is go back and study the classics if you will. If you were to pick up a book and think how old or out of date this book is, then you are probably reading the wrong kind of book. Successful apprentices will tend to focus on long lived books (classics) and use the internet or through practice to see how the information has evolved exactly. A classic they give in the excerpt is “The Psychology of Computer Programming” while this is “dated” wit h its punch cards and room sized computer parts the book was non the less relevant with is wisdom. Classics portray vital information to keep you heading in the right direction down on the Long Road, another apprenticeship pattern. By just focusing on classics you may take it to far and abandon more pragmatic knowledge and information that would enable you to improve your day to day craftsmanship. A simple remedy to this is to just mix the classics with modern, pragmatic books and/ or articles to your reading list. A way for this to act is simply pick up the oldest book in your pile. Or if you are looking through another developers book, take not of the oldest books and ask them why they still own them, sparking a conversation relevant to its wisdom it gave. Overall this is something I see myself doing down the road.

Sweep the Floor

For this weeks blog post I will be discussing the pattern known as “Sweep the Floor”. Sweeping the Floor is about you starting from the bottom and then getting into the more complex tasks. This being you contributing to simpler tasks, learning from these and becoming more skilled then graduating into larger more complex tasks. Imagine you are an new apprentice on a project, unsure where you stand compared to others on the team and they are unsure about you as well. You want to earn your place on this team, contributing where you can, gaining their trust and growing in the craft essentially. To do this you could simply volunteer for something simple that is necessary to complete. This is a good starting way to contribute to a foreign team and to the teams success early on by showing you can do high quality jobs even for simple matters. Skimping on quality here could lead to trouble later on when it turns out later that this part is actually very important. Some various examples of these tasks include maintaining the build system, production support, responding to maintenance requests, bug fixing, code review, setting up a project wiki and so forth. Basically you would be focusing on the edges of the system where less risk lies rather than the heart of the project where the stress and complexity would be. But this of course could prove tougher to swallow if you have spent a lot of time and money in a computer science degree. The moment leading up to your career in theory has been doing all of the said above tasks almost just without pay. Another negative aspect of this would be you ending up as the teams gopher, condemned to do menial tasks no else wants to do. You may find yourself intimidated by doing anything other than sweeping the floor, feeling only comfortable doing this. There is also danger in that you may not be able to develop appreciation for bigger projects due to the smaller menial tasks you are accustomed to. In short finding the tasks nobody wants to do or complains about and creatively resolving these problems in ways that exceed peoples expectations will allow you to slowly soar above, something that most including myself can get behind.

Sprint Retrospective 3


This past sprint not much has progressed since the last sprint in all honesty. Since the last sprint we were given a few new details onto what we are going to be doing exactly for this project. We discussed the matters as a team going into some of the files, we were originally given from the ngl-2 repo. As the sprint went on we talked about what are task should be. We had ideas of what we wanted to pick for our team role. But never really solidified our decision only verbally talking about what we wanted.  We know what needs to be done or rather what the final product should be looking like. So now we will begin to start actual work on the project it would seem. With each team working on different problems like setting up a mock server and so forth. In short not much has really changed since last sprint retrospective but I personally feel we are a step closer in the right direction than previously. I am looking forward to working on this project with my team as we get closer to an end product.

The Deep End

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.

Breakable Toys

For this weeks blog post I will be looking into the Breakable Toy pattern. The context behind this pattern is that experience is built upon failure as much as if not more than success. This is something that most people will agree with that you cannot better yourself without failure or knowing your shortcomings. Say for example you are working in an environment that really does not permit failure yet failure is important to learn from your mistakes. This could cause you to play everything safe without being bold causing you to never truly get the most out of your job. By being bold, failing due to new tricks or the boldness can you grow into a better version of yourself when faced with difficult problems. In a way this pattern is very similar to Be the Worst, but that pattern is about finding a team where you can be the worst in order to grow. Breakable Toys is about creating opportunities to learn by going out of your comfort zone and single handedly building complete software projects. Using your favorite tools to build the worlds simplest wiki while still maintaining the highest standards of quality is an example that fits this situation well. The initial version will not be fancy in anyway but a simple user interface that lets you view and edit the plain text files. As the project moves along you can add more features and find new interesting ways to distinguish the project from the other pre existing thousands. Let your professional- interests guide you not the constrains of existing implementations. It does no0t matter what you decide to do in this project but as long as you are experimenting and learning from it you are growing as an individual. Back to the be your worst blog I wrote a few weeks back I completely agree with the breakable toy ideology. This is a very good mentality to have especially for your own growth one I would see myself using yet again.

Out of the Trenches

For this weeks blog post I will be looking into the pattern where are you told to “Stay in the Trenches”. Here you are advised to stay in the trenches even if you are offered release off the front lines into a much safer area. What does this mean in a modern day environment well you are on the “front line” to say of a programming job where you in a “grunt” position where basic programming duties fall upon you. One day you are offered a promotion where you will no longer be programming or doing to say the “dirty work” but in a more comfortable position. As it says in the pattern that most people always assume a promotion into management is associated with success. Thinking that if anyone is offered a position like that it’s a no brainier to take, meaning you are doing good.  The reason going into a management position where you are out of the trenches is that your mastery fades due to you not practicing it anymore. To counter this maybe working with your employer to find other rewards for your good work whether that be more pay or other nontraditional technical leadership roles. If your employer is inflexible then it is perhaps better to seek opportunities elsewhere. This pattern is very interesting to me as it makes a lot of sense to stay in the trenches for experience rather than dwindle. It also falls upon the person to decide whether or not they want to stay on the front line or go up the ladder into a management position.  Someone may feel more comfortable or even get more out of a management position instead of being a front line programmer. But again, that is all up to the individual and isn’t really predetermined in my mind. It all depends on what you want to do with your career and so forth so its hard to tell if I could see myself applying this method to a real life situation.

Sprint 2 Retrospective

For this past sprint we didn’t really accomplish all the much since we had no work provided to us. One of the biggest accomplishments was getting the ngl serve and ampath login working for myself. Kyle was running into the same issue I was having and the problem was easily fixed thanks to him. All I had to was go down a version or two to npm version 8.12 somehow that worked while other fixes did not. After this we reviewed some angular and had a week of review essentially. Then yesterday we were given new tasks to complete from the project lead himself. Now we have a direction of what to do for this sprint given to us through several YouTube videos made by the project lead. Each video contains specific details on what we must accomplish/what is needed to essentially full the order. So in summary not much actually happened since the last sprint due to not having any new work given. Looking forward to working on this project in the coming weeks with my team where we will hopefully tackle each problem/objective well as we did for the initial problems.