Author Archives: lphilippeau

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.

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

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

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.

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

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.

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

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

Sprint 1 Retrospective

I have just finished the first sprint and there are a lot of things that I’ve learned from this experience so far. Before I talk about the experience I’ve had, I’d like to share my opinions about the task we will be performing down the line. I think that the work that we will be doing for Ampath is both really interesting and pretty important, it’s pretty nice to know that if this functionality can be completed it will be used to make a difference in other people’s lives. That being said, this week I’ve learned a bit about node, and javascript and some of the other components that Ampath uses, most of this knowledge so far on only top level but I am looking forward to diving deeper in the coming weeks. The components weren’t perfectly set up for us, there were a few bugs which members of the team took care of fairly quickly and this reminded me of how valuable teamwork is. If there is a lesson that I will take with me going forward from this week, (and this applies in most professions) is truly how valuable teamwork is.

On the topic of teamwork, my team worked very well together internally but even better still, we worked well as a class. I think that this ability to reach out to other groups will be extremely helpful down the line since we most likely be working on different components/modules.  I thought my participation was fair, but It could’ve been better. Moving forward I will try to spend more time trying to understand the code and most importantly improving my communication with the team. As a team we also are striving to improve our communication with each other.

During this week we mostly spent the entire time setting up. We had to set up all of the accounts that we needed including Jira, Trello, Git, Slack, Catme, etc. The setting up of the accounts was fairly straight forward, then we had to work on setting up the repositories at the class level, team level, and developer level. While setting up the repos we were also setting up our dev environments, this involved installing the NPM (Node Package Manager) and getting the Ampath application installed and successfully built. Successfully building the Ampath app required some extra work due to a bug that was quickly discovered. This bug was caused by a missing reference to a style resource, this bug was quickly fixed by (I believe) Oran Shoemaker and he shared it with the team to unblock the rest of us. The only other sizeable hiccup that we encountered was in connecting with the server, but the ampath team provided us with the instructions on how to do it correctly. During this time we were going through the Trello board and participating in scrum to share with the team our current status.

As a team, we were able to get through almost all of the Trello tasks for this sprint. There were a few that remained, but those tasks were either completed and not marked so or nearly finished. Personally I will make an effort to keep Trello up to date as much as possible. In conclusion, this sprint has done a great job giving me a general idea of what is to come and showed me that we as a team must work well to get it all accomplished.

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: Be the Worst

This week I read the apprenticeship pattern “Be the Worst”. With this pattern essentially says that once you become one of the best on your team, and you aren’t learning as much, you should put yourself in an environment where you are the worst and you know almost nothing. By putting yourself in the situation where you are the “worst”, you are surrounded by engineers who are better than you and are in an environment where there is a lot more to learn.

What I found the most interesting about this pattern is the author’s willingness to leave what most would consider an ideal situation and put yourself in one where the odds are stacked against you. For most people, being the worst on a team isn’t the goal. Most people want to grow and reach that level of expertise where you are nicely paid, do your job comfortably, and are looked to others as a leader, this pattern suggests that this means the end of your growth. After really giving more thought to this pattern I realized that I agreed with the author, this is because applying this pattern makes you a lot more marketable. If you apply this pattern it will ultimately give you more expertise in more different domains making you much more marketable and increasing your job security.

I agree with almost everything about this pattern, but I am not sure if it is the safest way to go about this growth. The author referred to this as a “sink or swim” strategy so while it is true that it might be a very good way to learn and grow, for some the risk might not be worth the reward. It is still possible to grow even if you are the best, nothing is stopping you from learning more and continuing to the be the best where you currently are.

In conclusion, I think that this is a useful pattern but I don’t think it should be followed exactly as it is stated due to the high risk. What I have taken away (and will try to apply) is that I should try to put myself in situations that will promote growth.

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: Be the Worst

This week I read the apprenticeship pattern “Be the Worst”. With this pattern essentially says that once you become one of the best on your team, and you aren’t learning as much, you should put yourself in an environment where you are the worst and you know almost nothing. By putting yourself in the situation where you are the “worst”, you are surrounded by engineers who are better than you and are in an environment where there is a lot more to learn.

What I found the most interesting about this pattern is the author’s willingness to leave what most would consider an ideal situation and put yourself in one where the odds are stacked against you. For most people, being the worst on a team isn’t the goal. Most people want to grow and reach that level of expertise where you are nicely paid, do your job comfortably, and are looked to others as a leader, this pattern suggests that this means the end of your growth. After really giving more thought to this pattern I realized that I agreed with the author, this is because applying this pattern makes you a lot more marketable. If you apply this pattern it will ultimately give you more expertise in more different domains making you much more marketable and increasing your job security.

I agree with almost everything about this pattern, but I am not sure if it is the safest way to go about this growth. The author referred to this as a “sink or swim” strategy so while it is true that it might be a very good way to learn and grow, for some the risk might not be worth the reward. It is still possible to grow even if you are the best, nothing is stopping you from learning more and continuing to the be the best where you currently are.

In conclusion, I think that this is a useful pattern but I don’t think it should be followed exactly as it is stated due to the high risk. What I have taken away (and will try to apply) is that I should try to put myself in situations that will promote growth.

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

Apprenticeship Patterns Chapter 1 Reflections

Reading the first chapter of “Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman”  by Dave Hoover and Adewale Oshineye, has so far changed the way that I look at being a new developer and the approach that I will take to growing. The quote that resonated with me the most was said by Marten Gustafson, he stated “I guess it basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing”. The previous quote in my opinion is the most important idea portrayed through the entire first chapter of this article, it applies to not only the apprentices, but also the journeyman as well as the masters. I think it’s very important to work with the attitude that there is always a better way because it keeps us from getting complacent and leads to many innovations, and because of this I will try to keep this attitude as I go through my development career.

The other key idea that this article taught was self responsibility. The classical apprenticeship pattern that they compared theirs to has a larger reliance on others (the apprentice has a reliance on the journeymen and masters for their learning). Though this chapter acknowledges that this will play a role in our careers, they make the argument that we should take control and and responsibility for our destinies. I found that particular part of the chapter very empowering because it stresses the fact that the responsibility falls on you. It tells me that I am responsible for acquiring the skills needed to advance in my career, and that I am responsible for finding the correct mentor when that is needed, and most importantly that I am the only one responsible for my successes and failures.

While a big part of the chapter stressed the idea of individual responsibility and growth, I really like how it demonstrated the link between this individual growth and that of the community and the craft itself. It shows that as you get enough skill to consider yourself no longer an apprentice, it is almost your responsibility to share your knowledge and ideas. As a developer you are going to be working in many different teams on many different projects, and you will be exposed to many other ideas, but you will also expose others to some of your own ideas. This exchange of ideas is in my opinion the best thing that could happen for the craft and profession as a whole, it ensures that things will not stagnate and is responsible for the many innovations we developers have had.  It talked about how as a master you are putting these skills and ideas under the microscope to improve the way that the community as a whole operates. That last sentence really summarized the theme of the chapter for me, I see it as saying something like even when you know almost everything about the craft (mastery) you still don’t know if this is the best way to get things done and that is something you have to investigate and try to improve on.

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

CS-448 First Post

This is my first post for the dev capstone

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