Software Craftsman Chapters 11 and 12

Chapter 11

I enjoy how this chapter opens with the “Don’t Be a
Smart-Ass Interviewer”. There is nothing more I dislike than someone who thinks
they are better than you and try’s and prove it. If I ever walk into an
interview and that happens I would like to think I would leave. I don’t have
the time or tolerance for such nonsense. I also enjoy some of the questions he
says to avoid in the brain teasers, “How many golf balls can you fit into an
airplane?” Hahaha. All joking aside I think that this chapter is pretty much a
common sense issue and unfortunately I think that some people really need it
beat into them. It is common sense you shouldn’t ask questions you don’t know
the answer to and don’t make the candidate look like a fool. If someone does
not know these basics, they probably shouldn’t be interviewing anyone, or maybe
even be in any position. I also like how he talks about not blocking the
internet during a coding activity and goes on to say, “I wonder how they would
do without it?” I also like his thoughts on not asking the interviewee to write
out code on paper or white boards and feels they should stick to what the
candidate would face on the job. Great tips and I am certain I will run into
interviews where I am asked to do these things.
His take on not asking to wrote algorithms or algorithmic
exercises is awesome. I like his thought pattern here on how they should ask
something closer to the reality of the projects at the company and that how
many problems weren’t related to the algorithms, but the lack of good tests and
the like. Overall good chapter and some great advice.
Chapter 12

I really don’t have much to say in this chapter as I think
it speaks for itself. Lack of morale is a company killer in my opinion. It is
all pretty plain to see that if you lack motivation and hate the job you are
doing than you will not bring anything of use to the company. It is contagious
as well. People moping around complaining about this and that and blaming everything
on so and so, when they really need to take a hard look at themselves. 

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

Software Craftsman Chapters 11 and 12

Chapter 11

I enjoy how this chapter opens with the “Don’t Be a
Smart-Ass Interviewer”. There is nothing more I dislike than someone who thinks
they are better than you and try’s and prove it. If I ever walk into an
interview and that happens I would like to think I would leave. I don’t have
the time or tolerance for such nonsense. I also enjoy some of the questions he
says to avoid in the brain teasers, “How many golf balls can you fit into an
airplane?” Hahaha. All joking aside I think that this chapter is pretty much a
common sense issue and unfortunately I think that some people really need it
beat into them. It is common sense you shouldn’t ask questions you don’t know
the answer to and don’t make the candidate look like a fool. If someone does
not know these basics, they probably shouldn’t be interviewing anyone, or maybe
even be in any position. I also like how he talks about not blocking the
internet during a coding activity and goes on to say, “I wonder how they would
do without it?” I also like his thoughts on not asking the interviewee to write
out code on paper or white boards and feels they should stick to what the
candidate would face on the job. Great tips and I am certain I will run into
interviews where I am asked to do these things.
His take on not asking to wrote algorithms or algorithmic
exercises is awesome. I like his thought pattern here on how they should ask
something closer to the reality of the projects at the company and that how
many problems weren’t related to the algorithms, but the lack of good tests and
the like. Overall good chapter and some great advice.
Chapter 12

I really don’t have much to say in this chapter as I think
it speaks for itself. Lack of morale is a company killer in my opinion. It is
all pretty plain to see that if you lack motivation and hate the job you are
doing than you will not bring anything of use to the company. It is contagious
as well. People moping around complaining about this and that and blaming everything
on so and so, when they really need to take a hard look at themselves. 

From the blog format c: /s by c-braley and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 7 and Ch. 8

Chapter seven, entitled “Technical Practices,” covers the topics of ideal programming practices and why they should be utilized in the field.  Of course by best practices I’m speaking of TDD, CI, paired programming, etc.  These are the topics that have been covered at length in The Clean Coder and my related blogs.  I found it interesting that Mancuso has a separate section for refactoring outside of TDD.  For those who are unaware, refactoring is a step within test driven development.  Therefore, if TDD has been utilized, then there is no need to explicitly describe refactoring.

Chapter eight, entitled “The Long Road,” is an interesting chapter about career choices. We all know that money is a motivating factor when making career choices, but taking money out of the equation leaves you with the following three factors:

Autonomy: It is when we are in control of what we do, how we do it, and when we do it. That should always be the case in a true Agile context.

Mastery: It is when we are constantly learning and evolving—becoming bet- ter professionals and better human beings.

Purpose: It is when we feel that our job is important and we are contributing to make things better—instead of just doing what we are told without under- standing why.

Once we get a grasp on where we want our careers to go, and what factors motivate us, it is easier to find the right jobs.  This doesn’t just happen, it requires a lot of work and effort in order to “craft” our careers.  Mancuso thinks it is important to differentiate between a career and a career within a company.  Your career is more important than a career within a company.  I think that your career and your career within a company are equally as important, and should more often than not align, but then again I have not worked in the field.

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

The Software Craftsman Ch. 5 and Ch. 6

I was speaking with one of my professors today about Sandro Mancuso’s The Software Craftsman and was expressing my preference of this book to Robert C. Martin’s The Clean Coder.  I may have deluded myself into believing that Mancuso uses less anecdotes than Martin in his writings.  I am not infallible.  Mancuso does use an exorbitant amount of anecdotes in his book.

Chapter five is called “Heroes, Goodwill, and Professionalism” and after reading the chapter I’m still not sure I understand what the title means.  Goodwill does not even appear in the chapter.  This chapter reminds me of parts of a few chapters from The Clean Coder especially the chapter on “How to Say ‘No.’”  I’m not going to recap previous blogs so if you are interested in Professionalism I invite you to read my series of blogs on The Clean Coder as that is the theme of that book.

Chapter six is called “Working Software” and it is a pretty simple chapter.  Essentially the main idea behind this chapter is that if code is going to be used for any extended period of time, it must be written properly.  “Working software is not enough.”  Rushing through the process and skipping steps is going to cost you time later, so it is in your best interest to take your time.  Mancuso also describes how to address legacy code.  He points out that nobody likes working with legacy code, but a change in attitude can make a world of difference.  Isn’t that true of everything though?

From the blog cs443 – TayNock's Blog by taynock and used with permission of the author. All other rights reserved by the author.

Capstone: Sprint Reflection 6

Sprint 6 was the final sprint of the semester. We rounded up this sprint with an unfinished solution to issue APTS-254. Over the course of this sprint, we were feeling really good on our understanding of this issue. We required quite a bit of clarification from the Ampath team. After getting some really good clarification we found that the code we needed to work on was in an entire different directory from the one we had been previously working in. Once we finally found where we should be working, we began digging in deep into the issue. The first thing we noticed is that this issue was associated with their ETL server implementation. None of us on the team had previous understanding of what an ETL server was so we I did some digging. I found a few resources online (Here’s a good brief description) that I summarized for the group. The idea was fairly simple, except the way the Ampath team was using ETL was basically by skipping the Load portion and just passing the transformed data to the end user as a notification.

I had a really good understanding of the issue at this point and even began writing some code that I thought might work for this specific issue. Part of the major issue that stopped us from being able to test this solution was the fact that we were unable to test that our solutions actually worked before committing changes. In order to test our solutions we were going to need a running ETL server. In the end I was kind of bummed we weren’t able to resolve another issue before semester’s end. But I felt good in the things I learned from trying to resolve this issue.

I would love to continue working on these issues in the future but with all my personal projects and the fact that I will be starting a new job (as a Software Developer) on the 22nd, I don’t plan on having a lot of extra time. All in all I really enjoyed working on Angular 2 and seeing how a large scale project like Ampath was built.

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

The Software Craftsman, Chapters 15 & 16

Chapter 15 goes over why quality code doesn’t have to come with a big price tag. Mancuso discusses that while managers and clients want everything done as cheaply and quickly as possible, they still expect a decent amount of quality to be in the software they are getting. Mancuso explains that coding does not have to suffer from being or poor quality if people stick to simple practices that will continue to help keep the code clean and easy to test. Again, very similar to the last book and previous chapters, he re-iterates the importance of TDD and how much time it saves. He also goes into why it is important to refactor code when and where you can to make sure that it was cleaner than before. I think the best thing in this chapter is the Four Rules of Simple Design; passes all tests, minimizes duplication, maximizes clarity, and has fewer elements. Keeping these rules in mind would greatly help programmers on track for keeping code as clean and simple as possible, and keeps TDD in mind.

Chapter 16 basically just sums up what being a Software Craftsman means and how they look at furthering their careers. A good portion of this chapter is common sense; knowing that being a good developer requires passion, and the urge to want to learn more about the software development field. To that extent, Mancuso goes over how to build your career and how to look at jobs to make sure you are aiming for positions that will help you later down the line. I did find some of the questions that he asked himself before applying to a job useful (again probably later down the line when I’m able to be more picky about where I apply to). I have also come across many people that graduate from this profession and admit that they don’t know what they want to get into. Again Mancuso provides some good, even if obvious, advice on how to ix this issue; simply get out there and talk to people. Overall I think that this book has provided some very useful information from how to stay passionate about your work to some really good advice about help to further your career in the industry. I would definitely recommend this book to anyone thinking about getting into the software development field, or even to someone that may already have some experience in it.

From the blog CS WSU – Techni-Cat by clamberthutchinson and used with permission of the author. All other rights reserved by the author.

The Software Craftsmanship 15 & 16

Chapter 15 discusses the benefits on writing quality code as opposed to average code. He describes that quality code is expensive and average code being cheap. As a project manager, you want to produce quality products. This entails quality code, but as the author described quality code is expensive. It takes time to write it nice, clean and in an efficient way. As a software craftsman, one must hone in their skills to write quality code that is cheap.

 

Chapter 16 talks about the definition on being a software craftsman and what to do in order to be successful. In order to be successful with anything, one must have passion in what they are doing. For example, take a look at all of the great athletes in the world. No matter what sport, they all share a similarity. It’s passion for that sport, and that’s what makes them successful. It’s the same for being a software craftsman. You must constantly be learning and keeping up to date with the latest trends in technology in order to stay in the loop.

 

 

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

The Software Craftsman Chapter 15 & 16 Blog (5/9/2017)

Growing up, I always thought you had to choose between making a difference in the world and having a career that pays really good. As it turns out, after reading this book, you can have both; as a software craftsman! I really enjoy reading this book throughout all of its chapters. There was definitely a good amount of valuable information but it was written in a way where a lot of important concepts were constantly echoed throughout the book; such as being passionate about what you do, always leaving the code you work on cleaner than when you first started and of course, realizing that its bigger than just you.

Reflecting back, I used to have the mindset of never wanting to share or collaborate with anyone else because I felt as though it was my code, and my code only. Now, I just chuckle at how ignorant and unknowledgeable I was. If there was only one concept I could retain from these readings, (not including passion) it would be the ideology that software projects are not just about us and our egos. To become better software developers (and better people overall) we have to think about the bigger picture. We have to make sure that the foundation of the code we create and work on is sturdy; that it will not come crashing down when we, the current developers, are no longer around.

I think one of the reasons why people shy away from legacy code is because the previous developers has created such a crappy foundation of code that we are afraid of moving or changing any piece of code due to the fear that everything is just going to come crashing down. But, it doesn’t have to continue to be that way. We have the power to change that way of thinking because we have the power to change the way we code!

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

Software Craftsman ( Chapter 15 & 16)

Chapter 15 was all about the benefits of writing quality/expensive code vs. average/cheap code. It is a myth that quality code is expensive. According to the book, often managers must choose between producing quality products which take time to produce and average code that does not take much time to produce.  It is the duty of software craftsmen to produce clean quality code that is inexpensive.

Overall, what I learnt from this chapter is that quality code is not expensive. The lack of skills on the part of the developer is what makes quality code expensive. Developers must do their best to produce quality code which is inexpensive.

Chapter 16 was about what it means to be a software craftsman and how to have a successful carrier. The #1 word that summarizes what it means to be a software craftsman is passion. Software craftsmen are passionate developers and they love what they do. Being a software craftsman means that you much constantly learn and improve your craft/skills. You are in a journey to mastery. Mastery of software development is a long hard road. Every carrier decision you make must be in order to move you forward in your goal to mastery. And also, as mentioned in the previous chapters a job is a mutually beneficial relationship. Both the employer and the employee must get the best out of the relationship.

To sum up, I learnt about what is takes to develop quality/inexpensive software and what it means to be a software craftsman from reading these chapters.

From the blog CS448 – The blog about software by Sudarshan and used with permission of the author. All other rights reserved by the author.

The Software Craftsmanship Chapter 13 and 14

Chapter 13 talks about the learning culture and it states that Jr. Developers are lead to have this notion about becoming a manager is the outcome of all of their hard work. Lets say a Jr. Front End Developer has a passion for building front end applications. He/she could become a manager in the long run, but if there is a true passion for it, another career goal is to turn that Jr. Title into a Senior title.

Chapter 14 was a little interesting. It talks about the different types of developers that you might encounter. As we all know, there are a ton of ways to get a job done in programming and everyone has their own way of doing something. A person might see that this is the only way to do something, but your way is more efficient, you must walk them through your code so they can see why your way or your thinking would be the better option in this situation.

 

 

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