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.

I realize applying this pattern will likely mean turning down promotions in favor of strengthening my overall skills. But honestly, I don’t think I’d be comfortable taking a job I didn’t enjoy just because the pay was better. I’d rather spend my professional career looking forward to going to work, instead of potentially dreading it. For that reason, I believe The Long Road is an appropriate pattern for me to follow.

When beginning to apply this pattern, it is suggested to think about where we might end up in the decades ahead when traveling down this “long road.” Personally, it is hard for me to imagine what I’ll be doing ten or twenty years from now. But one of the immediate goals I’ve set for myself after graduation is to learn as many programming languages as possible. This ought to require a lot of reading, programming, and collaboration with other developers. I’m genuinely looking forward to it.

If I were to guess what I’ll be doing many years from now, I am hoping to become well-versed enough in the software development world to have helped others in some substantial way. With all the reading on software development I plan on doing in the decades ahead, perhaps I will have written my own book or two. I guess only time can tell where I’ll end up, but I think I’ll always stay on “The Long Road” in favor of any promotion that might distract me from furthering my overall career. Ultimately, I predict I’ll always be a software developer in one way or another.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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.

I have come to the realization I am going to need mentors to gain any sort of momentum in my professional career. My greatest struggles that have been preventing me from reaching out to mentors are intimidation and fear of rejection. But as those describing this pattern point out, the potential payoffs reaching out to mentors far outweigh the risks.

I need to remind myself that the vast majority of open-source communities are very knowledgeable and friendly people, more than willing to help others. I can cite the AMPATH development community as an example here. When I first learned that we would be working with on an actual open-source project with seasoned developers, sure it was intimidating to say the least. It took a little while for me to gain the courage to ask for help from them. But honestly, it was certainly worth it. Not only did I get a pull request accepted, we now have a online tracker service to work with for our offline module implementation. I also gained a whole lot of priceless knowledge concerning the functionality of the overall project.

One of the suggested actions given by those describing the Find Mentors pattern is to actively observe open-source communities. The intention is to, over time, find one or more communities that seem especially helpful and inviting to newcomers. The aspiring apprentice should then reach out to potential mentors from those communities. After I graduate, I plan on finding such a mentor to help me get through the whole job interviewing process. I know I am going to need a lot of help and support for this.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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.

I’ve somewhat already applied this pattern throughout the course of working on the AMPATH project. I’ve developed a few “breakable toys” of my own with the intention of better understanding specific Angular capabilities. My reasoning is as follows: AMPATH uses many Angular functionalities I was previously unfamiliar with. I quickly began to realize I have a whole lot of learning to do.

The concept behind the Breakable Toys pattern seems practical for any Software Developer. In fact, I wouldn’t be surprised if the majority of all programmers have created at least one breakable toy or another. I base this on my personal experience with breakable toys. They have definitely given me a better understanding of the “big picture” behind the AMPATH app. When working on a large project, breaking it down into pieces can give us a better understanding of its overall functionality. We can feel confident evaluating the features in a breakable toy through trial and error. If the toy breaks beyond recognition, its okay. Whereas breakable toys are disposable, large open source projects like AMPATH are not. It seems a lot safer to evaluate functionalities in an isolated space first.

I would also like to mention the specific action suggested by those describing the Breakable Toys pattern. Personally constructing a wiki from scratch is proposed. I feel this will be very beneficial for me in my future endeavors. Building wikis appear to be great breakable toys to experiment with; we can use them to explore fundamentals such as concurrency, HTTP, REST, and general web development. As I begin transitioning to my professional career, these are fundamentals that I certainly need to become more knowledgeable in.

I’ve recently purchased a website domain and hosting space from InMotion. I don’t have anything on it yet, but my eventual goal after I graduate is to build my own “breakable toy” wiki. I want to do this to become more familiar with web development tools and prepare for job interviews. Further, I am hoping to showcase everything I’ve learned about the AMPATH project in this proposed wiki to help others in the future.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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.

The following is a template of a Personal Practice Map that I found on scrum.org:

I believe this type of mapping is beneficial not only for self-reflection, but for anyone reflecting as they work in any team environment.

One of the primary goals of Personal Practice Maps seems to focus on establishing connections between experiences and achievements. On somewhat of a personal level, these type of maps can also help us get to know more about our teammates. For instance, we can see the above template outlines many aspects of Susanne, including her goals and values, as well as her personal and professional life. A personal map such as this can help other teammates see what motivates each team member. Since many teams are likely to be considerably long lasting, I feel it is important to have a general layout of each teammate’s personal motivations. This is to help us reflect as we work, and Personal Practice Maps can assist in achieving this.

The authors describing the Reflect As You Work pattern remind us Personal Practice Maps can also be used to help identify potential roadblocks we are facing. For instance, we could use this type of diagram to map out projects we are working on. We could then look back at how we approached it. Perhaps there were techniques we used that could be improved. The more detailed a Personal Map is, the better we can use it to identify ways to improve our goals. We can then adjust our maps accordingly.

I’ve set a personal goal for myself to design a Personal Practice Map prior to entering my professional career. I believe it will be beneficial for me to evaluate my strengths, weaknesses, and areas that could use improvement. This ought to be a step in the right direction of personally applying the Reflect As You Work apprenticeship pattern.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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.

Lately I feel that as a class, we have been improving in our cross-team communication. We’ve been having more cross-team discussions and sharing of resources, both in-class and on Slack. This is very important; we may be working on different tasks, but ultimately we’re all contributing to the same project. It is certain that we’ll face many of the same obstacles. Thus I believe it is important that we continue to share what we learn. Doing so is a great application of the “Share What You Learn” pattern.

Personally, I’ve been trying to apply this pattern to the best of my ability. For instance, I’ve shared everything I’ve learned about my understanding of the AMPATH app’s processes and procedures. I’ve done this in previous blogs, during class, and on Slack as well. My hope is that sharing what I’ve learned can help others – whether they’re in my capstone course, or someone on the other side of the world searching for information on something even remotely similar.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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.

The authors describing a successful application of the Use The Source pattern seem to emphasize the importance of specific procedures, such as:

• Find an open-source project and analyze its structural pattern.
• Study every aspect of the project, including the code, layout, methods, and history.
• Try to think of why the original authors implemented processes in the ways that they did.
• Seek additional resources giving clarification for procedures that seem unclear.
• Attempt to refactor either parts or the entire project; perhaps in a personal “breakable toy.”
• Ask for (and/or offer) feedback whenever necessary, with an emphasis on constructional criticism.

These points seem to outline the primary objectives I should concentrate on when “using the source.” I’ve been trying to follow this outline the best I can.

After attempting to analyze the structural pattern of the AMPATH app, I’ve been realizing that it seems to rely heavily on HTTP processes and routing. Having limited knowledge of these topics, I felt I needed to familiarize myself with these processes going forward.

I’ve asked for feedback from the AMPATH development team, who suggested that I should focus on understanding the processes of REST APIs. This helped direct my attention to several quality Angular video tutorials concerning these topics.

Now that I have a better understanding of the workings of the AMPATH app, I’ve been working on a Angular breakable toy of sorts. The idea is to replicate many of the pivotal functionalities of the project. So far my “breakable toy” has HTTP, REST (Representational State Transfer) and CRUD (Create, Read, Update, Delete) capabilities. My ultimate goal is to make it sort of a “lite” version of the AMPATH app that emulates the basic idea of the program, such as submitting and retrieving medical records. I want to compare my implementation to that of the AMPATH development team. Perhaps this can help me better understand why they implemented certain processes in the fashion they did. 

Following these aforementioned procedures are helping me successfully apply this pattern. I recommend that anyone looking to further their progress in any complex open-source project to “Use The Source.”

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

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

There’s an Angular tutorial by sitepoint that I have done portions of at least a couple of times before. It’s incredibly helpful and seems to cover every important aspect needed to develop applications in Angular. I’ve used it last semester when I first started learning both Angular and Typescript for the first time.  Now I’ve been finding myself going back to it again and again. I feel this is a great way to Retreat Into Competence because it’s something I’ve done before and become at least somewhat familiar with. Right now I’m in the process of going through the tutorial as thoroughly as possible to ensure I understand every piece of code that’s in there. I think I’ve got the CRUD (Create, Read, Update, Delete) part down, which helps boost my confidence a bit as I proceed to tackle the more complex topics. But I’m still Retreating Into Competence, and I know I have some more substantial learning to do before I can say that I’ve successfully finished applying this pattern.

Ultimately, I need to work on better understanding how the AMPATH application communicates back and forth to a remote server.  I had at least a high level understanding of the “Todo app” discussed in the sitepoint tutorial. And when I “retreated into competence” and started to go through the tutorial again in a meticulous fashion, Angular is seeming more clear to me than ever before. I am hoping to finish the sitepoint tutorial section regarding REST (Representational State Transfer) APIs before my next team meeting on Tuesday. Learning more about the workings of REST and mock servers should help provide some clarification regarding how the AMPATH server communication works. Then perhaps as the pattern suggests, I can “launch forward like a stone from a catapult” after momentarily Retreating Into Competence.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

I’ve noticed something about myself that has occurred especially during the past few months. I mean I’ve always enjoyed reading anything that captured my interest, but lately, I have developed a colossal appreciation of reading. This appreciation seems to go leaps and bounds ahead of any time in my life that I can remember. I think this has a lot to do with the amount of time I have spent learning and reading about computer science topics, subjects that I am absolutely fascinated with. I am certain the apprenticeship pattern textbook has only further solidified my interest in reading, software development, and computer science as a whole.

That being said, I have chosen to reflect upon the Reading List pattern this week. The idea concentrates on the importance of keeping and maintaining a “books of interest” record. As someone aspiring to enter the job field of Software Development within a few short months, I feel it is my responsibility to acquire as much knowledge on relative topics that will help further my career. And as much as I like watching informative tutorial videos from time to time, as the context of this pattern implies, sometimes there is no replacing the content of what certain books have to offer. Even many of the people offering such tutorial videos online seem to consistently reference material from one book or another.

I’ve begun personally applying the Reading List pattern after completing the step of signing up for a goodreads account. It’s a powerful, easy to use web app that allows users to keep track of books. Goodreads seems to possess all the capabilities that anyone developing a quality reading list should expect; I think the authors describing this pattern would certainly approve. I was able categorize books I’ve read, books I’m currently reading, and books I’d like to read. After adding a variety of computer science books to my reading list, I noticed the app started to recommend popular books relative to the subject. I will continue applying the Reading List pattern by updating my goodreads book log every time I’ve finished reading a book or started a new book. And from book recommendations from goodreads, mentors, colleagues, and other comparable sources, I will also queue books I would like to read sometime in the future.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

The Concrete Skills apprenticeship pattern seems to give the assertion that entry level software developers should maintain a quality understanding of the “basics.” Employers can and should have the expectation that new hires can contribute in some substantial way, right from the gate. I feel this patterns’ context stresses the importance of understanding the fundamentals of programming, essential algorithms, and computer science in general. One of my main responsibilities as an undergraduate is to learn and maintain such fundamentals that any reputable employer should expect from any entry level software developer.

The authors describing this pattern do a great job of highlighting some pivotal “concrete skills” one should strive for as a newcomer to the field. For instance, it is suggested that gathering a solid understanding of one’s first programming language is a primary skill we should strive for. I realize that my first language (Java) is just the beginning of a myriad of languages I expect to be exposed to in the near future. I ought to practice Java to the point where I can roughly draft code for any rudimentary procedure at any given moment. My potential employers need to know that I grasp the basics of vital data structures and design patterns. I should strive for a solid understanding of these fundamentals to a point where I can just start shelling out code whenever it is asked of me. When I can do this to a point of solid understanding and self-confidence, this will be the day that I can say that I have done so by successfully applying the Concrete Skills pattern.

What I found most interesting about this pattern was the implication of the importance of learning how to play “buzzword bingo” to get your foot in the door as an entry level Software Developer. I must say I found this amusing in the sense that I pictured someone at an interview saying something like “…yeah I’m familiar with APIs, ASP, IDEs, J2EE, NPM, SQL, UML…” and all sorts of other alphabet soup. But at the same time, the term “buzzword bingo” was especially enlightening for me. Any quality resume/CV I’ve ever encountered for inspiration had similar keywords sprinkled throughout them. Thus I have set a personal task for myself to become familiar with such popular buzzwords to a point where I can at least explain them. Proficiency would be great, but I feel I can begin to apply the concrete skills pattern by at least researching more about these recurring buzzword terms. I feel this, along with striving and maintaining a solid understanding of my “first language” Java, are great ways to apply the concrete skills pattern.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.

I’ve been in the Computer Science (CS) program at WSU for quite some time now. Though I’ve learned a lot in the process, I realize that graduating in May will be just the beginning of my career. I still have a lifetime responsibility of learning ahead of me, and I must find a way to effectively approach this everlasting task.

The textbook references The White Belt as what I feel to be a highly effective pattern to apply when learning new things. The idea is to keep an open mind and bring a proverbial “clean slate” whenever approaching something new. I’m going to use the example of learning new programming languages to further explain this pattern.

We focus a lot on the Java programming language in our school’s CS program. Because of this, I feel I have a proficient understanding of that particular language. We have branched out into other programming languages as well, such as C and TypeScript. But since Java was my first programming language I’ve become proficient in, I always find myself comparing the new languages I learn to Java while I am learning them. The White Belt pattern has changed the way I feel I should be approaching new material. I shouldn’t be making assumptions of new technologies based on my knowledge of other topics, no matter how comparable they may seem. I should be applying The White Belt pattern when approaching new ideas.

For instance, consider a scenario where an algorithm that has been coded in the most effective way known possible for the Java programming language. I should not assume that the code will be just as efficient in a different programming language just because some of the terminology may be similar. I should approach learning a new programming language in the same fashion that I learned Java. A good start would be to consult the community who are well-versed in the skill I am seeking to learn. I ought to start at the very beginning, practicing beginner projects before attempting the more advanced ones. As simple as a “Hello World” exercise may seem based on prior coding experience, The White Belt suggests I should “set this previous knowledge aside.” Based on reading the context of this pattern, I will always try to approach new topics with an open mind and a “clean slate.” This applies not only to the example of learning new programming languages, but also any new situation I may find myself during my professional career.

From the blog CS@Worcester – Jason Knowles by Jason Knowles and used with permission of the author. All other rights reserved by the author.