Sprint 6 Retrospective

This sprint we made huge advancements towards accomplishing our goals for the semester.  Unfortunately, due to the time constraints, we will not be able to produce a final product.  Hopefully, we will be able to provide something that the next class can build on and learn from what we are able to put together and pass on to them.

For this sprint, we each chose a different aspect of what was needed and each worked on different services that we planned to bring together at the end and the beginning of this next sprint before working on the presentation.  We ran into a lot of issues though during this sprint with having crypto-js importing correctly. I am unsure at this time whether the crypto-js library will be able to be used moving forward or if the team that works on encryption next semester will have to find a different library to use.  I do feel that we have learned a lot of lessons though. We were able to participate in a project the same way that we will when we start working after graduation. I believe that is more or less left to figure it out on our own and put into scrums will make the transition easier when we take on our first real-world project outside of school.  I believe that another part that worked against us is that none of us were quick enough or confident enough to step up into a leadership role to help guide the team and help make sure we were reaching goals throughout the sprint, as well as the other sprints.

This sprint I did learn a lot more about Angular and testing in Angular in particular.  The set up reminded me a lot of JUnit testing that we have done in the past. You start by declaring whatever variables are necessary at the beginning of the test.  If they are variables that you need to be repeated for multiple tests you can either put them under declare each or to declare once before any tests run. Then in your tests to state whether or not you expect to equal or not equal a specific outcome.  From there you will be presented with an output to let you know if the test either passed, failed, or failed to run successfully. I do hope that while we will not complete what we were asked to deliver, what we will present will help future classes and does not have to be thrown out completely.

The next sprint will be our final sprint and will also be a shortened sprint, roughly half the length as a regular sprint.  We will be preparing our final group presentations and it will be tough to do without having a set of deliverables to present to the rest of the class.  I do think that ours will be a little different than the rest of the groups as we will be focusing more the lessons that we learned from failing to meet the desired objective of this semester.

The White Belt

The White Belt apprenticeship pattern is one that focuses on your mindset when approaching new problems and learning new skills.  It encourages you to approach new situations from a point of view that you are a beginner. That can be confusing, it’s not to say that you should forget everything that you have learned in the past, just that while using skills that you may already have when learning new ones just keep in mind that you do not know the new skill and should approach it with an openness and readiness to learn as much as possible.

When I was in the Army we were constantly going through additional schools and courses to build our list of skills.  Whether it was general skills for service or specific to our job such as new routers or satellite terminals. With all this schooling we learned quickly that you need to realize that you don’t know what you are in the course for and are there to learn that skill or how that equipment works.  When you realize that you are a beginner you open your mind to the possibility of accepting all the little things that you need to know to help grow your proficiency with this new skill.

My first job out of college will be a Quality Assurance Engineer role and the company I will be working for does not use an object-oriented programming language.  This will be a large shift from college where I spent the past four years developing skills and learning new things centered around object-oriented programming languages.  I plan to take the skills that I have learned through the years at Worcester State and keep them in the back of my mind and use as a foundation, but I will approach it with a clear head that I don’t know what I am doing, but open and ready to learn what they teach me.  Another important point to keep in mind is that even if I think I know some it is important to find out how they want me to accomplish the type of task. There may be a specific way that the company needs it done, those reasons could be from a legal standpoint or just company preference.  I’ve learned over time that the specific reason why things are done a certain way may not get passed down and may not make sense at the time, but chances are they are done that way for a reason and there is a better approach and talk to your manager if you think you may have a better way.

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.