Fortsätt till huvudinnehåll

Book review: The Software Craftsman

I just finished reading "The Software Craftsman" by Sandro Mancuso. Sandro is a sofware craftsman, author, and founder of the London Software Craftmanship Community (LSCC). He has worked on a number of different projects and companies ranging from small start-ups to large organizations.



Software craftmanship as a term is something that I came across for the first time in 2013 when I signed the Manifesto for Software Craftmanship. Around that time I also started reading books like "The pragmatic programmer" and "The clean coder" (both which I recommend by the way).

Actually Robert C. Martin - the author of "The clean coder" - has written the foreword for "The Software Craftsman", in which he states that he felt like he could have written the book himself. And that's 100% true. If you have read "The Clean Coder" you will recognize most of the ideas and topics discussed. At least for the first half of the book.

What Sandro emphasizes is that introducing agile methods at a company is good, but it is far from enough. Shortening feedback loops, empowering teams, and increasing transparency falls short if you don't change the way the developers look at their profession. Remember, agile puts individuals over processes and tools, right?

In order to really make a difference the developers needs to be passionate, proud, and professional. We should strive to always keep raising the bar.

Sandro goes on and describes attributes that he thinks are typical for a software craftsman, such as owning your career, keeping your skills up to date, know how and when to say no, taking responsibility for your actions and the code you produce and focusing on solving your customers' problems. He also describes techniques that the software craftmanship community has adopted such as test driven development (TDD) and pair programming.

A part of the book that I thought all managers and recruitement agents should read and consider is the description on how to attract great developers. The usual job ad that basically is a wish list of tools and techniques really isn't that compelling. Instead Sandro writes that a job ad should focus on attracting developers eager to learn and explore the areas in which your company operates. That the personality and passion for software development is far more important than the number of years you have been working with a specific language or framework.

I do not agree with everything Sandro writes. Sometimes I think he crosses the line of what you can expect from people. But mostly I recognize myself in what he writes and I even got some good laughs from this book.

I would recommend this book for any software developer that have been around for some time, espacially if your company has been through an "agile transformation" recently. You will find many things worth spending some thoughts on. People involved in recruitment of software developers should also read and think about the parts of the book related to that area.

Kommentarer

Populära inlägg i den här bloggen

C# Enum as bit field

Bit field enum Whenever you wish to express combinations of properties of an object, bit fields are a good way to accomplish this. As a simple example, consider a file in the file system. It can be Readable , Writable , Hidden or a combination these. The different attributes can be defined as an enum : [Flags] public enum FileAttribute {   None      = 0b0000;   Readable  = 0b0001;   Writeable = 0b0010;   Hidden    = 0b0100; } To indicate that this enum is expected to be used as a bit field I have defined it with the FlagsAttribute . It is important to understand that the FlagsAttribute does nothing more than making some changes to how the ToString method of the enum works, making it possible to print out all flags. It does not introduce any validation or special treatment of the enum in any other way. I have defined the values of the different fields of the enum using binary representation, this should make it even more clear that this is a bit field and which bi

Codility tasks - Part I

I was recently faced with two codility tasks when applying for a job as an Embedded Software Engineer. For those of you who arn't familiar with Codility you can check out their website here:  www.codility.com Task one - Dominator The first task was called Dominator. The goal was to, given a std::vector of integers, find an integer that occurs in more than half of the positions in the vector. If no dominator was found -1 should be returned. My approach was to loop through the vector from the first to the last element, using a std::map to count the number of occurences of each integer. If the count ever reached above half the size of the vector I stopped and returned that integer and if I reached the end without finding a dominator I returned -1. So was that a good approach? Well, the reviewer at the company rated the solution as 'pretty ok'. His preferred solution was store the first integer in the array and set a counter to 1. Then loop through the remaining i