Doers and Thinkers

It is possible to divide groups of people in a great number of ways.  Left-handers and Right-handers, women and men, so forth and so on.  Sometimes two groups are mutually exclusive and adequate to cover all of a population base, sometimes (even in the above categories) they are not.  I am about to discuss two groups of programmers – but I would fully expect that there are programmers out there who don’t fit either category as precisely as I will describe them.

Category 1, which I shall call “the doers”, includes the majority of programmers I have seen and have read about.  Their personal coding style can be bluntly referred to as a “trial-and-error style approach”.  That actually sounds far too much like a harsh criticism.  The majority of these programmers are not clueless monkeys prodding away at a keyboard.  They have a reasonable degree of knowing what to do, but the detail is lacking.  As they code, details come into focus, nuances are dealt with and problems are overcome.  The beauty of this style of coding is that it is easier to deal with when writing.  There is no need for a detailed analysis of all aspects of the code, which in turn makes it easier to concentrate on a specific part of the code.

Category 2 I shall call “the thinkers”.  They represent a much smaller group of programmers.  Their approach is more of intense thought followed by intense typing – with rarely a backspace key pressed.  I would suspect that this group would have a far better ratio of keys-pressed to source-code output.  These are the true geniuses in the field, but based on my experience, they make up no more than one or two percent. 

In reality, even the “doers” utilise and require a high degree of concentration to perform their task.  The biggest difference tends to be that the first version of working code the “thinkers” write will be neat and orderly, whereas some degree of refactoring will be required for the “doers” to turn in work of a similar quality.

As mentioned in my opening paragraph, I do believe that there are times when you will not neatly pigeonhole developers into only one of the two categories.  Depending on the task at hand a thinker may act as a doer or vice-a-versa.

Personally, I place myself in the “doers” group.  I used to feel convinced that the “thinkers” was where I wanted to be as a programmer.  Indeed, I recommend thinking about problems as opposed to blindly trying anything that springs to mind.  These days however, I am more forgiving of my own ability or lack thereof.

The computing industry seems to be coming aware that most programmers are not “thinker” programmers.  Many agile and XP style approaches to programming rely on this.  Concepts such as pair-programming and test-driven-development tend to favour “doers”.  For example, the fact that a “thinker” will visualise the code in their head for a long time prior to writing it down, makes it hard for them to participate in pair-programming environments.

The real danger is that thinkers will not be given a working environment that suits their needs.  One size does not fit all.  As the majority of the industry is made up of “doers”, it is important that methodologies are followed that allows them to produce output that a “thinker” would be proud of.  Essentially, that boils down to allowing time for refactoring.  The code is not done the moment it “works”.  Newer methodologies accept this and build it into the process of writing software.  But that is a story for another time.


One way to avoid riding with wobblers and idiots is to ride by yourself.  Sitting in a pub talking to yourself about how good the ride has been so far is not as advisable.  There is a solution to this dilemma: Carry a pillion-passenger. 

Some riders tend to react rather strangely at the concept of carrying a passenger.  It is as though carrying someone means they are no longer allowed to enjoy the experience of riding.  If you truly ride like an idiot, with not an ounce of self-preservation, then maybe you should feel this way.  Most riders are not as fast or as dangerous as they may like to think.

For me, carrying a passenger serves another purpose.  I like to introduce people to motorcycling.  I do not do this with an expectation of “converting” first time pillion passengers into becoming motorcyclists themselves.  (Although this has been known to happen!)  It is more an opportunity to help people understand why I ride.  Hopefully, this helps remove the look of fear and abject horror some people get when they discover you ride a motorbike.  It seems everyone knows someone, who knows someone else, who had a “bad” motorcycle accident.  Is there such a thing as a “good” accident?

If you have never carried a pillion before, where do you start? 

Hopefully, you will be a competent and confident rider before you consider carrying a passenger.  Remember that a pillion passenger can influence the direction the bike is travelling in.  If you can, find an experienced pillion passenger to take first.  They may be able to offer tips as to what you should be doing or asking your passengers to do. 

Trust is an important part of carrying passengers and if you can help set your passenger’s mind at ease before taking them, then that is going to be a good thing.  Three things I recommend for helping achieve this are:

Have the proper riding gear for your pillion.  I am of the school of ATGATT. Essentially, dress your passenger to the level that you are wearing.  If they see you in full Dainese racing suit and you offer them a barely-legal helmet without gloves or jacket, then they may get a little fearful.

Give them some comforting words.  An instruction such as “If you want me to slow down or stop, pat me on the back”.  They should feel as though they have an element of control in the riding experience.

Give them some simple instructions on what to do.  This can be a gradual thing.  First time pillion passengers will be overwhelmed if you rattle off an instruction list that takes five minutes to get through!  So, the solution here is to start simple and build upon the steps.

The first time someone goes pillion passenger, limit the instructions to something like:

“Ask me before you get on and off the bike”.  This gives you a chance to brace yourself for the weight change the motorcycle will undergo once the pillion passenger climbs onboard.  (Make sure both your feet have good grip on the ground, you are holding on with both hands and you have applied the front brakes to hold the motorcycle still.)  If the pillion is heavier than I am, I normally spell out to them to not get on, as they would when mounting a horse.  In other words, leave the first foot on the ground and swing the other leg over, rather than climb on the foot-peg and then swing their leg over.  The “horse” method puts their entire bodyweight onto one side of the bike, which when combined with the weight of the bike can be a good way to topple over.

“Act like a sack of potatoes”.  Explain to them that if the bike leans, then they should lean with it.  –not more than the bike does and not less.  This can later be refined to looking over the “inside shoulder” of the rider in a corner, but at the moment, we are trying to keep things as simple as possible for them.

Work out “slow down” signals and also a signal you give them if you want them to hang on.

Smoothness of riding is the last piece of advice to give.  Gentle acceleration and braking and gear changes makes for a more enjoyable riding experience.  It also helps the passenger to relax and trust the rider.

With practise and familiarity, a competent rider and pillion passenger will be capable of riding at a decent pace.  Then, you won’t have to be mumbling to yourself in the pub at lunchtime.

Identifying what is wrong with code

There are a number of head-nodding moments in Clean Code The book mentions many coding guidelines and good-code principles that aim to simplify code that is written.  Software development is definitely a career where you must continuously learn.  Even so, I’m somewhat disappointed to be this far along in my career before learning the names of certain concepts that until now I have only known as “common sense”. 

There have been times when I have identified “bad code”, but pressed to state what was so bad about it left me speechless…  This does not make the task of improving the code impossible, but can leave you with an inability to justify and/or quantify the changes you make. 

Here are some of the more common rules:

One level of abstraction per function.

This rule is not given a “trendy term”. Unlike the other rules I’ll introduce it is dealing with functions, rather than classes.  But it is still important.  This rule possibly came from “days of old” when top-down procedural programming was all the rage.  It’s still important and sans lengthy example is best summarised as:  Do not mix details with abstract concepts in the one function.  If you stick to the idea that each function should only do one thing, then you will be going a long way towards avoiding mixing abstract concepts and technical detail.

Single Responsibility Principle

The Single Responsibility Principle (SRP) states: There should never be more than one reason for a class to change.  The object mentors web-site has a series of PDFs discussing various aspects of Clean code, and has this (in part) to say of SRP:

“If a class has more than one responsibility, then the responsibilities become coupled.  Changes to one responsibility may impair or inhibit the class’ ability to meet the others.  This kind of coupling leads to fragile designs that break in unexpected ways when changed.”

In a rather circular fashion, the definition of a responsibility in SRP is “a reason for change”.  In other words, a class written to obey the SRP only has one responsibility.  If we were to develop an Object-Oriented “Space Invaders” game, we may end up with a class for the aliens, that looked like:

 public class Alien
    public void Move()
    public void Render()

However, this is a violation of SRP.  We now have two reasons for changing this class.  If the AI model changed, the calculation of the Move method may require changes – likewise if there were changes to the Graphics subsystem, the Render method would alter.


Law of Demeter

This is also known as the Principle of Least Knowledge.

“The fundamental notion is that a given object should assume as little as possible about the structure or properties of anything else (including its subcomponents).”

Object Oriented notation assists here, by having different scopes for the methods and member variables defined in a class. Clean Code points out that often you will see private member variables (good so far) exposed through public getters and setters methods (not so good).  This exposes the implementation details of a class allowing for other classes to violate the Law of Demeter.  Better (so the book argues) to expose the data through abstract concepts

“A class does not simple push its variables out through getters and setters.  Rather it exposes abstract interfaces that allow its users to manipulate the essence of the data, without having to know its implementation.”

The example given talks about a vehicle class that exposes the “percentage of fuel remaining” as opposed to “fuel tank capacity” and “gallons remaining”. 


This is by no means a definitive list of ideas presented in the book.  From my experience, violations of these principles represent the vast majority of “ugly code” that I have seen.  Once these coding techniques have been highlighted, it is possible to see where improvements can be made in existing code.  By refactoring code to utilise these principles, you can identify that tangible improvements have been made.

The future of transport

Recently, I found myself talking to a scooter salesman. I don’t begrudge anyone their choice in transport – be it a Hummer or a skateboard, or anything in between – but scooters aren’t really my thing. I was interested in the technology of this particular scooter. It was a Vectrix scooter and for those of you who don’t know: they are driven by an electric motor.

It’s very clichéd, but the stone-age didn’t end because the world ran out of rocks.There are several well-known competing technologies vying to replace the internal combustion engine run on fossil fuels. The least removed from the current technology are traditional engines run on ethanol (plant based) fuels. Rubber hoses and seals quickly perish from contact with pure ethanol and as such some degree of new components are required to make the technology possible. This technology is not without its downside: There are concerns over the ability to produce enough ethanol as well as food crops to sustain the Western world’s way of life. Also, engines run on ethanol still emit carbon-dioxide – thus contributing to greenhouse gasses.

The second technology uses Hydrogen fuel cells. This offers a huge potential energy source and is clean burning (the exhaust is water). Hydrogen however, is reasonably hard to contain, has the notorious reputation of being highly explosive and would require a huge infrastructure overhaul to support its widespread use. Ten years ago, those predicting widespread adoption of the technology thought it would require around ten years to mature. These days, those candidates are predicting the technology will take around ten years to mature…

The third technology uses electric motors. These vehicles may have once had a stigma of being slow and boring, but they’re doing their level best to throw off that persona. The biggest problem the vehicles currently face are slow recharging times (compared with the time it takes to fuel a car/bike) and the range obtainable between recharges. The price of the batteries is still quite high and this is probably the area where the vehicles are most “immature” but scooters such as the Vectrix are a viable proposition as a commuter vehicle. Whether electric powered vehicles “mature” enough to be the successor to the internal combustion engine remains to be seen, but so far, it seems to be the most likely to.

For me, commuting is not why I ride a motorcycle and so scooters such as the Vectrix will be little more than a curiosity to me. I wish the company well on their endeavours and look forward to seeing what progress they make.