Programming involves applying the right pattern to a wide variety of scenarios. A way to learn how to apply those patterns is to analyze how other people have done them. One of the best ways to do this is by reviewing the publicly written code by someone who has published open-source code. Reading and understanding the craft a master has created, it will spawn ideas within you as to how to improve your own programming patterns and creations.  

I find it interesting that it gets easier to read someone else’s code the more that you read it and that the faster you can comprehend code is an indication of your level of mastery. I also found it to be an interesting recommendation to use git to track the history of code over time to view how it is improved. Doing this will help you identify the type of errors that passed inspection but eventually needed to be fixed or modified. In the future, you will be able to apply the patterns you observed to the code you write yourself.

I often program using TypeScript and open-source npm packages. Oftentimes with smaller node packages, they lack full documentation of the entire codebase. When this happens, I use my IDE’s source inspection tool to look at the function within the node package to understand how the package classes and functions work. There are also times when there is a node package written in JavaScript that does not come with predefined TypeScript type definitions.

To use these node packages with type safety, I write my own type definitions by inspecting the source code for the open-source package I am using. To some degree, I have already been reading the source, but not with the sole purpose of reading and learning the patterns of the software’s author. In the future, I will spend more time appreciating that I am looking at someone else’s craft that they fine-tuned to the best of their ability. Making sure to learn and take away as much as I can from their programming. I do not disagree with anything in this pattern, as viewing the source is something that I have already made a habit of doing.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Programming alone can be difficult with unclear paths to take with lots of uncertainty about which approach will be the best. Without someone who can give you guidance, it makes it difficult to move forward alone. It is necessary to find a mentor who will be there to guide you in times of uncertainty. The mentor you find does not need to be someone who knows all, but someone who has more knowledge and experience than you in a particular programming area. Finding a mentor requires a lot of searching because they may be hard to find, especially finding someone who is willing to spend the time to help. However, when you find one, they will provide a world of experience.

I found it interesting the author himself found a mentor after a few years of already being a programmer. It shows that it is never too late to find someone who knows more than you and to ask for help. This practice relates back to a previous pattern about exposing your ignorance. You must be willing to do this in order to get the proper guidance.

This pattern focuses on the theme of approaching programming as a craft where you must start as an apprentice. This reminds me of my grandfather who was a carpenter. When he was young, he started small jobs without much knowledge. He learned from the other men on the job who were eager to teach him what they knew. Eventually, he learned as much as they did and in his later years went on to share his knowledge with those who were younger just learning their craft.

After reading this far into the book, I have reshaped the way I view the development landscape. I feel that it requires the perspective of apprenticeship and the need for finding others to help you develop your craft. I think it is possible that at the same time you are being mentored, you can also be mentoring someone else. There are no areas in this pattern where I disagree with the author. I find that his recommendations and personal experience are well thought out and are great advice.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

You should plan for the long run and not focus on short-term goals. The further out you plan for yourself the better you will be prepared for unexpected challenges. If you want to program for a very long time, then you’ll be more skilled than people who are newly coming into the field and this will benefit you. It is important that being a master at the craft is the goal and not wealth or another position. It is important to stay motivated to program and not be distracted by nonessential things.

I find it interesting that it’s possible to get distracted over time while you’re at your job. I think it makes sense that over time you lose focus of the goal. It’s easy to be tempted by money to find a different job and stop programming. I think it was a good reminder to stay focused on your passion for becoming a master of the craft. Mastering the Long Road means balancing your work life and goals to meet a long-term desire for programming.

This pattern will help me focus on keeping my motivation for programming. It’s important to have an outlook of what you want in the future rather than just focusing day-to-day. Focusing on becoming a master at programming will also make money. But if you just focus on making money then you might not become a master. Someone motivated by money is not going to have the desire to learn to program. I personally have encountered this with friends who have software engineering jobs. They dislike their job and are only there for the money. They’re always looking for different opportunities and never spend time learning to program, they spend time trying to figure out how to get a different job.

I do not have any disagreement about what is discussed in this pattern. I think it is essential to stay motivated on the task of learning programming and not be distracted by other less important motivations. I think it is possible to have the motivation to become a project manager or a CIO while also maintaining your passion for programming. However, I think this pattern is correct in that the ultimate motivation should be about programming and nothing else.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

It is important to create things beyond that what is expected. You should go above and beyond the specifications of the application and create something that will wow the product owner.

I think it’s interesting to look at software development as craftsmanship and what you create as art. I do think that programming is a form of art because you have to use your creativity to make anything that you produce. Being artistic is a good way to look at creating an application, especially one with a user interface because it is what people will be looking at whenever they interact with the software. You want something to look beautiful and appealing just like a piece of artwork. In my opinion, someone would be more likely to use attractive-looking software than one that is unappealing to the eyes. It’s also important to make something that’s easy to navigate because that enhances the user experience.

I typically try to go above and beyond in the project that I’m working on. It is good for personal growth and reflects well on my portfolio. It is nice to be able to show a future client past work and be proud of the artistic design element of what I created. I prefer working on the backend, but I do enjoy creating a nice UI that users enjoy interacting with.

I think it is important to put extra time and effort into the products that you are creating for your clients. However, I think it’s important to not get lost in the details of creating something more than they asked for. Sometimes it’s possible to add features and create things that the client might not want and then you are forced to remove them. There are other times where you might put in extra work, and you were taking time away from yourself for other projects that need attention. Even though it’s good to have just to have the learning experience, I think it’s also important to make sure that projects for clients, that you put in extra effort into, should get some form of acknowledgment.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

There are many critical systems that have no room for failures, such as banking software or a hospital’s patient management system. It is difficult to experiment with new features or try a new approach when a piece of software is heavily relied upon. In order to experiment with new things, you need to have a test environment where you can try out features. If these features turn out to be harmful or cause problems down the line, they will not affect the current user version of the software. Creating a playground environment allows you to not worry about breaking changes or failures cousin headaches for program users and other developers. Software that is a breakable toy means it is that something can be played with, broken, and replaced without impacting anyone else. It is a way to learn, test new workflows, and ideas.

It is hard to clone and play around with code when there is a complex system that requires a database, client, server, and other resources for its operation. Because of the work and resources to create a clone of an existing system, I would not have created a second replica of the system in the past. However, this pattern makes a strong enough argument for me to put in the effort to make a breakable system for testing. I thought it was interesting a breakable toy can also be a personal project where you are the only one who uses it. I thought of this almost like a programmer’s diary where you program your ideas in private and you are the only one who sees them.

I currently program with a pattern similar to breakable toys but on a smaller scale. When I want to add a new feature into a codebase, I make a testing branch where I can execute that idea. In my ‘toy’ branches, I do not have any intention of merging the code into the main branch, I only use it to play around with an idea to see how it might be executed. I do not disagree with any aspect of this pattern, although it is good to also be comfortable working in an environment where you have to be careful about the programming you do could have a major effect.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

Chapter Two’s is themed around growing your knowledge. The pattern “Confront Your Ignorance” follows this theme and focuses on working with projects that are outside of your expertise. When you feel as if each project you are working on is like the previous one, it means you are applying your existing knowledge. There is truly little chance to grow as a developer when you work strictly within the areas you are knowledgeable about. The ideal scenario is one where you are working outside of your area of expertise to maximize the amount of new experience you engage with.

In the future, I will be more willing to work on projects where I dive into a topic that I do not fully understand. I also feel that the action for this pattern, to map your projects in a timeline, is a useful way to track your personal development over time. A timeline is a terrific way to see if your learning has stagnated and it is time to jump into something new. This method is also a great way to see where you want to take your professional career and give you an opportunity to map into the future.

I found it interesting how large of a risk the author suggests taking regarding a project outside of your knowledge. It is suggested to work on projects where the possibility of failure to complete them is high. In a private setting, I would gladly challenge myself by deep-diving into a project that I do not feel confident I can complete. In a professional setting, I personally am a bit too risk-averse to immediately want to take on a task where the chance of failure is greater than my chance of success. However, I appreciate that it is a gamble where if I do succeed it will boost my portfolio and whether I succeed or fail I will walk away with more knowledge than I started with. I believe it is human nature to be frightened of failure. This pattern is a great reminder that the journey that led to failure was along the way a great learning experience and the following attempt will be a success based on what you had learned.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern Expose Your Ignorance is about the importance of feeling comfortable with showing your ignorance. Asking questions is how you learn and shows that you are good at understanding. The difference between an expert and a craftsman is someone who broadens their range of knowledge rather than only sticking to digging deeper into a single domain. The action the author recommends is to write down your

The quote included in this pattern from David H. Hoover was thought-provoking. “I actually had grown attached to feeling ignorant on a daily basis; it let me know I was in the right place. I was growing.” The quote reminded me of the Daoist view of yin-yang where on one side there is chaos and on the other side, there is order. To grow as an individual, you need to be in the middle of the two. As Hoover’s quote says, feeling ignorant means that you’re exposing yourself to new material and are learning. If you never feel challenged, then you are not doing anything new and therefore not gaining new experiences. If you are uncomfortable with feeling the unknown, then it means you are uncomfortable exposing yourself to new things.

This pattern made me realize it is not only okay to be in the presence of the unknown but that it is also necessary for personal development. Personally, I do not act as if I know everything or that my solution is always the best option. I make what I know heard but leave plenty of room for others’ opinions. There are times when what I recommended is ignored and then later those recommendations are then incorporated into the project. It is better for that to happen naturally than for me to force my ideas into the project without the full acceptance of the other people involved. I do not disagree with anything in this pattern, I agree with the author fully on his opinion.

From the blog CS@Worcester – Jared's Development Blog by Jared Moore and used with permission of the author. All other rights reserved by the author.