The article I chose for this week’s blog post is: “YAGNI (You Aren’t Gonna Need It) Principle Helps Devs Stay Efficient”, by Tatum Hunter. The article discusses what YAGNI is, how implementing it is difficult but necessary to implement in development teams, how it can be hard to know when to use YAGNI and how YAGNI can be applied to business as well as using a YAGNI methodology in making contracts. In this blog post I will be focusing on how being able to say no or not yet to a customer or employer is vital to a YAGNI system of software development. I chose this because we learned in class how useful YAGNI is to software development, with how it helps save time and money, as well as help morale and how communicating with customers or employers about what might not be good to implement is important.

YAGNI can be an incredible tool for making sure your team isn’t wasting time and energy on code that will not be used in the final product. This is incredibly useful, because as stated in the article, working on something for months thinking its going to be a great success just for it to be thrown aside can be devastating for team morale. “‘After months of hard work, it [a new component management system] just went by the wayside,’ she told Built In in 2020. ‘It might have been the right business decision at the time, but the team’s morale was really impacted.’” When YAGNI is implemented properly, it should lead to a faster development cycle meaning this project could have been completed before it was put aside. Saving the company money, and the team a lot of heartache.

Learning how to communicate YAGNI with customers and employers is one of the most important parts of implementing YAGNI especially if a requested feature may not be necessary. “‘To do that, we had to say ‘no’ or ‘not yet’ to about 30 features,’ Dingess said. And, true to YAGNI, that was the right call. After the product launched and the team could collect real user feedback, those 30 features ended up being irrelevant anyway. Instead, the team pivoted to build out the product based on that feedback.” A customer may want you to work on many extra features alongside your main task, only to later realize that many of those extra requests were not needed. If you were able to communicate to the customer that it would be best to implement those features at a later point in development, you would have saved a lot of time and effort for yourself, and money for your customer.

What I found to be most interesting about the article is how it relates the YAGNI principles to working with customers to make sure development teams don’t waste time and effort on implementations that don’t end up being used, or whole projects being scrapped all together.

Link to the article: https://builtin.com/software-engineering-perspectives/yagni

From the blog CS@Worcester – P. McManus Worcester State CS Blog by patrickmcmanus1 and used with permission of the author. All other rights reserved by the author.

This week I dove into chapter 2 of Apprenticeship Patterns and read the pattern Your First Language. This pattern was about just starting out and only understanding a little bit of one or two programming languages. I thought I would go back to the basics for this week and this pattern would be a good read for that.

The problem this pattern presents is the feeling your job or finding a job depends on your proficiency in a specific programming language. The solution the pattern gives for this problem is to pick a language and become fluent in it. It says whatever language you pick should be your main one for years and will become your default skill you work on when practicing. The pattern mentions the choice is a challenge because it will be the foundation of your early career. Some of the examples the pattern talks about for how you can work on becoming fluent in a programming language is to work on a toy application and write tests for your programs so you can understand what is going on better. A big part of this pattern was finding an experienced coder that you can work with and help mentor you and how it can make the difference in spending minutes on a problem or days. The pattern also mentions the importance of not getting stuck on only using a single language and preventing you from learning a new one.

One of the reasons I chose this pattern is because I can relate to the problem it presents. As a college senior in my last semester finding a job in the software industry will be coming up very soon. I have used several programming languages over my years of school so I have not had to focus on a single language. After reading this pattern I think java should be the language I focus on and become more fluent in because it is the one I know best already. I think I should follow the advice of the chapter and look into working on a small project so I can get better at java. Another thing I would like to do is find a mentor to occasionally help me out. I think that could be very useful for my career. Overall I thought this was a good pattern to read about and it gave me ideas of what I can do to improve my programming skills and create the foundation my career will be built on.

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

This is one of the more interesting patterns in the book. It’s a pattern that discusses the interpersonal relationships between the apprentice the masters or journeymen. I try to portray a lot of enthusiasm when it comes to the workplace. Currently, I work at a sub shop. It’s not my preferred job, but it’s a job, nonetheless. It’s different when comparing this pattern from a software development setting because I feel that I’ve exhausted everything I’ve been able to learn from this job. I try to develop some enthusiasm when it comes down to it though because it’s easier to go through a rush when everyone is in a better mood.

The same thing could be said when it’s time for me to work with a software development team, I can imagine. It’s easy to find people who don’t exactly feel enthusiastic because as the book mentions, they have been working at their job for way too long, they are caught up in many projects and deadlines, and they have no time to stick behind incompetence. After working a couple of jobs, I’ve seen this happen more then I could count, and it’s not a good feeling to conform to everyone else’s mood of dread and pain about a task or subject when feeling the complete opposite.

This pattern can be applied to almost anything in life. The young and incompetent apprentice who feels very enthusiastic about their job is once again shut down by their team. They might feel rather timid in trying to discuss or propose ideas to the team because they are afraid that the team will shut down their enthusiasm. When I’m going through this, I usually began to talk to people I feel that I can express my ideas very clearly too, who won’t attempt to shut them down, or who I feel won’t react negatively toward them. It’s easier to be told wrong by one person than by a bunch of people, and if it ends up being a good idea then I start by telling more people about it until I feel confident that it should be proposed at a more public level.

Sources:

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

For this week, I wanted to read over and discuss the Deep End pattern from “Apprenticeship Patterns” by Dave Hoover and Adewale Oshineye. 

The Deep End pattern can apply when you’ve only taken safe steps or have only worked with what you’re comfortable with, and you’re starting to feel that where you’re at is hurting you. You feel that you need to expand your knowledge and what you can work with. So, this means that you have to start working on more complex projects or tasks, maybe more high-stakes projects. You shouldn’t jump blindly into a complex project, but you should first prepare or gauge what you’d be able to do. If you take on something unprepared, it could just have a negative impact on you. The pattern gives a warning to make sure you don’t take on something that you may have no foothold in at first–with an example of Enrique Riepenhausen moving out of the country to act as a consultant for a client in Nigeria, but knows the language and someone who lives there.

To work on this issue, the pattern says to think of the projects you have worked on. Then, write about the scope of the project–complexity, how many lines of code, how many developers, etc. From these answers, you can give projects a rating or make a general scale of their complexity and compare new projects to the scale and use it as a tool to help you reach your career goals.

I thought that the pattern was useful in the way that it says you should measure/compare complexity of your past projects that you can use to then compare to future project opportunities. It would be a good way to see that it is complex enough to boost your skills instead of being something on the lower end of complexity that wouldn’t launch you forward. I do agree that we should take on something more difficult so we can learn more things–for example, I knew how to do little tasks for my internship, but I hadn’t written code for a report before and worked on a template nor a form–basically a bunch of aspects I had not touched before–and had the task of working on them. And I’m glad I did, because I learned so much from that complex project that I can now apply to so many more. I also did not step into it completely blind, because I had coworkers who could help me if I really needed, and a knowledge database available. I think it would be interesting to think about my portfolio this way moving on. I do not have any disagreements with the pattern.

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.

The computer has gone a long way compared to now. Modern computers have several CPU cores or CPUs. We utilize these cores to create high-volume applications. This week I read a blog discussing concurrency in programming. This blog, “Concurrent Programming – Introduction” by Gowthamy Vaseekaran, defines concurrency as the ability to run several programs or several parts of a program in parallel. Vaseekaran then goes further by saying that programs that take longer to perform certain tasks can benefit from using concurrency and that tasks can be done in parallel or asynchronously. This will, for the most part, upgrade the performance of the program. Vaseekaran also goes on to say that computers didn’t have operating systems back in the day, so single programs were executed from start to end. These programs had access to all the resources of the machine. Nowadays, executing a single program at a time is seen as an inefficient use of expensive and a waste of computer resources.

 Several factors led to the development of operating systems that allowed multiple programs to run, such as resource utilization, the author explains that programs must wait for external operations, so using that time to let another program run was way more efficient. Fairness would allow multiple users and programs to have equal claims on a machine’s resources. It is fairer to let them share the computer rather than having one program run from start to end and then another. Also having convenience is very neat, so that several programs can coordinate to perform a single task. It’s interesting while reading this because currently I’m taking a class on algorithms, and so in this class, we will discuss how some programs will take longer than others. There is the worst solution to how a problem or program in this case should be run, and the best solution. Concurrency could fit into making programs run more efficiently.

 The author then goes on to discuss computer threads which are a facility to allow multiple activities within a single process, a series of executed statements, a nested sequence of method calls, etc. We use threads to help perform background or asynchronous processing. The thread takes advantage of multiprocessor systems, and it simplifies program logic when there are multiple independent entities. Java will utilize threads very often. Every Java program creates at least one thread.

Threads can also pose risks; the main problem is the shared variable/resource problem. Solutions for this problem include not sharing any variables, making variables immutable which is the process of making variables unchangeable to their value or state, and using a lock. A lock is a thread synchronization mechanism in java. Another problem includes race condition which is the most common concurrency correctness problem, which pays attention to compound actions, which is when two threads access a shared variable at the same time. Vaseekaran also goes on to explain deadlocking which is a condition where two or more threads are blocked forever, waiting for each other. Deadlocks are caused by inconsistent lock ordering and limitation of resource capacity when a thread is waiting for another lock.

It’s very interesting to see how important concurrency is when it comes to making or even running programs, it brings a whole new understanding of how modern programs work. It’s also interesting to hear about terms such as “deadlock” because it’s a refresher of what it means and what role it plays when talking about concurrency. Reading about how computers used to run programs gives me a new perspective on how these programs run within a system and seeing how solutions were created so that we can run programs more efficiently. When making software I want to come back to this, knowing that one of these days’ problems such as deadlocking or shared variables will happen to me and so using the solutions Vaseekaran has listed in the post they wrote will help me a ton.

Link to “Concurrent Programming – Introduction”: https://gowthamy.medium.com/concurrent-programming-introduction-1b6eac31aa66

From the blog CS@Worcester – FindKelvin by Kelvin Nina and used with permission of the author. All other rights reserved by the author.

Object Oriented Programming is a topic that I wanted to brush up on because it has been a long time since I have programmed with it or learned about it.

 I read a blog by Omar Elgar called “The Story of Object-Oriented Programming” which was a great help with relearning the terms and use of object-oriented programming. Omar goes over the major aspects of object-oriented programming which are objects, abstraction, encapsulation, inheritance, and polymorphism. Omar explains objects in programming are meant to represent real-world objects like a car, phone, etc. When Omar gets to abstraction, he sums it up by saying it is focusing on common properties and behaviors of objects and getting rid of what is not important. For encapsulation, Omar explains it is breaking down a program into small mini-programs in the form of classes as well as hiding content that is not necessary to expose. Inheritance is when we take the common properties we created in an abstract class and apply them to the class that is more specific. The last topic Omar covered was polymorphism which is when an object takes the shape of many different forms. Omar even gives some code at the end of his post to show the readers a real example of object-oriented programming being used which is a nice touch and helps to see.

I chose this blog post to read because I wanted to get a clearer understanding of object-oriented programming and how it worked. I have coded using object-oriented programming in the past, but I do not think I had completely understood it and how useful it can be until now. Omar did a great job going over all the important pieces of object-oriented programming and explained them in an easy to understand way.  After reading his blog I feel like I got exactly what I was looking for out of his work. I will be able to apply what I learned from Omar’s blog to my programming and be able to effectively explain object-oriented programming to someone else if I needed to. I have a feeling that having a strong understanding of how object-oriented programming works is going to be important to have not only for my university classes but my future career as a software developer. I would highly recommend this blog post to someone who needs a straightforward and easy to understand overview of object-oriented programming.

Link: https://medium.com/omarelgabrys-blog/the-story-of-object-oriented-programming-12d1901a1825

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

                When entering the workforce, one aspect that can cause a great deal of frustration is the job title you are given. Many software focused companies will have different titles to differentiate developers of various skill and seniority. Junior developer, developer, senior developer all carry with them an expectation of skill. Depending on which title you are given, it can have an adverse effect on how you view yourself and your skill level.

                ‘Apprenticeship Patterns’ delves into this explaining the common reactions to situations involving being given a seemingly improper title. Those who are given titles such as ‘senior’ or ‘lead’ developer may find themselves frustrated in the fact that they themselves do not feel worthy of such a title. Or on the other side, a person may far surpass their peers in skill and yet be given the same title as them.
Dave Hoover and Adewale Oshineye reflect upon this stating that a title is merely a distraction from the improvement of one’s own skill. Those with a high position of authority should refrain from becoming complacent and those with an unimpressive title must not let fact cloud their judgment.  

The authors explain that the conundrum of titles is a sign that “our industry has a problem” and should be used as a point of judgement for the organization rather than yourself (Hoover, Oshineye pg 51) . Being given a title that seems to be above your skill is often a byproduct of a “shortage of craftsmen in our industry” (Hoover, Oshineye pg51). Being given a title below your skill level can be frustrating but must not distract from your goal as an apprentice. Hoover and Oshineye mention keeping connections with your Mentors (See Last week’s post) and kindred spirits will help keep you grounded in reality.

                I myself have felt at times that my contributions at my old workplace far outpace my current job title. As stated in this pattern, I used this as a measurement of the organization I worked for which clearly did not recognize the skills of those lower in the ladder. Others may feel that their current title implies they are capable of more than they are currently feeling anxious of living up to such a title. All of this comes down to a matter of proper recognition and belonging which is sadly pushed aside in todays fast paced work environments. There is no way to change the industry overnight but having mentors who can reassure you in times such as these goes a long way in ensuring you remain focused on your goals of improvement as an apprentice.

Bibliography

Hoover, Dave H., and Adewale Oshineye. Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman. O’Reilly, 2010.

From the blog CS@Worcester – George Chyoghly CS-343 by gchyoghly and used with permission of the author. All other rights reserved by the author.

Perpetual Learning Pattern: Expand your Bandwidth

This pattern is a very interesting to me. I worked as a software developer from 1980 – 2015. During this time, I found it necessary to take advantage of many resources. Some of these resources were offered to me by the companies I worked for, but more often, it was necessary for me to discover information on my own. I work for over 30 companies. In this 35-year span, I worked as an employee for 15 years, and as a contractor/consultant for the other 20. The employers were usually really generous about paying for tuition reimbursement, computer related conferences, and in-house training. As a contractor, more often I was required to pay for any career advancement benefits myself.

I really didn’t mind this, since they generally paid better, and there is far less politics involved in being a consultant. I was expected to be able to do the work I was hired for, and that usually sufficed.

I was lucky in the sense that I was really motivated to learn new technologies as they came out, and as a result I spend many hours outside of work reading over 100 textbooks, trade journals, attending conferences, and developing my own products.

I managed to gain a large skill-set learning for my own personal development efforts, and this knowledge, along with all I learned “on the job” was parlayed into knowledge, as well as resume entries, making myself more valuable, and allowing my career to “ride the wave” of progress in software as it occurred.

Yes, it is great to expand your skill-set, but if I have any word of caution to those seeking this path, make sure you study a skill as deeply as you can, so as to avoid being a “jack of all trades and a master of none”. I found the best balance to be found in trying to stay with a project for at least a year, but less than 4. In this range, you get deep enough into the peripheral skills they require, as well as sharpening your primary skills.

I worked as a mainframe developer in the 80’s and migrated to being a windows developer by buying my own equipment, teaching myself C and the Windows SDK (with a lot of help from the Boston Computer Society). I made a similar jump in 2008 from C#.NET enterprise level development to becoming an Android developer by jumping at the chance to develop an Android application by my company, but this was only possible because I had already developed the skill-set on my own.

From the blog cs@worcester – (Twinstar Blogland) by Joe Barry and used with permission of the author. All other rights reserved by the author.

In this first apprenticeship pattern, it talks about how a person may have realized they have gaps in their skill set and walks us through ways we can resolve this issue. I decided to do this apprenticeship pattern as my first one because I feel like I relate to this topic. Throughout my undergraduate career, I bounced around from major to major mostly because I am an indecisive person, but also because I am a person who has very diverse interests. I wanted to learn and do everything despite how unrealistic that may all seem. I often took classes out of order so that they would all fit in my schedule. As a result, for some of my classes, I felt like I was always playing catch up because I did not take the previous class that the class was built off or was either taking that class concurrently or at a later date. Because I was taking the classes out of order, I was always trying to learn things that I already should have known before taking the class. This left gaps in my knowledge because I wasn’t always sure that I learned everything that I needed to learn for the class.

One of the topics that the author talks about in this apprenticeship pattern is that often times when a person identifies the fact that they have gaps in their knowledge they don’t know where to start. This was how I felt sometimes when I realized I had a gap in class. In the book, it talks about how everyone learns differently and how we just need to find a way that works best for ourselves. For others it may be going online and reading a lot of articles and working through problems. For me, when I get stuck, I find myself staying late after class or going to my professor’s office hours and working through problems step-by-step with others. One thing that I found really interesting about this section is the topic of finding a balance between trying to hone your skills to confront your ignorance and fulfilling the needs of the team. I found this topic to be interesting because it was something that I never really thought about before. It is important for a person to confront their ignorance and hone their skills because that will make them a better programmer, but it is also just as important that you are mindful of others that you work with because in whilst in the process of honing your skills, you may inadvertently drag your team down. This made me realize this is something I need to think more about and work on in the future.

From the blog CS@Worcester – Just a Guy Passing By by Eric Nguyen and used with permission of the author. All other rights reserved by the author.