Author Archives: lphilippeau

Apprenticeship Pattern: Record What You Learn

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Practice, Practice, Practice

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint 6 Retrospective

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!

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Draw Your Own Map

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Create Feedback Loops

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!

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint 5 Retro

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint 4 Retro

Last week marked the end of the end of sprint 4, and we successfully built one the last sprint that we had. During this sprint got to learn a little bit more about javascript, angular, and generally how the front end of an application works at a higher level. Going through the code with t

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.

 

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Read Constantly

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’.

 

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Apprenticeship Pattern: Learn How You Fail

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.

Sprint 3 Retrospective

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.

From the blog CS@Worcester – Site Title by lphilippeau and used with permission of the author. All other rights reserved by the author.