This pattern is all about taking a step back, a deep breath, and fighting through the struggles you might be having. The authors talk about the roller coaster ride that an apprenticeship can become. They include advice about what to do when you feel like you aren’t making any progress and how to fix the situation. Essentially, I think the authors wrote this pattern for people struggling to learn new technologies. It can be scary to jump into a project that you had never been familiar with before and the authors provide a confidence booster to help you bounceback. The authors say to set a time limit for yourself to go back and practice the things you already know and are comfortable with, once that time limit is up, go back and try to work through the new problems you might be having. Build up your confidence and keep the forward momentum going.
I didn’t find this pattern to be as immediately useful as some of the other patterns, however I chose this pattern because this situation can happen to anyone. I am sure that it can be very easy to become overwhelmed with a project that you are not entirely comfortable with. However, I don’t necessarily agree with retreating, even if it is only for a short time. I find that being resilient and stubborn can help you fight through your issues, spending consecutive time working on something can help you break through the obstacles that you didn’t think you could. I don’t really understand the actions the authors say to take:
“Pick something self-contained that you know really well and reimplement it. For instance, Ade likes to implement caching algorithms because they can range from the trivial to the highly complex. They also allow opportunities to reinforce his intuition about design and algorithmic complexity.”
For example, it is great that he likes to implement caching algorithms but what does that have to do with the project he is working on, assuming that it has nothing to do with caching? Going back and doing something you’ve done many times can certainly help build confidence but I also think it might be too much of a distraction to try and be productive. Overall, I think not giving up is the most important part of succeeding. If you need a break you could ask someone (like a mentor) to help you learn the process.
During this sprint, we continued to work on revising and testing our methods that we created. At first, I was responsible for creating the update method as stated in my last blog. I found the PouchDB API to be extremely helpful for this as it essentially gave me what I needed to create the update method. However, we realized that we could save lines of code by having the add method update the data if it already exists. This made more sense so I started working on the getDoc method. Here is a screenshot of the code I wrote:
This code is simple enough, but it was the tests that I struggles with through this sprint:
Our team is still working well together, however I have noticed a slacking in communication between each other. This is only normal as the semester is coming to an end and people are getting ready for finals and presentations and what not. If our team could proceed differently, I think that they would all agree that we were really close to figuring out the solution to our problems. Working with other teams and investigating the code they wrote helped us get another perspective of the code that we wrote. If we had more time we would also clean our code to make it much more readable with clear comments. For example, since we didn’t have the time to learn the correct coding etiquette our add method ended up looking like this (the thens and catches are all promises, which I am sure we could have done differently):
However, even though this code looks really messy and complex, it works and the test passes. One thing that helped our team progress through our struggles was using console.log outputs to see where the code would reach before failing. This was a very useful tactic for us. Another useful tip that helped us get through was the console on the karma testing screen. This had much more information about what was going wrong in our code than the webstorm terminal offered. Webstorm automatically opens the karma browser, you can press “CTRL+SHIFT+I” to bring up this window with the elements, console, source, network and more. You can also view and delete the database that you have created. This proved to be helpful for ensuring that our add method worked even when the tests didn’t. Here is a screenshot:
This screenshot sums up all of our troubles. In the webstorm terminal the test “passes” but when you open up the console here you can see how many errors it has generated.
After all of this we learned that a better way of going about testing would be to test that our methods are calling pouchDB’s method in the correct order at the correct time. We may have dove a little too deep into specifically testing every little detail about our own methods that it was extremely inefficient. We would definitely change the way we tested our code as it would have saved us some time and headaches.
This is probably the most important pattern I have checked out in the book by Dave Hoover and Adewale Oshineye. The entire pattern is about finding a mentor/master that helps you walk “The Long Road” with more ease. Allowing you to grow and cultivate your skills into tools that will be used for the rest of your life. The authors make sure to note that since our profession is still relatively young, there aren’t many recognized “masters” of the art. However, your masters don’t have to be physically available to you at all times. Maybe you read a book about someone’s life who really interested you and you begin to develop a passion for the things the author enjoyed, that author will be your master regardless of whether you talked to them or not. They may even be deceased!
The authors go on to emphasize that just because you are the apprentice and your master is the master, doesn’t mean that they are the one and all-knowing god of coding. No one knows everything. Be free to opportunities and don’t only talk to your master, learn from other masters and expand your mind with knowledge. Lastly, this chapter reassures you that there is no real risk to looking for mentors. While it may be difficult, the payoff would be huge for you. The only risk is getting rejected, which really is not that big of a deal. Most top-notch developers had memorable mentors to help them along the way.
This pattern will certainly affect how I go about things in the future. I had never really thought about going up to someone and asking to be their apprentice or “assistant” but I could actually see it working. I could see someone at a new job being a mentor to me but I could also see myself going to volunteer on a separate project outside of work just to get extra practice and that sense of apprenticeship. I really enjoy the thought of having a mentor, so that may be one of my next steps.
This sprint was not a complete success. We wanted to have some code pushed and maybe make a pull request to AMpath. However, our progress was delayed due to our inexperience in writing angular 2 methods and testing them effectively. I learned that testing code in a language you haven’t studied can be exceptionally difficult to grasp. I am still trying to work out the uses for toBe(), toThrowError(), toEqual(), and how the expect works in the test suite. Writing the method for the code seemed easy enough and I think I have the correct code, however it is hard to confirm when testing isn’t going smoothly. I understand that writing tests first would have been the correct way to do this, but I can’t write tests for code that I don’t know how to write. Therefore, I had to learn how the code worked and look at the API for pouchDB (which you can find here https://pouchdb.com/api.html) to ensure that I was using the correct calls and what-not. If I could restart this sprint, I would spend much more time on learning how to test in angular (sense that is the most frustrating part to me) rather than writing the code. At first, I was coding a method that was too complex, with the help of google I was able to finish my updateDoc method (as far as I know).
Our team is working well together, I think we could do a little bit better helping each other remember to do our standups and evaluations. Besides that we work really well together. I think we are all contributing equally to the project, so there is no problem there. As a team we feel as though we could have gotten this sprint completely finished in the allotted time if we had prior knowledge of testing in angular. However, it is what it is. Our next sprint will most likely focus around testing the methods we have created and tweak them to try to perfect them.
Our sprint plan was to finish this module, obviously that didn’t happen. Each of us was responsible for writing a method and Connor was responsible for testing. I wouldn’t blame Connor for the tests not being done because he still has to learn the testing procedures for angular as well and if he has to write a test for each of our methods, that is bound to take some time. So each of us has been pitching in and trying to debug together. This means that our sprint goal will most likely be extended to next sprint as this really is the last step to finishing off the Offline Storage Module.
I am interested to see what will happen when we (our entire class) conglomerates the code and tries to piece it together. I can imagine that some snags will occur and it won’t be very smooth at all. We will have to assign different people to test different parts of the entire offline module to ensure that everything is compatible with each other.
I chose this pattern this week because I really need to work on growing my passion for the craft. I need to sit down and find something I love and make a correlation to software. This pattern taught me different ways to nurture and grow your passion so that you can dive deep into complicated projects, for fun. The authors mention 3 other patterns to help you grow your passion. These other patterns are Kindred Spirits, Study The Classics and Draw your own map. These three patterns will help you take the next step to loving the software craftsmanship.
My favorite excerpt form this passage was:
“To grow your passion, set clear boundaries that define the sort of environment you are willing to work in. This might mean you leave work while the rest of the team stays late, that you walk out of a meeting that has become abusive, that you steer a cynical conversation toward constructive topics, or that you refuse to distribute code that doesn’t meet your minimum standards. The result could be that you get passed over for pay raises, promotions, kudos, or popularity. But these boundaries are necessary if you are going to break free of hostile conditions and keep your passion strong.” – Adewale Oshineye, Dave Hoover
Basically, the authors are saying to stick to your code and don’t let yourself be abused. If you or your skills are being abused in the work place, it can greatly damage your passion for working on software. You want to stay positive and continue to love what you’re doing, it is the only way to cease your passion from leaving.
As I mentioned before, this pattern is important to me because I need to work on finding my passion. It isn’t always easy to sit down and work on a fun project just for the hell of it, but this pattern shows me that it truly is invaluable. All you need is time and patience to further your knowledge and skills of the craft. Developing a passion is something that I have been trying to do with school projects and what not but it needs to be more. Being passionate about a project would just be a kickstarter to become passionate for every step of software development.
You can find this pattern here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s04.html
Our team, Everyone Else is making good progress with our first module. Sense we are solely tasked with creating the offline data storage module, we had to narrow our view. We had been worrying too much about how the other modules would work with ours and didn’t focus much on just creating the offline storage module. After our meeting today, we could tell we were more focused on our task and our task only. Connor created a flowchart on Balsamiq showing the flow of the data and where we stand in the whole project. Basically we just need to create the place to store data with appropriate methods and let the other groups do their legwork. I noticed myself going to ask questions to the team that really had no relevance in our current progress of the project. Instead of focusing on getting ANY items stored, we were worried about storing the CORRECT data. Realistically, we just needed to do tests with any JSON Object to ensure that it would work. That is what we are focused on now, getting our module working and worrying about the perfection later.
This sprint was a real confident booster for me. I finally sorted out all of my issues with the application. In case you find yourself in a situation where your app won’t build properly, I highly suggest trying “npm rebuild” in your project folder. This reloaded all of the dependencies I had previously installed and ended up working after the first try, even with pouchDB installed! I still feel slightly behind on knowledge, but working with my team I am learning more every day. I think if we had previous experience with this language, we would have a much easier time with it. However, for our team never working with angular before, I think we are making very good progress.
I am now in a position where I feel comfortable adding to and testing the project. The angular learning curve is steeper than I had expected but I am slowly making progress with it. I would be lost without my teammates. They helped me figure out the errors and save my project file. While I was struggling getting my code to run, the team had already taken a couple of leaps forward. We created the actual service and have a basic test implemented. We officially moved out of the research phase and are getting into the production of code. We each have our own method we need to implement by next meeting and I feel as though our progress will speed up tenfold.
I am in charge of creating the “put” method for our database so that we can easily add information into the database that we created. Caleb, Fuverion, and Ben will be writing the other methods. Connor will be doing the majority of the testing. With the tasks broken down into different jobs we should be able to efficiently finish this module pretty quickly and show it to AMPath for improvement.
This pattern relates to my situation almost perfectly. The authors assume that you are an undergraduate who has knowledge of one or more languages. However, the way we learn to use tools is not always the best way to get a deep knowledge of the tools we are using. The authors say that this knowledge is superficial. It is superficial because you have to look up what to do every time a new bug arises. This line sums it up pretty well, “what’s even worse is that because your knowledge is so superficial, you’re not even aware of how little you know until something or someone puts you to the test.” (Oshineye, Hoover)
I am a little different than the people they are directing this pattern to because I am aware of how little I know in the grand scheme of things. Besides that, the solution to this problem is not cutting corners. Don’t take those shortcuts that will help you finish the project 15 minutes quicker, learn to grind through the hard work and come out with the rewards of Deep Knowledge of tools, technologies, and techniques. I have spent a lot of time being frustrated with my own programs and this pattern helps open my eyes to how many shortcuts I must have taken. To truly understand everything about what your working on you need to develop the deep knowledge and the work ethic needed to get there.
My favorite part of this pattern was some of the advice the authors give. “Find out who first came up with the ideas and understand the problems they were trying to solve.” (Oshineye, Hoover) This has never really crossed my mind (I know, sad). I never thought to go all the way back to the origins of the problem. This will definitely be useful to me in the future. Another piece of advice that I always fail to follow is “when you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge.” (Oshineye, Hoover) I find that sometimes when on a time schedule or you are picking certain things from a tutorial, you feel like you don’t have time to fully go through tutorials and learn everything about the guide. While sometimes this is true, it’s more than likely an excuse to get the project done quicker. I will be diving more into tutorials rather than taking them at face value for their code.
Overall, I think this pattern is great for apprentices. It goes to show that many people take shortcuts and if you do the same, you aren’t building your knowledge the way you should.
How do you grow your concrete skills? The authors suggest looking over the CVs of the people you look up to or the people who know the skills you want to learn. Jot down their skillset and work towards learning them. This way, you are learning relevant information and working towards helping the company. The authors also stress going through your own CV regularly and updating it.
I really liked this pattern because it is directly related to my situation. I feel as though an employer will have to take “a leap of faith” (as the authors say) and hire me relying on my concrete skills to at least help a little bit on the first day. I need to sharpen and hone my concrete skills so that I have something to show my future employer. I will especially be practicing making toy programs that I can bring to an interview to show off my skillset.
What skills do you need? Looking at the CVs of employees that are already working at the company would be a good start to generate ideas.
One thing to think about is that each company is a little bit different, they didn’t mention this in the pattern, but I think it would be useful. Having these concrete skills especially helps in small startups that need the workforce actually working all the time. On the other hand, most BIG companies take your skill set and begin to work on it with professional training. If you feel as though you need to build up a resume, training through a big employer will certainly help more than being confused on a startup team that doesn’t have time to train you.
The pattern “Breakable Toys” can be found here: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html
This pattern is a little longer than some of the other patterns I have looked over. Long story short, Breakable Toys is a pattern designed to help you learn. Kind of like Be the Worst but is more focused on you as an individual. The problem is that you are working in a company that can’t afford errors to destroy their data/program/whatever (who can afford that?). However, the other half of the problem is that you are just learning this stuff and need a safe space to practice. You should create your own safe space project that relates to the problem you need to solve in the company, just at a smaller scale. This pattern tells you you need to build these breakable toys from the ground up to learn the insides and outs. Once you have these breakable toys, they are yours forever to use with other jobs and problems.
I thought this pattern was very useful. I was always told that if I want to learn, I have to do. That’s what this pattern is saying. You have to take the initiative and build these projects in order to learn. The best part is, failing only harms your breakable toy, which you built specifically to be broken!
The first line says “If experience is built upon failure as much as success, then you need a more or less private space where you can seek out failure.” (Oshineye, Hoover) I love this first line because it tells you that failure really is okay. That is how you learn. Being successful on the first try only teaches you what works for this situation but not for others. If you fail, you can learn a whole bunch about what doesn’t work and what does work. I don’t think you should intentionally fail, but failing will help you improve your skills and knowledge (so don’t feel too bad). The most important part about failing is getting back up and trying another approach. I could definitely see myself using this in my intended profession. I get worried all the time about breaking things that are important and this pattern gives you a way around that.
This sprint was particularly rough. Every time we were planned to meet, we had a snow day. Communication was lacking at this time because some people lost power and we definitely couldn’t go drive. Not meeting up with the team left me unmotivated because I had questions and errors that I would of benefited from asking the team questions in person. My team is working really well together. We are all included in a group chat where we remind each other of standups, CATMEs, and tasks we need to get done. We communicate often over texting. I learned that communication is key, especially in person. The reason why in-person meetings are important is because it raises the morale of the team and reassures the team that we are making progress. Now that I know this, in person meetings are much more valuable to me.
I will be honest and say I feel a little bit behind after this retrospective. I am not picking up this new framework as quickly as the rest of my team, but I am trying to get to the point they are at in their knowledge. What is great is that my team will share anything with the group that they think is useful. Caleb was able to get a working implementation of PouchDB into the Ampath App which is an excellent start to our task. Once we were all together we tried to store some data and it worked! It wasn’t exactly what we were looking for, yet, but we are just trying to understand how the PouchDB database works. I think our team has been taking the right steps to getting this project done, I am just frustrated that it is only my computer that the errors can’t be resolved. I could of definitely put more time into getting this to compile and I am working on doing that now. I will be proceeding differently by being proactive and on top of tasks. I don’tlike feeling behind, so I am going to correct that from now on.
The reason I feel behind is because of the struggles I am going through to get the dependencies to install correctly. I have tried every method that team members suggest but to no avail. I have tried installing pouchDB first, then all of the other dependencies our project needs. That made the webpack fail to compile. Next I installed all of the original dependencies, ran npm install, then tried to install the pouchDB dependency into the project and the webpack failed to compile again. I have tried almost every combination of these installs and they all made the webpack fail to compile. I became sick of the errors. I cloned Caleb’s directory into a new folder and copied all of his files into my existing project. I then reinstalled all the dependencies into the project and ran it, it worked perfect (without pouchDB), as soon as I installed pouchDB I got a slew of errors. It’s like the pouchDB dependency is removing some of the packages that I still need and I am working on how to prevent that.