This is my comic SF novel – however it mostly takes the rise out of corporate culture … have fun.

• 1 Bay Sick Training
• 2 Down Sizing
• 3 Lumpy
• 4 Any Colour you Like

Back in the 1980’s I wrote a dark novella called The Warm Gun. It’s not autobiographical in a plot sense, but some of the things in it did happen to me. The horrendous beating at the beginning of the book, for example.

The machine it was originally written on died and I had a copy of it on paper, so I scanned it all in and then converted it, I did have the beginnings of a new draft as well.

I have put the new draft with the old and made it make sense.

I’m looking at how to build an audience for my fiction and other works and decided that a relatively pain free way of doing this would be to publish things for the Kindle. So I registered and put it on there, after purchasing a suitable cover picture from iStockPhoto.

The novella isn’t Hollywood, it doesn’t have clear endings, people don’t always get what they want. It doesn’t have that irritating Ruth Rendell thing where the bad guy or gal dies in a fire to expiate their guilt. It also predates me becoming a Buddhist, so some ideas are not ones I currently hold.

In any event, I wanted it to be free but Amazon need to cover the distribution costs, so I made it as cheap as I could. I hope you enjoy it.

Imported Comments:

Paul Jackson

I’ve downloaded a copy on to my wife’s Kindle and look forward to reading it – can you sign her Kindle cover!?

Assume we’ve got a namespace of Customer and in that a controller for Organisations.

This doesn’t work

class Customer::OrganisationsController < ApplicationController

  respond_to :html 

  def update
    @organisation = Organisation.find(params[:id])
    @organisation.update_attributes(params[:organisation])
    respond_with [:customer,@organisation]
  end

end

It redirects to the customer_organisation show method without checking for errors. I think it should work, but the respond_with code doesn’t handle it properly. Instead, try this:

class Customer::OrganisationsController < ApplicationController

  respond_to :html 

  def update
    @organisation = Organisation.find(params[:id])
    @organisation.update_attributes(params[:organisation])
    respond_with @organisation, :location => customer_organisation_url(@organisation)
  end

end

I’m not sure it’s annoying enough to want to patch it. There are a lot of edge cases in Rails in general around name spaces. Also, note it’s not just update that needs this but also create.

Imported Comments:

malclocke

respond_with :customer, @organisation should work, without the square brackets

Total responents 40

This is a temporary home for this while the main site is built.

Would you attend an Agile Charity Day (there will be a Ruby one anyway)?

Would you prefer a one or two day conference?

Would you like to be on a panel for a balloon debate?

Would you attend a post conference Ruby or Agile Dojo?

Would you or your company be interested in sponsoring Magrails?

Would you like to help with the organisation of the conference?

What Agile topics would you like to see and discuss?

What Agile topics would you like to see that weren’t in the list?

• agile v fragile – when to say no. It’s a fine line between being flexible and being stressed and overworked with constantly shifting directions or new features.
• How to start off
• Estimation
• CEO ACME org. Take 2 Agile pills a day for 6months. SWOT for the CEO.

What Ruby/Rails topics would you like to see and discuss?

What Ruby topics would you like to see that weren’t in the list?

• Building cross-platform mobile applications with Ruby – introduction to Rhodes
• Better Rails application design
• transition to rails 3 – routes
• bundler
• unobtrusive js
• Ruby 1.9 v 1.8
• which editor – textmate, vim, eclipse… maybe textmate etc. hints and tips
• improving productivity (I use textmate but I’m sure I’m not using a tenth of what it can do for me)
• Setting up an agile rails project – the plugins
• test frameworks etc you should use (ie do it at the start cos retrofitting things like cucumber etc is painful)
• Rails deployment strategies – phusion v mongrel etc. (I use passenger as it comes on a single box but there must be better ways)
• Event Machine – writing truly evented systems
• Making stuff work quickly with quality.

Suggested Balloon Debate topics

What Balloon debate topics would you like to see that weren’t in the list?

• IDEs make you dumb
• what’s really happening under the hood
• Cucumber’s wonderful, really

Once

A star died

Made the things bones are made of

All changes

Little star

My teeth

This article is part of what made me start on trying to organise the Manchester Agile Rails Conference – if you’re interested in it happening please fill in the survey.

You Ain’t Gonna Need It (YAGNI) – vs flexibility

The best software I’ve ever written is the software I didn’t write.

I use Ruby on Rails – you’re probably sick of hearing this by now. But one of the things I really like about it is how much it does for me without getting in the way. If I use the code generators and know what the data model looks like I can generate you a whole CRUD¹ application in about 5 minutes, as long as you don’t mind the appearance of the scaffolding application. You can pick other scaffolding or even spend a few minutes changing the generator to suit. There’s another Ruby framework with much less in than Rails called Sinatra ². It’s very minimalist and you write simple code that returns something to an HTTP request. It’s fast as all hell and very good for writing simple API’s. There’s a very simple application framework called Pandrino ³, that sits on top of Sinatra; it gives a CRUD application with two or three colour-themed looks – and that’s all it gives you.

I can create a working back office system that sits on relatively simple databases in about a day. Yes, a day. I can even put some validation in and make sure your data integrity is properly maintained. There are Python frameworks that do the same.

It won’t be full of flashy JavaScript, or do much beyond letting you edit and maintain your data, but it will do that very well, and cost practically nothing to build if you know your data.

If I use Sinatra inside Rails I can put an authentication layer in by putting it before Sinatra in the application stack using a Ruby gem called Devise ⁴. It’s about 20 lines of code ⁵. 

I didn’t write any of this code – that’s the point. Some very capable people had a need and met it, they shared it. Then others refined what they had. Then stopped when there was enough to get the job done. They did just enough to let fools like me sit on their coat tails, bless them.

Rails is opinionated – if you do it the ‘Rails way’ then it’s easy to do what you need. If you decide to be another damn NIH ⁶ geek who has to hand-craft the journey of every electron then go do that. The rest of us are helping people get what they want. The opinions are also those of people who know what they’re doing. So ignore them at your peril.

How much is enough?

In one of my other lives I play blues guitar. I was brought up on (amongst others) Paul Kossoff ⁷, he’s well known for playing the rather splendid guitar solo on All Right Now, however one of my favourite tracks is Oh I Wept – the guitar solo lasts about 30 seconds and is sublime (the rest of the song’s pretty dull if I’m honest). He’s quoted (somewhere) as saying it’s not the notes you play, it’s the ones you miss out that matter ⁸. When you listen to that song you know what he meant – probably 20 notes played supremely well, and the right ones to pick up the feeling of the song and raise it from blandness. He was originally a classical guitarist and could probably have played at 100 miles an hour – but didn’t. He played exactly what the song needed, and no more. This requires a kind of sensitivity, of humility, that’s pretty rare.

I’m a developer, I think in code. I like code – complexity and shiny new things fascinate me (at least while I can keep them in my poor old head). When I look at problems I see solutions – when someone talks to me in meetings I’m writing software in my mind (if I’m not playing guitar there). Fred Brooks (I bet you were wondering how long it would take to mention him) said ⁹ throw the first one away. I’ve done this plenty of times. You look at something that kind of works – and realise you haven’t understood properly. The first attempt is about understanding what the question is, you don’t have an answer yet, the second attempt will be closer – closer, not necessarily right. When I was a couple of years into being a developer I learned a great lesson from Pete Wilson ¹⁰ (you there, Pete?), who worked with me on a system for hospitals. We were looking at a vast lump of ‘C’ code built to load data into the accounting system we were working on. 300+ lines of code sat there. We were pairing before there was such an idea, just talking it through – I pointed out that the pointers in this code weren’t used right or something – he agreed and deleted all of it. All of it. Started again. Didn’t try to fix it, deleted it now that he understood the problem. Stopped the cut and paste monster ¹¹ in its tracks.

This shocked me to the core. No fiddling. No clever editor macros to move variables about. Delete it and start again. Wow. Don’t waste time loving that sick puppy, put the poor thing out of its misery. When I pair with people they get scared when I just delete things that are wrong. Sometimes whole methods or classes. But if they’re wrong they’re wrong – get rid of them. You need to ignore the emotional investment in the code and be glad you learned something. The code is a conversation.

Complify and Simplicate

We’re always trying to get to answers as coders – all the time. I watched a talk on Simplicity Archtecture ¹² by Dan North. One of the key points that struck me was the tension between YAGNI and flexibility. If you write software that can do anything in the problem space it it very flexible. So, lots of meetings where developers and designers have said but what if a lot and you end up with something that can do just about anything – but then only a small percentage of it is actually used. Anyone who has tried to migrate from Word 2007 to the latest incarnation with the ribbon bar and all the menus moved about will know how this flexibility feels to the user – as in it gets in the way. Most people only use about 5% of anything complex. What use is a retail site where buying stuff is hard because so much attention was paid to SEO that you can’t find the buy button? But you’ve been to that site – I was recently foolish enough to buy some lottery tickets on line – the BUY button is bottom right and very small – what’s the main function of the site? Selling tickets. What’s hard? Buying them! It took a couple of minutes before I could enjoy the vicarious pleasure of maybe winning £33 million for a £2 stake – a couple of minutes that nearly made me give up in frustration. I think they want you to read all the advertising copy about how wonderful they are first and the button sits at the end of it – I just wanted the button.

Other points about flexibility vs YAGNI (or the absence of unnecessary complexity) from Dan’s talk (mixed in with things that occurred to me while I was writing them down):

Ease of change. Maximise the work not done ¹³ – do nothing yet, defer until the last responsible moment, then make a decision. This is one of the Agile principles and gets forgotten a lot. 

Flexibility, on the other hand, is shove everything in just in case. This is expensive and very hard to do. Also pointless. It’s sticking the space shuttle engines on a 747 – madness.

Humans are designed to simplify and generalise what comes to them or they’d be overwhelmed. We get wrong footed by our complex society and the demands of work. One of his colleagues came up with the words complify and simplicate – humans generally try to over complicate things because they see patterns everywhere, even when there aren’t any, and then try to generalise them – hence complify. The goal of complicated endeavour should be to do only what’s needed and no more – simplicate.

Complifying’s most obvious symptom is yak shaving ¹⁴ – running off away from the problem because you haven’t taken a step back to think it through properly. Procrastinating without realising it. Dan’s solution to this is to ask why along the lines of the old 5 whys ¹⁵ technique.

Simplication – you need to go the other way and take a step back from what’s in front of you. Ask how?

Deliberate discovery – am I tackling the thing I am most ignorant about now? Ignorance is where the risk is. Eliminate oh shit moments at the end of a project. Tackling ignorance also gets rid of fruitless arguments around opinions – get some hard data and go where it takes you.

Every time someone says but what if – say will it? Talk to the user of the software, go for a walk. Use evolution to decide what lives ¹⁶: as in ‘no’ is the answer to any new thing until it manages to establish itself.

Dan talks about a technique I’m going to try soon: creating beyond/towards lists, as in go beyond late finance reporting, towards timely information – sometimes towards is too big a jump so create a column in the middle of the list via – this will help you come up with a road map of where you want to go.

He was also scathing about user stories – as in what the user wants, in the end, is capability – I want to be able to do something I couldn’t do before – the old scrum/XP thing of done means done – done is when you have the capability, nothing less than that.

Solutionitis and Cargo Cults

New coders, particularly since the invention of the internet and the ease of copying and pasting, tend to copy things they don’t understand and then poke them with a stick until what they see seems to respond in the right way. In Pragmatic Programmer ¹⁷ they call this programming by coincidence (see also Cargo cult programming ¹⁸ ). If you were thinking of evolution as a metaphor this might be a valid approach. But as a thoughtful approach to whatever problem you’re trying to solve it’s beyond poor, it’s a waste of time and gives you untestable rubbish instead of crafted code. If you have no idea where to start ask someone. Seriously, ask someone. Ignorance is not a sin, whatever various world religions may say. On the other hand, hiding it is – because it costs time and money. 

When I pair with someone I try and stop them writing code. I try and use the framework. I hate repetition because it’s dangerous and expensive. Rails is fast to get started and has a lot of useful stuff to help you. To get the most out of it you need to learn it, and read the books to keep up, and pair with people who know different things from what you know. Once that’s done you can get the framework to do the work for you, and be proud of the code you didn’t write.

But, if I wasn’t writing a database-backed website with some Ajax and dynamic content, Rails (and Ruby) might be totally inappropriate. I still occasionally write ‘C’ code, I still write simple text processing things using Awk – it just works for some kinds of problem. Always starting with the same set of tools, regardless of what you’re doing, is solutionitis. You think you already have half of the problem solved − maybe you don’t, maybe your tools are going to get in the way.

Pareto has two ends

In essence 80% of the results come from 20% of the effort ¹⁹. You can have a is the cup half full or half empty kind of argument about this; as in – saying you still need the remaining 80% of the results – so now you need to sit down and get obsessed by details. Or, if you’re looking at something that brings money in to your business you can say – where’s the next 20% I need to do? Most of the time the second question is the one worth asking. If you’re building something that involves human life or safety then you need the other 80% – but that’s part of the cost of safety critical systems and no-one will baulk at paying it, unless they’re an idiot, and then I would get away from them as fast as possible.

Productivity

I was browsing Martin Fowler’s blog the other day and came across this unfortunate truth: you can’t measure productivity ²⁰. But I think you can be far more productive if you don’t write code. Investing the time and energy in understanding the framework you use, and in finding libraries you can trust that do chunks of work for you, is productive. Writing the 20% and no more is productive. All the rest does is make your yak get cold.

YAGNI and real life

So, when someone tells you you can’t do something. When a problem in your life looks like it can’t be solved. When you can’t work out how to do something that isn’t software. What code can you not write? What things don’t you need to do? What yaks don’t need to be bald? It does no harm to apply YAGNI here too.

¹ Create, Retrieve, Update, Delete – the four operators of the database apocalypse. http://en.wikipedia.org/wiki/Create,read,update_and_delete

²http://www.sinatrarb.com/

³http://www.padrinorb.com/guides

⁴https://github.com/plataformatec/devise

⁵http://pragprog.com/titles/jvrails/crafting-rails-applications last chapter.

⁶http://en.wikipedia.org/wiki/Not_Invented_Here

⁷http://en.wikipedia.org/wiki/Paul_Kossoff

⁸ I suspect a lot of other people have said this too.

⁹http://en.wikipedia.org/wiki/Mythical_man_month

¹⁰ Emigrated to New Zealand in the 90’s and I lost track of him. Last known working for Sequent before IBM bought them.

¹¹ You paste something in that compiles and appears to work – but has the wrong variable names and you forgot to change them, until it’s cost thousands and everyone’s embarrassed. This happens all the time.

¹²http://www.infoq.com/presentations/Simplicity-Architect

¹³ Agile manifesto again

¹⁴http://en.wiktionary.org/wiki/yak_shaving see the second definition.

¹⁵http://en.wikipedia.org/wiki/5_Whys Click through to why/because as well.

¹⁶ Rework discusses this in some detail

¹⁷ Pragmatic Programmer

¹⁸http://en.wikipedia.org/wiki/Cargo_cult_programming

¹⁹principle”>http://en.wikipedia.org/wiki/Paretoprinciple

²⁰http://www.martinfowler.com/bliki/CannotMeasureProductivity.html

This is a reworking of a list I created a couple of years ago for a client. Hope you find it useful.

Contents

• Object-orientation
• Dry and Shy
• Tell don’t ask
• The law of Demeter
• Object Composition
• Ruby considerations
• Replace case statements with behaviour
• Fat model thin controller
• Short methods and classes
• General points
• Magic Numbers
• Let Boolean be Boolean
• No Surprises
• Comments
• Exceptions
• Databases
• Filters
• Generic Database Code
• Don’t ‘select *’ from tables
• HTML and CSS
• Javascript
• Recommendations for fixing “unstable” code
• Continuous Testing

Object-orientation

DRY & Shy

Don’t repeat yourself (DRY)

An example of this is having setup and teardown code repeated in every method. This avoids a heavy maintenance load and ensures that the “cut and paste monster” does not create code that looks correct but references incorrect variables, or require fixes to be applied across many classes where they might not be implemented properly.

Don’t tell people about yourself (shy)

In object-oriented design this means that an object should not expose how it does things, it may expose a method that gives you a result saying that it did it. Outside of a class used to transport data around most classes should not expose their internal attributes to client classes.

Back to top

Tell don’t ask

Procedural code gets information then makes decisions. Object-oriented code tells objects to do things.
— Alec Sharp

Objects should be told what to do – not asked about their state and then the client object decides, procedural code uses state like this. This causes strong coupling between objects and makes testing and refactoring a nightmare. This also avoids the “train wreck” scenario where you end up with long strings of method calls, e.g.

project.client.calls.first.message

See the following links for more discussion on this:

Tell don’t ask

Mock objects and tell don’t ask

Back to top

The law of Demeter

This came out of a project on object-oriented design called Demeter, it is a more formal way of talking about tell don’t ask. It is also described as the principle of least knowledge. A caricature of this is to say that there should never be more than one ‘.’ in the string of method calls; of course common sense says this is a guideline rather than a hard and fast approach. In essence constructing helper methods to mask out long chains and make it clear what you are doing.

In summary:

More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects:

1. itself
2. M’s parameters
3. any objects created/instantiated within M
4. O’s direct component objects

It is explained here

A common mistake is discussed here; one should endeavour to delegate behaviour not attributes

Back to top

Object Composition

It is often better to compose an object from others rather than extending something and giving it too much to do or overriding the default constructor and creating a hybrid object in a non-standard way.

Ruby-specific considerations

Reusability in Ruby is not just through inheritance. It also works through modules. You need to think hard about using modules or inheritance and be able to justify why you chose one over the other. There are no right answers but don’t just blindly do what you did last time. Sometimes modules can be hard to understand and debug, and even hard to find if they’re in, say, a library directory outside of the main code base.

Back to top

Replace case statement with behaviour

Long case statements are not true object code. Depending upon the circumstances there are several ways to refactor this:

1. Use a Hash
2. If an object needs to be instantiated or a method called then use the technique in 1 to call a lambda function (created using create_function if you’re a PHP head) that will return the object.
3. Any long list, e.g. of return codes, should be held as a Hash and used to return the associated value directly.

A long case statement indicates the target object is not broken up into grouped behaviours correctly – the client object should be calling a method to do what it needs directly and the case statements would be unnecessary.

Testing code written this way is far easier. The dispatching array needs to be set up correctly and each single method can be tested independently. Testing a large case statement is almost impossible. The behaviour in each case needs to be put into its own method.

Back to top

Fat models, thin controllers in MVC

When using the Model/View/Controller architecture any complex work should be done by the model code. This encourages reuse and moves the controller to just controlling and dispatching.

Back to top

Short methods and classes

Methods should not be in excess of about 25 lines including comments. A class should have its responsibilities well-defined and not have more than ten or so methods.

Back to top

General points

Magic numbers

There should be no references to numbers or stages that aren’t given symbolic names to make the code clear. This also means method names, e.g. fred_12321 is not helpful.

Back to top

Let boolean be boolean

Consider the following

isMyNumber = (defined?(biff) && boff == 3) ? true : false;

There is no point in testing a boolean result to return a boolean. (I also have a personal dislike of the ternary operator, because it encourages this kind of sloppiness, think!).

Back to top

No surprises

If there is an accepted way of doing something, e.g. a class constructor calls the super class method, do not create non-standard ways of doing things. If something has to be done in a non-standard way there must be a comment to that effect.

Back to top

Meaningful comments

An example of a meaningless comment is:

-- Open cursor
open cursor x for ...

A comment that just says what the code is doing is a waste of time.

Another example is:

/**
 * Enter description here...
*/

Enter the description or remove the comment. I don’t care if your code generator puts it in, it’s garbage.

Back to top

Exceptions

try{
 someDodgyOperation() ;
} catch( e Exception ){
  return null ;
}

Just don’t, ok? Handle the exception, or at least log it somewhere to give the next poor soul a chance of finding where the problem is. In Java you’ll get a null pointer exception somewhere probably completely unrelated to where the problem actually is, same in Ruby or any language you care to name that has exceptions, just don’t do this.

Back to top

Databases

No filtering of result sets from the database

This involves getting the database to do the work – there should be no need to filter result sets. Retrieving more data than needed has several deleterious effects:

1. Data sets need to be passed through several layers to get to the calling module – the less data that needs to be marshalled and transmitted the better.
2. Retrieving large sets and filtering for a few records can easily cause locking and contention problems.
3. Testing may be difficult because the PHP instance may run out of memory if the sets are not released quickly enough to be garbage collected.

In essence: make sure the database returns as little as possible and keys and relationships are properly policed.

Back to top

Generic database code

If the where clause changes but the columns selected do not, the where clause should be made into a something that can be set. This reuses the method and the return bindings, meaning they only have to be changed in one place

Back to top

Do not ‘select *’ from tables

Under no circumstances should * be selected from a table:

1. All of the columns will be selected regardless of the need for them – see the discussion in in the above section about this.
2. The values returned are dependent on the default order the columns appear in in the database and that is a function of how they were created. There is no guarantee that, for operational reasons, columns in your development and production environments were created in the same order, an RFC could have been applied in a different order – this will break and be very hard to debug.

Ruby on Rails Active Record fixes the ordering problem. But if you have several K of text you don’t use often, it won’t hurt to think about not retrieving it.

Back to top

HTML and CSS

HTML code should not use deprecated tag attributes, e.g. bgcolor, or valign. Styling should be done through CSS.

Sizes of elements, e.g. tables, should be done through CSS also. This allows a DRY approach to styling output.

CSS should not be in line but in its own sheets to promote reusablility and allow the web browser to cache it. It also allows restyling work to be done with a minimum of fuss.

HTML should be conforming, e.g. attributes should be inside double or single quotes and lower case as recommended by the W3C

HTML 5 may change the definition of conforming HTML, because there’s a lot less nonsense in there.

JavaScript

JavaScript should be in separate files, if it needs PHP then the web server will sort this out. If the script is less than twenty lines or so then inline is fine, otherwise it should be handled in its own file. This is to promote reusability of the scripts and allow the web browser the chance to cache the JavaScript.

Most of the comments about code in the above section also apply to Javascript.

Back to top

Recommendations for fixing “unstable” code

In order to change code you must be able to say that your changes have not broken any existing assumptions. This means that you need a reasonably complete test suite to begin with.

Creating such a test suite, and the culture that keeps it up to date, is a sound investment in future. When bugs are encountered then a new test should be created that exposes this error – then it is fixed. The whole suite running ensures that no new bugs have been introduced.

There is a good article (and book) explaining this in more depth

Back to top

Continuous testing

This does not require a large amount of resources and can be built up over time. It needs to be in place before any refactoring takes place. Normal practice is to keep the testing running and ensure that refactoring has not broken any existing functionality.

Deploys are automated and run the test suite against a test database before they happen. Any failure will stop deployment. (in my dreams)

Back to top

Linchpin: Are You Indispensable? by Seth Godin
My rating: 5 of 5 stars
Seriously, if you want to know why your children’s school seems to not be teaching them to think, if you want to know why you hate your job, read this book.
Our entire education system is built around creating good factory workers, who have no initiative and do what they’re told. You may sit in a call centre or push numbers into a computer all day – but it’s still a factory, think about it. Guess what – the factories are all gone or on their way, and cost-cutting means that you can’t compete with folk from other countries. The race to the cheapest is one you can’t win. The race to the most useful, caring, innovative – well, you’re competing with the cheapest, they’re going to lose.
Enter the linchpin – someone who adds value, who cares about doing a good job, who thinks about how to get things done more quickly and to a higher standard, a game changer. Your boss will employ a competent drone if no-one else is available, but would prefer a linchpin. Someone who is difficult to replace. If you don’t want to be easy to replace then read this book and follow Seth’s advice.
The latter half of the book gives a whistle-stop tour of the human brain and goes into some detail about how the “lizard brain” tends to sabotage the thinking brain and choose short term comfort over long term success. It needs to be tricked to get out of the way and allow you to succeed. Godin talks about how the lizard brain made him stop writing the book several times, because it was hard work. The paradox is the lizard brain likes comfort, but is scared of success.
Read this book if you want to escape the whole post-industrial “my job went to India” fear and find your way to a future where you enjoy what you do.
Just read it, it’s the 21st century equivalent to How to Win Friends & Influence People, (which you should read as well).

View all my reviews

Imported Comments:

ChuckJHardy

Reading this at the moment – really enjoying it, thanks for the review

The Circle of Innovation: You Can’t Shrink Your Way to Greatness by Tom Peters
My rating: 5 of 5 stars
Had this book on tape and listened to it many times back in the early noughties. I was writing a blog post about “The Agile Heart” (http://goo.gl/aBCae) and quoted from it, so I got a second-hand copy from Amazon to verify the quote, my tape player having gone the way of all flesh a while ago. Still need to change the quote, but there you go.

Thing is, even now, nearly 15 years after it was first published, it’s a gem. The style is designed to look like his presentations, with a slide-like set of images setting up a proposition and then some discussion about the ideas. I’ve also been reading Linchpin: Are You Indispensable? and they cover a lot of similar ground. Peters’ take is more based on subverting the traditional workplace, “brand you”, “making everything a project”, “making where you work into a company in its own right”. Godin talks about the kinds of behaviour and attitude you need to make what Peters talks about become a reality. The two books complement each other. I think Linchpin is an essential read for anyone who cares about where we are today, but Peters’ book gives some historical context.

The subtitle you can’t shrink your way to greatness is a polemic with the late 90’s obsession with the bottom line: how big corporations were doing a slash and burn on their workforce and their working conditions to drive profit up. But if you race to the bottom you end up competing with people who are much poorer than you are and will do the same low-value work for less in a different country. You lose, the whole enterprise loses, and that’s it. This is also the theme of Linchpin. Two recessions later we are still learning the same lessons, funny that. Those lessons being that creativity and what Peters terms “emotional labour” (as in giving it some heart and caring about it) will keep you fed, but charging to the bottom won’t.

Both authors say that if you’re stuck somewhere you can’t do “emotional labour” or become a Linchpin – move on. Good advice.

View all my reviews