## What The Sims taught me about socialising

For the purposes of this article, socialising means having meaningful conversations and interactions with other people (namely friends). So what’s the trick to maintaining a fairly large network of friends while still holding meaningful conversations with all (or at least most) of them?

Hold parties. Or organise group outings. Any event that involves many people and activities that engage most of them together.

[image by Yuri Arcurs]

Before I started blogging, I hang out with a handful of friends. Which seem to coincide with 4, the number of friends a male can have on Facebook.

Granted, Facebook is an online social network. The reasons cited for the number are valid though. You can know many people, and once the criteria of “having 2-way meaningful conversations” come in, the number of “real” friends drop to a low number.

This is a limit on how much information about those friends a person can hold at any one time. Who are the friends of those friends, what are their favourite foods and activities, who are the mutual friends and so on.

I did some research and there’s Reed’s Law, which states that

the utility of large networks, particularly social networks, can scale exponentially with the size of the network

and there’s Metcalfe’s Law:

the number of unique connections in a network of a number of nodes (n) can be expressed mathematically as the n(n-1)/2

Regardless of the calculations involved, they just mean the value of a network grows faster than the increase in number of people involved. A social networking site might be able to hold this information. A human can’t scale as efficiently, hence the limit.

Back in my pre-blogging days, that period of time coincided with my student days. So there wasn’t a need to actively organise group outings. Just meeting up at school would do, with a few outings outside of school here and there.

Then came working life, and the people I associated with most often were my colleagues. Thus far, the interactions were face to face, or via phone calls and messages, or email (though infrequent).

But there’s a limit to those kinds of interactions because they were one to one (or one to few). Then something lit up in my brain from thinking about the game The Sims. In the game, the same social and “physical” limits on friendships are there.

In order to maintain friendships (there’s a friendship score), a Sim has to continually interact with other Sims. By calling them on the phone. By inviting them over to the house. And yes, by holding parties and going out on group outings.

So the most efficient way is to have a bunch of friends together, and interact with them all at once. Better suggestion? Have those friends interact with each other and have fun too.

And this might be why social networking sites are so popular now. They enable people to interact with a lot of other people at a fairly frequent rate. They enable people to find other people whom they’ve never met and start conversations and build friendships. There’s still a limit to how many “real” friends one can maintain, but it’s probably higher. This has the side effect of creating a lot more friends whom one interacts with infrequently. But I guess we can live with that.

With that, I’m stopping here. Let me know what you think. You can also have meaningful conversations with me on Twitter and Facebook.

## Weaving in the crowd

The crowds in shopping malls have always frustrated me. I’m not the type to meander around the corridors looking for bargains or sales. If I want to buy something, usually I already know what’s the item and where I can get it.

So I’ll arrive at the entrance of the shopping mall, and I know where the shop that has my desired item. It’s a straightforward point A to point B thing. But there are so many obstacles! I feel like I’m running an obstacle course, dodging one after another, stopping to let one pass, speeding up to avoid another. What are these obstacles?

My fellow human beings.

Judging from where I am, the right side of the corridor seems packed. So I move straight, and encounter a slowly moving elder. That’s easy, and I swerve around quickly to encounter…

The family of five. You never really know what kids will do. I’ve had experiences where I would be walking and minding my own business, and then out of nowhere two screaming children would materialise on my left and sprint in front of me to my right. So I swerve a bit more to my left to encounter…

The giddy teenagers, who just emerged from one of those trendy fashion stores. Don’t go near them, because they could suddenly point their fingers somewhere, and go “Oh look, ZARA!” and run enthusiastically toward said store. You need a wide buffer area to improve your chances of dodging their stampede. That, and their unforeseeable and inexplicable fits of high-pitched laughter. So swerving, I encounter…

The young parents with their 6 month old baby in a stroller. This one’s easy, because they will usually move very slow. The stroller also restricts their range of angular movement, so if it’s pointed one way, that’s the direction the parents are moving towards. Easy to predict the point they’ll reach in say, 2 seconds, which is the amount of time I have before I reach them. By which time, I’ll encounter…

The bored boyfriend. This one can be easy or hard, depending on where said boyfriend decides to wait out his girlfriend’s retail rampage in the store. If he decides not to be a free model for the store, he will move out a little onto the corridor. At which traffic will then flow around him and make my path that much harder. This one’s a bit more considerate, choosing to stand close to the store instead. Simple to pass through, and I’ll encounter…

The sentinels. They are a bunch of friends, laughing and talking. Quite ok actually, if not for the fact that their preferred battle formation is a single file moving horizontally. This isn’t a CSI search and comb; you don’t need to spread out into a line. If you want to maximise face time, the line is the worst formation. A circle is much better, like around a camp fire for example (haven’t they heard of complete graphs?). The worst thing is they’ll block a lot of the corridor, leaving you with very little maneuverability. They’re like the sentinels of some hidden treasure, who found an intruder, and are inexorably moving forward to crush the invader… Moving sharply to my left, I avoid them and finally reached my destination. *whew*

The above story was fictional. Well, I didn’t meet the characters all in one trip anyway… but they’re real. This is my long-winded way of saying, sometimes even if you know the destination, there are many unforeseen variables. Such as a software project. Ok, that analogy is a little weird…

I want to point out that, in order for me to successfully navigate around all the colourful characters who so innocently obstruct my path of least resistance, I have to read them. I have to read their body movement, posture and facial expressions to decipher what their likely directions of movement are.

That takes some practice, because you need to know that the person slowing down in front of you might change direction, or even stop completely. Of course, you will need to detect that the person is in fact slowing down…

I used to get angry because of the people blocking me. Why are they moving so slow? In time, I’ve learnt to control my anger. I’ve even turned it into a game of sorts. Here’s how you can play too.

At a moderately populated shopping mall, decide on a destination, preferably one that’s on the same level as your starting point. Your goal is to reach that destination at a more or less constant speed. Say your walking speed is 2 metres per second. You can speed up a little, or slow down a little, but you may not break into a run or stop completely.

This should test your knowledge of human behaviour, how good your reflexes are, whether you can adjust your route on the fly based on real-time data and so on. It also trains you to be more aware of your surroundings, your body position and posture, the length of your stride and so on.

I have 2 killer moves to help you: the shoulder slant and the side step. In the shoulder slant, you swivel one of your shoulders forward and the other backward. This way, you’ll be able to squeeze through some “cracks” in the obstacle run. Because sometimes, there’s never a good time, so when an opening appears, take it. With practice, you’ll learn which shoulder to swivel forward too, depending on situations (swivelling the left shoulder forward means the left foot is more natural to use for the forward leg).

The side step is particularly useful for when the idiot in front of you who don’t know where to go, decides to stop completely. At this point, you must rapidly decide if you want to go to the left or right of this confused and lost person. And then do a side step. Basically you open up your legs sideways. So instead of moving your leg forward in a normal step, you move it to the side.

You need to decide quickly because your momentum will carry you forward, and you don’t want to knock down the fella, right? Because of your forward momentum, there’s almost non-existent side-ways momentum. Thus if you move to the left, you must exert pressure on your right leg to “bounce” to the left. It takes a little practice…

Also, if you decide to go right, and your left foot is in front of you, then the natural movement is to move your right foot to the right in a wide split so as to avoid the now stationary person in front of you. Similarly for the decision to go left.

What if you decide to go right, and your right foot is in front? Uh, try to avoid this situation… Don’t try any fancy dance moves or you might entangle your legs and fall down. Just stop (and you’ll lose the game, but it’s better than public embarrassment). With some practice, you’ll learn to move in the direction based on the length of your stride and where your feet are.

And that’s some 1000+ words to tell you to be observant of human behaviour, to be conscious of your surroundings and to be aware of your body position and posture.

## When even screenshots fail

My best weapon for handling user queries is the screenshot.

User: Hey Vincent, I’ve got an error when doing X.
Me: Send me a screenshot.

User: Hi Vincent, sorry to disturb you. The application Y doesn’t work.
Me: Send me a screenshot.

Me: Send me a screenshot.

I’ve been fortunate in that I don’t have to educate my users on how to create a screenshot. Imagine the conversation with me describing where the PrintScreen button is…

User: Uh, how do I send you a screenshot?
Me: Just do a PrintScreen.
User: How do I do a PrintScreen?
Me: Just press the PrintScreen button.
User: What PrintScreen button?
Me: It’s a button on the top right corner of your keyboard, beside the Scroll Lock button.
User: Ok, I’ve pressed the PrintScreen button. Now what?
Me: Now send me the screenshot.
User: How do I do that?

I’d probably slam the phone down and throw it halfway across the hall.

### PDFs, Word documents and bitmap files

Anyway, even with the absence of the kind of inane conversation above, I still receive some interesting emails. I might receive an email with a PDF file. I open the PDF file and lo and behold, there’s a screenshot inside, all shiny and black and white and kinda fuzzy and grainy due to the warping from the PDF writing software.

Yes, there are users who are more adept at creating PDFs than Word documents.

Then there are screenshots where the user diligently took a capture of the screen. With the actual error obscured by another window.

Then there are the emails with a file size of 2 megabytes. Think bitmap file attachments with a resolution of 1024 by 768 pixels.

Then there are the clever users who took a screenshot, and to compress the file size, they dumped the contents into a Word document. Word automatically compresses the bitmap. I can’t blame them for not knowing how to use an image editor, even one as simple as Windows Paint. Didn’t get any fancy meta-screenshots, though I’ve gotten a screenshot in a PowerPoint file before.

Then there are the ultra-clever users who know how to take a screenshot, use an image editor to crop it, and *exclaim* save it as JPG or PNG. Even then there are problems. Let me first show you this:

If you’re familiar with ASP.NET, that’s everybody’s favourite error screen. It has useful data such as the general error message, the line of code where the error occurred and the stack trace. The stack trace contains information such as what events were triggered so you know for example, which button was clicked.

Now I have this web application with a loading screen, played out with an animated GIF image. And when there’s an error, something like this shows up:

I’m terrible at drawing stick figures… It’s supposed to be a stick figure searching for files in a file cabinet, and throwing any useless files behind him.

Well, my user sent me that. Most of the useful information was below the screen. So I asked her to scroll down so I could see them.

Me: Can you scroll down and resend the screenshot?
User: How to scroll down?
Me: Just use the scrollbar and scroll down.
User: What scrollbar?

That’s the compressed version of a few emails back and forth. I didn’t quite throw my phone across the hall, but I did take a deep breath and drink some water.

I accompanied that modified screenshot with more comments in my email. I can’t remember what I typed, so here’s the closest version:

Hi,

I’m sure the man throwing files all over the place is all very nice, but I can’t see the actual error below him. Please scroll down so I can see more of the error message.

Regards,
Vincent

Sometimes, you’re not just debugging code. You’re debugging human behaviour.

## Human-first software development

Aaron Falloon asked in a previous post if I could write something about the actual theory behind programming.

I don’t even know where to start. I have to assume that he’s referring to the non-coding aspects, because it feels like a philosophical question more than a technical one. So I thought hard. And I got an answer.

To fully explain the answer, I’m going to go deep in philosophy, so just bear with me for a while. Of all the species on Earth, humans are the only one actively and aggressively changing our surroundings. For the sake of argument, let’s take it that we do that to make things better, for us, for the environment, for every living creature.

Ignoring the Darwinian theory of evolution and the belief that we all sprang forth from the union of a single man and woman, Nature seems content to just let things go at their own pace. Have you seen a cat work hard? Albatrosses glide over miles and miles of open ocean, and they land only because of the need to procreate or to feed their young. Bristlecone pines live for millennia. Can you imagine doing nothing the entire day except grow a fraction of an inch?

Where was I? Right, so not only do we humans do something about our surroundings, we do it at an alarmingly fast rate. Buildings spring up like mushrooms. Cars are built so we travel faster. And then came computers and the need for programmers. The Internet exploded the transfer of information, and software is part of the driving force.

I believe it’s our basic nature to want to better ourselves and in relation, our surroundings. In the software development world, this means writing better programs. Perhaps because of the ubiquitous nature of the Internet, this gave the illusion that anyone can program. Everyone wants to program, because there’s the satisfaction of creation and the element (or illusion) of control. That the program will make our lives easier. It does, just not one created by anybody

So how do we become great programmers? One way is the UI-first approach. Design your user interface first, because it’s the only thing your users care about. Then work backwards towards the code.

And so my answer to the actual theory behind programming?(yes, finally!) It has always been about humans. Programming languages come and go. Paradigms, methodologies and Internet fads. Software development life cycles, from design to coding to testing to launching. All these variables are nothing compared to the human factor. We are the most unpredictable, and paradoxically the most important part.

The human factor is involved in estimating project deadlines. It’s why I see fresh graduates struggling with the corporate environment. It’s also why I seem to write stuff about human behaviour, such as observing a hungry youth, or the reluctance for authentication. There’s the importance of understanding user queries, placing ourselves in the user’s perspective before we jump to conclusions.

The study of human behaviour greatly benefits your skills as a programmer. Because ultimately, you’re creating programs to be used by humans (The Matrix and robotic artificial intelligence aside). To create great music software, it helps if you’re a musician. To create great blogging software, it helps if you’re a blogger. To create great image editing software, it helps if you’re a graphics artist.

Program errors aren’t about the program itself. It’s about the human between the computer and chair. It’s about the programmer’s misunderstanding of human behaviour.

20 years from now, we might not have to write code at all. We might be shuffling stuff on virtual screens like in Minority Report or The Matrix. But the human part is always there. So use a human-first software development approach.

## Forced to mingle

There was a recent company event. It was organised for the IT departments. It’s usually referred to as a dinner-and-dance or D & D (not to be confused with Dungeons and Dragons). We usually just do the first D (the dinner, not the dungeons). Everyone seems too tired at the end to do the second D.

My colleagues in my department are close-knit. There aren’t many of us anyway. So we assumed we’d be put together in the same table.

When we arrived at the event, we found that we’d been separated. 2 of us in that table, 3 of us in this table, and another 3 in another table. We were a bit miffed of course.

It’s not so much that we were separated. It’s that we were seated with people we don’t know. We were forced to mingle with people from other departments and teams. There’s nothing wrong with mingling. We just weren’t prepared to mingle.

So we went into the event room, sat down at our respective tables and started making small talk with the people at our own tables. Well, at least I made small talk with the person next to me.

Then something happened. People started changing seats. People found out where their friends were seated and a mass migration happened swiftly and quietly. It was kind of fun. So together with the 2 “known” colleagues from my table, we changed tables. The “new” table has *shock* everyone from our known clique!

I don’t know what the organisers had in mind when they rearranged everyone’s seating plans at the last minute. From what I knew, we were in the same table originally. It just shows how humans can behave when forced along some rule or restriction. Given a chance, we will find a way to rectify the situation.

So here’s a question for you to think about. When you design and write an application, do you force your users to be in an uncomfortable situation? Maybe a button that doesn’t make sense, but they have to click on it anyway. Maybe the flow of entering information doesn’t make sense, but they follow your flow because they have no choice.

## Reverting to base nature

This is an article on observation and human behaviour. Faced with a situation outside a person’s comfort zone, how will that person react? Can that person’s reactions tell you anything about his base nature?

### Handling hot tea

I read this in a detective comic book. In one of the episodes, there’s a senior detective giving tips to the protagonist, Q (yes, that’s his name). So the senior detective went about his activities while engaging Q in conversation. He casually prepared two cups of tea*, and served one to Q.

After Q drank his tea, the senior detective smiled and told Q that he had just given Q a quick test. He had deduced two pieces of information

• Q was right-handed
• Q was in a state of calm

When a person is (suddenly/unexpectedly/casually) given a cup of hot drink, in order to carefully handle the cup, the person uses the dominant hand (usually). Q had used his right hand to grab the handle.

When a person is sipping a cup of hot drink, to test the temperature and prevent scalding, the person usually relaxes his facial expression, and shows his real expression. Because of the focus on the hot drink, any false expressions used to mask his feelings disappear.

For example, a person is smiling at you. When that person sips a hot drink, and suddenly furrows his eyebrows and his lips sag a little downward, he may be worried about something, but puts on a happier front.

Because of sipping a hot drink, a person revealed his base nature.

* can’t remember if it’s tea or coffee.
And I don’t know if this is true. I haven’t conducted nearly enough observations to conclude…

### The truth trailing tough times

I’ve read and heard that one of the ways to determine if that special someone really fits you, is to go travelling with that person. Or go hiking, or camping, or any activity where both persons are under moderate stress.

Suddenly, one finds out how the other person handles flight delays, inconsiderate hikers, missing toothbrushes, a scratch, a cramp, and decisions affecting both persons. During tough times, a person’s base nature shows up.

Flight delays become “How about that cup of coffee?”, and cramps become “Well, at least the view here is beautiful. Ouch, ouch…”

Or missing toothbrushes become “How could you forget that? I distinctly remember telling you to bring it!”, and decisions affecting both persons become a one-sided dictatorship (Amazing Race had plenty of those).

### Coding under stress

What happens when you code under deadlines, under new and unheard of requirements, under strange and different environments? You revert to your base nature.

If you have bad coding practices, then under stress, those bad coding practices will show. If you’re lazy about debugging, then under stress, your programs are going to be chock full of bugs. If you’re plain terrible at programming, and had always relied on friends and colleagues, then under stress, well, somebody’s going to notice it.

For example, copying and pasting. I’m sure you had copied and pasted similar pieces of code, never mind the rule of reducing redundant code. This is where the base nature of a programmer shows. The disciplined programmer would copy and paste that code, then quickly go through each line to make sure it’s appropriate to the context (variable names, conditional checks and so on). The careless programmer would just give it a cursory check if it compiled.

The shortcut of manually typing out each line was taken to fulfill our innate programmer laziness. Yet it’s the understanding of the code copied and the actions taken after pasting, that distinguishes the better programmer.

Practise your desired qualities when in a calm state. Practise the use of `printf`s, `Console.WriteLine`s, `MessageBox`es or whatever can be used to display variable values. Practise spotting errors before your compiler does. Practise the use of your programming language constructs (how to loop, how to control decision branches) in a non-critical program under a non-critical state.

When your desired qualities become second nature to you, it’s still not enough. Because in the face of adversity, that second nature might still fall off. Practise until it becomes your base nature.

## Jumping to conclusions

In this age of information overload, our brains do a fantastic job of protecting us. By filtering and making assumptions. By jumping to conclusions. The thing is, sometimes they’re wrong, because the assumptions were based on past information, and may not apply to the present or the future.

We need to take rein and maintain a questioning mind.

### Do you season before you taste?

I people-watch. When I’m having meals, or a cup of tea, I notice people. Their facial reactions, body movements and hand gestures. Their speech patterns. What they’re wearing. Any accessories such as laptops or wooden paddles (students in dragon boat racing).

I noticed something when people eat. Most of them reached for seasoning and condiment, and added them into their food before even tasting it. I’ve seen people sprinkle chilli flakes on their pasta. I’ve seen a child scooping grated cheese and plopping it on his pizza. There were people who dump packets of sugar into their coffee or tea. My friend, the classic case, squeezed four packets of chilli sauce on his burger (and mayonnaise and tomato sauce if he could get away with it).

All of them added seasoning before taking a bite, a sip, a taste of the food.

After watching this phenomena and thinking it over, I realised it. All these people had already decided that whatever food that’s in front of them needed more seasoning, whether the food was great or not. Their ingrain habits of pre-seasoning had blinded them to the case where the food was great in the first place.

### The missing cursor

There’s this suite of Windows programs written in PowerBuilder that were passed down to me. There’s this quirk where the textboxes were too short in height. Because of this, even when the textbox was in focus, such as using the mouse to click on it, the familiar blinking cursor was still missing.

I had users who told me they could not edit the data in a textbox. I clicked on that textbox and hit the backspace button, the delete button and a random sequence of keys such as “asdf”. The textbox worked fine. The only thing missing was the blinking cursor and highlighted text to indicate the textbox was in focus.

There’s this particular case where I asked the user if she tried actually editing the data, like pressing the delete button. She said no. She had already assumed that because the blinking cursor was missing, that not only was the textbox not in focus, that it was also not editable. She didn’t even try editing in the first place.

### Debugging errors

Jumping to conclusions based on weak assumptions is dangerous when debugging program errors. Faced with an error, you already made the assumption that most of the program was working fine, that hopefully only a small part of the code was wrong. Then you slowly trace back to hopefully one line of code, fix that and be on your merry way.

Debugging is like mathematical proofs. Proofs start with assumptions. Once you’re convinced the assumptions are correct, you move on to getting further assumptions based on the original ones. You deduce results, come up with findings and finally a conclusion.

What if your original assumptions were wrong? Then the proof becomes useless other than an exercise in logical reasoning.

### Closing

Just to make it clear, I am for jumping to conclusions. Within reason of course. With experience, one can quickly come up with plausible causes for bugs, and act on correcting them. Sometimes I get an intuitive sense of trying out a solution over a few others. What you need to be aware of, is that you choose to be open to possibilities before closing in on your conclusions.

I understand that in French cuisine, it’s considered an insult to the chef if you add, say, tomato sauce to his dish. It doesn’t matter what you added. Just the act of adding something is an insult. It implies his food is not up to your standards, that it’s so tasteless that you need to enhance the food by adding something. Taste the food first. Don’t insult the chef by jumping to conclusions.

Pop quiz: See if you can figure this out. I found it in my math textbook in university.

Suppose there’s a barber who shaves only those who do not shave themselves. The question is, does the barber shave himself?