... their lead Technology story today is that "people in remote locations, across the world, can use technology to get their Christmas messages back home to Britain."
Oh, really?
Wednesday, December 24, 2008
Thursday, December 18, 2008
We're doomed
After its success on the USS Yorktown, the Royal Navy have decided to run their nuclear submarine fleet on Windows.
The Register summarises:
The Register summarises:
But we just might, if things go wrong, be looking at ... British sailors of the future staring helplessly at what would shortly be literally a blue screen of death, as the shipkillers bored in without response.
Tuesday, December 16, 2008
Wednesday, December 10, 2008
On leading and serving
Things aren't perfect.
OK - hopefully that wasn't news to you. The question I pose to you is: when things aren't perfect, something goes wrong, or something is not done that needed to be - how do you react? I've seen about three different approaches recently, and I think it's a matter worthy of comment.
Take this scenario: at work (I work at a software firm) someone makes a commit that sets the build on fire[1]. Thanks to the wonders of version-control and continuous integration software, you can see exactly what set of changes was made, and who made them, to break the build.
At this point you have three options: you can leave it, and hope that someone else picks it up - or maybe somebody else is assigned to that area of the code, so they'll pick it up instead. (Fair enough, particularly at work.) Or, you could run an svn blame and find out who 'owns' the line responsible, then shout across the office, "${name}, you set the tree on fire!"
Maybe, and this is your third option, you could find out how the build is broken, fix it, then commit that fix (and receive the adulation of DeciBot[2] when it announces "All watched trees are now green").
Put like that, I guess it's reasonably apparent which is the best of the three options to take. But so often - and now I'm not just talking about work - people pick the wrong one!
I was reading Joel Spolsky's blog the other day; the entry entitled "My Style of Servant Leadership". In it, Spolsky tells a story from his time in the Israeli army:
You can try the ostrich approach - that is, bury your head in the sand until it (hopefully) passes. You can take the "assertive" approach, and bang some heads together until (hopefully) everyone sees things from your point of view (or at least are speaking to each other again). Or, you could step out, and do something to serve them. There's truth in the cliche that actions can speak louder than words; how different things would be if, instead of shouting matches with harsh words thrown in both directions, we all opted for serving matches, both sides wanting to do things for purely the other's benefit?
That's both simplistic and idealistic; in truth, even in the best case it's rarely two-way, at least not straight away. But, leaders, persevere - not just because it's effective (it actually works!), but because it's the right thing to do, out of love for those you are serving. And it's not an easy road - because to serve others is to necessarily sacrifice some of your own ambitions and plans. Then maybe, just maybe, for the briefest fraction of time, you'll get a glimpse of better things to come. And when you get that glimpse, don't stop there - keep hold of it, keep "cleaning toilets", and perhaps you'll get there in the end.
Perhaps, God willing, we will.
[1] Note to non-software engineers: this essentially means 'someone breaks the program you're all working on'
[2] A friend of your friend, the DecisionSoft Continuous Integration watching IRC bot
OK - hopefully that wasn't news to you. The question I pose to you is: when things aren't perfect, something goes wrong, or something is not done that needed to be - how do you react? I've seen about three different approaches recently, and I think it's a matter worthy of comment.
Take this scenario: at work (I work at a software firm) someone makes a commit that sets the build on fire[1]. Thanks to the wonders of version-control and continuous integration software, you can see exactly what set of changes was made, and who made them, to break the build.
At this point you have three options: you can leave it, and hope that someone else picks it up - or maybe somebody else is assigned to that area of the code, so they'll pick it up instead. (Fair enough, particularly at work.) Or, you could run an svn blame and find out who 'owns' the line responsible, then shout across the office, "${name}, you set the tree on fire!"
Maybe, and this is your third option, you could find out how the build is broken, fix it, then commit that fix (and receive the adulation of DeciBot[2] when it announces "All watched trees are now green").
Put like that, I guess it's reasonably apparent which is the best of the three options to take. But so often - and now I'm not just talking about work - people pick the wrong one!
I was reading Joel Spolsky's blog the other day; the entry entitled "My Style of Servant Leadership". In it, Spolsky tells a story from his time in the Israeli army:
Those that know your Bible will already be thinking of Jesus' words to his disciples, after an argument breaks out over which of them is the greatest. Get this:Anyway, on my first day of work for the sergeant major, I didn't know what to expect. I was sure it was going to be horrible, a suspicion that seemed to be confirmed when he took me to the officers' bathroom and told me I would be responsible for keeping it clean. And then he said something I didn't anticipate.
"Here's how you clean a toilet," he said.
And he got down on his knees in front of the porcelain bowl -- in his pressed-starched-spotless dress uniform -- and scrubbed it with his bare hands until it shined.
To a 19-year-old assigned to clean toilets, which is almost by definition the worst possible job in the world, the sight of this high-ranking, 38-year-old, manicured, pampered disciplinary officer cleaning a toilet was a shock. And it completely reset my attitude. If he can clean a toilet, I can clean a toilet, I thought. There's nothing wrong with cleaning toilets. My loyalty and inspiration from that moment on were unflagging. Now that's leadership.
"If anyone wants to be first, he must be the very last, and the servant of all." (taken from Mark 9: 35, NIV)Those words from Jesus - the very instrument of creation, the incarnate God of the universe, who washed his disciples' feet.
You can try the ostrich approach - that is, bury your head in the sand until it (hopefully) passes. You can take the "assertive" approach, and bang some heads together until (hopefully) everyone sees things from your point of view (or at least are speaking to each other again). Or, you could step out, and do something to serve them. There's truth in the cliche that actions can speak louder than words; how different things would be if, instead of shouting matches with harsh words thrown in both directions, we all opted for serving matches, both sides wanting to do things for purely the other's benefit?
That's both simplistic and idealistic; in truth, even in the best case it's rarely two-way, at least not straight away. But, leaders, persevere - not just because it's effective (it actually works!), but because it's the right thing to do, out of love for those you are serving. And it's not an easy road - because to serve others is to necessarily sacrifice some of your own ambitions and plans. Then maybe, just maybe, for the briefest fraction of time, you'll get a glimpse of better things to come. And when you get that glimpse, don't stop there - keep hold of it, keep "cleaning toilets", and perhaps you'll get there in the end.
Perhaps, God willing, we will.
[1] Note to non-software engineers: this essentially means 'someone breaks the program you're all working on'
[2] A friend of your friend, the DecisionSoft Continuous Integration watching IRC bot
Subscribe to:
Posts (Atom)