Riding gear

I like to wear proper safety gear when riding a motorcycle.  The local law starts and ends with enforcing wearing a compliant helmet,  but the minimum riding gear I use is helmet, jacket, gloves, jeans and boots.  I have yet to get into the trend of wearing Kevlar reinforced jeans and I have a strong suspicion that the jeans are the weakest link in my armour.  I have no intention of testing my suspicions. 

During Brisbane summer months, many motorcyclists go the “squid”  route – riding in T-shirt and shorts.  I am not one of them.  I am still out there with jacket / gloves / jeans / boots.  Unlike ten years ago, synthetic jackets made from a mesh material over body armour means you no longer need the discomfort of wearing the outside of a cow on your back.

One overlooked factor in judging the appropriate level of attire when riding, is how it affects concentration.  Racing guru Keith Code talks about your $10 worth of concentration.  His point is simply that you only have a finite amount of concentration – what you spend it on, is up to you.  Different factors require differing amounts of your $10.  They could be things like road condition, other traffic, wildlife, weather conditions and so on.  If you don’t spend it on the right thing at the right time, you risk missing something important.  If you are distracted by your personal discomfort (i.e. if you are too hot riding around town in your full leathers), then this robs you of part of your $10. Like many decisions made in everyday life, what you wear on a motorcycle is a compromise.

At this time of year, the opposite weather conditions are likely to rob you of concentration.  Whilst Brisbane winters are undoubtedly very mild, up in the hills, with the added wind-chill factor, it still gets a tad chilly.  Unlike our southern states, we don’t have the added worry of black ice on the roads and the generally clear sunny conditions means it’s a great time of year to ride.

To accommodate for cooler conditions, most riding gear simply goes up in bulk.  Jackets get an extra lining, gloves get thicker etc.  Glove thickness is a big deal when riding.  The level of “feel” transmitted through the bars is reduced by bulkier gloves and finger dexterity is reduced.  Subtle feedback is received through your hands and it can convey information relating to grip levels (between the tyres and the road), so it’s important to allow for all these points when riding.  Bulkier gloves can lead to an increased level of “finger stretch” when holding the bars.  This can become uncomfortable if it’s pronounced.  – Riding in summer weight gloves alleviates these problems, but of course thermal insulation is sacrificed.  Cold hands ache and don’t move as quickly.  So you can have “slow clumsy hands” due to the cold, or due to the bulk of your gloves.  In my experience, “cold ache” is worse than “stretching ache”.

The other attire I use in winter is a “neck sock”.  This not only helps to keep your neck warm, but has the added benefit of reducing wind noise around the base of your helmet.  I find them immensely superior to wearing a scarf, as there’s less excess material.  Scarves either flap around in the wind, or if you tuck them into your jacket, restrict your head movement. 

The other option (for which a Brisbane climate is really too mild to make worth exploring) is electrically heated gear.  Electric gloves and vests can be worn, or seat and grips warmers can be purchased.  Clothing often plugs in to the bike’s electrical system via a cigarette lighter.  Some bikes (more in the cruiser and tourer markets) have these fitted as standard or optional factory equipment, or some have been fitted after market.  If you’ve ever used any electrical heating systems on a bike, I’d be interested to hear your comments on them.

Till next time, ride safe and stay warm!

A nerdRider’s guide to training

dsc_0010.jpgRecently, I had the opportunity to train developers in Hong Kong. My “day job” is as an application framework developer. The way I explain my job to my mum is: “Imagine I build the chassis of a car, then hand that on to different customizers who put their own bodywork on the completed chassis and sell it as a car.” That is an overly simplistic analogy of the job that doesn’t stand up to close scrutiny, but like most analogies it is correct enough – up to a point.

The company I work for is US based, with development and sales offices worldwide. It has grown through various acquisitions of smaller companies with products that complement the current line-up of products. There had been some shuffling of projects recently, with the end result that developers working in our Hong Kong office had inherited a project based on our framework.

Normally, our architect gives technical training to the developers when required, but this time, the training coincided with his annual leave and as such, I got to present the “course”. After jazzing up the power point presentations with a few newer screenshots and running through the slides I was pretty much ready to go. Many moons ago, the architect and I had given the “first version” of this training course to a group of developers who had convened in Chicago for the event. I don’t think I had conducted a training session since then! What this meant (I discovered) was that my presentation skills were a little rusty.

I tend to be quite critical of my own ability and work, and in a reflective way, I try to learn from “my mistakes”. Whether or not other people notice these mistakes (or would even consider them “mistakes”) is irrelevant. I consider communication skills are both (a) very important to have in any job and (b) something I like to think I have got a relatively good grasp of. So, here are some things I learnt/re-learnt/should never have forgotten:

1. Speak slowly. In my case, this was doubly important given the fact that English was their second (or third) language.

2. Improvise. Having sat through my fair share of dull Powerpoint presentations, I was keen to avoid the trap of just reading the bullet-points on the slides I presented. Speaking slowly is just as much about “sentences per minute” as it is “words per minute”. Give yourself time to think of something sensible to say, rather than just suffer verbal diarrhoea. – Leave that for your blog 😉

As a side note to rules one and two: Remember that this is new material to your audience, they need time to absorb the information. This gives you some leniency in how long you can afford to think of what you are going to say next. Visual cues from your audience can also help you determine if it’s worth repeating a point or giving a more “in-depth” analysis of it.

3. Avoid skipping ahead. This is difficult when you improvise. With the material I was presenting, it quite often had the format of introducing points that built on what had gone before them. Try not to be too forward looking.

4. Don’t pad a presentation with extra material. If you forget Rule #1, you may be tempted to add extra material when you finish early. Problem is, you can tend not to stick to material that can be described as “Introductory”. As stated above, this stuff is “new” to your audience. Giving them in-depth material just confuses them. Avoid this trap, by remembering Rule #1.

5. Writing code in presentations is best avoided. This is not a hard and fast rule. Sometimes it is a good way to demonstrate how easy something is to do. If you do write code, make sure your editor is using a big-goofy font so that people can read it on the projector.

This recent training session was given to a small group. There were only two developers with me and two more “tele-conferencing” in. In such a small group, I feel questions should be encouraged at any stage. Answering with “we will cover that in a minute” is a perfectly valid response. Also, you should not fear getting a question you don’t know the answer to. Every presentation I have ever given was not designed to be a test of my skills in a hostile environment. As a result, people won’t ask questions that they know the answer to. If you don’t know the answer, have some way of recording the question and simply state “I will get back to you on that one”.

In larger groups, it is best to encourage questions at the end of a session. With larger groups, the next rule becomes important:

6. Always repeat / paraphrase the question asked, before giving an answer. Not everyone is blessed with good vocal projection and even those who are tend to have their back to some or all of the audience. No matter how clearly you hear their question, you can almost guarantee that some people won’t have. As such, your answer will be out of context. I must admit, I do feel kind of silly starting with “OK, so the question was…”, but as an audience member, I have always appreciated that effort made by the speakers who use this technique.

7. Take breaks. You should also plan to have breaks in the schedule. Whilst you can plan to have them, it is best not to actually schedule them in terms of how far through the material you will be, when the breaks are taken. Rather, use your audience to provide you with clues as to when they should be taken. People fidget and get less responsive when their concentration levels drop. Use these signs as indicators of when breaks should be taken.

I am sure there are other far more useful web-sites on public speaking that can give you better advice than what I have listed here. But if only one of my rules stick, make it “Speak slowly!

The benefits of “Big and Goofy”

Back in the days when I was learning my craft, text mode operating systems were all the rage. Well, it wasn’t so much that they were fashionable, just that there wasn’t really much in the way of a choice. At that stage, the university wasn’t even teaching object oriented languages, but at least it was teaching C!

Having been a truly nerdy child, my programming experience prior to university was restricted to self-taught BASIC . The power of GOSUB and RETURN were at my disposal, but the performance overhead of using them simply meant they weren’t exactly popular in my home-spun code. Thus, the notion of functions and procedural programming was a big step and completely new to me when it was raised in about the third week of Introduction to Programming. Mind you, I also remember how much of a big step that programming without line numbers and using something called a compiler was too!

One of the earliest lessons regarding functions and procedures (for this subject, we were using the “educational” language Pascal, after all) was we were taught that each function should do one thing and one thing only. As a guide, we were given the following metric:

Each function should be no more than two screens long.

This actually meant something on text-based screens. For the benefit of you young whippersnappers still humouring the old-fogey by paying attention: that meant each function had to fit in 80 columns by 50 rows – tops.

These days, a lot of programmers I deal with still pay lip-service to this notion of keeping functions short / readable / single purposed. Despite this, there seems to be an awful lot of functions with an awful lot of code in them.

Short, readable, concise functions still make a lot of sense. I’m sure, just like middle aged spread, code bloat is assisted by laziness. Where multiple people work on the code-base, the responsibility for keeping the code in tip-top shape should fall on everyone’s shoulders, but without the right team dynamics and encouragement it’s easy for this point to be lost. When that happens “code improvement” tends to cease – functions get longer, they get subverted for other causes – in short, they get less maintainable. Next time you maintain a function, don’t be a lazy programmer.

Graphical editors don’t have the restrictions of 80 x 25 that the old text mode editors did. Fonts, designed for readability on LCD monitors can throw an amazing number of characters on one screen full. Using eight point Consolas font, on a 1400 x 1050 pixel LCD monitor, I have no problems getting 226 columns and 67 rows on one screen. How much bad code can someone shove on a screen now?! The fact that the text is readable on a 14 inch laptop screen doesn’t mean that the code will be!

Something I do when I code, (which seems to fly in the face of convention) is to run a big goofy font in my IDE… Next time you are writing code, try running 13 point Courier New (or similar). I dare you. In all the years I have done so, I’ve never been tempted to write hideously long functions and have never found maintaining existing ones a “pleasing experience”. That’s exactly the sort of irritation you need to inspire you to keep the code neat and tidy. I will warn you though… When you first switch to “big and goofy” it will offend you. Be prepared to squint at the monitor in shock and horror (as opposed to squinting because the text is so small). Give it the benefit of the doubt for a couple of days and let me know how you find the experience…