This week I also read the pattern “Record What You Learn”, and this is a pattern that I am not anywhere near doing correctly. I think that this problem is useful, and though not as significantly as the others, still one worth implementing. This pattern is essentially asking you to take notes and record all of the things that you’ve learned throughout your journey. Taking notes does help in learning, but its real power comes when you actually go back and review these notes. The author alludes to the previously mentioned by suggesting that we keep our notes in a medium that we are more likely to access and interact with. Often times notes are taken in a subject specific notebook or application, the problem with this can be actually going back to this material to review it since it may lack that personal touch. This problem can be alleviated by storing your notes in a personal wiki, journal, or blog, the key being that this medium is personal and that it is something we interact with often.
The author emphasized the idea that your notes should be a “nursery, not a graveyard”, meaning that these notes should be a source of progress and growth and not stagnation. Even if you go through your notes daily, if you are only trying to memorize what is in your notes rather than trying to gain new insights and making new connections with them your time could be better spent doing something else. The other great benefit of having these notes is the fact that they act as some sort of wiki for you. The author mentions this and I have seen the truth in that myself. There have been times when there was a problem/bug that I could not figure out and the solution required multiple different things to be done, when I originally learned to solve the problem it may have taken me hours to gather all of the resources and information, but after storing all of those steps in my notes, I do it in minutes. Taking notes can often be too mundane and boring to actually want to do but this pattern has really showed me that it’s worth powering through it. By recording what you learn you have a detailed history of your grown, your own personal archive, and source of future ideas and innovations and because of this I will definitely try to apply this pattern as well throughout my career.
This week I read the pattern “Practice, Practice, Practice” and the focus of this pattern is pretty obvious. An expected theme that I came across when reading this pattern was the importance of practice itself, but the author went beyond that and specified the type of practice that is most valuable. The technique of practice that is optimal is said to be “deliberate practice” in which “ a mentor would assign you an exercise based on her understanding of your strengths and weaknesses…”. This method of practice is good because the exercises that you are practicing with match your skill level and most important of all, you are receiving feedback. Depending on your performance, this mentor would then decide whether or not increase the difficulty of the exercises. I can see the value in practicing like this, a big thing stopping me and many others from going back and practicing is how boring and mundane it is and this method ensures that you are amply challenged.
Another aspect of practice that the author mentions that you don’t often hear about is relaxation. The author says “if you aren’t relaxed you’re not going to learn from the practice”, in my experience this could not be anymore true. The practice that you are doing should be relaxing, it should be done without a deadline in an environment where you can break things without consequence.That brings me back to the level of challenge once again, this is because the practice should be done at a difficulty where you can learn but not too difficult that you get frustrated. Having learn how much being relaxed helps in the learning process I intend to use this going forward. The goal is to get to the point where you enjoy your practice sessions if you do not then you should likely change how you are practicing, and if that still fails then it could be because you don’t really enjoy the thing you are practicing.
The other major point that the author hit upon was feedback, this topic has been addressed in other patterns throughout the book and this is because of how important it really is. Yes it is true that practice makes you better, but practicing the wrong this will make you better at the wrong thing. Feedback is important because it makes sure that while you are practicing you are doing things right and developing good habits.
This pattern has reinforced to me the importance of practice, but more than that it’s showed me the importance of CORRECT practice. I plan on implementing this pattern not only throughout my software career, but on any skill that I want to develop in the future.
This week marked the end of the 6th sprint, and with this being the last one to write code and finish up our tasks it was very hectic. It was by far the most challenging sprint and also one of the most productive sprints as well. It was productive because we were able to wrap up the frontend and backend work, the challenges came when putting together the two. Trying to connect those two layers of the application really exposed lots of gaps in my knowledge that I would need to quickly fill up to have any hope of completing the tasks on time. Being more comfortable working on the backend I was able to get those tasks done relatively easily, but the front end is completely foreign. I had to learn about how UI components such as Checkboxes and Buttons work, how they get declared, and most difficult of all how to reference them and their values in the backend code. Working on this has given our team an even better understanding of how things fit together, and had we known that things would be this challenging before, we would’ve begun learning about all of this much sooner.
Like all of the other sprints, the team worked together very well. The work was very evenly divided and we communicated very well. Teamwork was a bigger part of this sprint than most of the others because we were each working on a different layer of the application. Even while working with all of these different moving parts, we were still able to quickly help each other out when errors and other issues came up with the application. Going forward we don’t plan on changing anything regarding teamwork. As for my own personal performance and participation, I think that I did pretty well. I tried to help out my teammates on some issues that they were having and reached out to them on mine.
As for what was done specifically, we added a checkbox that would allow you to choose whether you would save your credentials for later or not. I was in charge of the backend component which was essentially taking the boolean from the checkbox and setting up the logic to have it selectively call our new functionality or not. This had to be done while ensuring that the login logic that was already there still worked perfectly as before. Another one of my team members was in charge the the UI for the checkbox. We also had a team member working on writing some tests for this new functionality. Once that was done, lots of work was done on integrating all of these layers together and making sure that things work like we’d expect. While all of this was going on we also had other teammates working on documenting all of the work that was done, this in order to give a quick and concise summary of exactly what was done and how to use it.
That being said, this was a very successful sprint, there are still a few minor things to iron out but once complete, we will have a great product to show for it!
This week I read the apprenticeship pattern “Draw Your Own Map”, and it is on the the most inspiring patterns that I’ve read so far. This pattern instructs you to do exactly what its title states, and this is big for me because it gives me a sense of control. This pattern asks you to reflect about your current path, your current position and answer the question “is this really where I want to be in the future?”. If this the answer to the previous question is not a yes, and there is no way to alter your current path to fit with the path that you desire, then the author suggests that you leave, even if you are leaving a “great” title or fantastic salary. Of course what is being asked by this pattern is very intimidating and can be very difficult to actually do when the time comes. This is because from the moment we decide to go to school and take on a new career, the path is already laid out for us and society expects us to follow it, that is: get your degree, get a job, stick with that job and try to climb the corporate ladder there. That being said, there is nothing wrong with the climb if you are happy with where you are, the difficulty comes from taking the risk and abandoning what is sure and working for what you want.
I could not agree anymore with this pattern, and having read it it caused me to think about what some of my goals are. Though I enjoy learning about software and will be very happy to enter the field and work as an employee for a few years, one day I would like to start my own company. I’m sure that making the decision to leave a secure source of income behind a taking the financial risk of starting a company will not be an easy one, but that is what this whole pattern is all about. This pattern has changed the way that I think about the software industry and even working as a whole, it’s made me realize that in the end despite all of the technical challenges and setback that we will face in the professional world what matters is doing what you love, and this is a mentality that I will take with me throughout my career.
This week I read the pattern “Create Feedback Loops”. I thought that this pattern was the most one of the most practical of the ones that I’ve read so far because there are so many ways that this could be applied. I also think that this is one of the most crucial patterns that everyone should apply because it has the power of significantly shortening the time it takes to learn, as well as pointing out any potentially catastrophic errors in the way that things get done.
A great thing that this pattern was able to do was telling us some mechanisms that are available for acquiring this feedback. The ways of getting feedback included test driven development (TDD), using type-checked languages, as well as just simply asking a colleague. Of those provided, my favorite is TDD. I am a huge fan of TDD because it gives you instant feedback letting you know that the functionality is implemented correctly, but even more important than that, it lets you catch regressions even faster. I find that TDD is even more effective when someone else has written the tests, and when there are negative tests cases written as well. Fortunately this is something that nearly every tech company practices so I will not have to convince anyone of it’s value. The method of getting feedback that can be the most daunting is asking a colleague or boss, but it can be very valuable. It can be difficult to honestly assess yourself (as this pattern stated), so having the opinion of someone else can help give you a more true vision of your performance. When it comes to asking another for their opinion, the author hit upon a very important idea which is essentially that the given feedback must be “useful”. So if the feedback that you receive is negative and there is no way to grow using this feedback then it is absolutely worthless.
I agree completely with this pattern, and it is one that I intend to use throughout my career. The learning potential using this pattern is extremely high, and if applied correctly will lead to extreme success!
This week marked the end of sprint 5, and so far this one was by far one of the most informative sprints for me as well as the most productive. This week I got the opportunity to dig much deeper into typescript because I needed to implement some back-end code. I got a chance to actually implement some of the basics that I had been reading up on, such as declaring new variables and making variables visible from one class to another. I know these are some very basic things, but this was an important thing to do because it is fundamental to every programming language and having this foundation will help me build and implement more advanced functionality that we will soon need. I also learned that Ampath has some very strict code style settings. I had the build complain because I declared a public variable after a private one, and also because I had left an extra new line between two of my methods. I of course realized this after I had already pushed my changes up to later receive a message telling me that I had broken the team build. Had I known in advance that these rules were so strict, I would have checked the state of the build before pushing up my changes because even though this did not hold our team back long, this is something that could’ve wasted tons of time and should be avoided in the future.
The team worked very well together during this sprint, I would go as far as to say that this was the best sprint that we’ve had teamwork wise. I was having a few build issues and my team members quickly helped me resolve them so I could get back to work. The later on another teammate was having an issues that I previously had, they asked for help and I was able to quickly get them back on track. Even the way that we split our tasks was efficient, we had individual tasks that we would later link together. We would definitely like to keep this very high level of teamwork going forward and improve on it if at all possible.
During this week, the main focus was to get a checkbox or switch that could be toggled to decide if the user would like to save their credentials for later storage and let that determine what happens going forward. We were able to get that done, I was in charge of writing the back-end code (which was fairly simple) and Dominique was in charge of the UI aspect. That however was not the only work that was completed this sprint. There were improvements made to the offline detection that our code used. Previously we would know that we were offline because of a failed API call and our logic would run from there, now we use the service that was written by another group. We have also run some of our proposed changes by Ampath to ask for their approval.
This sprint, we have accomplished a whole lot and the coming sprint we plan on tidying up most of what we did. I believe that after the coming sprint, we will essentially have a nearly have the offline functionality exactly how we want it and we can shift gears and focus on other things like encryption, but in the meanwhile we will continue building on the progress we’ve had.
he team find the correct way to implement the offline auth gave me a better understanding of local storage and how web browsers like Firefox and chrome save data. Being able to use the same local storage used throughout the AMPATH application, we were able to see places that we may not have to use pouchDb thereby saving us some time. I wish I had known about this before because if I did, it would’ve sped up the time that it took to understand the correct implementation that would be required.
As usual, the team worked together very well. Our team was able to come up with a basic implementation because we all threw out ideas and tried to help each other understand the problem. My participation was extremely helpful this sprint because I provided some potential ideas/and approaches that our team could take, and some of those ideas were built upon to come up with the implementation that we currently have. During this sprint we accomplished lots, was able to locate some of the server side API code and looking through it helped me come up with a few implementation ideas that I shared with the team. Our team was also able to get the flow laid out, and we plan on sharing that with AMPATH soon to get their thoughts. Most important accomplishment by far was actually being able to save the user info when logging in and using that later on to log back in when offline. Although this implementation currently falls short of a few AMPATH requirements, it is a fantastic foundation that we will build on in the following weeks.
Having built this foundation cleared our vision for what we need to do next, and what we need to add in before we can really consider this complete. Currently our version of the app knows to use the offline auth to log in via handling of an error received when offline. This method is not the most graceful and is very limiting. Another team has completed a proper offline checker, if we had realized this sooner we could’ve easily used that instead. Integrating with the offline checker will be one of the first things that we do going forward. We also plan on having an API defined and documented, not only for our team, but for any other team that could need to integrate with our component. We also plan to communicate with the encryption team as well as the storage team, even if they don’t have a complete implementation yet we can at least try to agree on how our components will mesh.
This sprint went very well and we finally have a concrete product from it. The plan is to keep up the good teamwork and communication so we can accomplish even more next sprint.