Monthly Archives: October 2015

Baguettes

The recipe I use for making baguettes (as taken from http://www.dk.com/uk/9781409352723-bread/ – I have avoided a link to Amazon).

These get the best shape when cooked on a baguette tray.

Put 1lb strong bread flour in a large bowl and make a well in the middle.

Put 1/4 pint of warm water in a jug. Add 2 1/2 teaspoons of dried yeast and mix together. Leave for 5 minutes.

Stir the yeast mixture and add to the well in the flour. Mix in some of the flour to the yeast to make a batter. Cover and leave for 20 minutes so that the batter starts to froth a bit.

Us a wooden spoon to mix in the remaining flour, adding tepid water, one tablespoonful at a time, to the mixture. It can be a bit tricky to judge when the right amount of flour and water has been added, but for me the dough should be easily workable but not feel wet and stick to your hand.

With all the flour mixed in, turn the dough out onto a clean (!) work surface and knead for about 10 minutes. Personally, the ideal consistency is when you don’t need any flour on the worktop and the dough doesn’t stick to the worktop but still feels elastic when kneaded; this comes down to experience and simply getting a feel for the dough. Try to avoid the dough being too dry (maybe I’ll post a video that shows a good consistency).

After about 10 minutes you should feel a change in the texture of the dough and it starts to stick to the base of your palm as you knead. This is when you know that the kneading is done.

Pop the dough in  a clean bowl – you can use the one it was mixed in if you managed to get all of the dough out – and cover with a damp tea towel – damp does make a difference – and leave to rise for about 90 minutes, until doubled in size.

Knock back, cover with the tea towel and leave to rise for about 45 minutes.

Knock back again, cover with the tea towel and leave to rise for about 45 minutes. Yes, this is the 3rd rising.

Put two baguette trays on a worktop and lightly cover with flour.

IMG_20151030_184318078

Knock back the dough and scrape out onto the lightly floured work surface.

Cut the dough into four pieces and roll out each piece into a long sausage shape and pop it onto the baguette tray.

Cover with the tea towel and leave to prove for about 45 minutes or so. Turn the oven on (gas mark 5) about 15 minutes before the end and put an ovenproof tray in the bottom on the oven and fill with water.

Cut 4 slashes across each baguette with a sharp knife and put both tray in the oven. In my case, this has to be at the very top of the oven having moved the standard oven racks out of the way. They need to cook for about 25 minutes, but after about 12 minutes I take them out quickly and put them back the other way to avoid the furthest in loaf getting incinerated.

Cool on a wire rack and they are best eaten when still crispy.

Should I really be here?

And anytime I hear a manager say that ‘the process is there for a reason’ and ‘you can’t just do what you want’, I know that’s a place I don’t want to work.

I damn well know that the process is there for a reason (in many cases I’ve probably developed it) and things like change control are a given. That’s not the point.

Free your mind. If no-one’s prepared to say ‘this is rubbish’ (or managers can’t tolerate hearing it from their sub-ordinates – I hate that word), then we’re scared to challenge prevailing ideas and fearful of team creativity.

When everyone has the opportunity to challenge the nonsense in front of them a team is thinking and is alive to possibilities and wanting to improve. All we need to do is gently steer and guide the team to maintain their focus and let them create.

The process isn’t everything

Following on from a previous post, the concept of tracking small everyday projects became known as the BAU process (because it tackled everyday activities).

But it became a process in itslef. Requiring involvement from an ever-increasing number of participants from different disciplines and with a formal definition of what constituted a BAU project (having passed through a management approval board) and moving further away from the light-touch support to get things done.

It got to the point where staff weren’t allowed to plan out this work amongst themselves (and a willing PM) because it had to follow the process.

Any time you find that following the process becomes more important than the actual stuff it’s there to deliver then you have a problem. In this case people found the meetings pointless and attendance dropped and managers wonder how to reboot the process to make it relevant again.

The whole purpose of devising the simple approach was to avoid a rigid process while giving some control for team members who had the freedom to decide what was important, achievable and deliverable and could develop the skills to manage themselves.

Use it, abuse it or lose it

When introducing a new system that will have an impact on the work that others in the organisation will do, there are three possible outcomes:

  • It makes their job easier,
  • It neither makes it easier nor more difficult,
  • it makes their job harder.

If we find that users of our new system, process or whatever or looking for loopholes or ways to get around our carefully laid plans, it’s probably symptomatic of the third outcome.

And it’s also a fair bet that the users weren’t involved with the spec or design of that way of doing things.

The first outcome is ideal and there’s only one way to achieve it.

21st century multitasking

A really good post on the perils of switching between tasks and something I have been very aware of:

http://timharford.com/2015/09/multi-tasking-how-to-survive-in-the-21st-century/

But where I think former colleagues and I have really suffered is the rapid switching between the types of activity: from rapid-task-switching to creative development back to rapid tasks. On an hourly and daily basis. For months on end.

This is where it gets really hard. And it’s exacerbated by managers that have never done the more creative stuff and don’t understand the difference.

Puppet manifests without site.pp

A simple diagram showing a possible flow using a Puppet ENC (External Node Classifier) and remove the need for a site.pp file.

Puppet external node classifier flow

Simple flow of a Puppet ENC to avoid the need for site.pp manifest

This obviously assumes that all your environment can be described using modules and classes and that they can all be referenced via Hiera. The ENC can be any type of program; I might post a sample piece of Ruby or Python later.