⇥ On being human

If I had to pick a “best sentence of 2010,” it would be this little tidbit:

I do like and have tried to champion OpenSource software. How can I square that with my love of Apple? I’m complicated. I’m a human being. I also believe in a mixed economy and mixed nuts. I love our National Health Service and the National Theatre, but I also love Fortnum and Mason’s and Hollywood movies.

It comes, of all places, from a piece that Stephen Fry wrote on January 28th, in occasion of the launch of the original iPad. If I had to pick a “best reason why I admire Stephen Fry,” by the way, this sentence would encompass it precisely as well.

The reason I love this short paragraph is not that it has to do with Apple, or the iPad, or open-source software. Rather, it’s the fact that it’s an honest admission that being human means dealing with a never-ending supply of conflicting feelings, contradictory ideas, and seemingly irreconcilable realities.

The real trick in life is not to reach absolute conviction, but, rather, to process all your inputs, distill what you can learn from them, discard that which is unhelpful, and formulate a personal philosophy with the knowledge that it will become a living, ever-changing thing.

It’s an amazingly difficult thing to do, which is probably why so many people prefer to adhere to One Real Truth instead. People who do that without ever questioning themselves or their beliefs frighten me if they are in charge, disgust me if they are trying to sell something, and make me sick if they just do it to feel part of a group.

⇥ Postscript to “the lost art of using your brain”

My recent blog post The Lost Art of Using Your Brain ended up on both Hacker News and Reddit, where it generated a considerable amount of traffic and comments.

Several of the comments were interesting and even improved on my original thoughts; for example, one point that was made concerned this sentence:

The third, finally, is that a lot of people are not taught to deal with the consequences of their actions. From childhood, they are told that they are special, that they deserve better, that it’s OK to be less than the best.

Some folks noted (correctly) that being nothing but the best is a bit of an absurd demand on any person. There can only be one “best” under any given set of circumstances, and that means ipso facto that not everyone can be the best.

The problem is that the word “your” slipped out of that sentence when I first wrote it; thus, I ended up writing “to do the best” and, on the second pass, my poor brain recognized that those words didn’t quite fit together and made me fix them the wrong way.

I actually meant to say “to do your best.” And I stand by that: it’s one thing to fail despite one’s best intentions and efforts, and quite another to fail because one is being lazy. Unfortunately, the prevailing attitude towards life these days seems to be the latter.

A number of people also took umbrage to my apparent dislike for IDEs. (I will leave those who seem to think that I am one of those “old guys who wrote assembler” and that I want us to work without tools at all to drown in their own stupidity. I have nothing to say to them.)

I have absolutely nothing against IDEs. The whole point of my post was that you need to evaluate the benefits and drawbacks of every tool you use and decide if it works for you—including, of course, IDEs.

For example, I don’t normally use an IDE when I write server-side code. I’ve simply never had any reason to use one, and can’t find one that adds anything useful to my development process¹.

This doesn’t make me special. It doesn’t make me feel different. It simply makes me a person who doesn’t use an IDE when writing server code.

If you do use an IDE for whatever work you do, good for you. We have no quarrel as long as you don’t splash that fact around as if it makes you smarter than the rest of us.

⇥ Understanding the post-PC world

There is a post by Paul Hontz at The Startup Foundry that keeps popping up on my Twitter feed and has really started to grate at me.

Hontz’s thesis: the iPad needs iTunes to be activated and, therefore, is not a “post-PC” device. Android devices activate out of the box and, therefore, are “post-PC” devices.

Box and inbox

Let’s start with the obvious: the iPad does need iTunes to activate. There is no denying that.

If you set activation aside, however, the iPad is perfectly capable of running independently of a PC of any kind. I’m pretty sure I haven’t synced mine in a while, and I know of plenty of users who are in the same boat (and loathe the thought of syncing and backing up).

One could even argue that Apple has made damn sure that as much of the iPad’s life can take place untethered. Even if you wipe out your device, there are ways to get most of your content back without connecting to a computer¹.

In fact, if you happen to buy your iPad in an Apple Store, they’ll be more than happy to activate it for you. It takes only a few minutes.

Still, Hontz is entirely right when he says that you need iTunes to activate the iPad.

So what?

However, if you think that untethered activation is what makes a device “post-PC,” you’ve completely misunderstood the meaning of the term; you are staring intently at a tree, while a majestic forest is growing all around you—and, pretty soon, you’ll turn around and figure out you’re lost.

“Post-PC” is not about the liberation of the device from the PC. It’s the liberation of the user from the concept of PC.

If you’re a developer and all you ever do is thinking like a developer, a device like the iPad makes no sense whatsoever. It’s closed, limited in what it can do; it lacks a keyboard; it can’t be used to write code. And so on, and so forth.

Users—regular folks—don’t think like developers, though. Users dread computers, and only deal with them because they must.

From the perspective of a normal person—no matter how intelligent or erudite—a computer is something that breaks easily and takes a lot to be fixed, either in terms of money, or in terms of condescending looks from an obnoxious IT person.

Computers make you feel stupid; unless you know the exact incantations, key sequences and special shortcuts, they’ll refuse to yield the results you want and go rogue on you.

IT specialists, of course, generally make no effort to improve things. We like being part of a special group that “gets it,” and actively—if unconsciously—endeavour to keep outsiders where they belong. We’re the world’s geekiest secret society.

What post-PC really means

The genius of iOS—rivalled, so far, only by Windows Phone 7—is that it is, essentially, a foolproof system. Short of throwing an iPad against the wall, or falling prey to regular wear-and-tear, there is no real way to do irreparable harm to it that requires expert repair.

Of course, this doesn’t mean that its software is perfect, just like “it just works” doesn’t mean that Macs don’t crash or break. It simply means that you can use it with reasonable certainty that you will not dig yourself into a hole.

IT people seem to have a really, really hard time understanding this. For the past three or so years, I have been telling anyone willing to listen that it’s about time for us to stop promising people that computers will cure cancer and take us to the moon, and start showing them that the average person can, instead, use them to put together a Powerpoint presentation that doesn’t look like it came straight from a cow’s digestive system. More often than not, when I make that point, I am met by blank (or, worse, condescending, “Tabini is crazy” stares).

Imagine if you walked into your car tomorrow, and the dashboard looked like the cockpit of a 747. How would you like that? Would you take the car for a spin? That’s the way the average user feels in front of a computer.

Instead, your car has simple controls. Strangely, this doesn’t mean that the average automobile is a low-tech affair. Think of the hundreds of years of engineering advancements that went into making driving so easy that an unfortunately large number of people can master it. Sure, Michael Andretti probably laughs every time he sees a Tercel, but I doubt he’s the prototypical customer Toyota had in mind when they designed that car.

The similarities between an iPad and a car are startling. An automobile has one last-ditch failsafe mechanism: the ignition key. Even though it’s ostensibly there to prevent theft, you know, at the back of your mind, that, should everything suddenly take a turn for the worst, you can just yank the key out and the car will come to a complete stop.

The same is true of the iPad’s home button. Officially, it “takes you back to the home screen.” To a regular user, however, it’s a big red button that screams “LET ME OUT OF HERE.” Press it, and you’re safely back at the beginning, no matter what you have done.

And so, it seems to me that “post-PC” has nothing to do with openness, tethering, or even tablets. It has everything to do with the rebirth of the computer into a device that average people can put to good use, without fear, for the performance of the tasks that matter to them.

Miss that, and you’ll shut yourself out of a huge opportunity.

⇥ The lost art of using your brain

“I thought all serious programmers used an IDE”

“My tests have 100 percent code coverage!”

“You mean you don’t use OOP?”

If words like these ever escaped your mouth in my presence, you should know that only the strongest rules of good social behaviour stopped me from punching you in the face.

We may agree or disagree on whether IDEs are useful, or whether code coverage is an important metric of the effectiveness of your testing strategy, or whether object orientation is an important, useful and positive technique to use in your code.

But one thing we need to agree on: people need to use their brains more and rely on the brains of others less.

The world of technology is riddled with inhabitants who treat tools as if they were religions. OOP, unit tests, patterns… these are all instruments that are supposed to make some jobs better, and not theological formulas that will magically make every single line of code written on the face of the Earth better.

And yet, the vast majority of people treats them like they are, sparking everything from language wars to endless—and pointless—discussions on whether a particular technique is better than another. I swear I sometimes look at threads on mailing lists that look like one giant Hello, world program: not merely pointless, but counterproductive.

Tools are not just pieces of software

Programming is about one thing, and one thing only: solving problems. As developers, we must look at everything that we do in that light; whenever we don’t, we are doing ourselves and our clients a horrible disservice.

The fact is, there is no accepted “true” way of writing code. This should serve as a powerful hint to developers that there is no “best” way to work; rather, we must build a war chest of tools, attempting to understand how each of them can best be applied to a specific problem.

The “why,” as is so often the case, is more important than the “how.” And yet, so much of the training material that we have at our disposal is focused on the latter and completely ignores the former, leaving the incautious student in the same conditions as a plumber who is given a wrench and not told they should make sure the water is off before unscrewing the faucet.

My partner Keith Casey made a great example of this at last year’s Codeworks tour; he picked an example from a book on unit testing that shows a simple class (I can’t remember what the class did, but it was something absolutely trivial) and then the associated unit tests. The example concludes with something like “of course, you would never write a class like this in real life, but this is how you achieve 100 percent code coverage on it.”

The question is: if I’m never going to write code like this in real life, how am I supposed to learn why I should use unit tests?

The why of the why

I can think of at least three reasons why this malaise seems to be so commonly spread.

The first is that the proponents of a tool are usually less than fully honest about its benefits and drawbacks themselves. This could be out of intellectual dishonesty (that is, because they want to sell you something), or because they want to see their own work validated by means of adoption. Nothing wrong with either of these things—people have to eat, and hard work needs rewarding. Why, I am probably doing the same thing right now.

The second is that it’s easier to sell a practical something than a theoretical something else. We like to delude ourselves into thinking that we like choice, but the harsh reality is that end users don’t want to choose: they want to be told what to do. This includes most developers, who would rather rely on someone else’s blind advice than apply their own critical thinking. We all do it—it’s a common failing of all men and women.

The third, finally, is that a lot of people are not taught to deal with the consequences of their actions. From childhood, they are told that they are special, that they deserve better, that it’s OK to be less than the best. And this shows in so much of the work I see every day: “architect” makes a decision that goes south; “architect” disappears; remainder of the company is left to deal with “architect’s” mistake. Rinse, lather, repeat.

The way to the how

How does one stand apart from the masses? Simple: by learning to apply his or her own critical thinking to a problem.

The first step is never to accept anything at face value. Question everything—not for the sake of questioning, but for the sake of getting to the truth. Once you have all the facts, making a decision is a matter of weighing each factor against the others and picking the tools that give you the best resolution. You’ll still make mistakes, but your batting average will get much better. (Also: you’ll have some way to figure out why you made a mistake and learn something.)

The second step is to continuously question your knowledge. In the past eighteen months, I have begun writing for Macworld, taught myself how to program in Objective-C for both OS X and iOS, have played with XNA and just started delving into Ruby with some level of details. I haven’t become a master at any of these¹, but I have learned things from each one of them that I have been able to apply elsewhere in my day job.

The third step is to surround yourself with people who have as different (and diverse) a perspective from yours as possible. If you only ever stick around people who think the same way you do, you will stagnate and never grow. If you surround yourself with people who respect you but don’t always agree with what you have to say, you’ll be forced to question yourself more often and learn a thing or two.

Of course, these things are true of many other aspects of life—politics, philosophy, sports, you name it. As applied to technology, however, they will at least make you not be one of those people I want to punch in the face.

Update: I posted a postscript to this post in response to some of the comment I received.