Tag: Patterns

I anticipate my career to involve software development for the rest of my life. I need to start preparing for the intense journey to come. That being said, I want to discuss The Long Road apprenticeship pattern. It seems directly relative to the situation I find myself in, which is a soon-to-be entry level software developer.

The Long Road is a portrayed as a direction apprentices should take when new to software development. It is asserted that those looking to journey down this proverbial road should not be looking to become instantaneously rich and famous. Instead, it is suggested that we ought to steadily increase our knowledge and skills throughout the decades to come. We should not feel obligated to accept any promotion that could potentially constrict our quest for knowledge. Continue reading “The Long Road”

It seems fitting to discuss the Find Mentors apprenticeship pattern this week. I recently finished up a successful refactoring of the AMPATH online-tracker. My pull request was accepted by their development team, and is officially part of the ng2-amrs repository. I am adamant the end result was possible only after receiving the help from a mentor of sorts. I consider Felix from AMPATH a mentor in the sense that he helped clarify many questions I had concerning the online-tracker refactoring, the overall project, and Angular in general. One of the objectives when applying the Find Mentors pattern is to seek someone with knowledge in an area of interest that far exceeds your own. Since Felix’s knowledge of the AMPATH application is leaps and bounds ahead of mine, I think I’ve made a considerable effort to begin applying this pattern. Continue reading “Find Mentors”

Those describing the Breakable Toys apprenticeship pattern assert the importance of designating a safe-space for failure. But we must accept there is no room for failure on the job. In a professional working environment, many expect us to produce material that works every time. But as depicted in this pattern’s description, failure is necessary in order to grow.

Building breakable toy projects can be a great way to contain, evaluate, and improve upon one’s failure. The idea is to personally design something “on the side” that emulates one or more features you’re working on professionally. Continue reading “Breakable Toys”

Our Software Development capstone course is very team intensive. I think it would be helpful to research ways I can improve as a contributor in a team-based environment. I’d like to discuss the Reflect As You Work apprenticeship pattern. A successful application of this pattern ought to not only improve myself as a teammate, but could help boost the overall efficiency of my team as well.

The authors assert we should be assessing our personal identities when applying this pattern. The goal is to identify relative connections in our life achievements. Also known as “Mind Maps,” drawing Personal Practice Maps is suggested as an effective way to evaluate ourselves.

We’re currently in the stage in our capstone where teams are beginning to implement code for the AMPATH project. I’ve been noticing that all of the teams having been making a lot of interesting discoveries in the process. I think I’ve done a good job communicating what I’ve learned with my team so far. But at the same time, I believe communication with all teams as a whole is equally as important.

The “Share What You Learn” apprenticeship pattern concerns primarily what its name suggests. It is asserted that when we learn or discover something new, it ought to be shared with anyone who might benefit from that information. This can be done in a variety of ways. Examples include sharing resources on blogs, relative community platforms, and/or during face-to-face discussions. I feel this is important because even if one person has struggled with something seemingly trivial, chances are there are many others having the same exact problem. For example, a couple of weeks ago, others mentioned that deleting the package-lock.json file (while in WebStorm) before running npm install allowed a successful build of the AMPATH project with no errors. Sharing this information was especially useful to myself, my team, and any of us who had to previously make several manual code edits just to get the app to run. Continue reading “Share What You Learn”

So we’re finishing up our second sprint regarding the AMPATH project, and honestly I feel like we’re making some progress. Personally, I’ve been concentrating on Angular fundamentals to help me understand the “big picture” a bit more. I realize I need to implement strategies to hold onto and straighten my knowledge of these fundamentals. To accomplish these goals, one of the tasks I’ve been doing is applying the “Use The Source” pattern. For instance, I’ve been meticulously going over the AMPATH project code, trying to familiarize myself with every aspect of the app’s process. Continue reading “Use The Source”

Retreat Into Competence seems like the ideal apprentice pattern to apply this week. Our capstone team is in the process of discussing ideas for implementing the AMPATH application with offline capabilities. The problem is that I have become keenly aware of how complex this project is for me to even begin to understand. I’ve been noticing that my limited knowledge of Angular is certainly hindering my process. So I started to think to myself, “what can I learn more about that can help me move forward with the AMPATH project?” Then, and I’m not kidding here, I began thinking about this textbook, trying to remember the name of the pattern that discussed what I should do when I feel I’m in over my head. I found it, and as the name suggests, I should Retreat Into Competence. Continue reading “Retreat Into Competence”