For this week’s blog post, I took a look at the ‘Craft Over Art’ pattern. Now shifting from how to improve your skills as a developer, this pattern describes using your skills to make something that is useful for a customer. The pattern encourages us as craftsmen to mainly prioritize function over form. As stated in the pattern, “The things we build for customers can be beautiful but must be useful,” meaning one should try to maintain a balance between the two. Customers will usually value a quality working product over something impressive but unusable, so it is important to not put personal interests before a customer’s request. A good mindset to have is to be able to sacrifice beauty in favor of utility.

For the most part, I think that this pattern makes sense. Reflecting on myself, I am usually the type to write code to meet specifications as opposed to writing extraneous code that only does the same thing. The pattern mentions the tradeoff between beauty and utility. There will be times when you make the wrong decision and will need to go back and fix the mistake. As mentioned in the pattern, “fixing that mistake by rewriting the system from scratch may not be in the customer’s best interest. In those situations you will need to develop the ability to refactor and repair.” On the other hand, if you cut corners, you will end up with a subpar product by trying to dish out a program in as little time as possible. With the little experience I have in this profession, I can say that customers expect high-quality code and a fast turnaround time. Making such mistakes can be stressful especially when deadlines are involved.

When writing a piece of software that is useful, it is important to maintain the level of quality it should have. One of the ways I can think of that makes code higher quality is to utilize the principles of clean code. In doing so, I end up writing higher quality code that is arguably better to have than having something beautiful. Having clean code will be beneficial in the long run when I will eventually have to refactor my code. As I continue down this path to become a software craftsman, I want to culminate the skills that it takes to consistently produce high-quality code for customers.

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

Stay in the Trenches

As you progress in your skills and your career as a software developer, you’ll find yourself in the position of advancing your career due to your successes. You’ll take on a managing position or even a position and find yourself coding quite bit less. You’ll see your path as improving but it’s advancing your career in that company and not in your abilities as a software developer.

It’s imperative that regardless of all duties at the company, you try to stay in the trenches. Keep building your skill-set and training yourself around software development. Your company might not need that manager role in the future, your company could go bankrupt if it fails, you might be put into an even higher position that pulls you even further and further from any actual coding. The path of the software developer doesn’t have to diverge from your career path.

I found this one interesting as it makes sense. I have thought, what do managers of programming teams do in their spare time? I only figured they would take up coding something related to the company or even just taking up spare coding work from other teams. It never occurred to me that someone in that position might take the ramp off the long road of software development and instead focus their career on gaining a higher position in the company that they work in. This in of itself is a perfectly fine choice to make for their career, but the desire to code is likely how they ended up here and I find myself wondering why they might give that up.

It could be a little tempting if I am being honest. It’s kind of strange to me at least that those higher up in the company still end up getting paid far more than those who do the actual work to make the project physical and marketable. At the same time the actual workforce you need to get a project like that built requires several people and if all of them were getting the highest tier of payment then the company probably wouldn’t be profitable. Money in modern days is very tempting as those who have experienced hard physical labor understand how tempting it is to earn a six-figure salary and in essence get paid to attend meetings, write emails, and manage a team of programmers. I don’t imagine myself taking one of those positions though. If I’m not actively doing something while working, physically or mentally, I find myself incredibly bored and frustrated. I don’t think I’ll have many issues if I end up in a higher position. I likely would have followed this principle without even knowing about it.

From the blog CS@Worcester – A Boolean Not An Or by Julion DeVincentis and used with permission of the author. All other rights reserved by the author.

My next post is on the problem Sweep the Floor from chapter 4, which has to do with when you are getting started on a group project and want to be able to contribute to the team and grow your own skills. This problem got my interest the most in the chapter because it is a problem that I have when I am in anything that needs a group effort, usually projects, and I think this is a common problem for people. Whether it be a project for school or work, a team based sport, or other activities that involve teams, contributing to the activity and earning trust from your team are the main concerns.

I tend to worry about not doing well and holding the team back, and the solution offered matches what I usually do to prove myself. The recommended solution is to start with the “simple, unglamorous, yet necessary, tasks” and work your way through your tasks to show what you’re capable of. When it comes to contributing and earning your teams trust, the two concerns usually go together because it will be your contributions that help you earn trust, and you can improve yourself as you work and do your share of the workload. The type of tasks you do are also important because what you complete can show your capabilities, and you will want to do some of them that you may not enjoy but are necessary for the project to show you are willing to do them.

While it is important for you to contribute to the team, you want to avoid getting to the point where you end up doing more work than others, or are the only one working on the “simple” tasks that the others do not want to do. Either you are the one stuck with those tasks, or those are the only tasks you are doing and are not doing any of the higher level tasks and can’t improve yourself. It can be difficult to contribute that way, and you won’t learn that much. Team projects can be beneficial to the members working together and improving them all at a higher rate than working alone, but it can also be difficult to divide the work and for new members to the team to contribute.

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

Craft over Art is a drastic change in tone from the rest of the patterns I have covered. All of the previous patterns I have read have been about how to advance myself as a developer, while this pattern is more how to act as a developer. Craft over Art stresses the importance of providing a useful product for a customer instead of a wildly experimental one that might not work. I would argue that this still is about advancing myself as a developer, but in a different, more practical way.

Obviously I should continue to do everything else discussed in these patterns, but I feel like Craft over Art will be the most immediately useful. This pattern can be implemented day one of your first job. It also is the most important pattern for your employer, since they care about actual products. I would imagine many apprentices are very excited to enter the industry and make something amazing, but this is simply not the reality of the profession. Real customers want products that work, do not need complicated maintenance, and are industry standard.

Craft over Art then goes on to explain that when you are rushed to deliver a product you must make compromises between beauty and utility. These compromises will inevitably lead you to a mistake, and you will need to fix it. This is a good thing, the pattern argues, since only by fixing things do we realize which compromises are the correct one.

This idea is a liberating one for me. The fact that I need to mess up in order to learn means that people will expect me to mess up. I feel like this takes a weight off my shoulders. The stress of working on real products with real customers is one I think is very common.

I am glad I read this pattern for my last blog post. I did not plan it, but it was a very nice surprise. Over the course of a semester reading about how I should improve myself, it is a nice shift to learn about how to provide a useful product for my customers.

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

Stay in the Trenches is about how you must stay on your path and focus on learning rather than promotions. If you are offered a promotion which takes you away from what you want to do, you should reject that promotion. This of course does not mean that you should never accept promotions or advancement, but you should always remain focused on what you want to do with your career. This pattern implies that you want to program, and I do, but I can see this pattern applied to many more disciplines.

Over the course of all these patterns one thing has been emphasized more than anything else: as an apprentice, your primary goal should be to learn. This pattern spells that out more than any other. This pattern is a very tough pill to swallow, but it is very good advice. Sometimes you need to be told things you don’t want to hear, and should listen to advice from people who have made mistakes before you.

I like this pattern since I am a very promotion oriented person. I can see myself taking the quick promotion and I needed this pattern to guide me on the right path. Throughout my working career I have taken the promotion when I should not have. This is different from what Stay in the Trenches is talking about, but it shows what kind of person I am. I need to be aware of that going into the future.

One thing I wonder about is when should I take the promotion? You are always able to learn, when have I learned enough? Fortunately I don’t have to worry about this for a while, and I think that it is an easier decision than I’m thinking it is. Right now I do not have the experience to tell what I want to do, and what I’m ok with not doing.

The pattern also suggests that instead of taking the promotion you should work with your employer to find other, more advanced tasks that you can take on. I like this idea since it allows you to continue programming, but it also might not offer the same pay or benefits.

Overall I like this pattern, it is one of the better ones I have read so far. I think my favorite patterns are the ones that tell me things I don’t want to hear; things I already agree with is not really teaching me anything. It is easy to take the advice of work hard, but not so much to pass up promotions.

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

One thing that the field of Computer Science is rather notorious for is that, for new learners, the entry level may seem incredibly low for someone who is interested in pursuing programming in any degree. Given the abundance of freely available resources for learning programming languages, this should not be that much of a surprise. It is easy for someone to find a tutorial online on how to implement inheritance in JAVA, with such tutorial presenting this concept through some oversimplified example. This, in and of itself, is not a bad thing; it is important to learn things in smaller steps. However, some software development apprentices may take to simply memorizing the knowledge they acquire and how to simply implement the tools available to them without much understanding, thus acquiring only a superficial understanding compared to a deeper, more thorough understanding, which in the future may become a habit that can interfere during the development of bigger projects. This situation is introduced as a pattern titled “Dig Deeper”.

What this pattern means for an apprentice developer is that, oftentimes, they may have found themselves in part of the development where their technical knowledge at that point in time may seem to be lacking because the superficial knowledge they have gained during the learning process was not sufficient to provide meaningful contributions in a project of a larger scale, especially in a professional environment. For example, someone who may be working on deploying a web-based application may run into this pattern. The apprentice, though they may know a bit about how REST APIs may work, they may still find themselves struggling because the project they are working on presents concepts that are impossible to cover in a simple tutorial. The apprentice may know how to implement functionality on the backend, but have neglected to get a  deeper, understanding of how such functionality may impact the frontend. Thus, when something in the frontend fails because of the backend, the apprentice may provide a solution that in the long-term does little to solve that problem. Overall, an apprentice who, regardless of their proficiency in their area of expertise, does not take the proper care to understand how such expertise may interact with other areas can hinder the long-term maintainability of a project, as well as have a negative impact on the apprentice’s own learning process.

While it is impossible to be an expert on every single concept and tool that exists ,not only within one’s area of expertise, but also for every single area that may constitute a bigger project, it is still important to take the time to gain a deeper understanding of how other areas work in conjunction to one’s expertise.

From the blog CS@Worcester – CompSci Log by sohoda and used with permission of the author. All other rights reserved by the author.

Similar to prior weeks, you have a basic set of skills, and your understanding of software development is narrow and small. Expanding your bandwidth allows you to further expand your horizons and learn more. The best step to solve this is to take in new information, but it is important to do so carefully, as it is easy to be overwhelmed in the information intake.

Some examples of ways to gather the new information is through following software development blogs, following software developers on social medias like Facebook and Twitter, and subscribing to a software development mailing list, just to name a few. There are also many hundreds of online courses and videos as well, so there is no shortage of information to be had. Following software developers can key you into new technologies before they become widely popular, which can give you a head start into the game before others. There are also national conferences that you could attend as well, and another great thing to do is to read any books some of the speakers have written in the past, so you can help get an idea of what they will be talking about and their software development history.

However, it is just as important to know when to expand your bandwidth then just how to as I explained above. It is possible to get stuck with the gathering of information, and it can easily happen where you get stuck researching and learning and never go back to creating any software. It is important to use this skill to accelerate your learning, but it is also important to not get stuck with the learning, learning is a means to an end, you must come back when you are done with the learning. Usually it is recommended to not spend more than a few months with this learning process, as that allows you to not get stuck in the learning process, as it is not too long, but it is also not short enough to the point where you do not learn much of anything at all.

From the blog CS@Worcester – Erockwood Blog by erockwood and used with permission of the author. All other rights reserved by the author.