Now we suck at verifying user input from web forms. The current state of code that verifies user input has both managed to take us back to the kindness of the command line when it comes to freedom of input and manages to check all the wrong kinds of things. Why is it so hard to write these checks? I suspect because people don’t really think much about them, and I bet there are more interesting things out there than to write user input verification.

These problems aren’t some beginner coder errors either — they’re rampant on even the biggest sites out there like paypal.

The most common field to get me snared is the phone number field. In 99% of all cases, the site assumes that all phone numbers in the entire world are formatted like US phone numbers. Not, as one could imagine, because I’m claiming to live in America — I clearly just told the site that I live in a European country. So anyway, inputting my actual phone number causes an “invalid phone number” error. Not that there is any mention whatsoever on the site about what the correct format of a phone number is (there are, in fact, even several ways of writing a US phone number).

This sets off a wildly unamusing guessing game of how to “convert” my phone number into a format the site will accept. This practice often costs the sites money as I end up giving up and going somewhere else, frustrated and unable to make a simple online purchase that didn’t really require that phone number anyway, did it?

Passwords

Another highly amusing game is the one where web sites try to force users to choose “secure” passwords by enforcing the formats of passwords. “You must have at least 6 characters, with at least one letter and one number”. Sounds good, except in general these passwords are restricted to only contain letters and numbers. Hold on, isn’t it common wisdom to include at least one non-alphanumeric character in a secure password?

As such, out of my set of passwords, the only password which tends to pass most password verifications is my least secure one. The idea that you could fix a social problem through technology is somewhat funny anyway — “password1″ is not more secure than “password” in any way that really matters.

The same thing applies to the old trick of forcing your users to change passwords every month. This can have two potential outcomes — users append a counter to the end of their password, and increment it every time they are forced to switch, or they keep a post-it note taped to their monitor with their current password. Neither outcome is a net gain in terms of security.

Some sites even let the user set a password which is then considered invalid when the user tries to log in (ebay, for instance,  has done this) — causing a prompt for a new password and much annoyance.

Format wars

Parsing stuff is what computers are good at. So forcing me to input something in a strict format is always a loss. Either separate the fields and force me to select the individual parts of a date separately or actually use all that computing power at your disposal to do your user a favor. Telling me you have no idea what I mean by “2009-12-21″ because you expected “20091221″ is annoying the user for no good reason, even if you told me to not include dashes.

If you find yourself in a situation where you need to verify input  from the web, take an extra minute to consider how you could make things as convenient as possible for the user, which ones of your assumptions only hold true for the region you live in… and when you’re done, whatever you do make sure you tell the user exactly what the expected format is.

Still, there are some issues with free software that don’t really show up to the same degree with commercial software. One such thing is documentation. It’s painfully obvious that documentation is written by people who:

1. Already know the software in and out.
2. Don’t like writing documentation.
3. Know nothing about how people learn.

For instance, when I started a side project a few months back, I was looking for a build system. After settling on CMake, I set about trying to make sense of it. There’s the ever-present getting started example, of course. And then there’s the full reference of everything you could possibly want (almost).

But in between those, there’s nothing. Well, nothing except a book, which just goes to show you that there’s something missing — a professional writer could obviously make some money out of explaining things in a reasonable way.

The problem with this is that it doesn’t match how people learn. Getting started is a good step, but a relatively small one. Most of the time will be spent incrementally expanding the knowledge, moving from beginner to expert. Most time will thus be spend in some kind of zone in between the “getting started” and “reference of everything” levels.

Worse than that, some open source programmers have a tendency to view their full reference documentation as an appropriate resource for everyone. “It’s all in there,” right? But pointing a beginner at a 40-page document detailing all the options of some application when all they want is to run it properly isn’t very helpful. I’m sure you know what I’m talking about if you’ve ever used an open source command line tool.

That ends us up with the really dark side of free software culture. The true douchebags out there will not only be extremely smartass in their RTFM comments, they’ll also be incredibly sensitive and defensive about the software they’re working on.

I ran into a problem with cygwin’s SSHD implementation last week. In searching for the solution, I found this mail list answer:

  Wrong.  That is uninformed speculation and guesswork.  Stop
spreading misinformation.

  Cygwin SSHD has had the support for fully logging in as any
user since 1.7, as you have already been told and completely
ignored.  Go and read the manual.  The link was in the previous
email I sent in this thread.

  freesshd works exactly as Cygwin *used* to before it got
subauth support: when you log in with a key, rather than a
password, you just end up as an admin user.

Wow. This kind of answer is wrong on so many levels. First of all, while he makes it seem like the functionality has been there forever, cygwin 1.7 is still not even out of beta. The chance that an end user has it is about 0. So, with the current version (1.5),  supposedly cygwin sshd works just like freesshd. This is clearly false, because the original poster reports one working and the other not (which is, by the way, exactly the same results that I had).

So, a user reporting a problem about logging in gets pointed to a long documentation about security settings in a beta version, doesn’t understand a word from that document (no surprise there), and as a result gets told to “stop spreading misinformation”. Truth is, simply installed like any normal user installs applications, one works and the other doesn’t, something made quite clear by an answer from the original poster in a different place in the thread:

> Are you talking about password or public key authentication?
> If the latter, Have you tried the LSA authentication package
> in Cygwin 1.7?

I don't know. I'll try to deciper that. Sounds complicated. In
the meantime, friend is using freesshd.

The essence of what he’s saying (which has been completely missed by the cygwin developers) is that the effort required to get cygwin to work like one would reasonably expect of it is much higher than the effort required to just google for something that just works out of the box. The fact that you could potentially make it work is irrelevant, because he’s not getting any help actually making it work.

He might as well just have said, “I don’t care about making it work for you. It works for me.”

Software companies usually compensate for their complete lack of useful technical support with a good (or at least reasonably decent) amount of help documentation. Free software usually has neither.

I encourage any programmer to practice their technical skills on an open source project. But while you do so, take the opportunity to practice your people skills a bit as well, or why not your writing skills? Don’t be an open source douchebag — someone reporting your software’s flaws is not attacking you personally.

Taste these:

“He believes it proved that, even in a 21st century digital fantasyland, an ugly side of real-world human nature pervades, a side that oppresses strangers whose behavior strays from that of the mainstream.”

“Myers was stunned by the reaction, since he obeyed the game’s rules.”

“It started to not be fun,” said Myers, a video game aficionado. “I became the most hated, most reviled player.”

“He said his experience demonstrated that modern-day social groups making use of modern-day technology can revert to “medieval and crude” methods in trying to manipulate and control others.”

Someone actually grants funds for this nutcase? Hell, I could have told you all of those things at once, without the need to be a total dick to people for two years: There are social systems in any context that go above and beyond that of the rules and laws of the context. Yes, this goes for online communities as well. No, you wouldn’t be stupid enough to do that to someone if you weren’t online and anonymous.

I’d urge Mr. Myers to try it out AFK sometime. A subway train could be a good place, for instance (though I’m certainly open for other suggestions, these things are common). Place yourself in the middle of the doorway. Stand in the way of peolpe trying to enter or exit the train. If they move to sidestep you, follow to block the movement.

This is not illegal or against subway rules, but it will still make people really fucking angry. The social context tells you “don’t do that”, not because it causes people to become “medieval and crude” when they force their way past you violently, but because you’re being a real dick to people if you do.

People started out by asking kindly, but then stepped up their efforts to change his behavior as he ignored them. Like people under threat from abuse AFK, they first tried all the normal, appropriate ways of dealing with normal, reasonably sane people, but then had to go to extremes when this didn’t work.

This has nothing to do with him being a “stranger” (hint: everyone’s a stranger in an MMO), but with the fact that he was making their lives miserable to the best of his abilities.

In any game there will be things that are possible according to game rules, but forbidden due to social context. In Battlefield and other shooters, it’s spawn camping. In golf, it’s crossing another player’s line of putt on the green. In World of Warcraft, it’s ninjaing a target or piece of loot from other players. I could go on for a long time.

In the end, we come down to the simple fact that this guy gets paid for being a twat to people for two years, and tries to interpret it scientifically as some sort of bullying on their behalf.

There are plenty of interesting areas to research when it comes to games… games are still a young medium, and especially the social effects and interactions of MMOs are fascinating. So picking an area with slightly more relevance could be nice. Better teach this guy the basics of human psychology before letting him near another study, though.

I love being able to communicate with fans of the games I make, and I certainly won’t stop communicating on how to make the best games possible for all of you guys.

We do code reviews of all code that’s about to be checked in. It’s interesting to see the different approaches to code reviews different coders have. Many (especially junior) programmers tend to lack the self confidence required to go about a code review in an effective manner.

Let me explain that — why would a code review require self confidence? Well, a code review will go over a large amount of code at times, and your job as the reviewer is to find any question marks that might possibly cause any kind of trouble. This is, apparently, a problem for many programmers when they review the code of another (usually more senior) programmer, since pointing out potential errors or problems is seen as somewhat sensitive. I know many coders get very emotionally attached to their code.

You would think this should be something which happens only to junior programmers, but I’ve seen this happen with relatively senior programmers as well. It’s more about character than it is about experience I guess. The reasoning is “I don’t understand this, but this guy’s smart so it’s fine” or something similar, sometimes connected to how much code there is to go through and how long that would take.

However, the quality of a code review is directly proportional to how much you can disconnect your own respect for others. Your task is to understand everything you get shown, and to be the most nitpicking, hard-to-please obsessive-compulsive asshole the earth has ever seen for as long as the code review lasts.

Sound like something you don’t want to do? I hope so. But remember, you’re doing a service here… if there are bugs, someone is going to find them. We have QA people who specialize in finding bugs and piling them up on your desk, producers with a great attention to detail, and if nothing else you can bet someone will find it and it’ll end up on youtube. I don’t know about you, but at least I’d want to see my errors pointed out to me before I check them in.

So here are my tips for doing a code review:

• Understand everything. If you don’t understand something, make the reviewee explain it again in a different way. Chances are, you aren’t understanding because there’s something strange going on, or because what’s been done is unnecessarily complicated. Either way, if you don’t understand something you can’t guarantee that it’s right. Part of the purpose of a code review is for the reviewee to explain his thinking, and while doing so make for a possibility that he or she discovers errors as well.
• Be picky. Point out all details, from naming convention errors to coding standard misses to comment spelling errors. Whenever something gets checked in, the cost of changing it is a lot higher. Often the details may be the things that are wrong, and being picky forces you to notice such things.
• Look at everything. Resist the temptation to skip files where only small things have changed, but like I mentioned above, the details can often be what’s wrong. I can’t begin to count the amount of code reviews I’ve done where we’ve found inverted if conditions and equally dangerous things. The relevant code is simply a missing exclamation mark, but the consequences are far reaching, and if you had skipped the file because it had almost no changes in it, then you would have missed it.
• Endure. If you feel like you’re being a pain in the ass, think of it as a great favor since the amount of potential bugs you’re stopping is high. It’ll also act as an incentive for the reviewee to focus more on code quality for next time.

Think of yourself as the guardian of quality, personally responsible for the quality of the code you’re reviewing. Imagine that you’ll be the one yelled at if the code is broken, or the one who’ll be put to fix it.

The end result will be much higher quality code.

I went to Vancouver about a month ago, to visit EA Canada and among other things hold a presentation on part of our work. Quite a trip, I can tell you, considering that most of the time was spent travelling there and then back. I can also tell you that a sufficiently large family of which none speak English on a transatlantic flight is quite an adventure, but that’s a different story.

This story is about the presentation — and about what it taught me. Not because I’m the best presenter out there and I want to teach you all my secrets, but because the big secret is that most people holding presentations are just like you and me, they also lack the experience, and they’re just as terrified when they step up there to say the first word. My presentation went by pretty decently. I did many things right from the start, but I also learned quite a few of new things from it, and it’d be rather silly of me to not share that with you.

On a grand scale, people tend to be bunched up between the center notch of “uncomfortable” and the high extreme of “about to throw up” — most people just absolutely hate or fear presentations. There must be some deep hidden feature of the human psyche that makes any gathering of more than, say, 10 of your colleagues turn into something as intimidating as an invasion army. And knowing how silly this is does absolutely nothing to prevent it from affecting you.

Fortunately for me, Sweden, where I grew up, has understood this, and puts an incredible focus on presentations in public schools. Unfortunately for me, a very core part of holding a good presentation is to be extremely confident of what the hell it is you’re trying to tell people. You need to be seen as an authority to be believable and feel somewhat comfortable in what you’re saying. And while the exporting stats for Bolivia, the dates of historic battles in France and the thoughts and motives of Jonathan Swift may all be fascinating subjects, they’re not my area of expertize just because I just read my homework about it 7 times in a row.

My gut feeling is that the education just cements the students’ fears, by putting them in a position where it’s essentially utterly impossible to hold a good presentation. Maybe that’s a good thing in a way, because no matter how badly you perform when the time comes to hold a presentation on a subject you know about, there’s just no way it’ll ever be as bad as it was in school.

Anyway, where was I? Oh, yes, somewhere heading to Canada. So, several repetitions of putting all your belongings in a plastic box (your shoes as well please, sir) only to put them back on again (don’t forget your belt sir), I found myself in Vancouver about to deliver a presentation on a subject I actually knew and cared about. That’s quite a different beast, and in the whole process I became aware of a whole lot of things I’d otherwise ignored.

My company for the trip was one of the programmers from the Mirror’s Edge team, who was also about to hold a presentation, and who was nervous to the point of breaking down. My own nervousness has been somewhat masked by playing in a band on stage, practicing acting for a while and by a few years of talking to groups of people trying to coordinate them to slay the next big beast or a new set of opponents in various computer games, but it’s definitely still there. The key difference in this case was the fact that he was completely convinced that he didn’t have interesting content.

The first thing you need to realize when you step up there to deliver a presentation is that your audience, for one reason or another, are actually interested in hearing what you have to say. You always start out with a grand chance, as the audience will always assume the best of you before you start. That’s probably not what you wanted to hear as you stand there thinking you’re going to make everyone disappointed, but it also does mean that as long as you tell them new stuff, they’ll happily listen.

The next thing to do is prepare. Prepare so you know everything you could possibly be expected to say. Prepare so nothing but you matters, prepare for any problems that could possibly occur. This doesn’t mean learn a sequence of words by heart and then just speak them in sequence as you hold the presentation — it means be confident in all the material you have, and be ready to deliver it in any way and form.

For instance, the number one most common error I’d say is the reliance on technology — especially slides. Reading from your slides is always a really bad idea for a number of reasons, but there’s a different kind of slide addiction as well. If something goes wrong with your slides, make sure you have a way around it. I’ve seen presentations completely stall because of a video not playing, when the video wasn’t essential to the topic at all. Sure, it was a good visualisation of the subject at hand, but as someone in the audience I’m much more interested in the rest of the presentation than I am in someone trying to make PowerPoint perform a specific move.

Prepare for your slides being broken an unusable — have your vital images and videos in free form as a backup. And have some form of plan for what to do when that fails, as well. Think of how you’d present if the electricity failed and you were forced to hold your presentation in a circle of candle light. Will it impact on what you can show? Of course it does! But it should (almost) never stop you from holding a good presentation.

Even if everything goes the way it should, preparation is entirely vital. What I do when I finish writing a presentation is to boil it down to a few words per sentence or paragraph, and write those down on a separate piece of paper. Then I’ll hold the entire presentation alone using only those words as a memory. You’ll find that you remember a bit more, and some of the words are not really needed — so strike them out, write a new set of words. Hold the presentation again.

Sound like a painful procedure? Think it’s hard to hold a presentation only to yourself, listening to your own voice? Damn right it is. That doesn’t make it less vital. And if that sounded like a pain, check this out: Now continue repeating the process until you need no words at all. Hold the presentation without papers, and without ever turning to look at your slides. Practice this many times more — because when you step up there  to deliver the presentation for real, your mind turns everything which isn’t very deep in there to blank.

This is where I made my biggest mistake… I just simply didn’t have the time (or take the time) to do this, but ended up with some words on a few papers. Not many, but still this ties you to the place where your words happen to be… for me, it turned out to be a big problem because there was nowhere good for me to place the papers. The result was that I got stuck several times, and didn’t have the mental chart I needed to keep going without the words… had I practiced more, I’d definitely been able to do a  more free version of it, not being tied up to my papers awkwardly balanced somewhere.

The next thing to do is to listen to yourself (ouch). Nearly everyone hates this, and it can really put you in a state of total despair. Don’t let it — you need to listen to yourself hold the presentation, so you need to record it. It’s going to sound horrible, but that’s because most people don’t like the sound of their own voice as recorded. What you need to listen for is the words you get stuck on, the points where you go “ummmm… and then, ahh, well, you know…”

Everyone has those moments, but no one  knows about all of them. Now that you’ve identified them, practice on getting rid of them. Remember — being silent is fine. Remaining silent for a bit is a good punctuation, lets people ponder what you’ve just said for a bit. The only person in the room feeling awkward about it is you – so gather your thoughts for a bit, make sure what you’re going to say and then say it all in a flow.

Sound like a lot of practice and preparation? It is. Holding a presentation and making it good takes its time, and you need to be ready to invest that time if you’d like to hold a really good presentation. In a way, you’ll need to keep practicing in front of actual audiences to gain the experience that, in time. can give you that almost super-human ability to deliver good presentations displayed by people that end up on TED.

There’s so much more to say about this subject, but this post is already long enough. I’m sure I will return to it again, but for now I’ll leave you with some very good links with presentation wisdom.

Rands has written two pieces on holding and writing presentations that delve a bit deeper into some parts than I did here. The first one is called “How To Not Throw Up” and the second one is called “Out Loud“, and both are very interesting reads.

Scott Hanselman has posted his 11 Top Tips for a Successful Technical Presentation. Some of his tips are somewhat hard to think of for beginners, when your brain is panicking and all you can hear in your mind is “gahhhhhh”, but if you strive to become a great presenter, it’s a must-read.