Book Review: The Software Craftsman: Professionalism, Pragmatism, Pride

Spur

 There were a few things that made me read this: 
  • I saw it lying on my dev managers desk
  • We have a coach from the company that the author co-founded in our place at the moment
  • I was cynical about the software craftsman idea and thought it was about self-serving, elitist and pumped up self publicists
Inspirational
 
I'm not a soppy or effusive person, but I have to say this book really resonated with me and, like a really good rally call,  made me feel positive about my current position and how to sustain and develop my career further and just how I might achieve this. The thing is, I knew most of this already but just hadn't bundled the virtues, thoughts and values that are described, under a particular banner. 


The Software Craftsman Manifesto


It actually exists!  A set of values to which a software craftsman can hang their hat.  Now, like the author says, there are people who don't like to call themselves craftsman and I am one of them, but the ideas of professionalism, adding value and trying to do a good job are things I already embody and value in my peers. Its good to see that in the UK there is a large community of people who are interested in the same things, the LSCC being one of these groups.  I need to get to one of these groups locally, any of these in Brum? 


Not about TDD or XP

The book isnt about TDD or XP necessarily but they are advocated as, currently, the best ways of helping produce quality and valuable software.   In fact it is mentioned an awful lot  - but you will need to buy a different book for advice on specific technical practices.

What to do

I, like the author, often hear that people say that the company they are working at is not investing in them and propelling them forward in their career.  Sandro pulls no punches in saying that this responsibility is left squarely at your own feet, which I completely agree with.  Professionals in other industries have to stay current and continue a life long journey of mastery why should devs be any different.  

From reading books to attending meetups to pet projects to blogging,  a number of strategies are discussed to help you help yourself.  

This is probably obvious to most people, but doing it is different from talking or knowing about what you need to do. In the first part of my career -  after leaving Uni - I didn't invest enough time in learning  new stuff and keeping up to date with what is current - its a lot easier now and I'm lazy - but I'd be further ahead if I'd maintained my out of work learning after Uni. Don't get me wrong, I was still working hard and wasn't a 9 to 5'er but my working life may have been a bit easier if I'd supplemented it with stuff I'd learnt so that I could lead and not just be lead. 

Identifying your peers
There's a great section on the different types of personality traits of people you will work with from the "fanboy" to the "irrational" to the "cynic".  Discussing how to deal with different people and knowing that other people have identified them, certainly makes you realise that you weren't the only frustrated person.    There is some great advice about being humble and open to ideas, which is a quality some peers lack and hopefully when they read his hallowed words they will reflect and be a bit more open.   Also "fanyboys'" should take stock and just "chill the fuck out".  Yes, I'm sure the tech you learnt about last night is great I just don't want it rammed down my throat - again....


Interviewing/Being interviewed/Career choice


Yeah , tips on interviewing may seem a bit out of place but good advice on interviewing your prospective employers is indispensable.  Also, advice on owning your career and knowing what you want and when you want it vindicates some of the choices you have had to make where more money was necessary or opting for a slightly less hectic pace when building a family. 

 Summary

I'm certain I've missed some pivotal parts of the book out of the review, my short term memory is terrible (and I promise to pay them their dues next time I pick up the book)  but I am left in no doubt that this is an excellent book, if you are disillusioned it may reignite you hunger, if you are looking at what you need to do to help you progress, it has sage advice.  I'd almost label it a developers self-help book,  I certainly wouldn't have bought it, if it had a self-help title but it makes me think I might read a few more of these if it gives you a spring in your step.  Or is that just because its Spring? Enjoy. 



Comments

Post a Comment

Popular posts from this blog

Book Review: Test Driven Development By Example (Kent Beck)

GitHub I have coded the examples and both are available in GitHub.   Money  and xUnit  Delayed... I am recalling this after a few weeks finishing the book (I should've done this immediately so my memory is hazy, but the code examples should attest to the fact I have read it, if my descriptions of the text are a little ambiguous)  I have read this book on a number of occasions previously, in reference form and once all the way through,  but hadn't worked through the examples in  a code editor.  I think, for real value, you have to  code the examples, after a while it does feel like you are actually pairing, like others who have reviewed this though, I think the humour leaves a bit to be desired but its not too distracting! I have been TDDing for a while but this was a good refresher and reminded me of the maxims and techniques "fake it till you make it",  "obvious implementation" and "triangulation". There are also some nice "red" and &quo
Read more

SSDT March 2014 Static Code Analysis Extensibility

Static Code Paralysis. Coding standards (and more latterly styles) in any organisation of any size are liable to incite religious wars and makes zealots out of even the most considered or apathetic of us.   Inconsistency and subjectivity,  lack of enforcement and heavy handedness all contribute to the contempt often leveled at them.   Sod it. I say sod all that, if you or your company aren't using static analysis tools  then you are missing out on improved code quality and productivity (borne out from a consistent approach) and reducing the most banal and mind numbing conversations and sometimes pissing contests associated with discussing the minutiae of standards.   As an aside, having a few years under my belt  in the industry  I've found that people who "really" moan most about this are usually rabble-rousing morale sappers who like to moan about everything, so it stops them doing this and maybe might lead to them getting on with work instead! Makes thin
Read more

MongoDB

Mongolicious MongoDB training, provided by MongoDB themselves, was up for grabs recently, so I put my name in the hat to get a keener insight into MongoDB and NoSQL databases, having used them only a few occasions. The training was attended by a near 50/50 split of devs and DBAs and this led to some interesting debates and reactions.   Like lots of the stuff I've been introduced to/have started looking at recently (I am late to nearly every technology party there is) they (Mongo and NoSQL) have been around for a while and have become established as a viable alternative persistence solution to the likes of MSSQL.  The main features: Its schema less Document oriented/No support for JOINs  Querying performed using JS/JSON Indexing Replication/Redundancy/High availability Scaling out via Sharding  Aggregation (unfortunately we ran out of time so this is not covered here) Authorisation (again ran out of time on this one)  Its schema less You'l
Read more