The ideal gift for your computer-illiterate loved one

I’m running a crowd funding campaign right now to raise money for the publication of my book, Brown Dogs and Barbers. It is a popular science title that explains the fundamentals of computer science so that anyone can understand them.

Although it’s proven informative even to IT veterans (read what Professor Cornelia Boldyreff kindly wrote about it), it’s particularly aimed at beginners. I’ve shared drafts with readers who are firmly outside the computing sphere and the response has been very encouraging. Despite the topic being new to them, my test audience got the hang of the concepts I discuss, concepts that go to the heart of computer science.

So, if you already work in IT, there’s every reason to be interested in it. Furthermore, if you have friends of relatives who puzzle over what exactly you do for a living and pester you to explain what you do all day long, you might consider Brown Dogs and Barbers an ideal gift. After they’ve read it, the recipient will have gained an understanding in the fundamentals of your subject and won’t harass you any longer… either that, or they’ll have a hundred more questions for you, their appetite suitably whetted.

In fact, my crowd funding campaign has the ideal perk for you. If you contribute €60 (that’s about $80 US or £50 UK), you’ll get two signed advance copies of the book, one of them already gift-wrapped ready for you to give as a present. The book scheduled to be ready in June, so it would arrive just in time to supply some summer holiday reading.

Go over to the crowd funding page and contribute today.

Learning about computers – The motivation behind Brown Dogs and Barbers

In the opening chapter of my new book, Brown Dogs and Barbers (which explains how computers fundamentally work in a way anyone can understand it), I talk about part of my motivation for writing it. After pointing out that most people can quite easily understand many forms of technology (toasters, cars etc.), I contrast this with computers:

“For many of us, our relationship with computers is one of bemusement, frustration, and fascination, all experienced at arm’s length. We sometimes even find ourselves as the servile member in the relationship, desperately reacting to the unfathomable whims of our computer trying to make it happy. This is not the best state of affairs to be in if we’re going to be so reliant on them in our everyday lives. It doesn’t have to be this way. If our relationship with computers is sullied by their mysteriousness, the answer is simple: learn more about them… To understand what’s going on in that magic box beneath your desk, we’ll look in this book at the science behind it.”

I believe that by learning about the scientific principles behind computers, we put ourselves in a much stronger position: informed, confident, and empowered.

While perusing one of my favourite authors, Ben Goldacre, I found we share similar sentiments in this regard. In his excellent book Bad Science Ben explains how an ignorance of science can have negative impacts.

“Fifty years ago you could sketch out a full explanation of how an AM radio worked on the back of a napkin, using basic school-level knowledge of science… When your parents were young they could fix their own car, and understand the science behind most of the everyday technology they encountered, but this is no longer the case. Even a geek today would struggle to give an explanation of how his mobile phone works because technology has become more difficult to understand and explain, and everyday gadgets have taken on a ‘black box; complexity that can feel sinister, as well as intellectually undermining.”

Today’s mobile phones are not phones – they’re computers with an antenna attached to them. And it’s not just phones; computers have crept into most modern technology, rendering them much harder to understand. This is not going to go away. If anything, it’s going to intensify with some truly staggering applications of computers on the horizon (self-driving cars, anyone?).

By making sure people have a basic understanding of computing principles, we can dispel the ignorance, the suspicion and the frustration.

I offer my book as one place to start. Please help me crowdfund the publication process so I can make it available to everyone.


Brown Dogs and Barbers – A computer science book for everyone

I’m very excited about my latest project. I’ve written a book explaining the fundamentals of computer science that requires no IT expertise at all to understand. My main motivation is to provide an easy to read work of popular science for an everyday reader who’s interested in computer science, although I’m confident that experienced computing folk will find it interesting too.

I’m going to self-publish it and for that I need several things to make it a professional piece of work. These all need paying for, so I’ve launched a crowdfunding project at Indiegogo to cover the costs. Time for the hard sell…

What’s this all about?

Computers are a huge part of our lives. They are everywhere powering so much of what we do.

And yet, how well do we understand them or how they became so ubiquitous? We take computers for granted but many of us don’t appreciate the fascinating ideas behind them. If you look closely, there is a rich trail of puzzles that had to be solved to make them what they are now.

I’ve written a book, Brown Dogs and Barbers, which explains how the ideas of computer science developed throughout history.

When you read this book, you will join me on a journey through the story of computing, discovering the basic principles of what makes the machines tick and learning why computers work they way they do.

Who is the book for?

I would like to make computer science accessible to all. Brown Dogs and Barbers is a work of popular science aimed at both beginner and experienced alike, no expertise required with as little in the way of formulas and code as possible.

If you are a beginner you will get an introduction to the fascinating world of computer science. If you are experienced you can enjoy reading about your field from a different perspective and perhaps learn a new thing or two. It would also make a great gift for an IT worker’s friends and family who haven’t got a clue what it is they do all day.

In any case, you will develop an understanding of the puzzles and theories behind computers, and meet some of the characters who have steered computing over the centuries.

Why me?

I’m a big fan of reading about science. Whenever I go into a bookshop, I’m dismayed to see that the popular science section hardly ever seems to carry titles explaining my subject – computer science – to the masses.

I’m trying to fill this gap with my book. Brown Dogs and Barbers examines some of the foundational concepts of computing. I can still remember the stumbling blocks I encountered when I first learned about these fascinating ideas, so my book strives to light the path so you may avoid them. I’m also a PhD-level computer scientist, an experienced teacher and a published writer on IT and computing topics.

What’s the current status?

All text is written and a collection of placeholder diagrams and illustrations are in place. It now needs some polish, formatting and professionally designed images to make it a kick-ass publication.

The book has 38 chapters. That might sound like a lot, but each chapter deals primarily with one idea and in the final product I estimate chapters will be around 5-6 pages long on average. That’s about 220-230 pages.

What do I need funds for?

To polish the book, I need three things:

    • A professional proof reader to fix any mistakes, inconsistencies and grammatical errors.
    • An illustrator who can produce an awesome-looking front cover, and also take my placeholder diagrams and illustrations and make them look beautiful.
    • A copy editor to give the book a professional finish.

I already have estimates for each of these services.

Want to read a sample?

Go here.

You might also be interested to know I’ve contributed several articles in the past to Linux User and Developer magazine. Some of them are available online (e.g. “Wikimedia: Wikipedia’s Game Changer” and “Kolab: David and Goliath” ).

Other ways you can help

Don’t forget, you can contribute in ways other than donating funds. Tell your friends, share this page and tweet about it to the world. Help me get the word out!

Please visit the project’s Indiegogo page to find out more and, more importantly, to contribute!


Software development and your natural rhythms

One of the lessons from Joel Spolsky I took to heart right from the start of my career as a software developer was to schedule tasks honestly. Scheduling dishonestly means estimating a task when you don’t really know what work is involved. As a result, you end up putting an incorrect time estimate on it.

To combat this, you should schedule honestly and Joel proposes this simple rule: tasks should be measured in hours not days, with a realistic estimate being no larger than 16 hours. If your estimate is larger than that, then you probably don’t appreciate the true size of the task. Experience tells us that programmers usually underestimate tasks they don’t fully understand, so estimating in terms of days or weeks risks schedule overrun. Tasks which will take more than a day or two should therefore be broken down into smaller sub-tasks, because this forces you to think about the work in more detail and gain a better understanding of it.

But how much time is in a day?

So an 8-hour task will take about a day, yes? Well, maybe not. One of the other things I recall Joel saying is that there is less time in the day than you think. Yes, we ‘lose’ time to lunch breaks and meetings, but that’s quite easily taken account of in a schedule.

What about that other ‘lost time’? You know what I’m talking about: all that web-surfing, checking email, chatting at the water-cooler. How much time every day is ‘lost’ to these? And how guilty do they make us feel when work ends, because we know we spent a cumulative hour on them instead of completing that task which should have taken only a day.

In actuality, we probably shouldn’t be feeling guilty about this at all. We should just be scheduling better.

Scheduling in cycles

I recently read this article: “The origin of the 8 hour work day and why we should rethink it“. It presents interesting arguments for switching away from a traditional 8-hour work day and has several tips for working more effectively. The one that really intrigued me was the argument that human concentration follows a natural rhythm whereby we can focus on a task for a certain amount of time before we start to lose it and need a break. The article claims that most of us can hold focus for about 90 minutes before requiring a break of around 20 minutes, and so advocates planning work time in 90-minute windows (let’s call them cycles).

Ultradian Rhythm of Life

So what happens when we combine this with Joel’s advice? A task estimated to take 6 hours effort (360 minutes) would require 4 cycles (4 x 90 minutes). When you factor in the 20-minute breaks between tasks that’s an extra hour.

If you can manage more than four cycles in a day then good for you, but four is enough for me. Under this cycle-scheduling system then, “one day” (if we stick to an 8-hour day) clearly gives you six hours work time, a one-hour mealtime, and recognises that we all give in to the temptation to take little breaks now and again.

Can it work for programmers?

Let’s consider a few things.

  • It factors in those more unpredictable distractions (Facebook, email, coffee etc.) which are actually symptoms of us reaching a loss of focus. Using cycles allow you to actually allocate time for them, which recognises we need them and stops us from feeling any guilt about ‘wasting’ time.
  • It can be encouraging to know that your current cycle of work will soon be followed by a scheduled break, especially when the work is intense.
  • You can more easily track the work you did. At the end a day, can I really be sure I put in X hours of work? How much cumulative time was lost to those little breaks? If you follow the cycles, you have more confidence in how much time you really spent on tasks.
  • Granularity. Most of the time, programmers can’t measure progress with the granularity of certain other professions (like a bricklayer who can measure bricks laid per hour). But there are still activities we can plan which fit into a 90-minute cycle. Think along the lines of: layout one basic screen design, implement that setter function, write the code that makes TestX pass. And speaking of testing…
  • Cycles can also help to make the distinction between coding and testing clearer. When you estimate a task as 8 hours, it’s easier and tempting to lump the two together in a schedule only to find that coding takes up all the allocated time and testing gets pushed back or even dropped. Using 90-minute cycles encourages the approach of spending one cycle getting something working and then spending the following cycle reviewing and testing what you’ve done. Most programmers can relate to how different code looks when it’s examined again after a break and how this makes the flaws easier to find.
  • Interrupting the flow. One objection I’ve heard goes along the line of: “It can take programmers several hours just to get into a task, so you shouldn’t interrupt the flow.” This is true, but getting into a task still needs factoring into a schedule somehow. Just like cycles force you to think about the actual small details of a task, they also force you to plan your research or preparation.
    • Try reducing the breaks in-between preparation cycles to 5 minutes.
    • Be more detailed about what “getting into a task” means: How many pages of a resource can you read in one cycle? How much of a prototype/test code can you write in one cycle? etc.


So, instead of estimating a task or feature in terms of the number of hours it will take, why not in terms of the number of cycles instead? Personally, I like the approach and I already work in a similar pattern anyway. If it is indeed effective and quite natural to all of us then why not  make scheduling explicitly take it all into account and give yourself a more accurate project plan?

Edit: One reader seems to have the impression that I’m saying non-peak time is exclusively time to slack off, even though I never stated such a thing and even included work tasks in the examples of non-peak time. Let me make it clear: non-peak time includes unscheduled stuff that doesn’t contribute to the development project you’re working on and billing for. It could be slacking off time, but it could also be reading your email, checking in with work colleagues, looking at or updating the project plan,  and so on…. anything that takes your focus away from the scheduled development work.


Happy Birthday GNU!

It was 30 years ago today that Richard Stallman announced something kind of crazy: he was going to initiate a project to implement a version of the Unix operating system that was completely free (as in freedom). He called the system GNU (GNU’s Not Unix) and his original announcement is preserved here as a piece of IT history.

GNU is highly significant for FLOSS fans. It was the first project that consciously and clearly set out sharing of source code as a basic principle. The Free Software movement didn’t yet formally exist in 1983, but Stallman went on to become a key figure in its formation as time went on. GNU itself became a key component of the Linux operating system.

If you want to learn more about GNU, go over to and read up on its history and the philosophy behind it all.