There's a malady experienced by some folk, known as 'lost time'.

The condition arises when a chap looks around, stunned, suddenly finding themselves far from home, dressed in someone else's clothes, driving someone else's car, with no memory of how they got there, or what happened in the last 3 months. Time was lost.

Through the law of equilibrium I deduce there must be an equally common condition whereby time is found. Some harried, stressed-out individual is bemoaning the fact that they've got so many tasks and so little time, when suddenly they realise oops! today isn't Thursday -- it's only Monday -- and there's an extra 72 hours of bonus time, delivered from nowhere!

Project managers, of course, live in the optimistic belief that this syndrome will suddenly attack their whole team in spadefulls.

I've even known project manager's to try and slip a whole extra month into their nasty tricksy Gantt charts. ("Umtember" falls between November and December.)

If you happen to be infected with a wicked dose of Found Time, please take careful notes regarding cause and contagion, so your time-poor brethren can benefit.

Thank you.

Remember how Justice Gray started that little fad about becoming a better developer in 6 months?

Well, that was a while ago and most of you failed. Badly.

So here's a simpler challenge, some ways to be a better programmer in 6 minutes.

You've got 6 minutes, right?

Go for it!

1. Use a bigger font size.

   This is ridiculously easy -- but it works.

   Go to your favourite IDE, and crank the font-size up. I switched from 10pt to 14 pt. The difference is that a lot less code fits on the screen at once.

   The effect is: you're forced to write shorter methods. And that's a Good Thing.

   (Scott Hanselman recommends that one)


2. Make hard-coded strings look ugly.

   I learnt this from Joe Cooney.

   Go to your favourite IDE, and set it so that literal strings stand right out -- for example a yellow background with a red font. Make 'em ugly. Damn ugly. This will encourage you to perform less hard coding, and to notice when you are embedding strings in your text.

3. Pick an 'obscure' keyword and master it

   Do you fail to yield?. Is there a keyword you never use?

   Every keyword has a purpose. Learn to master those mystery keywords and your powers will become extraordinary.

   Here are lists for a few .net languages: C#, VB.net, F#.

4. Increase code-coverage by 1%

   Don't kill yourself striving for 100% coverage of code with automated unit tests. But take a few minutes to increase your coverage by 1%.

   Most likely, that means going from 0% to 1%. And that's the biggest improvement of all.

   Find a particularly ghoulish regular expression. Or a critical piece of business logic. These things can't be trusted without tests.

5. Read the code from an open source project

   Sometimes, when I'm looking at the code of a complete stranger, I get that same, weird feeling I get when I'm creeping through my neighbour's house. Picking up their stuff, looking through their fridge.

   Learn to overcome the creepy sensation, and bring on the learn.

   Maybe start with Hanselman's Weekly Source Code series.

6. Run a static analysis tool against your code

   Use fxcop, or StyleCop, clone detective, ndepend, the code metrics feature of VS 2008, or any other static analysis tool of your choice.

   Uncover your greatest weakness. Even a cursory glance at the output will leave you distraught at just how much room you've got for improvement.

7. Pick an ugly method to refactor

   You know the method. That method you're particularly ashamed of. That one that's long and ugly and horrible. And it's crucial to the whole application.

   You don't have to polish it from a turd to a diamond, but just neaten it up a little. Rename a variable. Hoist part of it out into a separate method. Start simple. The momentum will increase. Watch out.

8. Stop reading, start writing.

   And don't just write. Write a compiler!

   This ol' msdn article is a good place to start. Joel Pobar will get you writing your own language compiler in but a handful of minutes.

That's all I've come up with for now. But what've you got?

What are some 6 minute activities that helped you be a better programmer?

This article has been kindly translated to Serbo-Croatian language by 'Web Geeks'

Consider this little step-sheet.

1. Q:What do managers do when they're stressed?
   • A:They call a meeting.
2. Q:What gets managers stressed out?
   • A:When projects are not making progress.
3. Q:When do projects fail to make progress?
   • A:When people spend too much time in meetings.

Thus we have the rise of meetingitis -- a deadly malady that has struck down many otherwise healthy projects.

Once the disease has set in, the prognosis is grim.

The only aproach is to prevent the syndrome before it develops.

How do you prevent meetingitis?

Many people foolishly think that meetingitis is caused by 'too many meetings.'

But look closely at the steps above and you'll recognise the root cause is stressed out managers

Picture this futile attempt at preventing the syndrome:

Jack is a busy coder trying to implement his code.

He says to the manager: "I don't want to go to the next meeting. I'm not making enough progress, so I'm not gonna attend your stupid meeting."

What happens next?

Jack may get out of that particular meeting. But what is the larger effect? will the manager become more or less stressed? More stressed of course (rhetorical question) and what happens then? The manager, now in a state of complete freakout, calls extra meetings: status meetings, emergency meetings, all-hands-meetings, crisis talks, war-rooms, action-squad meetings and before you know it the meetingitis has reached its final stages: the manager decides to form a committee.

The only approach that can possibly work: deal with the stress itself. Put the manager at ease.

Communicate more, in order to meet less. Be proactive in your communication. Don't wait for them to call a meeting. Tell them what's going on. Produce regular reports. Don't "promise" to produce regular reports -- just produce them. Let them listen in on some of your day to day chatter. If you have daily standups, bring the manager in. Stop baffling them with technical mumbo jumbo. Feed them edible slices of information. Walk them through it in bite-sized chunks. Give them documentation tasks to keep them feeling important. Give them communication tasks. Draw pictures for them to stick on the wall of their office. Give them some kind of flashy management information portal that has interactive charts (you don't need to hook them up to any real data -- a random number generator ought to do it). Or maybe there's a better way?

What do you do?

How do you prevent meetingitis?

The other day, someone on stack overflow said they wished copy and paste were not permitted within an IDE.

It's a wacky idea, but sometimes I'm inclined to agree.

Maybe it shouldn't be completely illegal, but it could be harder to do (in specific circumstances), or tracked more closely.

At one point (perhaps long ago, perhaps today...) I stumbled onto this chunk of code [above], and I thought "Hmm, interesting lack of reuse..."

Why use a data structure when you can copy and paste your code?

It's only a little code smell, right?

Not really, because you know that where people have the 'copy/paste' bug... it's only going to get worse.

Let's zoom out and see what we find...

The code sits inside this method... ^^

(There's other issues there too, but let's leave them aside today, please.)

And the very next method down is almost identical:

Then I look at the next class, it's an almost identical class, and it has two methods of its own with identical names to the ones above and only very slightly different code...

So we're talking about a serious case of "Achieves reuse through the cunning application of copy and paste"

And you know it doesn't stop there.

It just keeps going — thousands of lines of copy/pasted code. File after file. Bugs here and there (notice the 'harmless' bug in the first snippet?) quirks abound.

It's a fractal! The more you zoom out, the more you see the same pattern copied, pasted, modified, and reapplied over and over at greater and greater levels of scale. The author's entire career could be composed of the same programs, copied, pasted, and modified, retrofitted to slightly different problems.

Copy/Pasting is like the weather. Everyone complains about it, but nobody does anything about it.

If copying and pasting were illegal (or more difficult) — would the implementer have thought about achieving reuse through other methods?

Illegal is taking it a bit far. So: how could the copy/paste virus be reduced?

Maybe clippy could pop up and say: "It looks like you're copying and pasting code. Do you know that you can achieve re-use in other ways?" (Maybe we could use Scott Bellware's face on clippy? eh?)

How about this... every time you use the "paste" function inside your IDE, a little counter is incremented. And that counter is displayed on a gigantic, glowing LED panel suspended from the ceiling above your desk.

Or: Every time you use the "paste" function inside your IDE, a loud buzzer sounds for ten minutes, and a flashing red siren pops up over your desk.

Or: Every time you use the "paste" function inside your IDE, your screen is locked out for ten seconds.

I think you'd only need to apply a technique like that for a few minutes a week and you'd soon be permanently cured of copy/pastitis.

My friend OJ suggests...

"an enterprise Copy and Paste server, which acts like a petrol tank. Hence you only get to use your copy and pastes wisely before you run out."

Perhaps a plugin would need to detect when code is copied and pasted from within the ide. It would only punish you when the copied code (and subsequently pasted code) contains some degree of logic.

And before you say it — I know there's a tool called Simian that you can plug in to your continuous integration server, to detect this sort of nonsense. I haven't tried it, but I'd like to know more. (They're Australian by the way)

Also — an apology

Let me be crystal clear about one thing... writing this kind of code doesn't make you a bad programmer.

This particular code was written by a very successful programmer, who does an excellent job of delivering value to the business.

It is definitely a better example of programming than a hell of a lot of code I've seen in the business world.

I'm just decrying the fact that sometimes we work harder not smarter, and if we trained ourselves into the right coding habits, we could achieve both: work hard and smart.

Tools for Tackling Copy-Pastitis

• Clone Detective (free Visual Studio plugin)
• Simian (similarity analyser)
• Axivion Bauhaus Suite (Stopping Software Erosion)

There's a common UI anti-pattern of making "readonly" fields harder to read than editable fields.

I think this is a poor technique. I blame it on Windows Forms -- but I've seen it out there on the wild web as well.

If a control is readonly, then you should cater for the user actually wanting to read it. Shouldn't you?

Newspapers, for example are readonly. And they are commonly in black and white. Fine, crisp, perfectly legible black text. Not dull gray.

Rather than making the readonly fields dull gray, use some other form of visual hinting to differentiate between what can be edited and what can't.

For example, here's some readonly checkboxes.

They are shown as dull gray with gray border.

Instead, the check marks could be black, while only the control border is gray.

Or, perhaps the control border could disappear.

What about this drop down list — its 'readonly' status is indicated by gray text and gray border.

It gives the impression that it has no meaning and no influence. In fact, it's message is fairly important - perhaps extra important since the user has no control over it.

It could instead have black text and gray border.

How about black text with NO border. It's easy to read, and it's clearly not editable.

I think that both of these are preferable to the 'make it gray' approach. Don't you?

And finally, as a reward to those who "clicked through", here's a repeat from last time, since no-one mentioned it ;-)

Got that? "Not a tuna!" Ha! That is genius. No, no. It is better than that. It is "genious."

Somewhere in my hard-drives I've got a very lengthy and never quite finished article on this topic.

The Online-IDE. What a thing of beauty. What a must-have. What a killer app.

And of course: What a horrible idea! What a monstrosity!

I think I started trying to write about the topic in about 2003. And I was pretty serious about it then. I started building one. Twice!

It seemed like it was only just beyond the state of the art. Sure there were challenges. But there was this thing i'd discovered called httpWebRequest... and with it's power, the Online IDE seemed inevitable.

Well, it's 2009 now and we're still stuck with these crazy desktop IDE's. But how long now, until the IDE goes online?

"Maybe not tomorrow, and maybe not the day after that. But soon, and for the rest of your life, you'll be programming online."

What do you think? Inevitable?

Here's dodgy pictures of some of those I found.

'The web 2.0 database' lists a lot of Online Development tools and there's a Big List at itredux.com

The main one I'd heard of is heroku garden (formerly heroku), which combines Ruby with Amazon's cloud compute offerings.

Plenty of people mention CodeIde and Coghead. Yahoo Pipes and Microsoft Popfly are not qute the target topic, but they get an honorable mention.

Assume that your children's generation are using online programming environments for all of their programming needs. How do you see it working? What innovations are required to make it feasible?

(It's long and it's preachy -- but I hope you enjoy it)

JFK speaks his mind about programming techniques

That great software programmer John F. Kennedy once famously said:

"Ask not what your software project can do for you - ask what you can do for your software project."

(Few people realise the 'F' in 'JFK' stood for 'Fortran'.)

I'd like to go one step further than JFK, and look at both sides of the deal: What you can do for your project as well as what the project can do for you.

In putting this list together, I'm going to steal liberally from two classic articles "The Joel Test" and "The programmer's bill of rights"

Here's the quick overview...

What can the project do for you?

First up we have a bunch of items along the lines of "I expect -- maybe demand -- that management will provide me with..."

1. Two monitors
2. A fast PC with a crapload of RAM
3. Choice of mouse and keyboard
4. A comfortable chair
5. Quiet working conditions
6. Internet unlimited
7. Freedom to install software
8. The best software
9. Good coffee
10. Sensible working hours
11. Separate Environments for dev, qa and production

What can you do for the project?

But it's not all "take take take".

The other side of the equation are items along the lines of "I am committed to ensuring that these practices are performed..."

1. Source Control
2. Continuous integration
3. Track bugs
4. Unit testing
5. Code analysis
6. Continual peer review
7. Peer training
8. Keep yourself up to date
9. Learn to Communicate with non-technical people
10. Refactor!
11. Passion

JFK asks management for a second monitor

Part 1: What can the project do for you?

Two monitors

The research is in. It's worth ten times its price. Give your dev two monitors.

A fast PC with a crapload of RAM

There's a messed up philosophy-- a kind of offshoot of the 'eat your own dogfood' school of thought -- that insists developers should have the same desktop rig as end users. This is nonsense.

End users aren't running three virtual machines, a local database server, three instances of visual studio, and two instances of blend. Devs need a hot rig with massive RAM. Anything less is ridiculous.

Choice of mouse and keyboard

Want to see a perfectly sane developer go nuts? Give them a bad keyboard. I have anecdotes around this topic... terrifying anecdotes that would turn your hair white... but the people involved are all still alive and i can't spill the beans. Trust me. Don't f*** with a developer's keyboard. Bad things happen.

A comfortable chair

This isn't just a programming thing of course, it's crucial for all office workers. The productivity loss from one screwed-up back could buy Herman Miller chairs for the whole company.

Quiet working conditions

Four-walls and a door might be too much to ask, but at least organise the open spaces in ways such that the shouty/squealy-teams are separated from the thinky-teams.

Don't put marketing next to the devs. Don't put the help desk next to the devs. Don't put the angry shouting Glengarry Glen Ross-style sales team next to the devs. In an open space, use baffles and greenery to isolate the noisy teams. Consider the different Yerkes-Dodson requirements for optimum performance from each team.

JFK's workstation includes a state of the art console and a swivelling chair. Uniform: relaxed

Internet unlimited

Consulting has shown me some pretty weird scenarios. I've worked at places where they insisted that 'contractors don't get internet access' and i've seen plenty of places where there are heavy handed website filters in place. 'This site is banned because it looks like a blog' -- for example, WTF? Even worse: "sorry, you can't use google, our company policy is that we use yahoo." WTF? If you choose to work with people, put some trust in them. Monitor them if you must (and tell them if you do) but don't put roadblocks between them and the obscure information they're trying to get their hard-working hands on.

Freedom to install software

Group policies, S.O.E.'s, limited user privileges -- these are all good and helpful things that IT departments need to keep their own sanity. I get it. I know. But let the devs break out of the box, please. Tell the dev's that they're on their own if the stuff they install causes problems. They have to fix their own messes -- but give them the freedom to install whatever dinky little weird utility they need from one minute to the next.

There's plenty of specific tools I've installed to use just once in my career, and then never needed again.

Having to fill out a series of forms on such occasions is a waste of everybody's time.

The best software

Why for the love of god is .net 1.0 still in use? Why are you advertising for a VB6 developer? Why do you make developers manually track the differences between two databases? Why do you let developers roll their own code generator? Because you're a stingy short-sighted fool I guess.

Good coffee

What is this crap we're drinking? Nes-frickin-cafe granulated food service blend? You had better be kidding me. Get me a goddamn macchiato. Now. Then back the hell away and let me write my goddamn code.

(Image courtesy of Rands in Repose)

Separate Environments for dev, qa and production

You can't afford testers and you just want me to fix it in production, eh? That's awesome. That's great. Next time the dentist is drilling out a cavity in your mouth, I'm going to tell him "This is an urgent operation. Let's not waste time on X-rays. Just start drilling, you're bound to hit something that's rotten. And let's save a few dollars and cut out the anaesthetic altogether."

Part 2: What can you do for the project?

Source Control

If they don't have source control -- you create a subversion repository. If they do have source control, but they're using VSS, you can move them onto Sourcegear vault. (It's an easy transition and it overcomes most of VSS problems.) If they're using vault you can move them onto subversion. If they're using subversion you can bump them up to mercurial. If they're using mercurial you can push them into git.

Okay -- don't change things just for the sake of changing them, but make sure you're using the best source control solution available to you, you're using it well, and everyone's using it.

Continuous integration

If there's no daily build, then put a daily build in place. If there's a daily build, them make sure it starts with a clean environment (no cheating) and make sure it builds everything, not just a couple of things. If the build is good, then make it continuous -- make it happen on every check in. If the build is good and continuous, make sure the communication lines are clear -- everyone can tell the status of the build at any moment. If all that's in place... well move onto another point.

Track bugs

Email is not a bug tracking system. You can't run queries over email. Email slips through the cracks.

If there's no bug tracking system, set up a shared spreadsheet. If the only bug tracking is some crappy shared spreadsheet then use sharepoint, or install Jira. If the only bug tracking system is sharepoint or jira, then install lighthouse. If the team are stuck on lighthouse then purchase Fogbugz. If TFS is available, make sure the workitem tracking is well configured and well used. If checkins aren't associated with bug numbers, make it so.

Build whatever tooling you need, above what the products you use offer, to ensure that the bug tracking works for you.

JFK asks the users for feedback on the proposed entity-relationship diagram

Learn to Communicate with non-technical people

Stop baffling them with bullshit. You don't do it on purpose (well, not usually) but you still do it way too often. Stop using technical terms with non technical people. Find the simplest way to state your ideas. Leave implementation details aside. Dummy it down. The end user has a full life of stressful issues all their own, without having to translate into your crazy mumbo jumbo.

Unit testing

If there's no unit tests, identify hotspots, start slow.

Start with regular expressions. Never trust a human's ability to write regex. Every regular expression needs solid unit testing. Focus on critical business logic. Focus on stuff that matters. One by one, knock them down. Every gain you make is a victory. Feel free to celebrate.

If unit tests are already included, but they're not part of the build, put them in the build. If there's a good amount of unit tests, then get code coverage metrics into the build. Set interim goals -- increase coverage by two percent within a week. And then increase it some more.

Code analysis

The build is running -- but how bad is your code? Run FX-Cop on every build. You're running FX-Cop? Then fix your problems. Identify common problems and fix them in batches. Update the list of exceptional terms (this is like adding new words to a spell check dictionary). You've done all that? Run further automated analysis. Fold n-depend into the build. Oh and before I go on... please, for the love of god, treat warnings as errors. Clean up that dirty code you're shovellin'.

JFK dressed as a US president

Continual peer review

You want to create a workplace where you understand and learn from each other's code, constantly. The trick is to make it non-confrontational. If it happens rarely, it's going to seem confrontational -- but once it happens routinely it will be an understood part of the workplace. Some places use code reviews prior to every checkin, some places use continual pair programming. Use what works best for you, but make sure code ends up being owned by the whole organisation not just the individuals.

Peer training

Teach each other. Discuss code, discuss business. Talk to each other. Say hello to each other in the mornings. Train each other. Organise lunch time brown bag sessions. Attend user groups. Talk at user groups. Be active in your community.

Keep yourself up to date

Don't let your skills stagnate. Don't stick to what you know -- put yourself outside your comfort zone as often as possible.

I'm not saying you should learn every shiny new technology you see -- but I am saying that you should take responsibility for your own continuous education. Moaning that your employer doesn't send you on courses is ridiculous.

Refactor!

Fix the little things. Fix them often. Improve method names. Improve variable names. Be consistent, be clear. Extract methods. Focus on those terrible long methods. Reduce cyclomatic complexity. Get a second opinion. Talk about your code. Little fixes add up.

Passion

No -- you don't have to go too far with it. You don't have to take everything personally. But you've got to care. You've got to give a shit about the code you write and the people who use it. If you don't care about it, you're never going to enjoy it properly.

Yes, it's a frustrating job, where little details threaten to derail the entire project at every moment. Yes, you are surrounded by silly ass-hat clowns who don't understand a thing about what you are trying to achieve. Yes, it's tedious and gruelling and it makes your brain hurt. But you've got to care dammit. There's no shortcut on that one.

Summary.

You're an idiot. Deal with it.

The longer version.

I've been pondering the chronic over-supply of stupidity, and I've come to a new conclusion.

Stupidity itself is not the problem. Abundant stupidity is inevitable. The problem is the people (like you, for instance) who don't even begin to suspect that they are stupid. People who insist they're God's gift to intellectual discourse. But in reality: as thick as whale blubber.

So here's a matrix to show four different types of people... the cross product of those who think they are smart (or dumb) and those who are actually smart (or dumb).

This matrix has four types of people. Stealing an idea from my usability-buddies i've assigned a 'persona' to each quadrant:

1. Forrest Gump: stupid, but he knows it.
2. Homer Simpson: is actually dumb, but seems to think he's the cleverest guy alive.
3. Columbo: is actually smart, but comes across as quite a dope.
4. Mr Spock: smart, and knows exactly how smart he is.

Here's a pictorial version.

4 types of person		thinks he is...
		dumb	smart
is actually	dumb
	smart

And here's my guess at how common (or rare) each of the four categories are.

(I started with the rule that only 20% of people could be called smart, and then assigned a breakdown after that.)

The chief lesson: lots of Homers, very little of everything else. The stupidity vortex is spreading. More on that later.

The goal, interestingly enough, is not to end up in the lower right (Spock) but in the lower left (Columbo).

Why would a smart person (a Spock) decide to put themselves in the third quadrant and become a Columbo? Because they're smart enough to realise that they're really stupid. Stupid for two reasons.

Two things make you stupid

There's two reasons that a smart person should realise they are still, essentially, stupid.

The obvious thing is that no matter how much you know, your knowledge is an insignificant dot compared with the sum total of what can be known. (It's even very small compared with the sum total that other humans currently know.)

But here's the real kicker: every idiot in the world knows at least one or two things you don't know.

I've gone all out and used Powerpoint to create a Venn diagram (at right) to help illustrates this point.

Here we're comparing a genius with an idiot -- and the size of the circles indicates the relative size of their 'knowledge' or wisdom or intellect or some other hard to measure, but easy-to-chat-about concept.

Clearly the genius has greater brain points -- and indeed knows almost everything the idiot knows. But look out genius, because there's still a little sliver of things the idiot knows that you don't know. And this is a humbling thought.

The idiot won't hesitate to grab onto those one or two tiny points and rub your nose in them mercilessly. Trust me on this: I've done it to smart people many times over.

So don't get too cocky there Spock. Chill out, Yoda. Pull your head in, Gandalf.

Stopped Clocks

To remain humble even in the face of blatant stupidity, never forget:

"Even a stopped clock is right twice a day."

Tattoo that on the back of your eyelids.

The real lesson

But the real lesson is this: if you think you're Spock, you're much more likely to actually be Homer Simpson.

Please, dear idiot reader, err on the side of safety and assume that, like me, you are a mental ass hat with much to learn. We'll all be better off.

Final word: How To Get Smart

One final word though, on a more positive note... it might be possible to actually become smart. Imagine that?

I haven't tried this personally, but according to 'Wetware refactorings' which quotes 'Pragmatic Thinking and Learning: Refactor Your Wetware' by Andy Hunt:

...in a rich environment with things to learn, observe, and interact with, you will grow plenty of new neurons and new connections between them...

Your working environment needs to be rich in sensory opportunities, or else it will literally cause brain damage.

i've always been itching to tinker with microsoft robotics studio -- but i put it on my list of "things NOT to do" a long time ago. There's not enough time to play with every good thing in life.

But last Christmas i spent a bit of time on making fractals in logo, and learning F#, and drawing awesome robot pictures... so it's only fair that this christmas i'd crack out microsoft robotics studio and give it a tinker.

As a bonus, my nephews are around and I was hoping to help get them hooked on a life of computer programming.

first impression:

stupid roadblocks. I know this is an awesome base operating system to unify and enable all the robotics systems of the world... but my god, nothing is obvious. The "pit of success" idea seems to have overlooked these guys.

I like to jump in anywhere and hope that it makes sense. That didn't seem to be appropriate here. Jumping in anywhere lead to confusion.

So I swallowed my pride and headed to the first tutorial. That was utterly lame. So I moved to tutorial 2. Lame. There is no tutorial 3... no sure why, but the next in line is tutorial 4. I loaded that in visual studio, compiled and ran... okay... some potential here... something to sink my teeth into... but oh god, how about that confusing user interface from the team that UX forgot.

Quick reminder about User-Interfaces By Developers

Dear developers (and this includes me) -- please don't open up the windows forms designer, blow chunks wildly, and then publish it to the world.

Either get a usability expert to provide some nice feedback or, at the very least, see if your little sister can understand how to use it. Pure developer UI can be a terrible thing.

Now back to the task at hand.

Explain this to me... someone... please...

Variations on this 'dashboard' form are common in the tutorials. And it's very 'developer UI'. This form is fail.

Generally if you click anywhere on this form you get two responses: nothing, or an exception.

After a lot of experimentation I worked out that you have to click in the boxes in a particular order (that the UI doesn't give any clues about).

Your average programmer would be able to work this out quite easily if they were motivated. Fine. But don't even think about handing this to your little nephews.

After working out the right order, we went in to the code (we being me plus my brother in law Rick) and re-ordered the controls to make it more appropriate, and gave better feedback on errors. A two minute refactoring, seriously.

Now we found that, with meticulous clicking and typing, we could convince the articulated robot arm to move in whatever way we wanted. (Yay! We knocked the dominoes over!)

It was cool in a way that only your most-geeky segment of the audience could begin to comprehend. For example, I loved it. But the nephews: not so much.

I'm pretty sure it gave little more than a whiff of the real power of this platform. I've listened to podcasts where people rave about the concurrency and coordination runtime, and the way real industrial houses use this software to simulate, build and control their real-world robots. From where I am right now, it takes quite a bit of imagination to see those distant capabilities.

Some things I'd love to be able to do:

• click on an object in the simulation environment and thus have it 'selected' in the remote control. (or even less -- float over an object in the simulation and have its name as a tooltip)
• record a series of movements and replay them.
• use a logo-like language for talking to these little robots. The powershell team could give great guidance on this.
• move the cameras around. (I know I can work this out programmatically -- but it's a pretty basic thing I shouldn't need to be a programmer to achieve)
• Hit reset -- to get the scene back to how it was at the start.

Computer games are full of lessons. They give you clear goals that get progressively harder. What each 'simulation' needs is an obvious goal. The final goal for tutorial 50 might be: write an autonomous robot that can drive 100 kilometres through rough terrain, unassisted. Some goals from intermediate levels: tell a robot to move; teach a robot-mouse to solve a puzzle; use a vision sensor to shoot down a robot duck.

In the meantime, anyone know what would be a good robot to purchase? I'd like to get a real world robot, provided I can also tinker with it in robotics studio. Some of the things i'd like it to be able to do for me:

• Mowing the lawn, including trimming the edges.
• The shopping (everything from keeping track of supplies, to collecting the goods)
• Organising breakfast (and cleaning up afterward.)
• Noticing when the batteries are low on my phone (or ipod, or camera, etc.) and re-charging the items as needed.
• Hunting down and killing anyone who has ever annoyed me.
• Giving gifts to children once per year.

I imagine he'll look something like this -->

I've had a long off-line sojourn, but have been feverishly writing and programming throughout.

There are many updates to follow. Including journeys with Microsoft Robotics Studio, Oslo, Hudson, Spock and that notorious programming-fiend: JFK.

Happy new year,
lb.

p.s. here's a picture of Joe Cooney dressed as Hunter S. Thompson. Note that Joe is not ordinarily bald, and nor is he wearing a bald wig. I only include this artefact because a) it is a sad indictment on the state of mind of young joe, and b) HST is a particular hero of mine from years long past.