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


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.

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.

Apprenticeship Pattern: Dig Deeper

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.

Apprenticeship Pattern: Breakable Toys

This week I read the apprenticeship pattern called “Breakable Toys”, like the other patterns that I’ve read so far I think that this one is very applicable. This pattern suggests that one of the best ways to learn is through being able to try new things and do experiments that can and likely will lead to failure. The issue that this pattern addresses is that often times, we are not in an environment where failure is acceptable or consequence free and thus by having a “breakable toy” we are free to effectively try whatever we please.

I think that this pattern is extremely useful because it is very applicable in real life. Everyone has been in a situation where they wanted to try a new approach to a problem but didn’t because the risk associated was too high. When applied correctly, the risk associated with trying something new is almost nothing while giving you an increased opportunity of finding new solutions and learning new things. After giving this pattern a little more thought however, I realized that we developers apply it almost daily (often times not to an optimal degree). Take branching for an example, by working against a branch of the master code, you are essentially working on a breakable toy where you are free to try almost anything you please. Having the ability to work on a breakable branch of a product brings a level of freedom and productivity that working on a master branch never could!

This pattern has changed the ways that I look at my profession in the sense that I now have a better understanding the true importance of working on a branch for any change (even if it is miniscule) and test builds/environments. With the former you can for example, try implementing a feature however you please without fear of it breaking and halting the progress of your coworkers, and with the latter you can (for example) load test and try to break a “toy” version of your app without worrying about taking down production.

In conclusion, this is a great pattern that we use to a certain degree daily. This pattern can provide great benefits when applied correctly and result in catastrophic failures when not applied at all. I intend to use this pattern to continue learning as a grow in my career.

Sprint 2 Retro

The second sprint has just finished, and though this one was not as involved as the last one, I still learned a whole lot about software design and javascript itself. While the last sprint was very informative due to the environment set up, and generally getting familiar with the new tool, this sprint was informative in the sense that it taught me some of the challenges that come with breaking down a very big task. As developers, we want the tasks to be broken down and very clearly defined for us from the start when in reality, that is never really the case. As frustrating as that is sometimes, it is a lot is learned when you are able to break down and design a task yourself. I would say that was the most important thing that I learned from that sprint, because having to work as a team and breaking down a task that we barely understood forced us to ask some questions that we probably wouldn’t have if the task was handed to us like “here, code this”. I think that this ambiguity is ok to an extent when it leads you to ask questions that give you a clear picture, it is very easy to be too ambiguous where it leads to time being wasted since it feels like there is no starting point.

Work wise, I think that this sprint was a bit lacking (since it was mostly planning and design), so our team worked through that very well. As a team we bounced ideas off of each other and asked questions that helps clear up some ambiguities. More impressive than that is how well our team worked with other teams, we know that class-wide communication will be needed to complete this project and I thought our team asked the right questions to get a good idea of how we will integrate some of the key functionality (like how does the app know that it is offline). I thought that my participation in this was sizeable because I threw out a few ideas on potential ways that we could implement this offline detection functionality.

The most important thing that came away from this sprint was each team coming away with an understanding of the modules that will be needed, a general understanding of how they will fit together, and starting to get a feel for which component in particular they intended to work on. We accomplished this by talking to each other and staring at the code the learn how it works and sharing that knowledge with each other. If we could have done something different it would be going into that deeper level of detail much sooner in the sprint, but now that we know how well this works we will improve on that for the next sprint.

Apprenticeship Pattern: Confront Your Ignorance

This week I read the apprenticeship pattern “Confront Your Ignorance”, I chose this one because I thought it would be very relevant to me due to the fact that I am in a new role where many things are new to me. This pattern suggests that you do exactly what the name says, come face to face with the things that you do not know. Thus far, I think that this is one of the most valuable pattern mostly because nowadays, since the industry is constantly changing if you are not actively trying to fill in the gaps in your knowledge you WILL fall behind.

To relate this to my own personal work experience, I am currently trying to fill in the Spring gap in my knowledge. I have in a sense been “lucky” for a while since I have been able to avoid any tasks involving those tools, but my team uses Spring so much that my luck will eventually run out. If I do not confront my ignorance when it comes to Spring, then when I am assigned a task involving it I will harm my team. The other great benefit to this pattern is that, if applied, will make you an invaluable member of your team, nowadays there are so many technologies and components to learn that it is almost impossible to know them all so if you are constantly trying to learn more of them, then your value is constantly increasing.

Though this all sounds good on paper, in the real world I don’t think this pattern is applied because it is intimidating. We are comfortable with what we know, and we don’t like being thrown into a situation where everything is new, never-mind doing that intentionally! Also, I think another major hindrance is time, often times you are working on a major project that is taking up nearly all of your time making it difficult to find the time needed to learn something new. A solution that this pattern provides is starting small, you don’t have to do a very deep dive, you can start with an overview and simply learning the basics and that is what is the most promising for me. By learning the basic of Spring in the spare time that I do have, it will massively decrease my ramp-up time when I have to use it. In conclusion this is a very useful pattern that I will 100% try to apply in my software career.