Dig Deeper

Dig deeper is a very important apprenticeship pattern to remember throughout your career and especially one to pay close attention to early on in your career.  It stresses that just writing a solution that you found online or just guessed until it worked is not good enough. It is important to know why the code solved the problem that you were having.  You should also look as to why was this the chosen solution, why code A over code B. This will help you stand out at work as someone who is a more effective problem solver. This will also help so you don’t submit a project that is only half complete; maybe the question that was answered on stack overflow did not include a test that was specific to your work.  If you do not dig deeper into your solution you may not realize this and turn in an unfinished project. When you only scratch the surface and just barely do enough to get by or even less than that work falls to others. There is a set amount of work that needs to be done for each project. Just because you do less doesn’t mean less work needs to be done, it just means that you are putting a bigger burden on the rest of your team that needs to complete their own work and pick up your slack as well.

When moving on from school I intend to make it a point to set aside time to review all the work that I complete as well as try to fully understand other parts of the program that I have a chance to see before submitting my work.  I think this will be beneficial for a few different reasons. First it will help set an impression with both my peers and superiors that I am a thorough worker who puts extra effort into my code. More importantly though it will allow me to expand my knowledge and provide the best possible solution for the problem that I am presented with.  It will help a well rounded tool kit that I may not only use immediately but could be applied in the future too. Doing this early on will create a solid foundation to build on for the foreseeable future.


Sprint 5 Retrospective

This sprint felt much more productive than the previous sprints from my perspective.  I think that is mostly because we did more than research or creating test programs. This sprint we started writing services for the AMPATH project.  We created an encryption service, at this time it specifically focuses on hashing passwords. We also added a test for this method simultaneously, by the end of this sprint though we were unable to run the test successfully.  Moving forward that will have to be one of the focuses is to get this test working, I believe that it is necessary for us to get this test successful in order to use it as a template for creating our other tests. There are two pieces of wisdom that have stuck with me that I believe will really come in handy for this next sprint.  “Slow is smooth, smooth is fast” and “Those who fail to plan should plan to fail”.

If we rush into writing other tests without building a successful one I think that there is a very high chance that we will get in over our head with too many tests that will fail for various reasons and we will start to try and fix different issues at the same time and just creating more issues.  If we take our time and focus on fixing this test first then we will have a clear picture of what is needed to write successful tests. We need to slowly approach this to help the project from a larger perspective move smoothly and at a good pace.

Since we are quickly approaching the end of the semester and the end of the project, everyone participating in the next sprint planning meeting is crucial.  If we do not take the full opportunity to carefully plan out what we will each be doing over the next week and a half the risk of us falling incredibly far behind to not be able to produce any meaningful deliverable to the project and negatively affect the ability for the other teams to effectively move forward on their own projects.

The service we did write however is a good start, we created an encryption directory within src/app.  In this, we created a hashed password service that takes a string and hashes the string. In the spec service for the hashed password, we wrote a test to test if the hashed password does not equal the original string that was used as a test password.  The test originally failed and produced the error that “Cannot find type definition file for ‘source map’.” After doing some research I thought I found a solution for manually adding “@types/source-map” to the package.json folder. After adding this and running ‘npm install sourcemap@latest –save’ the new error that was given was that there were now conflicting definitions for source map.  The solution on stack overflow that I found called for doing both, but I will now try removing the line from the package.json folder and see if that produces any significant changes. Depending on what that produces will determine the direction that we move in from there.

Breakable Toys

When starting in a new work environment, especially when stepping into a new craft as an apprentice you only want to produce positive results, even though failing is a great learning tool.  A good apprenticeship pattern to develop is to create breakable toys. Develop personal projects that you can afford to fail on and break so that you can learn these valuable lessons without it having an impact on your performance review and without risking your job.  These can be programs, servers or anything else that mimics your work station and helps develop your toolset. The important part though is to remember that it while it should mimic your workstation it should not intermingle with your work by any means. This could lead to massive problems if you break your toy and it negatively affects your work.  You also don’t want to run the risk of breaking any confidential agreement that may lead to legal trouble beyond just losing your job. This is not a pattern that should just be applied blindly; you need to apply a basic level of common sense of whether or not it would be ok to include things that you may have gotten from work onto an unsecured system.

When I start my new career I intend to mock my work station at home to the best of my ability.  I will use this to create similar projects to the one that I am working on so that way I can have more freedom trying solutions.  While that is part of what version control fixes this will allow slightly more freedom to try things that shouldn’t work and take the time to see why they don’t work as a viable solution to the task at hand.  Then as time permits I can create new projects that are not associated with work and expand my toolset to work on mastering new areas of my craft. I know for myself that I learn better by doing something hands on rather than in a visual manner.  Creating a personal workstation will allow me to further develop my craft and skills that I need to succeed in this new role. It will also allow me to explore and create any personal projects that I may find interesting that will help develop a broader toolkit that may come in handy later in life.

Learn How You Fail

Everyone is going to fail at one point or another in our lives.  Those that do not experience failure haven’t tried; failure is a part of living.  The important part is to see what these failures are, see what setbacks you face and what you are going to change moving forward in order to try and keep from repeating the same failures over and over again.  It may also just mean recognizing when things are heading in a direction towards failure and cutting your losses.

This is another apprenticeship pattern that I believe can be applied to any other profession and also extends to all aspects of life.  Early on in my career in the Army, I saw my share of failures and mistakes. The Army knows that this will happen and that is a big part of basic training.  Making mistakes and realizing that a lot of the time it is not the end of the world. The important part is to not dwell on your mistakes and feel sorry for yourself, but instead to identify what caused the failures and change your habits or actions to prevent that mistake from happening again.

Starting at a junior position I will be in a position to make plenty of mistakes and fail multiple times.  I am excited about this opportunity because while I understand that failure should not be celebrated and we showed be striving for success, it does give me the chance to learn and grow in this field.  It will give me a chance to stumble and interact with my superiors who will provide guidance and pass along what they have learned. If I stay away from any position or role that has the opportunity for failure means that I have also stayed away from any role or position that gave me a chance to succeed and progress toward a mastery of the craft.  Taking risks and running the possibility of failure is what will help me grow in this trade and pass that knowledge along to others that I work with and those that come after me and hopefully leave the field a little better than when I came into it.

Share What You Learn

Share what you learn is a pattern that believes that in order for new apprentices and others to learn we need to share what knowledge we have.  This is a very important apprenticeship pattern that is looked over often. Passing along your knowledge is what allows future generations to improve standards and practices.  It may also help your peers fill in that missing piece that they may need in order to complete a large project that they are stuck on. With the advancement in technology, it is easier than ever to share what you have learned with almost anyone around the world.

My past work experiences have instilled in me that this is absolutely true.  When I joined the Geek Squad at Best Buy I had a base level of technical knowledge but was not an expert by any means.  Thanks to the other employees sharing what they knew as I watched on for the first few weeks. This allowed me to take in and learn from what they already knew instead of being on my own to figure out what the specific problem was, research the different possibilities that could have caused this to occur, and finally trying the different solutions through trial and error.  This not only made my life easier but created a better experience for our customers. They got their device back sooner because we already had a good idea of what the problem was and they were able to start from the most likely solutions and work out from there. It also made them feel more confident in our abilities to work on their unit. While some may know that there can be different causes for a problem and a solution could be as easy as turning it off and on again, most customers that I interacted with did not know or understand this concept and would sharply lose confidence in us if we were not magically able to touch the device and have it fixed so the quicker we are able to do so the better.

As a brand new apprentice, I will not have the ability to follow through with this pattern right away I will be able to, and plan to, take full advantage of others sharing what they have learned and absorbing as much information as I can to better contribute to the team and the final products.  I do believe that it is a very important pattern and as soon as I am in a position to help pass any knowledge that I have along to others in order to help them improve and develop in their trade I intend to take full advantage of that opportunity. It will help improve on three different aspects.  First, it will help the apprentice to develop a stronger toolkit moving forward. Second, it will help you develop leadership skills and presentation skills. Lastly, it will help your trade as a whole, having more skilled tradesmen working will help create better products and practices.

Sprint 4 Retrospective

This sprint was a little different than the others because the week of spring break was in the middle of our sprint.  I think for most of the team, and certainly know that this applies to myself, that the week of spring break threw off my rhythm of work.  I had plans for things to accomplish, but other things kept coming up to include taking a break from all school work and reset. Although we were able to accomplish several of our goals and move forward as a team.  We worked on different basic programs that used encryption in order to try and find which library would work best for this project. In the end, we chose the crypto-js library. Crypto-js is flexible enough that it can effectively encrypt a string to allow us to accomplish our goal of encrypting passwords.  It will also allow us to encrypt objects so that will make it easier to encrypt information inputted by the users. From what we can tell so far this will cover all of the encryption needs that were laid out in the user stories at the beginning of the semester.

We also talked and realized that we may not be moving at the best pace and are not where we are all happy to be for the project at this point in the semester.  It’s important that we realize that we can’t go back and change what has happened earlier in the semester. All we can do is realize what we may have done wrong and fix those issues moving forward to the rest of the semester.  We discussed it a little during our retrospective and will talk about it more when we plan our next sprint. We will keep the lessons that we learned both good and bad while moving forward and accomplishing as much as we can for the end of the semester.

As a positive, we realized a good formula for our team in regards to breaking up the larger tasks into smaller more manageable individualistic tasks for team members to accomplish.  I feel that we have developed a good level of communication throughout our team. In my opinion, I believe that it took us a little longer than we all would have liked to get to this level of comfort and ease of sharing ideas that we may be a little nervous of that is not one hundred percent correct and the best solution.  We have developed a more open communication and I have noticed that we are starting to share more ideas and that will help us for the next couple of sprints to effectively produce a product that can help the Ampath project improve.

One obstacle that we need to realize that we need to get over is that while we may have to write a basic encryption service we will also have to develop more communication will all of the other teams and work together to write the code that will go into each of their services that the other teams are developing.  If we don’t do this then all of the teams run the risk of the services not syncing up on the encryption level or the teams trying to use different encryption libraries because we did not proactively work with the rest of the class to prevent that issue from occurring.

Sprint 3 Retrospective

I feel that this sprint was good from the aspect that during the planning phase we seemed to come together more, and everyone added more input into tasks to break the items on the product backlog into and which ones we felt that we could accomplish during this sprint.  I feel that we are starting to hit our stride and be more comfortable as a team voicing opinions and ideas to each other.  Even though we are approaching the halfway mark in the semester without making too many contributions to the project.  From this last sprint into this upcoming sprint, each member of the team is making a bare-bones application with each one using a different encryption method.  When we meet again we will all have a better understanding of how encryption is applied in Angular and we can effectively suggest an encryption method to the Ampath team.   After that, I feel like we will have better direction and a better sense of purpose as a team since we will be working on services that can be applied to the project and feel more like we are contributing.

While our communication improved during the work classes we still have a lot of work to do communicating outside of class.  Some of our work classes were canceled due to snow and I believe that negatively impacted our team more than it should have.  Someone mentioned during the sprint review that the sprint would have gone better if we had been able to have more work classes.  While I don’t disagree with that statement it did make me think; did we utilize our time and communication ability between classes as much as possible?  I cannot honestly say that we did or feel like we accomplished all that we could in the time allotted.

I was assigned to create an application using crypto-js.  My first step was to do research, this included three different areas to focus on.  The first was encryption in general to get more familiarity with it, the second was how encryption was implemented in Angular, and the third part was to research crypto-js and how it was specifically implemented.  I found several examples of how to insert the encryption code into a program as well as one to create an Angular app to encrypt a file.  I lost the link to the site and am on the hunt to find it again, I was lucky enough to have downloaded the sample code already.

I hope that after spring break we can accomplish more as a team during our sprints and feel that we will after hitting these setbacks and discussing our team shortcomings at the sprint retrospectives we will keep improving every time.  After this upcoming sprint, we will be able to choose an encryption method with reasons why to back it up when we present it to Ampath.  Then I truly believe that we will have a renewed sense of purpose that will give the team the drive we need to meet our project goals by the end of the semester.