For this weeks topic, something I that I chose to learn more about and get a better understanding behind of is YAGNI; which stands for You Aren’t/Aint Gonna Need It. To supplement my understanding for this topic, I watched a small conference video about a Software Architect, Ian Thomas, who gives a talk about the importance of YAGNI in real world environments. Throughout the talk some of the main points were that YAGNI reduces costs, and he also gave fixes or solutions for promoting YAGNI in work environments; and he also gives examples from his experience to better explain the importance of YAGNI.

Throughout the talk, I enjoyed some of the quotes and references he brings up because I thought they were powerful and changed my perspective of the software industry. In his introduction he brings up a Uncle Bob quote, which was ‘the number of developers in the world doubles every five years’; and then he points out that means half the developers entering the markets have less than 5 years of development. This is actually a worrisome quote when considering that one of the less experienced developers may be working on an airplane or automobile system that I may use in the future; however, Ian brings up this point because it ties to another reason for promoting YAGNI. This benefit of YAGNI is making material easier for new hire ups to understand and pick up; he refers to this as carry costs improvement.

Out of the other costs benefits he covers, he says that reducing carry costs is an important benefit of YAGNI often not acknowledged; it is also one I was not aware about. Carry costs may refer to the impact given from writing a new feature and when YAGNI is not upheld this often means that a new feature is overly complex, which would mean that it would take someone too much time to read before adding on or working in conjunction with that feature; this would also make it harder for new hire ups to pick it up. It appears that the code smells needless complexity and obscurity are byproducts of the absence of YAGNI in code.

Rather Ian mentions something important to think about when writing a new feature. A recurring theme that he brings up is thinking about the future; and so think, about writing/refactoring in a way that it’s not going to be too hard to write later on because you’ve taken the time to leave it in a good state now. And the quote he used for this was “it’s better to do a simple thing today and pay little more tomorrow to change it if if it needs it, than to do a more complicated thing today that may never be used anyway”.

And his takeaways to keep up YAGNI were narrowed down to keep things simple, to change things in small increments and also test them so you get to understand how the system is working and what you’re doing for your customers. Also he advises having courage in being able to stand up and explain why you are doing something and need to take the time to do it.

Link to Video Below

From the blog CS@Worcester – Will K Chan by celticcelery and used with permission of the author. All other rights reserved by the author.

The pattern “Stay in the Trenches” talks about how you should avoid climbing into management or other positions that don’t involve coding when offered them. The pattern suggests that you suggests alternatives, such as pay raises and other incentives that can be offered to you, if a person is offered a job in management or another job that pulls them away from coding. The pattern also talks about how taking a management job can lead to loss of skill when it comes to programming since it wont be a daily occurrence for the person in management. The pattern talks about how a person should, as the name suggests, stay in the “trenches” or in a position that involves coding directly and where they can continue their craft. The pattern hopes to convince people that they should focus on excelling in their passion of coding and find other ways to be rewarded for their work, instead of pulling a person away from coding.
I feel like this pattern makes a great point that was discussed in the pattern “Practice,Practice,Practice”, which is that when people don’t code for a while, then they will most likely see a drop in their coding abilities and lose most, if not all, of the progress they have made. I think it’s important for any person in the computer science field to do things that interests them the most, either with the work they do, a side project or both. I can see myself continuing side projects of my own as a hobby even when employed in a coding job to not only further my skills, but to do things that I find interesting, fun, or both. I don’t fully agree with this pattern and believe that if offered the opportunity to get into a higher position in a field I’m interested in, I will, most-likely, take the opportunity as a chance to further my career and myself as person. While coding will always be one of my passions, I can not stop myself or hold myself back from trying to reach higher and higher goals in my career and life.

From the blog CS@Worcester – Tyler Quist’s CS Blog by Tyler Quist and used with permission of the author. All other rights reserved by the author.

With the final sprint of the semester underway, I have had to learn several new technologies for our LFP microservice over the semester. This has led me to obtain only the necessary knowledge to move forward in the project. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman,by Dave Hoover and Adewale Oshineye, has a pattern that addresses this problem: “Dig Deeper.”

“When you read a tutorial, you should not be looking for code to copy but for a mental structure in which to place your new knowledge. Your goal should be to understand the historical context of the concept and whether it is a special instance of something else.”

The apprenticeship pattern, “Dig Deeper,” discusses the downfalls of having a shallow knowledge base and the need for obtaining a deep knowledge of how the tools and technologies work. There are several advantages to having this level of understanding, including: improving confidence, providing a starting point when joining a new team, and improving interview skills. The pattern refers to programmers with this knowledge as “cathedral builders.” These “cathedral builders” can debug, decompile, and reverse-engineer code. The best way to obtain this knowledge is to read specifications and familiarize yourself with debuggers.

The need for this pattern’s practice is like the need to learn history. Learning the history of a tool or technology will prevent repetition of previous mistakes and illuminate the reasons for the inner working’s current state. In addition to learning the history, it is important to dive into the different layers behind the tech and learning how the system works as a unit.

I realize my current understanding of the technologies I have been using for our LFP microservice is shallow and now, I have a direction I had not thought of looking into yet, debuggers.

A problem I have with this pattern is deciding where to start, as any time used to dig deeper is time that cannot be used for learning a new tech. This problem will likely resolve itself, though, once I decide upon a career path. For now, I can just dig deeper into our LFP microservice’s technologies: MongoDb, Node.js and its packages, angular, docker, and all the testing frameworks.

From the blog CS@Worcester – D’s Comp Sci Blog by dlivengood and used with permission of the author. All other rights reserved by the author.

The overall idea of the white belt apprenticeship pattern is that when you are learning a new skill for example a new language you need to actually need to learn a new skill and a new process. You can’t just apply the old process to the new skill. That will only result in, as the pattern says in its programming example, “writing fortran in any other language”. It says you can accomplish this by unlearning some of your previous skills and starting from scratch with the new skill. It also says that many people are scared to do that because they worry about looking foolish or ignorant. In the example of learning a new programming language it’s important because if you don’t unlearn some of your habits from a programming language you already know and unlearn how to code in that old language you will end up never learning how to use some of the new features of the new language. This is the overall idea and point of the white belt apprenticeship pattern.

I like and agreed with applying this pattern and its main point. I like how it says that in order to learn something you have to start from the beginning and let go of how preconceived notions about how code should be written. I agree with how it says if you don’t do that you won’t be able to write in the new language the way it was meant to be used. I also agree with how it says also that if you dont you will miss out on some  features of the new language.

I found a lot of it interesting and useful. I found it interesting how there was a saying about writing a new language like the old language. I found it useful to remember that when learning a new language it’s important. I found it thought provoking how it says that it’s important to unlearn before you learn. It’s kinda the opposite of what you would think at first. However it makes sense. I will definitely keep this in mind and use this in my future career when learning new languages or skills. Overall I really like this pattern.

From the blog CS@Worcester – Tim's WebSite by therbsty and used with permission of the author. All other rights reserved by the author.

This week, I would like to discuss the “Sustainable Motivations” pattern. This pattern explains that professional software developers often must work on messy projects with unclear specifications and conflicting demands. Such chaotic projects are exhausting and frustrating to work on, which can cause developers to lose their motivation to pursue software craftsmanship. The pattern’s solution emphasizes that developers need motivations that will adapt to the difficulties presented by these projects. Developers should have multiple sources of motivation so that, when is damaged by an infuriating situation, they will have other reasons to push through their frustration until the situation gets better. The pattern recommends writing down our different sources of motivation to help us understand which are the most important. When we find ourselves loosing the desire to continue developing software, we can refer back to this list to remind us why we should continue.

As I have explained in my past couple posts on Apprenticeship Patterns, I have really been struggling with motivation over the last few years. Many software-related projects I have worked on during college have been exhausting, frustrating, or unclear. I found it difficult to complete such projects because I simply couldn’t find the effort to work on them. This pattern resonated with me because it focuses on this very issue. I especially relate to the second bulleted example given by the solution, which describes a developer whose main motivation is their enjoyment of programming. For me, this was the main reason I decided to pursue software development, and it has been discouraging to feel that enjoyment dwindle.

However, the developer in the example continued programming due to financial motivations despite a loss of passion, and they eventually regained their love for programming. Similarly, I have continued to pursue software development because of my desire to finish college. I’ve never really considered my education to be a reason to program, but in retrospect it has clearly been my main motivation for the past several years. Clearly, reading this pattern has helped me think differently about my motivations. I’ve always thought my enjoyment of programming was the only motivator I had, but I now realize that other factors, like finishing college and gaining experience, have actually been motivating me more. Hopefully, these other motivators keep pushing me to continue programming until I am able to regain my passion for it.

From the blog CS@Worcester – Computer Science with Kyle Q by kylequad and used with permission of the author. All other rights reserved by the author.

The apprenticeship pattern Create Feedback Loops is an interesting way to learn from yourself and your own interaction with your environment. This apprenticeship pattern is about finding ways to review or “give yourself feedback” regarding your level of skill and competence on whatever you may be working on. 

Working in a team environment you may want to find out your team’s opinion on you and your contribution to the work. It’s not enough to judge your success based on the team’s success, whether that success is good or bad. Being on a team that is great and completes tasks efficiently it is important to know if you are a key contributing factor, or as this pattern put it, a “backup singer”. Just the same if you are on a team that is not producing good work, you can’t get stuck thinking that you are the best on the team and blame the failure on others. Even if it’s not your fault you have to realize that you are not contributing yourself correctly and this could hold you back from furthering your career.

Testing yourself on your own is also important in setting a realistic but higher standard for yourself. Test your work early, learn to expect failure and don’t be discouraged when you do. This pattern is about overcoming your failure by understanding what you can improve. Creating clear feedback is basically a criticism that can be acted upon. “Reinforcing feedback encourages you to do more of something. Balancing feedback encourages you to do less of something”. See both of these types of feedback require you to act, they aren’t stalling you with no clear direction.

One of my favorite examples from this pattern was that of asking for feedback from job interviews or team members. Asking people’s opinion of yourself can help you understand how you are contributing to your environment. A job interview that rejected you could be a great source of knowledge to prepare you for your next interview. Building from failure is how you create success, the more you have from failure the more you can put together to succeed. I find it vigorously motivating to ask my team members their opinion of me and my contribution. Of course I take pride in hearing positive feedback, but I often find that the criticisms help motivate me to be better. Now as long as feedback is delivered to you respectfully it’s great to receive in order to help with your direction. Your team members will also find that an open and friendly environment of communication helps team morale and forward progress.

From the blog cs@worcester – Zac's Blog by zloureiro and used with permission of the author. All other rights reserved by the author.

 Often times when you are a newcomer on a project, the team does not know your capabilities and does not know your worth. It is vital that you show your value in any means possible. This is often accomplished by taking on the unglamorous tasks but preforming to the highest of your ability. Since you are new, the team can not immediately trust you to be thrown in the midst of the project as it can often be dangerous without understanding the full scope, depending on what is being worked on. By completing these seemingly meaningless tasks to the best of your ability, it will help to prove our worth to the team. Eventually, all those “meaningless tasks” will be vital to the project and if the team is able to see them done to highest quality, they will be able to incorporate you deeper into the project.

I find this pattern to be one of the most useful patterns I have read, not only in the computer science world but in life. Often times when starting any new job, you are given the low-end tasks. When I was working at a grocery store when I was younger, I was given all the tasks of taking out the trash, cleaning the floors, and a lot of other unpleasantries. However, I was always on top of these and never had to be asked for them to be completed. In a short time, they had moved me off of these tasks and onto managing the next person who would be doing them. By simply proving my worth early on, in what seemed to be meaningless tasks, I was quickly able to gain my teams trust.

I think this pattern simply reinforces the mindset that I have always had whenever you are beginning something new. Often times people will come in with their head held high because they were considered extremely competent at their old work. However, if the new team you are a part has no reason to respect you yet and you come in with an arrogant attitude, that will cause the team to immediately not respect you. You must always put in the grounds work in order to start to build anywhere.

From the blog CS@Worcester – Journey Through Technology by krothermich and used with permission of the author. All other rights reserved by the author.