Category Archives: Week 6

Code Smells

This week, I wanted to read up on code smells. Code smells are conditions of code that indicate problems with code quality.

A great resource I stumbled upon is “Everything you need to know about Code Smells” from Codegrip at https://www.codegrip.tech/productivity/everything-you-need-to-know-about-code-smells/.

Code smells may slow down processing and can make it easier for bugs to develop in the program. There are three levels of smells: application level, class level, and method level smells.

Codegrip lists duplicate code, shotgun surgery, and contrived complexity as application level smells. Duplicate code, of course, is similar code that appears in more than one location. Shotgun surgery is a change that results in the need to change other classes. Contrived complexity is using complex design patterns where a simpler design could be used.

Class level smells are: large class, freeloader, feature envy, divergent code, data clump, inappropriate intimacy, middle man, downcasting, parallel inheritance hierarchy, refused bequest, and cyclomatic complexity.

Large class smells are when a class has too many functions and it has too many instance variables, whereas freeloader is when a class does too little. Feature envy is when a class with a method wants to use features of other classes more than its own. Divergent code smell arises from a class that has to undergo many changes in order to make a change in a system. Inappropriate intimacy is when a class depends too much on the implementation information of other classes. Downcasting is when there’s a typecast that breaks the abstraction model. Parallel inheritance hierarchy smells are present when you make a subclass for a single class, and then a subclass must be made for other classes. Refused bequest is when a subclass does not use the methods and data of the superclass. Cyclomatic complexity smells occur when a class has an excessive amount of branches and loops.

Method level smells are: long method, speculative generality, message chains, too many parameters, oddball solutions, god line, excessive returner, and identifier size.

Speculative generality smells are present when only test cases are users of methods. Message chains are when methods call on other methods and those methods call on additional methods. Oddball solutions occur when multiple methods are used to solve the same problem. God line is when a line of code is unreasonably long. Excessive returner is when a method returns more data than what is actually needed. Identifier size occurs when the identifier is too short or too long.

I selected this source because I liked how it neatly categorized the different levels of code smells and offered an audio version of the post. In addition, I thought it was interesting to see how Codegrip explained code smells as it provides tools to recognize code smells and provides suggestions for how to resolve them. This source helped me learn the code smell types and how to recognize them. I’ll be able to apply this to my code in the future to prevent opportunities for big errors to develop down the line.

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.

Expose your ignorance AND confront your ignorance

If you want to reassure them, it should also be through your ability to learn, not by pretending to know what you don’t. In this way, your reputation will be based on your ability to learn, not on what you already know. The easiest way to expose ignorance is to ask questions.

People often disguise their ignorance by pretending to know a great deal about their field. But they forget that knowledge is acquired by knowing one’s own ignorance. Knowing your ignorance, and then study hard to improve your knowledge reserve, is a craftsman needs to have and cultivate the basic quality. Because no one can know all the knowledge in their field, it is through their own ignorance and facing their own ignorance that you can truly achieve the omniscience you need to achieve. It takes a certain amount of courage to recognize and face your ignorance correctly. But in the show you will find that often standing on top of the people they will be very open to accepting their own ignorance, and open to learning. Often it is the people who are afraid to face their ignorance that have little knowledge of their own territory.

Pick a skill, tool, or technique and actively fill in the knowledge gaps associated with it. Do it in the way that works best for you. For some, the best approach may be to read all the literature and FAQs available to get an overview. Others may feel that building a “crunchy toy” is the most effective way to understand something. Whichever method works for you, don’t forget to ask around with your “peers” and mentors to see if anyone has already mastered the skill and is willing to share what they’ve learned. Sometimes others may be learning the skill, and you’ll progress faster by working with them. At some point, you will have reached a satisfactory level of competence in this new area, and you can decide whether it is more productive to dig deeper or to turn your attention to other skill gaps. With only 24 hours in a day, you can’t grind every skill to a very high level, so you have to learn to make the necessary tradeoffs between them.

It’s not just about conquering previously unknown peaks, it’s about carving out a new path, step by step.

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

Craft over Art

This week I choose to talk about the craft over art pattern. So, what is this pattern about? The book explains that craftsmanship is built upon strong relationships. This pattern is not about doing merely what is expedient. It also encompasses the idea that a useful craft artifact always displays at least a minimal level of quality. When using this pattern, you will have to balance your customer’s desire for the immediate resolution of their problem with the internal standards that make you a craftsman. 
There are many things a developer should keep in mind when he/she develops a program but one thing that we should never forget is that you are primarily building something that serves the needs of others, not indulging in artistic expression. Developers think creatively, experimenting with different solutions to fit user needs and generally are comfortable with design systems. I have been many times in the place where I had to build something that I didn’t feel like it, but it is the customer that you need to satisfy.
Something that I really like from this pattern is when the book explains that You need to do your best work in ways that place the interests of your customers over your desire to display skill or pad your resume, while still adhering to the minimum standards of competence provided by the software development community. Walking the Long Road means you must balance these conflicting demands. If you starve because you are too much of an artist and your creations are too beautiful to be delivered in the real world, then you have left the craft. If your desire to do beautiful work forces you out of professional software development and away from building useful things for real people, then you have left the craft.
When you are making decisions about software, you should guide yourself by always keeping this in mind: How we can help? You can even prioritize feature requests this way. Remember: the purpose of the software is not to show off how intelligent you are.  Your purpose is to help people — Max Kanat-Alexander, Code Simplicity

Reference:

Apprenticeship Patterns by Adewale Oshineye; Dave Hoover

From the blog CS@Worcester – Tech, Guaranteed by mshkurti and used with permission of the author. All other rights reserved by the author.

Learn How You Fail – Apprenticeship Pattern

Today I will be writing about the “Learn How You Fail” apprenticeship pattern from the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman by Adewale Oshineye and Dave Hoover, 2009. This pattern is for everyone. Everybody has failed at something and will again in the future. If you are not failing then you are not pushing the boundaries of your capabilities, and/or you are overlooking these failures.

The problem addressed in this apprenticeship pattern is that you have enhanced your success through learning, but failures and weaknesses remain. The solution to this is to gain an understanding of the habits, behaviors, and patterns that has led you to failure. With self knowledge, you can make conscious choices to avoid these behaviors/habits or to break them and give you an idea of your limitations. As explained in the book, This can help you make a decision whether to fix a problem or cut your losses. If something is going to be a disproportionate investment of time and money only for a small improvement, it may be time to improve on something else instead. Excepting your limitations is important, seeking for perfection will only disappoint. This could mean letting go of some areas of expertise that cannot benefit you as much if you do not have the time to maintain those skills.

A method recommended by the author is to keep a list of your current skillset and boundaries. This way you can have an organized view of these boundaries and decide which areas you would like to push/explore. I found this interesting because it is similar to the “Record What You Learn” design pattern that I had written about in my previous post. By writing down your experiences, you can gain a greater understanding of what is happening. This way you can grow as a developer. Writing down your habits, actions and patterns which cause you to fail, can help you move forward from the endless loop of repeated actions leading to failure. I like this pattern because it accepts that you will fail sometimes, but whats worse than failing is to not push your boundaries. This pattern helps you understand and map out your boundaries so you can push them in an organized, thoughtful way.

Hoover, D. H., & Oshineye, A. (2010). Apprenticeship patterns: Guidance for the aspiring software craftsman. Sebastopol, CA: O’Reilly.

From the blog CS@Worcester – Austins CS Site by Austin Engel and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns Blog – Your First Language

For this week’s blog post, one pattern that stood out to me the most was “Your First Language” I believe that the first language will be the most important one for our careers because for the next few years this will be the main language, we use to solve problems or practice to improve.  My first language technically was HTML that I learned back in a web design class at High School, but my first official language is Java from our CS 140 class. From that class and onward I have been using java for almost everything even for personal projects or in other classes.

As I was reading the rest of the article, I came across a sentence how the author states, “For several years, your first language will be the framework against which you learn other languages. The better you know your first language, the easier it will be to learn your next language.” I believe this is very true, your first language will be the foundation for the rest of the languages you will be learning. I remember when we had the CS 282 class in which we learned the C language, it was much easier for me to learn the concepts faster because I had a good understanding of the first language. Another concept that I thought was interesting is about how your first language can prevent you from learning and using other languages, the author states that “One danger of digging deep into your first language is getting stuck. It likely will remain with you throughout your career as your native tongue.” I agree with this statement, having good proficiency in one language can indeed prevent you from learning and using other languages. However, it is good to have a diverse knowledge of languages, especially in software development as each language provides an opportunity to solve problems using different paradigms.

I agree with all the statements about this pattern, it is important to look back and see that starting from “your first language” now we are all learning and getting used to different languages. Especially for me, I have been trying to learn Python since most of the companies use it nowadays and, R to analyze different types of data which I find quite interesting.

From the blog Derin's CS Journey by and used with permission of the author. All other rights reserved by the author.

Your First Language – Apprenticeship Pattern

Our first programming language can be similar to the first language we learn to speak or our native tongue. What this pattern talks about is to first pick a language and start to master that language by practicing and solve problems in the specific language. It also talks about having some mentor or asking questions to someone more experienced so they can help guide you along the way of learning the programming language, but also at the same time not becoming dependent on them to solve your problems.

I found this chapter to be very interesting because whenever I think about coding and solving problems, the first syntax or code to use that comes in my mind is Java. The reason for this is because it is my first programming language that I learned and I have the most experience with it. This pattern has led me to confirm my belief that we need to first become better programmers in a specific language. A lot of people try to jump from one language to another and think it will be more beneficial. However, what this results to is not thorough understanding of a programming language, and more simple knowledge of each one. It is much more efficient to pick up a specific language based on your preference, and broaden your knowledge with it. Try out different problems to solve and keep on practicing. Once you feel you are at a level that you are content with, then move on to another language and broaden your knowledge about different types of programming. If you started with an object-oriented language, then learn about a functional programming language. Also, what this does is help moving from one language to another a lot better as well as understand the differences of each. With more experience in languages, we can start to see what languages are better for certain tasks and can examine advantages and disadvantages. In essence, the goal of this pattern is to take things a lot more slowly and in a more efficient way. It will be much better taking time to learn critical details then having front level knowledge. Overall, be open minded when it comes to languages as well and don’t just stick to one and decide that is it.

From the blog CS@Worcester – Roller Coaster Coding Journey by fbaig34 and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

The White Belt

Despite your inexperience and precisely because of your inexperience, you bring some unique qualities to the team, including infectious passion. Don’t let anyone dampen your excitement about software craftsmanship, it’s a valuable asset that will accelerate your learning. As a software developer, you will inevitably be part of a team and work on that basis. In any organizational structure, there is a tendency to conform to norms, especially for new people. Most teams don’t have an overheated passion for technology. To be sure, they are all focused on delivering the next project or improving some aspect of the software development cycle that is giving them headaches. As a result, passionate apprentices often succumb to outside pressure to keep a low profile. They either repress their passion entirely or let it manifest itself only in the absence of routine work. Unleashing passion in a relatively well-established team is, of course, risky. If morale is low or the team doesn’t welcome new people, you may get a dirty look behind your back. For those who believe that competence is more important than the ability to learn, there is no doubt that you will leave a bad impression, especially if you expose your ignorance. Like any model, this one should not be applied blindly. Team dynamics are always a consideration. If you find yourself in a group that doesn’t embrace your passion, then you’ll need to do something to nurture it.

Diversity of ideas should be seen as a key element of collective intelligence. An intriguing study of the collective psychology of aircraft carrier fleets shows that newcomers play an important role in the complex, coordinated operations required to safely maneuver a giant ship from which fighters constantly take off and land. The researchers found that a team made up of people with different levels of experience was healthier. When different levels of experience are correlating, for example, when novices with nothing “taken for granted” interact more frequently with old-timers who think they’ve seen the whole picture, everyone’s understanding of the problem deepens. It is true that in a healthy community it is good to be polymorphic.

As you transition into the role of a journeyman, you will become less dependent on those skills and gradually others will start hiring you based on your reputation, the projects you’ve worked on before, and the deeper qualities you bring to the team.

Expertise is a byproduct of the long journey we have taken, but not a destination.

Pursue excellence and success will find you. — Three Idiots

From the blog haorusong by Unknown and used with permission of the author. All other rights reserved by the author.

Breakable Toys: Improvement Through Experimentation

Photo by Polesie Toys on Pexels.com

In software development/programming related projects, much of the time making a mistake can feel like the end of the world, or at the very least a major inconvenience to everyone else around you. Yet by failing we often tend to learn more than we do by succeeding, since success seems to come most often from familiar and comfortable subjects or ideas which we might already have preexisting experience working with.

This is why I find the Breakable Toys pattern, described in the book Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman as a way to work within a “safe space for failure” to be an interesting and largely relevant idea in the context of software development. The pattern describes the practice of building “breakable toys”, these being smaller, self-contained projects making use of the same toolsets you might use during professional or otherwise high-stakes development.

The pattern suggest building simple games or programs as a way of learning a new programming language. Building simple games such as Tetris or Checkers in order to get to grips with the language seems like it would be a fun experience, I think game development is an extremely interesting field, and focusing on your interests is an effective way to speed up familiarization with a new language by making use of something fun and engaging as a sort of “practice project”.

I have always enjoyed the idea of self-building software; the idea of having a usable program or application which is self-built is appealing. Similar to how a woodworker might feel sitting in a rocking-chair hand built from their own shop, the idea of building something which is demonstrably useful, or even just as an experiment to see what happens is a great opportunity to express creativity and explore a new topic. The added benefit of experience and potential to learn something new makes it a worthwhile experience in my opinion.

In terms of putting this particular pattern into practice, my first course of action would most definitely be to make a few simple games and applications, an image editing program or simple web browser seem like reasonable small-scale projects to work on as a learning experience.

Building something out of personal interest can make learning the required skillset a relatively painless experience, as by the end of it you will likely have something which you can be proud of and enjoy for many years to come.

Text Referenced: https://learning.oreilly.com/library/view/apprenticeship-patterns/9780596806842/ch05s03.html

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