Author Archives: patrickgrahamblog

The Software Craftsman 15 & 16

Chapter 15: Pragmatic Craftsmanship

Pragmatic – “Dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations” This chapter is about encouraging mastery of skills. Stating that Quality is not expensive and doesn’t slow things down.  But Mastering skills is a bottle neck. It is your job to master these skills to provide quality software every time.

Chapter 16: A Career as A Software Craftsman

This chapter details that a software craftsman is dedicated, passionate, and driven. The software craftsman masters their skills and every day is excited to learn new things. Every day they wake up and not only go to work for a paycheck but also try to change the world one block of quality code at a time.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 13 & 14

Chapter 13: Culture of Learning

Some think that a culture of learning is hard to create or it cost a lot of money and time. But in this chapter, the author details some simple ways to do it. One thing that can help is hiring passionate developers. This step is the most important because passionate developers love learning new things and this can accelerate this process a lot. When you are passionate about something it doesn’t feel like a hassle to learn new things.

Chapter 14: Driving Technical Changes

One thing that is difficult with driving technical change is dealing with people. Everyone has a different stand on what you are trying to change or improve and one of the difficulties is changing the minds of all that you encounter to proceed with your project. One thing that can help change people’s minds is being able to communicate clearly what you are trying to change.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 11 & 12

Chapter 11: Interview Anti-Patterns

In this section, the author details some things that interviews do and some things that you should not do when looking for a developer. A classic example is the difficult programming problem to get the awesome development job but the author looks down on this. He states that there is no point in haveing a brain teaser or coding on paper without the internet because this does not make any sense. If you think about it this doesn’t help anyone. You should observe the interviewee in their best conditions not make them look like a fool. I completely agree with this.

Chapter 12: The Cost of Low Morale

Low morale is always a problem. In so situations, it can be the cause of the death of a company. Unmotivated people don’t want to do productive things or think out of the box. Companies need innovation to be competitive. Innovation is spawned by passion and drive but low morale can kill this.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 9 & 10

Chapter 9: Recruitment

In this chapter the author details some interesting facts about recruitment agencies. The author states that they should only be used as a last resort. This is because they are only looking at some skills on paper and don’t really care about the career development of the individual. The author says some interesting things about how to recruit for your own company. His statements are the direct opposite from what I have noticed when looking for a job. He states that you should detail culture and passion and never required experience or academic background. This makes sense when looking for a valued member of the team but has been the complete opposite of my experience so far.

Chapter 10: Interviewing Software Craftsmen

In this chapter, the author elaborates on some interesting skills to learn from your interviewers and what they will learn from you. If in an interview they are very strict then you might be able to pick up how the developers are treated within the company. He also states that developers look for more than just the technologies and the money. They look for a good environment, including a good team, a good atmosphere, and sometimes the technology. In some of my interviews I have picked up on some of these things but this chapter gives me a few more things to think about during an interview.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 7 & 8

Chapter 7: Technical Practices

This chapter discusses some techniques that can help save time, money, and headaches for all involved if developers can convince management that they help. Some of these techniques are:

  • Test Driven Development- Write tests have them fail, write code to make them pass, repeat
  • Continuous Integration- requires developers to integrate code into a shared repository multiple times a day to detect problems early.
  • Pair Programming- Programming with someone else to bounce ideas back and forth
  • Refactoring- restructuring code to make it more efficient

Chapter 8: The Long Road

This chapter illuminates some potential missteps when choosing a career path. One of these such missteps is allowing your career to be directed by your job and not letting your career choose what job you get. Sometimes the skills that you would like to learn are not used in your job. If this separates too much from your desired path then maybe you should look for a better fitting job.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 5 & 6

Chapter 5: Heroes, Goodwill, and Professionalism

This chapter is very similar to the chapter in clean coder titled when to say no. The author of The Software Craftsman details some situations that require a skilled and professional Software Craftsman to tell the client no. Some of these include situations where the client does not know the full extent of implementing their wants into the product. This could result in a dangerous situation for the client and it is our responsibility to enlighten them on the full context of the situation.

Chapter 6: Working Software

This chapter boils down to how good your software is. As a company and as an individual. As a company, the quality of you software can directly be linked to your flexibility. The ever-changing marketplace requires the need to be flexible to those changes for companies. This means that you need easily changeable and upgradeable software.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 3 & 4

Chapter 3: Software Craftsmanship

This chapter delves into software craftsmanship. The author states that it is all about professionalism. Like most jobs professionalism is very important. It is always important to provide the best that you can. This is the short summary of the chapter and I believe it to be true when applied to most facets of your life. Who wants sub-par coffee in the morning? or a half toasted bagel, or even a raw donut. I might be hungry but the point still stands no one wants less than perfect. Try to make everything that you do capture and exceed the thing you were trying to accomplish.

Chapter 4: The Software Craftsmanship Attitude

In this chapter, the author details an attitude that is always learning and progressing. This is interesting because I believe that this what I strive for from day to day. Every day I try to tinker with anything and find out how it works whether it’s my mechanical keyboard or the vending machine at my work I love learning how things work. He applies this attitude to a career. In your career, you should always be learning new things. I feel like I am on the path to this applied attitude.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

The Software Craftsman 1 & 2

Chapter 1: Software Development in the Twenty-First Century

Due to the ever-changing nature of software development seniority is not exactly the best way to check someone’s skills. The field itself needs more flexible coders and having skilled individuals that know nothing about new and upcoming techniques is the opposite. I definitely agree with the way the author approaches the topic of seniority and its lack of correlation to skill set. I do not have much experience in this field in a job sense but abstractly it makes sense.

Chapter 2: Agile

The agile method is one way for businesses to obtain the flexible nature looked for when trying to be competent. But this can be a bad way to think about it because in practice companies tend to give attention to the processes and the meeting but forget that they still need good software craftsmen and craftswomen to turn out good software. If you adopt the meeting but not the necessary mastery then you will still have bad software but get to go to scrum meetings. This to me is a clear cut way to look at agile. Like in one of the scrum books that detailed a story about indigenous people trying to get plans to come back it makes sense that having meeting does not always get you the things you are looking for.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Reflection Sprint 6 (Final Sprint)

There are a lot of things that I was hoping to accomplish during this class some were just pipe dreams, some were attempted, and some actually got done. We will get to that at the end, but first the last sprint review.  During this sprint, we were hoping to finish and commit our bug fix. Unforchanatly this was not the case. Due to work and other classes projects and assignment we were unable to accomplish this feat. So instead of talking about what could have been, I will detail our thoughts on this issue and some potential ways of accomplishing this.

We ran into a bit of a wall again during this sprint. At my internship, I learned that they use a module for messaging the user that every part of the web app can use. This is what I was looking for in our capstone project but I was thoroughly stumped. I couldn’t figure out how the web app was sending info to the users some were using inline text in the HTML files, but others were calling it from the database I believe. So using what I learned from earlier to ask for help I asked for help. Well, this proved to be a huge waste of time because I received no answer. So I delved into the problem myself. We were looking for a universal module that handled messaging that we could call to display the message. What I came up with was trying to use the display error message module but this only lead to a large red box within the edit contacts page. Then I started to try and implement an observer pattern where the edit contacts page would be the subject and the contacts page would be an observer. So when something changed within the edit contacts module the contacts page would open small HTML box that would supersede the other divs and have a line of text “contacts have been saved”. Unforchantly I could not finish this within the sprint.

Leaving this class I have gained some helpful knowledge. First and most importantly I have gained some knowledge with web development and I would like to look more into this as a possible direction for my future career.  Secondly, I had a lot of fun using angular 2 and learning javascript. Lastly but equally important I have learned of some great tools that can aid in development like slack, trello, web pack, and web storm.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.

Reflection Sprint 5

Sprint 5 was when the team split. As in split into pairs to tackle the 3 different issues we pulled down. The first was the original button problem, the next was an issue having to do with a colored box that appeared next to patients to show status aka dead/ alive, the last issue was the one that I was working on which had to do with displaying a message when contacts were saved. So kyle found the function called to save the contacts. This already put us to a good start. As a test, we placed a javascript alert into the function to see if it was, in fact, the right function. The test was a success when web pack compiled with our added change the alert box appeared. Alright, this was fine but this alert was not within the web app so we decided it was not the right way to accomplish this. Another way that we approached the fix was to recreate the box that was shown when the edit contact button was clicked. Unforchanatly we did not accomplish this within the sprint and it had to be put on the backlog until the next and final sprint.

At the end of this sprint, we are heading into finals territory and papervile. What I  mean by this is that other classes are starting to assign final projects, papers, and exams. This means we will have less time during our last sprint to actually accomplish a fix for this issue. I hope to push a fix to the product because it will be a very good thing to point to for experience for a future job.

If I were to do this sprint over again I would start working on the issue sooner. This has been an ongoing problem for me throughout college, procrastination.

From the blog CS@Worcester – Conundrums In Computing by patrickgrahamblog and used with permission of the author. All other rights reserved by the author.