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.
This week, I read the apprenticeship pattern “Read Constantly”. Out of all the patterns that I’ve read so far, this is the one that will be most difficult for me to implement. Although this pattern will not be the easiest to implement, I think that I will be worth all of the effort because how much it will really increase your market value. The industry is always changing, and it is essentially impossible to keep up with all of it. There are new technologies coming up, old technologies changing and other technologies becoming obsolete, the most valuable engineer is the one who is aware of most of these changes.
Constantly reading has both immediate and long term impacts on your career. In the short-term you can choose to read material pertinent to you current line of work. This might involve deepening your knowledge of a concept that you’re somewhat familiar with. This reading if done consistently can lead to one becoming knowledgeable of how multiple components come together and interact. If the reading you choose to do is focused on the short term, you may find yourself being recognized by your team as the “go to” guy for a wide variety of question and once that occurs, your value as an employee has rocketed. In the long term, constantly reading makes you extremely marketable. This pattern applied with even a tiny bit of consistency will lead you to having a great understanding of the ENTIRE industry as a whole. Having this general knowledge is already a leg up on the competition, but if you choose to apply and experiment with what you’ve read, you may find yourself comfortable with many different programming languages, frameworks, operating systems, etc. Armed with this acquired knowledge and skill, you now have a solid foundation that can be build on going forward in your career.
The value that this pattern has is evident, there really are no drawbacks to this one at all. The one difficulty with this pattern may be time. It is possible that you find yourself having barely enough time to handle the work that you have, never mind having time to do some extra reading. Even with the time constraint, I still intend to apply this even if I am not reading “constantly’.
This week, I read the apprenticeship pattern “Learn How You Fail”. To quickly summarize, this pattern asked you to stop looking at your successes and start actively seeking your failures and weaknesses in order to learn from them. I really liked the message behind this pattern because it is different from what we are accustomed to. It is normally very easy to focus on getting better at something you are mediocre at, and even easier to focus on getting better at something you are great at, but it is really difficult to confront your shortcomings and approach what you are terrible at. My interpretation of this pattern was that it doesn’t seek to discredit the good aspects of your skills but rather putting a focus on the bad as to make you a better engineer overall.
This is another applicable pattern for me personally because I still have a few areas of weakness in my development skills, even in some of the technologies and languages that I’ve been using many years. I have caught myself opting out for a simpler but worse performing option because I didn’t want to confront an area of weakness needed to implement the better solution. The other key aspect of this pattern in accurate self assessment, asking yourself “am I really this good at X, or is there major room to improve there”. I often find that we normally give ourselves the benefit of the doubt and say “Yes we are that good”, and this closes out any potential opportunities to actually improve. What this pattern teaches is to really ask and assess deeply and even ask for an external opinion (via peer review) for areas of weakness.
I agree with this pattern and I plan on implementing this going forward in my career. This pattern should be fairly easy to apply because of its practicality. If you are weak in a skill that will no longer needed, the pattern suggests that you shouldn’t waste your time with that and focus on more important areas of weakness. The only challenge to applying this pattern will be the reluctance to do what we are not good at, but I believe that overcoming this will be much easier if we think about the benefit that will come from fixing our weakest links.
This week marked the end of Sprint 3, and during this sprint I feel like thus far this was easily the most productive sprint. Although we did not spend too much time writing code, we did do a substantial amount of planning. I think that the planning that we’ve done will make producing our component that much easier and because of this I am looking forward the the following sprint that much more.
Although the majority of the following sprint was spent planning among our team and others, I still learned some things from it. Our team spent time trying to understand the way that they currently do authentication and what changes we’d need to make to be able to do it offline. Investigating the auth code forced us to go deep into the code. We started from the ui and followed the code until we found the REST call that is made to the server to authenticate. Having followed the code to this extent, the team and I now have a very clear understanding of how it works. This investigation has also revealed to us that we may need some access to their server code as to understand better exactly how the user authentication data is queried from their end.
Had we known from the beginning that we would’ve needed some access to their server code, we could have asked them from the beginning of the sprint and save some valuable time that was wasted searching for it.
As usual, the team worked very well together we did a great job breaking the tasks down and evenly spreading them out among team members. As for performance, we completed more tasks this sprint than previous sprints but the best thing that I think came from the sprint was the discussions that we had, every member of the group contributed their ideas and it really helped us see different potential solutions to some problems and pick out which one is best going forward. Individually I think I performed well, I contributed some useful ideas and helped the team come to some key design decisions. The previous sprint, time was a slight issue for me so I feel as if I did not do as much as I could’ve, but with the time that I did have I think that I used it very well. Going forward I think that we need to continue doing what we’ve been doing and build on the great sprint that we’ve just had.
The following sprint will involve a bit more documentation as we clearly layout our interface and make sure it coincides with that of the team doing the database component. Another big part of the next sprint will be communicating with AMPATH and asking them for the server code and asking for their thoughts on some of our current data designs, hopefully we can communicate quickly and get our answers so we can begin implementing because we intend to spend the majority of the following sprint getting a large portion of the implementation complete.
This week, I read the apprenticeship pattern “Dig Deeper”, and as the title suggests, this pattern was about trying to gather a much lower level understanding of some of the tools and the libraries that we use daily. The author acknowledged the fact that you do not always need to be an expert in everything to get the job done, sometimes a superficial level of many technologies is more valuable. This pattern suggested that a superficial level of understanding is needed in times where you need to just get something working, maybe you have a deadline, or you are satisfied with the way the product performs. This pattern also did a fantastic job of highlighting the value of digging deeper.
Like many of the patterns in this book, if applied, they will make you more desirable as an engineer. This pattern will not always lead to you acquiring a new skill, but rather it will sharpen your skills and give you an understanding so deep that you may find new ways to use the tools that you’ve always been using, as well as finding new solutions to that problem that has been glaring at you. One personal experience that I’ve had with this pattern was during an internship. I’ve previously had a very basic understanding of REST, and for the most part, that was enough for me to get by, but I was eventually assigned a task that required knowing more than just the basic GET, POST, PUSH, and DELETE requests. This task forced me to dig deeper into rest to understanding things like authentication, query parameters, and other low level details. Having been forced to dig deeper, I now have a much better understanding of REST and with this understanding comes the freedom to write better APIs as well as being able to diagnose issues much more quickly.
I find this pattern extremely useful, and although it may not always be possible/viable to dig deeper when working on a project, I now believe that it is always worth it to make the effort because the benefits are almost always worth the time investment.