The pattern I decided to read is titled “Craft over Art” from chapter 3 of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Dave Hoover and Adewale Oshineye. The line that best summarizes this pattern is the one that states how the programs we create can be beautiful, but must be useful. This pattern starts off with a quote by Richard Stallman in “Art and Programming” that defines programming as, “a craft, which is a kind of art, but not a fine art.” This distinction is important because it shows how making beautiful programs is a good thing, but how its beauty should never outweigh the utility of the program that has been created. This pattern ends by giving us two tasks. The first task asks us to find something to do where we can prioritize usefulness over beauty. The second task is a reflective one that has us think about times we have chosen artistry over utility in our craft.

One of the sentences that I found interesting was the one that described how “utility and beauty are not opposed to each other, but interdependent.” This sentence stood out to me because although there is no denying that programs must be useful, it reminded me that I can not completely neglect the aesthetics of my program either because it goes hand in hand with how it is used practically.

As far as how this pattern has caused me to change the way I think, I would say that this pattern has made me be more mindful about the kinds of choices we make in our capstone project. We have already had a couple of conversations around this topic and I’m happy to say that our team has erred on the side of practicality over aesthetics. One of the things we have said in our team is that we should focus on setting the foundation of our project, and if we have enough time, we can come back and worry about our application’s appearance some more.

Overall, there isn’t anything that stands out that I strongly disagree with. It was a reassuring chapter to read after reflecting on some of the decisions my capstone team has already made on this topic. Additionally, it is a great message to instill early on in my programming career.

From the blog Sensinci's Blog by Sensinci's Blog and used with permission of the author. All other rights reserved by the author.

This week, I decided to look at the next apprenticeship pattern in chapter 2, “The White Belt.” This pattern describes the dilemma of a programmer being confident in their skills of a language but has reached a plateau in their personal development. This pattern offers a solution to those who feel that they are not acquiring new skills fast enough. After reading through the previous pattern, I’ve gathered that it is important to keep learning and honing your skills. And this pattern directly addresses an issue that one would encounter when doing so.

The solution provided in this section is to put aside your current knowledge when approached with new knowledge. While this will potentially affect productivity in the short term, it will allow time for new knowledge to sink in. In the pattern, it states, “wearing the white belt is based on the realization that while the black belt knows the way, the white belt has no choice but to learn the way.” This can be applied to learning anything because it can be beneficial to approach something new with the mindset of a beginner. The example with Dave the therapist was an example of when the mindset could apply outside of learning code. Dave found that taking a “not knowing” stance when working with clients opened up a new door of unforeseen possibilities and solutions. He put aside his expert knowledge on the subject and approached clients with curiosity.

Another example that I would like to refer to is that of the 10-year industry veteran Steve. He mentions that after reading “Working Effectively with Legacy Code,” his codebase improved into a better tested, adaptable system that was more fun to work with. While Steve did not go into detail, it was interesting to know how much more a 10-year veteran could grow. I certainly don’t have that many years of experience, but when learning new things, we are all starting at this hypothetical white belt. For the most part, the languages I have learned thus far are all based on similar logic. It would be beneficial for me to take one of my existing programs and implement it in a vastly different language. Not only would it give me a chance to learn a new language and the idioms, but it could also improve my coding skills in general, as mentioned by the 10-year veteran Steve.

From the blog CS@Worcester – Null Pointer by vrotimmy and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern I’m going to be looking at today is called “The White Belt”, from chapter 2.

The use case for this pattern is when a programmer has reached a point in their development where the rate at which they learn new information has begun to decline. The proposed solution is to hold on to newfound confidence while setting aside newfound knowledge. This way the new knowledge has time to sink in before it is synthesized with old knowledge, allowing new information to flow more easily.

I liked the example brought up here of Dave, a therapist. He found greater success with his clients after approaching his clients with as few assumptions and as much curiosity as possible. I feel that this demonstrates that this is a useful general principle for learning, rather than just one for learning about technology. This is why I find this idea compelling.

Something I found insightful in a more practical way was the idea of suspending the use of idioms you are familiar with in favor of the ones that are considered “best practice” for whatever tool you are using. Even if you don’t necessarily agree with, for instance, the concerns that Java programmers focus on, understanding the community around a language is essential to understanding the language itself. “Emptying your mind” in this way can be especially helpful the more unfamiliar you are with the language you are using, like if you were moving from a procedural to a functional language, for example.

I think that with technology fields in particular, there is immense pressure to be perfect, or at least exceptional. It can be extremely difficult to sacrifice productivity for benefits that are not immediate, and even more difficult to risk looking like you don’t know what you’re doing. Still, this is a leap of faith one must take to be good at what they do. Having it said so clearly makes it easy to see my hesitation as kind of silly.

I think I’m also going to add the book mentioned at one point, “Working Effectively with Legacy Code”, to my reading list. Not much was said about it, save for the effect it had on one reader, but it sounds like something that I, personally, would be really interested in. 

Another thing I’m going to try at some point is the exercise about rewriting a program with different idioms. I want to take something very simple I wrote for practice once, like a program that converts between temperature units, and rewrite it in a completely different language with idioms that are totally unfamiliar to me. I’m not really used to caring about idioms in this way, so I feel like this is the next big step forward I can take as a programmer. 

From the blog CS@Worcester – Tom's Blog by Thomas Clifford and used with permission of the author. All other rights reserved by the author.

The Breakable Toys pattern is about creating your own projects that allow you a safe place to experiment with new ideas and become more comfortable with your toolset. A project where you can try unconventional things to improve your skill, but where it doesn’t matter if they fail. The project they recommend for this is creating a wiki for yourself, to help learn multiple facets of design techniques.

I really liked this pattern and the idea that it promotes. Working on a rigid system that many people use, or whose functionality is necessary for the operation of your job, there isn’t really any room to try new things and grow. So having your own little workspace to try new things seems like a great way to build your knowledge in an environment that is completely your own. Like a chemist having a chemistry lab to experiment, it is important for software developers to have a place to experiment themselves. I also really enjoyed the idea of maintaining a project like this across different jobs, always having a place to try new things and to try new techniques when you are stuck on something. I think that implementing this into my own life will allow me to grow as a developer and gain new skills and insights that I would never have the freedom to do in a work environment.

The recommended “action” for this pattern is to build a wiki, and while I think this is a good example, I don’t think that that would work for everyone. So I think that if anything, I disagree with that specific recommendation, as I feel that depending on what is necessary for your work, a wiki might not need the tools that you need to work with or work on. So while I think it is a good example, I think that the individual has to come up with a project of similar scope that better matches what they need.

Overall, I think that this pattern is a very good piece of advice. Any profession can have difficulties and expectations that cause you to stagnate in your learning, but in the ever-shifting landscape of the software development field, this stagnation can leave you behind very quickly. So having your own personal project to experiment with things in will keep your skills sharp and keep you constantly learning and developing solutions to problems that can later be implemented in a work environment.

From the blog CS@Worcester – Kurt Maiser's Coding Blog by kmaiser and used with permission of the author. All other rights reserved by the author.

People have always asked me: “why are you so smart?”. Well, the truth is: my intelligence and my memory are a result of the same process that leads to world-famous athletes – we practice, practice, practice. I study academically during my semesters, and I study recreationally during my vacations; a true thirst for knowledge always welcomes a refill to the chalice.

This constant flow of acquiring knowledge comes with a cost though; more often than not, I have been incorrect over and over again. However, such is life within the field of science – experimentation is the process of challenging what we know to falsehood, and seeing if its truth still holds.

Connecting this ramble to Apprenticeship Patterns, I am pleased to tell you that the pattern for this week is “Practice, Practice, Practice”. The product within is just how it’s advertised; this pattern emphasizes that beginners learn best through “doing”, by performing actions under the guidance of professionals.

I find it interesting that the idea of “practice making perfect” is challenged; the new idea becomes “practice makes permanent”. Upon further analysis, I do have to say that I agree with this confrontation of the old adage – learning techniques improperly can lead to code smells. Proper, constant feedback while learning will prevent the coding landfill from becoming overwhelmed.

Personally, I would have to slightly disagree with the idea that apprentices must rely on their own resources to practice. I understand that this self-reliance can develop an independent learning process for the apprentice; however, a true leader reduces their aid for an adept apprentice (instead of completely removing it). Sure, beginners need more attention, but lifelong guidance builds relationships and motivates crafters; it’s easier to experiment when you feel tethered to a base.

While I have always stuck to the idea of constant practice, I will consider the idea of getting more constant feedback for my future professional habits. Personally, I have always had a fear of being judged for my shortcomings (and have only confronted this fear recently). In order to become the best of the best, we must practice our katas, within a dojo of coding professionals. As seen with other patterns in the book, we must assume that we are the worst (in a positive way), and confront our ignorance. Through practice, practice, practice with breakable toys, we achieve the proficiency that we strive for.

From the blog CS@Worcester – mpekim.code by Mike Morley (mpekim) and used with permission of the author. All other rights reserved by the author.

This weekend, I decided to research technical debt. I wanted to look further into this topic because one of my classes had activity introducing the term. I came across a wonderful blog discussing the different types of technical debt and how to manage them.

The blog: https://www.bmc.com/blogs/technical-debt-explained-the-complete-guide-to-understanding-and-dealing-with-technical-debt/#ref4

The blog lists four types of technical debt: planned technical debt, unintentional technical debt, unavoidable technical debt, and software entropy.

Planned technical debt: when a team has to compromise on the code but knows the risks and damages collecting the debt will have. An example is a team not spending time coding smaller aspects of a project in order to meet a deadline. The blog advises to keep a detailed record of the compromises to help the team keep track of what to address in the future.

Unintentional technical debt: arises from struggles with new coding techniques and problems from rollouts. An example of unintentional technical debt occurring is a design having many errors due to miscommunication between different teams working on a project.

Unavoidable technical debt: arises from changes in technology and business. A business may suddenly change its views on what features a project should have, and new technology may come out that can perform the functions more smoothly. This would make old code defunct.

Software entropy: occurs as software quality degrades. This can be caused by the changes developers (who do not fully understand the purpose of some code) make that yield more complex code. Overtime, the software will be riddled with errors and will be difficult to use.

The blog discusses three ways to manage technical debt, which are: assessing debt, communicating debt, and paying off debt.

Assessing debt: technical debt can be measured by how many days it would take developers to refactor or make changes to the target project, and the monetary value of that time can be calculated. This data could then be compared to upcoming significant events to help with cost analysis.

Communicating debt: it is important to properly convey the existence and impacts of technical debt to stakeholders so that fixes can be accounted for later.

Paying off debt: there are three ways to pay off technical debt: waive the requirement, refactor the application, or replace the application. Waiving the requirement would not set the team back in creating new features. Refactoring would help improve the structure of the code without changing program behavior. Replacing the application would result in new technical debt, but it should be limited and dealt with quickly.

This blog post taught me about technical debt in more depth, with the different types and different management aspects. I was curious on how technical debt could be calculated, but I’ve learned it can be measured by time spent to make the changes. Going forward, this information can help me understand what technical debt a project has and how to help deal with it. The graphics and the video the blog attached discussing debt was pleasant to view.

From the blog CS@Worcester – CS With Sarah by Sarah T and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.

Hello and welcome back to my blog! In this blog, I want to discuss YAGNI, which stands for “Ya ain’t gonna need it” or “You aren’t gonna need it.” My professor for CS-343 briefly mentioned it in class one day and I wanted to go over it more in depth. In the past, I’ve done something in my projects where I should have followed the concept of YAGNI instead. I made several methods to change a variable before I actually made the main methods of what that variable would do. In the end, it turns out the methods I made were useless toward my goal and I lost a lot of time. I hope to start applying the concept of YAGNI to my future programming in order to not waste time.

YAGNI is a really important concept in programming. Basically it means programmers and developers should only implement classes, methods, or whatever things they need only when they need them. By doing this, you can avoid doing unnecessary work and save a lot of time. When you think ahead and try to code a class or method that you think you will need in the future, it can be hard to know what exactly you need to include in it. The programmer has to do a lot of guessing and for a lot of the times, they guess incorrectly and end up not needing the feature that they spent some time on in the end. By following the concept of YAGNI instead, you don’t have to do all that guessing work and are also more focused on your current task. You should only develop things that you need once they become relevant. In a large project, YAGNI is especially beneficial for programmers and developers. Let’s say a programmer wants to design a feature they know they might need but aren’t sure if they need it or are unclear of how to implement it. By postponing the development of that feature, it can be more clear to the programmer/developer what they exactly need to do for that feature once it becomes relevant again. You should always ask yourself if the feature you are working on is really needed at the current moment. If it’s not needed, then you can take a note of it instead and come back to it later once it becomes relevant again. That way, you keep the project more simple and you program the features better since they are relevant and you have a more clear understanding of what to implement. And the most important thing, you save a lot of time with YAGNI.

Source: http://c2.com/xp/YouArentGonnaNeedIt.html

From the blog Comfy Blog by Angus Cheng and used with permission of the author. All other rights reserved by the author.