The pattern Craft over Art in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye discusses the opposite approaches one can take when writing software…

On one end of the spectrum there is practicality. This would be considered the “craft” portion of this apprenticeship pattern [AP]. The best way I can describe this side of the spectrum is with the idiom “don’t reinvent the wheel”. If a solution is already there, don’t go out of your way to rewrite it. Why would you waist your time? If there is no currently solution, then find the quickest and most efficient way possible that solves the problems and meets the customer’s demands [AP]. Don’t go above and beyond.

On the other end of the spectrum is the “art” portion of this pattern [AP]. This means that your solution should be beautiful and elegant [AP]. It should be a master piece [AP]. The tradeoff here is that creating masterpieces takes both time and money. Although the pattern seems to lean towards favoring the “art” side of things, it does suggest that there are times where you’ll have to find a middle groud between the two [AP].

I’ve mentioned this in the past and I’ll mention it again. If you truly want to be a master software developer, then I feel the advice this pattern gives is worth taking. However, in most cases, following this pattern doesn’t seem realistic. Companies have goals and deadlines that need to be meet. They aren’t going to want you to take a week to complete a task that can be done in a day just so you can make it perfect. Time is expensive, so if you can meet the customers demand in a day rather than a week then they are going to expect you to do so.

The pattern also notes how one should be wary about making something beautiful, yet useless [AP]. If you are going to take weeks to perfect something in which a valid solution could be developed in a few days you better be darn sure it is going to work [AP]. This is something that I agree with. Creating something that is useless isn’t craftsmanship or art. It is a waist of time.

Form an overall perspective I get what both this pattern and book are trying to preach. This pattern is great advice if you can find a place that will let you follow these practices. It just doesn’t seem practical. If you are given the opportunity to actually follow these guidelines I say go for it. I just don’t see it as being realistic for most people in most situations.

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s02.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Most people view promotions as a good thing. It means you are moving up in the world. More importantly, it means that your peers and managers feel you are doing a great job. It is always a great feeling to get reassurance that you are good at what you do. Not to mention that promotions often come with a raise. However, in the eyes of Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye a promotion isn’t necessarily a good thing…

The pattern Stay in the Trenches discussed in Apprenticeship Patterns isn’t about finding the quickest way to the top of the ladder. It focuses more on becoming an expert at your craft [AP]. Promotions often mean you are one step closer to management or are going to be in management, which also means that you are one step further removed from development [AP]. Now, not everyone wants to be a lifetime developer. I certainly don’t know if want to be. But for those who do want to truly master the craft of software development, then a promotion isn’t necessarily a good thing.

If you choose to not accept/avoid promotions, there are some other ways to be rewarded/compensated [AP]. They suggest finding a company that is flexible in allowing you to stay on as a developer [AP]. Perhaps you can find technical leadership roles such as a lead engineer [AP]. By taking on this type of role it may allow you to still receive a raise if that is what you are looking for, so it can be the best of both worlds. However, some may not even want to take on a role like this as it is an additional burden that can take you away from your work.

Personally, I feel this strategy is easier said than done. If you are good at what you do, promotions are going to come. If you turn down too many of them you’ll more than likely be looked down upon. Even if the company is ok with you staying in your current role, at the very least you are going to take on more responsibilities. Often times those responsibilities aren’t strictly development related so they will pull you away from what you want to truly do. Now I’m not saying adhering to this strategy can’t be done. What I am saying that following this strategy to a tee is something I feel would be challenging to do. The more experience you have, the more “jobs” you are going to be asked to take on whether you intend to or not. If you want to follow this strategy and can actually pull it off, then more power to you.

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch03s07.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Write it down. Document it. Record it. From my personal experience, it is always better to write things down. This goes for things at home, work, or school. If you have an idea or come up with a solution to a problem, write it down so you don’t have to come up with that idea/solution again a month down the line. It just so happens that one of the patterns in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye is about recording information. It is called “Record What You Learn” [AP]. The title of the patter itself explains it all. It discusses how it is very important to record any ideas you have or solutions to problems you have developed [AP]. More importantly, it discusses how these things should not just be written down and forgotten [AP]. I cannot agree more with what this pattern is all about. Your records should become a resource for you to use later on down the line when you are working on something you felt you have seen before and aren’t quite sure what the solution was [AP]. Writing stuff down can save you time and frustration. I have learned this lesson more than once and I’ll probably learn it again a few more times too. I agree with how this pattern stresses why it is important to record thoughts, ideas, solutions, etc. I can’t tell you how many times I have fixed some sort of program or had some sort of idea and said “Oh, I’ll remember how I did that. It was a pretty simple fix” only to run into the same problem 3 months down the line and spend a whole day trying to fix the issue. Had I written it down, it probably would have taken me about 10 minutes to realize I had it written down and another 10 minutes to follow the steps I wrote. The problem is fixed in 20 minutes. Another benefit to recording what you’ve done is it allows you to share it with others [AP]. By doing so, you may be saving someone else tons of time and frustration because they were able to utilize what you shared. The end lesson of all this is simply, write it down. It will make everyone’s lives easier.

Link to pattern in book: https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch05s06.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

A pattern that peaked my interest in Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye was “Concrete Skills”. In short, it discusses how it is important to have a basic set of “concrete skills” as they will be important when going for jobs and gaining the respect/trust of team members [AP]. It also discusses how to acquire these skills [AP]. The reason I was interested is because this is a book for the apprentice. One might think that an apprentice may not have a whole lot of concrete skills. They may have enthusiasm about the subject matter and are probably more that willing to learn, but they may not have the necessary skills. In my opinion, a person is an apprentice because they have to learn these concrete skills before they can go off on their own. There should be no expectation for a new apprentice to know anything other than a few basics of a language or two. If you already have these concrete skills down pat, then why would you still be considered an apprentice?

While I disagree with the expectation that apprentices should have a bunch of these concrete skills (at least that is how I interpreted it), I don’t disagree that concrete skills are very important when going for jobs and getting a new team to accept you. You have to be able to prove that you can do the very basics of the job at a minimum. In other words, you don’t want to walk into a job and be a burden to the team. I think it is understood that there will be a learning curve and someone from the team is going to have to go out of their way to teach the new person how things work at the company, what the project they are working on is all about, etc., but the team shouldn’t have to babysit and guide the person through every task for the next year. Having some concrete skills along with the ability to learn quickly will prevent the babysitting aspect. It will also give the respect of other more veteran team members. It is important for people with more experience than you to be able trust that you can get the job done and respect your work. I just feel that if you are going for an apprenticeship type positions (a.k.a. internships), that the expectations of what you know are significantly lower than if you were going for a full fledged engineering position.

Link to the pattern in the book:

https://www.safaribooksonline.com/library/view/apprenticeship-patterns/9780596806842/ch02s04.html

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Apprenticeship Patterns: Guidance for the Aspiring Software Craftsman[AP] by Dave Hoover and Adewale Oshineye isn’t a book for those looking to take the easy road. It isn’t a book for those looking to quickly ascend in to management. It isn’t a book for those looking to become wealthy fast. What it is however, is a book for those looking to truly become masters at what they do. In chapter 3, a pattern called “The Long Road” [AP] is discussed. It discusses how in today’ society there is a big draw towards quickly rising to fame and wealth [AP]. People want to get rich quick and without much effort [AP]. The pattern discusses how for most people that is unrealistic [AP]. More importantly, if you truly want to be great at your craft of choice, then jumping into management isn’t the right path to take [AP]. Expect to sacrifice promotions and salary increases and make other sacrifices along the way [AP]. Some people may aspire to go into management. If that case, there is nothing wrong with that and no one is going to stop you. But that’s not what this book is about.

I agree that to truly become a master software developer, you have to continue to be actively developing for a long time. The field is forever changing and changing quickly. Each passing year you continue to hone the skills you currently have while picking up more new skills along the way. Eventually you’ll get to the point where you can handle any situation. I feel when you reach that point; when you have an answer for everything (or almost everything) relating to your field then you truly have mastered what you do. To get to this point will take a long time. I also feel that this road is not for everyone. Not everyone wants to be developing software into their 40’s or 50’s. Some may want to move on to other things. Some feel that the role of a developer is merely a stepping stone for higher ranking positions. There is nothing wrong with this philosophy. Not everyone aspires to be a master developer. Personally, I am not sure if I want to become a master developer. I’m not sure if I want to be a true developer into my 40’s or 50’s. I feel this is a question I will answer for myself as time goes on and my career develops. I don’t think anyone my age (I’m 21) has an answer to this question. However, if you are one of the one’s who do want to be a master, then long road is the only way to get there.

Link to pattern in the book: http://chimera.labs.oreilly.com/books/1234000001813/ch03.html#the_long_road

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

Since I would consider myself a novice with Junit and java testing, I decided to take it upon myself to try a learn a bit more about it since we have been using it in class. I found a blog on ZeroTurnAround.com by David Salter that discusses a few tips on this topic, which I found to be quite insightful, so I am hoping to relay those tips to you.

The first tip is to follow the AAA pattern when writing tests. That is Arrange, Act, Assert. Arrange the conditions at the start of the method, act on the system, and then assert that the results are what you expected them to be. I am always a fan of easy ways to remember things, so I really like this acronym. It a nice easy way to remember what a good java code test should include.

To go along with the AAA, there is an important thing to remember when using the last of the A’s, assert. Although assert is a cool and powerful feature, you must be careful as to where and how often you use them. One should be careful that they are not testing things that the method wasn’t intended to test. It is also important to make sure you are not testing too many things in one method. This cause headaches if a tests fails, because it requires debugging multiple methods/classes, rather than being able to focus on just one. This tip really stood out to me because I think one can easily go down this rabbit hole thinking that they are making their lives easier, while in reality they are making it harder.

The last item I want to discuss is important to testing, but it is also important with regular development as well. Take advantage of what the software has to offer you. It can make your life a lot easier in the long run if you take the time to learn a new feature or two. Although you have to invest time upfront learning how it works, you can save a lot of time because that feature makes it easier for you to develop, debug, etc. For example, libraries like EasyMock and JMockit allow you use a mock object. This allows you to “mock” objects that do not exist yet. The example used in the blog us mocking a security system that controls who can access what, depending on the user logged in. Because you are able to create a mock one, you are still able to test your product, even though a key component is missing.

Obviously there a lot of different tips a whatnot to help make us better testers. This really is just the tip of the iceberg, but I hope it was as useful to you as it was to me.

Link:

https://zeroturnaround.com/rebellabs/top-testing-tips-for-discriminating-java-developers/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.

In the past, I have talked about Code Smells. However, did you know there is also a Design Smells theory? What’s the difference? Well, according to the CodeOps blog, “Design smells are certain structures in the design that indicate violation of fundamental design principles and negatively impact design quality.”. In other words, the difference between code and design smells is Design Smells focus on the design quality and principals (the architecture of the code) while Code Smells focuses on poor coding practices (what bring the architecture to life). The blog mentions a couple of red flags to look out for the may be an indication of Design Smells that I feel are worthy of discussing. Since I know I have perhaps accidentally or perhaps out of laziness have done some of the thing mentioned in this blog, I figure it can a good learning experience for both myself and the readers of this blog.

Violation of design principals: They use the java calendar class as an example. Not only does it support dates, but it also supports time. Since it has multiple roles, it is in clear violation of the Single Responsibly Principle (the first of the SOLID principals discussed a few weeks back). This is known as Multifaceted Abstraction smell. When you think about it, violating design principals is clearly a bad idea. The principals are there to promote better design and coding, so going directly against is clearly not the brightest idea.

Inappropriate use of design patterns: This one is on the opposite end of the spectrum. Instead of complete ignoring common practices to promote better code, you force it upon yourself. Just because the design pattern could be used in whatever situation you might be in, it doesn’t mean that it should be. Don’t feel obligated to use them if you feel if it will do more harm than good.

Language Limitations: Sometimes languages force you to do thing you don’t want to do, and often times it can be out of your control. Java is used as an example again. Because java does not support primitive types, if you need to take in different primitive types, you will need repeat the code, with the type taken in being the only difference. While I agree that language limitations can promote bad practices, I don’t know if it is fair to considered this to be a trait of a smelly design since unless you were able to pick the language, there is largely nothing that can be done about it.

Viscosity: This is basically taking the easy way out. Sometimes there is a hacky way to solve a problem that may be prone to errors, isn’t modular, etc., but it saves significant time and resources. Because developers are often under a time crunch, they often resort to this. I know I have, but I also know it will come back to bite you. Avoid the hack if possible.

Obviously, there are various other causes of smelly designs, but I hope this short list gave you a good idea of what Design Smells is all about.

Link:

http://www.codeops.tech/blog/linkedin/what-causes-design-smells/

From the blog CS@Worcester – README by Matthew Foley and used with permission of the author. All other rights reserved by the author.