The process and the people
I am a Level 3 Kayak (L3K) coach and have been for several years, probably around 15. In the software industry there are a lot of folk who call themselves coaches, but I do find myself wondering if they’ve ever had any kind of formal training. It took me a lot of time, money and personal risk to become a coach and I don’t regret it at all.
By the way, I don’t consider a three day Scrum Master course to be formal training. I had to meet the prerequisites, which were things like being a Level 2 coach, and holding various first aid and rescue qualifications. Then I had to do a three day course, where I became a candidate, then I had to amass at least 50 documented hours of supervised coaching, and then I had to do another 3 days assessment. The people running these courses had to go through very stringent criteria to run them.
I also have to attend recognised events every few years to make sure I’m still up to date. I don’t see this in the software industry. I do see a lot of pretence and bureaucratic certification, but that’s a different thing.
A L3K can take people on white water, assuming he or she feels they are competent and the group isn’t too big. In fact I spend a lot of time working on flat water with the Guides and Brownies, which means I work with total beginners aged between 8 and 10 who can’t even hold the paddle. Many coaches don’t like this, they want to work with older and more experienced paddlers.
I love it. It means I have to keep going back to the beginning and making sure I can express them in ways people can understand. It means I never lose contact with the fundamentals. There is a story about an American football coach, who used to begin every training season holding a ball and saying gentlemen, this is a ball. You have to have the fundamentals or you won’t go far, and you have to return to them or you may lose your way.
People learn by doing. There is no substitute for this, but equally there is a problem where you can create an ingrained habit that is a bad habit, where that habit holds you back. This makes coaching a very tricky proposition, it’s not practice makes perfect. Although this is true, it’s perfect practice makes perfect. You need the input of someone standing outside where you are, who knows the common faults and their solution. Then you need to be willing to sometimes start again, or at least it feels like it. You need to be practicing in a way that grows your skill, not embeds problems.
For example in the kayking forward paddling is a fundamental skill. A beginner will place the paddle in the water and pull on it, this will give them some forward movement, after a while of trying and experimentation they will learn to paddle forwards in a straight line. But if you were to compare their paddling action with someone who was say, a top-level slalom competitor, you would see a number of differences. Mostly to do with keeping the paddle close to the boat and using twisting of the body rather than just movement of the arms to engage the core and leg muscles for maximum power.
So you have to keep learning to paddle forwards over and over again as you get better. I’ve had to almost go back to the start three times in the last twenty odd years I’ve been paddling and every time I come out of it with a better, more powerful stroke. But I can’t fill a beginner’s head with this stuff, it would only confuse them and put them off. I always try to get them twisting if they can understand it, that helps a lot.
When you find yourself in a coaching situation the other thing is you have to go where the people are. What this means in practice is there’s no point in talking about a complex stroke, or rolling your kayak, or even the many techniques for rescuing people who have come out of their kayaks until the person can paddle where they want to go consistently and competently. They first need to be relaxed, and have a certain competence, before they even try to do anything more difficult. They have to be able to paddle forwards somehow before they can improve upon it.
In fact, they are incapable of taking on any more information until they get past the fears and annoyances they are experiencing right now.
Introducing something new
When I was a very new coach we used the acronym IDEAS
I think these points are pretty obvious, with the possible exception of explanation, which briefly touches on the why.
Of these Activity dwarfs the others. My big fault when I was new to coaching was talking too much. You need to show what needs to be done in small enough pieces and then get them to show you what it is they thought you said by doing it. That’s the process, not talking. Demonstrating, doing, not talking. Watching them in action and knowing the common stumbling places to help them overcome them, not talking. The summary is also extremely important because it helps the good behaviour become fixed.
Finding a coaching opportunity
There are two kinds of opportunity:
- Catching people doing it right – reinforcement
- Catching people in need of correction or direction – tuning
Notice I was very careful not to say doing it wrong. If you see a behaviour you don’t want you must work out where it came from and then correct it. If someone is doing it wrong, it’s your fault for not explaining or demonstrating well enough, or they just weren’t ready for the finer points the first time you showed them.
It’s not a problem, just show it again. As long as they are paying attention and trying their best there’s nothing to get worked up about.
The worst word you can use is but, particularly with male participants. Everything positive you said before the but is lost. Because of our school system and the way we’re wired, we listen for the negative, so criticism and correction have to be couched very carefully. It’s best, in fact, to ask a question to try and draw out the reasons for the problem. It’s best to let people discover the right answer themselves. A coach is a guide, an instructor instructs – be careful to be the former. A coach creates a safe place for people to learn.
No matter how keen somebody is to learn something once they get tired they will start to find it hard. Try something else or just bring the session to a close. If you start to flag then the same is true.
It’s important to inculcate good habits. For example, one of the worst things you can do when surfing or using support strokes is to lean back. When you are a beginner on flat water you discover that it lowers your centre of gravity and makes things easier. On moving water it creates vulnerability and also locks your hips, making control and recovery much harder. So I teach leaning forward and encourage it, but it doesn’t always go in.
So, in coaching people to be better coders recognise the bad habits – rushing in hacking instead of thinking, pasting in whatever comes out of google without understanding it, having a cynical attitudes that damage team productivity or a default position of blaming others – which usually comes from not listening carefully and checking assumptions.
This also links with tiredness and stress; when you are tired you fall back on the original habits you had because they were the first thing you learned. They are the default position, so cultivate good habits from the beginning. I know from my own experience that this is far harder than it sounds.
The beginner doesn’t know what they don’t know. So in fact they are capable of discovering new things that the coach can’t see because of their preconceptions. It’s always good to engage with the beginner, that’s how you keep yourself fresh. It also means that beginners aren’t necessarily wrong, and the questions they ask can be really useful and stimulating. It saddens me that our awful educational culture means that people often don’t ask these useful, gem like questions, because they’re afraid of looking silly or standing out. I’ve built my career on a playful, constructive silliness.
Beginners also need simple rules to help them – rules that an expert knows are more like guidelines. Simple rules can get you from zero to 80%, and they are always worth sharing if you have some. But just be careful they don’t become the dead hand of bureaucracy and start choking everybody. Rules are a what and very powerful, but an expert knows the why and when to bend or break them. Beginners need to lay in the good habits, so don’t confuse them, and stay quiet until they start to hit the limitations of the rules, then they can learn.
Part of going where people are means you must leave your ego at the door. Part of respecting the beginner’s mind means that you must also listen to what beginners have to say. If you don’t listen you are no use. You can’t go where someone is if your arrogance means you can’t see the map they provide you. This is why I often feel doubtful at self-appointed coaches, and why I don’t get on with the macho culture you often find in software teams.
If your participants aren’t enjoying the experience they won’t learn anything except they don’t like it. If you aren’t enjoying it you won’t be able to share what you have to share. So always look for fun and interest in what you do.
How many times have you heard employers or politicians talking about empowerment?
They’re going to give you permission to make decisions that affect you, or perhaps the people you serve. They’re going to allow you to organise things in a way that makes you feel happy with what you do, gives you the autonomy to do it right. Oh. That’s big of them, isn’t it?
This rests on some fundamental fallacies:
- In order to have any capability beyond some repetitive mechanical work someone has to give you permission.
- Someone has to pick you, and other people (therefore) have to wait.
Think about it – did Gandhi ask anyone for permission? He saw a problem with the world and just started doing whatever he could to change it. I went to Thinking Digital in May and one of the talks towards the end was a 15 year old who had come up with a cheap test for pancreatic cancer that will find early stage using carbon nanotubes, antibodies and filter paper. Wow.
He’s bright, very bright. But lots of other people are too. He was upset by the loss of a relative to this disease and decided to do something about it, he read a lot and came up with some things to try. Then he badgered some medics with research facilities until one let him come and try to develop a protocol.
It works, I hope it will come soon too. But the point I’m making here is no-one told this fantastic young person no. No-one gave him permission. He just went and did something that makes the world a better place.
So, the next time someone offers to empower you tell them where to get off. Pick yourself.
If you work in a way that creates systems and processes where human beings make human decisions then empowerment is not needed, permission is not needed. Grab that filter paper, grab those nanotubes, talk to that person.
Since I first made this post, which is a sketch of an idea I will develop further in Unicorns in the Mist‘s next outing more things have occurred to me that I wanted to share here.
I was chatting on Facebook and realised that I believe empowerment is also insulting. To clarify:
Insulting to the “empowered” – as in “you’re no longer too child like to look after yourself”. My take comes from a lot of the rhetoric you used to hear when people who had been disenfranchised by poverty or some disability where being ‘empowered’ by the state to make bogus ‘choices’. Instead of addressing the real need for creating systems that meet and help their needs they were so powerful they can fill in a survey. This is of course a simplification but I hope it helps getting the point across.
And, of course, the flip side of being given permission is that it also allows the giver to take it away again. That’s big of them too. It assumes a paternal relationship and distribution of power where the empoweree (sic) has to rely on others to validate what they do. Just take a look at the whole crazy gang of incompetents and buffoons that try to run your life and think about how little permission they can ever grant you, or anyone else.
One of the other speakers at Thinking Digital was talking about opening up government data, which is a cause dear to my heart. Apparently at least some of the nominal owners of this data are concerned that people like us, the poor unwashed masses, might draw the wrong conclusions from this data. Wrong in terms of whatever ideology or spin they want to put on it. So the empowerment that this data may bring should be conditional on whatever they think we should be saying or knowing. Yeah. Bless them.
As Deming is reputed to have said in Jesus Christ we trust, all others must bring data. I’m not a Christian, but the rest of the sentiment is sound 🙂
I think this is a great book in terms of the ideas it promotes, but for me somewhat flawed.
It’s billed as a companion to Domain-Driven Design: Tackling Complexity in the Heart of Software and as such is less abstract and works through some case studies to get to the meat of what that the original DDD book only hinted at and actually went round and round a lot.
For me it harks back to a lot of things I have recently read and done, in particular the design process for good (for some definition of the word) object-oriented software, as Practical Object-Oriented Design in Ruby: An Agile Primer covers really well. Sandi talks about OO being all about the messages, and you end up with well put together clusters of objects if you start from there.
DDD comes at the problem from a different direction, instead starting out at a higher level of abstraction in the problem domain, rather than creating objects and seeing how they work together. It has some tools for uncovering what the business wants. It starts by looking for a ubiquitous language and making sure that the development and testing silos are speaking the same language as the business.
Of course, it’s more complicated than this. Vernon gives the example of a book publisher. The people commissioning a book need different language to describe setting up their relationship with an author and paying them, the people creating the book and illustrating it again have different needs, and distributing and stocking the final physical product is different again. So, if you were trying to create some kind of master book object that met all of these needs you may well end up with conflicting terms, and indeed needs expressed by those terms.
To get round this you break your problem space into bounded contexts, and these become functional areas which each have the own ubiquitous language. This gets around the weird mashing together of functionality that quite often makes large systems a complete pain to maintain. Each area manages its own needs and translates, as and when required, if it needs to talk to another. I believe that a pretty reasonable SOA architecture will fall out of this in the end.
I think I’ve understood this process after a hundred pages or so, but I don’t want to read any more of the book. I had the same problem with the original DDD book as well. The core concepts are pure gold, but the presentation is extremely repetitive, wordy and really hard to read for useful content. Both books needed more pictures and a catalogue of the concepts, organised rather like Martin Fowler’s Patterns of Enterprise Application Architecture – with about 100 pages of well-written and illustrated chat with the remainder of the book taken up with a list of the patterns in detail once you know how to use them. In fact, both books need a damn good edit.
The other thing that I find really annoying is things like bounded context, once introduced, are always capitalised Bounded Context. Maybe it’s just me, but the constant capitalisation of a concept really breaks the text up and interrupts the flow. The original DDD book does this as well. This capitalising thing is a disease caught from an old-fashioned style of writing, common to people who read the King James Bible, which was written at a time when you would capitalise nouns. Myself, I use italics when I introduce a concept and then either abbreviate it to, say, BC, or just use it as normal. This capitalisation reads like the old pompous religious tracts handed out by slightly demented people going door to door when I was a kid, and I didn’t like it then either.
So I would like a list of all of the Ideas Expressed With Capitalisation and how to use them, and about half the amount of text without all the waffle. I gave up because I got the concepts and the rest of the signal to noise was too low.
The cartoons of the cowboys make no sense to me either, and there was a weirdly old-fashioned feel to the one offering your stakeholder a cup of coffee to talk to them. You could probably put each chapter into about three paragraphs and not lose a lot of information.
So, I gave the book four stars because the ideas are incredibly useful, but be prepared to struggle with keeping awake between the useful nuggets.
Incidentally, if you want Sandi’s book, please buy it from her site.
That’s really hard. If there was one for emptiness it would be easy. Not space though – that one’s really annoying 🙂
I’ve been working on Unicorns in the Mist for a while and, because I was ill, decided to get it out of scrivener and into the wider world.
It’s my take on applying systems thinking to getting projects and stuff done and is assembled roughly 50/50 from old blog posts and new material.
It’s free to download if you want to have a look at it.
I think this is an important book, and I also think its message might be difficult for some people to reconcile their world view with. Ormerod sets his stall out to show that economists have presumed that the economy (and lots of other systems we think of all day every day) actually is a steady state, that markets exist as a relationship between buyers and sellers, with supply and demand following perfect curves that come from perfect knowledge.
Of course, as he points out, this is nonsense. Markets don’t exist in a steady state, there are too many factors that cause change. Ormerod cites work done that shows even if the steady state were to occur any kind of shock to it could take as long as a hundred years before it would stabilise again.
The classical view that comes all the way from Adam Smith assumes perfect knowledge, actors in the system need to know what every other actor is doing. This doesn’t happen, the textbook view that makes assumptions around marginal costs is bogus, a lot of the time businesses don’t know what they are, a lot of the time they don’t know what their competitors are doing, and as you can’t see into the future, even if they did it probably wouldn’t help because you still don’t know what your customers may want that you don’t do. Most businesses of any size or complexity tend to work using rules of thumb, and the MBA spreadsheets don’t help because they assume perfect information. Also, your customers might just not like what you have to offer this season.
He looks at work done on evolution. In particular work done by Raup shows that there is a power series relationship between the frequency of extinction events and their size. Other people have discovered that you can draw almost exactly the same curve if you look at business failures. This has some interesting consequences – if you play with these models and look at an arbitrary measure of ‘fitness’ in the Darwinian sense then a degree of cooperation is actually good for the long term viability of the system as a whole. Ultra competition forces prices down and isn’t good in the long run – neither is cost cutting.
The problem of perfect information is also addressed by looking at simple games, such as the Prisoner’s dilemma, played over many iterations and looking at what strategies win over the long term. As well as an arbitrary game involving where on a line you might place your ice cream stand to get the most customers. As soon as you have more than two players, and more than one time of entry into an existing market it becomes almost impossible to do more than work out what the graph of possible solutions to the problem is and understand the shape of it. If you are one of the players it’s hard to work out what to do.
Interestingly we have two extinction models – one is external shocks (the asteroid of dyno extinction fame), another is that a niche closes because of some other factor in the competition and a species dies out. Species are competing and cooperating (predators stop prey eating all of the available food and destroying the environment which means both species survive), so there could be a cascade from what looks like a relatively small cause. In fact, both happen, there is no either/or. But modelling this, predicting the future, becomes impossible. All you can do is look at the shape and work out how to cope with what may happen.
Ormerod concludes by giving an overview of the work of Schumpter and Hayek, that is often ignored.
The visions of the world articulated by orthodox economists and by Hayek are fundamentally different. Conventional theory describes a highly structured mechanical system. Both the economy and society are in essence gigantic machines, whose behaviour can be controlled and predicted. Hayek’s view is much more rooted in biology. Individual behaviour is not fixed, like a screw or cog in a machine is, but evolves in response to the behaviour of others. Control and prediction of the system as a whole is simply not possible.
Ormerod quotes several examples of systems coming up with robust solutions to problems (even the origins of the mighty US dollar) that weren’t obvious until they were left alone to find solutions themselves. A good example of this is the hub and spoke architecture of US domestic airlines that appeared after deregulation. It serves customer needs but no-one could have foreseen it at the time.
The central argument is that central planning doesn’t work and solutions that are workable and human come from creating environments where the actors can work together on solutions that benefit them. Essentially.
… it is innovation, evolution and competition which are the hallmarks of a successful system …
Schumpter coined the phrase ‘gales of creative destruction’. He argued that innovation led to such gales that the caused old ideas, technologies, skills and equipment to become obsolete. The question … was not ‘how capitalism administers existing structures … [but] how it creates and destroys them’. Creative destruction, he believed, caused continuous progress and improved standards of living for everyone.
This has serious and interesting consequences for policy makers – the models show that forcing too much competition between actors hurts the overall fitness of the system, and also protection does too. So most of the time they must resist the urge to exhort and fiddle – this comes right back to the work that Deming did all those years ago that no-one remembers and everyone should read. Four days with Doctor Deming
But if they resist the temptation to exhort and fiddle without enough information, if they don’t listen to lobbyists and make sure decisions are made locally by the people who know what’s needed. If they do all these things, we don’t need that many them and they don’t need to do much to keep things steady.
I’ve just started reading Antifragile, which addresses the other side of this equation, given that the world is very unpredictable isn’t it better to create institutions and systems that aren’t brittle from so much command and control mania and even benefit from small shocks and changes. I will return to this subject again in my next review. I think that I have accidentally stumbled on two books that complement each other. Ormerod’s work gives a mathematical, scientific background that looks across many disciplines to say some very similar things.
So, read this book, it will surprise you and leave you thinking about how we should do things so that failure is part of what happens but isn’t a catastrophe.
I’ve recently taken on a gig where I am writing Python code because the work is mostly done in Python and they want it to be maintainable by the original team members.
I have to confess that Python was my gateway language into the world of non-rigid Java nastiness but this is the first time I’ve ever used it proper hard in earnest for money.
In my Ruby practice I’ve recently changed the way I write code pretty radically. I now
- tend to write very small methods that just do one thing, I write tests that test those one things. I usually write the tests first.
- I’ve also started using little lambda functions and passing them into other wrapper methods that just need to call the processing hidden in the lambda.
- Every time I see lots of assignments one after the other I’ve started using tap or returning to protect me from my own stupidity.
- When I see case statements I tend to create a little helper class
- I will create little classes inside the current class so I can just ask them about things instead of writing procedural code. I can also test them too if I need to.
- Really getting away from writing long methods full of procedural code. They are a sod to test and confusing to read.
Now I’ve done some Python I’ve realised that there are a few things I like:
- Files are modules, and namespaced. This is a little odd at first but I like it. It means you could do without classes if you wanted, maybe.
- I’m on the fence with objects needing to have self typed everywhere. I can see how it’s easier to create an OO style quickly if you force the coder to put self everywhere, but it feels heavy. It also feels right because you can’t do stupid assignment bugs like you can in Ruby, or rather the bug shouts out at you when you have.
- I like list comprehensions, but they seem really heavy after using blocks for years.
- I like how (like Ruby) you can pass references to functions around, and I think the syntax is superior.
- I like the built in help. Ruby’s is not built into the classes the way Python’s is and you often find yourself digging round on the web for a while when a couple of commands in the Python interpreter and you’re away.
I don’t like (as in … why?):
- I don’t like procedural-style conversion functions polluting the top level namespace, but I have understood that (for example) list is really a class that you initialise and isn’t really a function. It just looks like one.
- Ruby enforces a convention that classes (i.e. constants) all begin with a capital letter. It seems silly, but not having an enforced convention makes unpicking code harder than it needs to be. I think the first point would have been easier to get my head around if I’d been able to see that these conversion functions were actually class constructors. Java has the convention of upper case classes but doesn’t enforce it – this is a major pain, or can be.
- Python has a built in complex number type, but doesn’t have any native syntax for regexp. I was looking in the Python docs and there was some nonsense about not needing syntax because you don’t use regexp much and typing strings is fine. Utter crap, I use them way more than complex numbers. Plus if you want a complex type in Ruby it’s really easy to make one and just drop it in. Always having to screw around with strings is one of the things that makes Java so unbearable. I like syntactic sugar and syntactic checking, makes life easier and it’s relatively trivial to add in. Just lazy not to, and it shouldn’t be dressed up.
- Overriding methods like + and so on is a bit hard, because of the method naming. Not too bad, just irritating.
I got a copy of Learning Python, and I’m about 40% of the way through it. No significant mention of objects at all yet. I mean, the word has been used, but not the thing. Just loads of procedural code examples. I’m beginning to think that this is a function of how the language grew. It was picked up by a lot of folk who were moving from hoary old procedural environments, like Fortran, and who were used to thinking in huge chunks of code. So it gets taught that way, and people pick up habits that are bad, and hard to improve upon. I’m almost tempted to put together my own book that puts the objects first, but don’t have enough time to do the things I need to do as it is.
So the first Python module I picked up as an example of how to do the work I’m doing was 300 lines of procedural code. I ignored most of this and started with unittest and worked backwards into some simple classes that do a similar job in about half the code (not including tests). So it is possible to write nice clean BDD Python code, but doesn’t seem to be part of the culture. The examples aren’t very good.
I think it’s a good language and don’t mind using it, but there is definitely a problem with object orientation and design being treated as something for the adults and maybe only later that I think needs to be addressed.
I thought I’d try out the Lean pub platform and put my novel Archive Fragments up there. Over the next month or so most of my creative and technical work will appear there so that people can see it more easily.
It’s over 64,000 words long, and I hope an interesting read.
I keep making the obviously false assumption that people know how to run Rails apps on a Mac.
If you’re starting from scratch have a look here: http://railsinstaller.org/#osx – I haven’t looked at it, but it looks like it will take a lot of pain away. This post is for people who have an existing app running on an old version.
The following assumes that you have some kind of Ruby installed and some kind of Ruby gems that came with it.
Also, you’ve already got some Rails code, that may be running an old version of everything.
Install XCode if you need to
Start up a terminal and type
If it gives you a command not found error then you need to download XCode from the App Store, fire it up, and then ask it to install the command line utilities. This can take a while, and google is your friend if you don’t know where to find things.
If you already have XCode then you just need to install the command line utilities, which are off on a menu somewhere.
gem install rvm
when it gets to the end of the install it will tell you what to do to your shell environment to run rvm properly. DO IT. 🙂 For reference see https://rvm.io/ If you are unfamiliar with getting things to run in the active shell after altering the shell startup commands, just close the terminal and start a new one, life’s too short.
Install the Ruby you need
In this exercise we want Ruby 1.8.7, so …
rvm install 1.8.7
Eventually it will finish and tell you the version it installed, e.g. ruby-1.8.7-p352
You may encounter some errors, where Apple have kindly set the default C compiler not to be the old GNU ‘C’ compiler but their llvm one. Cut the error message out and paste it into Google, then do what it says.
These instructions might say that it can’t find the command that you put into the environment variable, in which case use whereis cc to tell you where the cc command is.
Any other problems, use the more command or an editor to browse the log file it says
Create a .rvmrc file in your Rails root
Let’s assume the Rails app is called brightstuff. In the root of your Rails app type
If it finds something, have a look and see what it says, for the purposes of this exercise I’m assuming the file isn’t there. Type the command
cat “rvm use [email protected]” > .rvmrc
Change brightstuff to the name of your app.
This takes you up and then back to the directory you just added the rvmrc to. If you have installed RVM correctly it will ask you if you want to use the .rvmrc. Say yes.
gem install bundler
This will set all the gems up for you in this version of Ruby, in a group named after your app.
Some people don’t use the gemset (which we have named brightstuff) and rely on bundle exec, but I’ve found this to be pretty bomb proof.
You can also install gems independently of the Gemfile used by bundler, I typically install things like powder (see below) like this, because they aren’t needed in any context other than development.
Start the Rails app
As is standard, you can start a development version of the app with:
bundle exec script/server
This will start the app on http://localhost:3000, you can use /etc/hosts and various tools (go look for them) to alias them, and start things on different ports.
I use the pow utility and it’s friend the powder gem to run my apps. http://pow.cx/