Swizec Teller : Geek of the Week

Why do programmers work best at night? Is this related to the idea that drinking alcohol improves cognitive ability? Is programming a young person's game? How do you tackle spaghetti code and avoid job-burnout? Swizek Teller has achieved fame in providing a wry commentary on these questions, and the way that computers have come to dominate our lives.

Three years ago a young freelance programmer from Slovenia, Swizec Teller wrote a blog post, which put forward his ideas about why some programmers work better at night.

2169-swizec.jpg

His explanation was not so much about exploring the extremities of the human condition, rather a kind of light-hearted theatre aimed principally at programmers and those who live or work with them and explain why many people work better during the night than during the day.

His blog was so popular he published a book based on his experiences. Swizec is now much in demand, not so much as an after-dinner speaker (he’s too busy programming) but as a speaker at conferences and as a fixer of spaghetti code.


RM:
Swizec, the obvious question first, how did you become a programmer?
SZ:
When I was 7 my parents bought a book called Logo in Računalnik which translates to Logo and the Computer – it’s a children’s book about the history and inner workings of computers. That got me interested in computers. When I was about 9 I started learning programming at an extracurricular at school and I guess I just never stopped.
RM:
Ah, does that mean there is an IT background in your family or was the book an inspired guess from your parents?
SZ:
I think it was just a lucky guess. My dad was always interested in technology and since this was the late 80’s and early 90’s computers were the new big thing. I mean, I loved learning about how engines and gearboxes worked, so I guess they decided to give computers a shot.
RM:
Do you remember the first interesting programming you wrote?
SZ:
Wow, there were so many, but I think the first interesting thing I did was what I considered an operating system at the time. It was just a text-based GUI for MS-DOS that had all the common features you’d expect in Win95 – a notepad, calculator, file handling and so on.

I was 12 at the time and I remember having to learn how to use functions and procedures in Pascal because GOTO couldn’t jump far enough. There were also some 200 global variables for everything. Aptly named a,b,c, aa, bb, cc and so on. It was terrible, but it worked.

RM:
One of the aspects of the modern style of programming is that programmers have to absorb things quickly. How do you understand a big pile of code, none of which you’ve seen before?
SZ:
That depends a lot on how well written the code is! In an ideal world I could get away with understanding a small percentage of the code and having a plethora of well-named, clearly defined functions to fall back on. They would always do exactly what I expect them to do and I could focus on adding new features.

It’s almost like learning a new language really. You look at what the other programmers are doing and eventually come to understand their local dialect. The less you have to dig into the details to know what’s going on the better.

At the end of the day, the best approach is to poke around with print statements and calling random bits of code to see what they do.

RM:
You’ve had first-hand experience of Google and their asking puzzle questions in interviews. Do you think that’s a good approach? Is it a good way of identifying talented people?
SZ:
Maybe I got lucky or Google’s practices have changed, but I wasn’t asked any puzzle questions. At least none that seemed superfluous or contrived. All the questions I got were exactly what I’d expect to be doing as an engineer at Google – here’s a problem, solve it, tell us how you solved it.

That is to say, all the questions were solvable analytically. A real puzzle question cannot be solved without lateral thinking.

I’m not sure which is better, but puzzles that are completely disconnected from a real-world problem bore me and that makes me terrible at solving them.

RM:
Given how pervasive computers and software is do you think everybody needs to understand a bit about programming just to get along or understand the world they live in?
SZ:
Yes! I don’t think everyone should know how to code unless they really love it, but everyone should at least know what’s possible. There are too many people out there solving problems the old fashioned way simply because it doesn’t occur to them that a computer might be able to do that.

For instance, a lot of people still think fuzzy string matching is something computers can’t do.

RM:
A lot of people I’ve interviewed over the years got into computers because they just enjoyed it and because they felt it would change the world. Equally some of the people I talk to now say they’re depressed by how little they feel the world has changed as a result. How do you feel about that?
SZ:
Computers are definitely changing the world. Just look at all the people tapping away on smooth chunks of glass. Even sci-fi didn’t imagine computing being that ubiquitous!

But I do miss the enthusiasm around general artificial intelligence that existed in the 70’s (judging from what I’ve read). They thought it was just a matter of slapping together some prolog statements and voila! smart computers. Turns out creating a smart computer is much more difficult than and we might never get there.

We are raising the bar however, self-driving cars are slowly becoming road legal! How cool is that? We are definitely living in a sci-fi future right now.

RM:
In 2011 you wrote down a lot of assumptions about why programmers only work at nights? What was your conclusion and did this attract much support? And do you think it’s related to the mythical Ballmer Peak, where Steve Ballmer maintained that drinking alcohol improves cognitive ability which might itself be a variation of the Yerkes-Dodson law, which shows a correlation between arousal and erm performance?
SZ:
Yes, in 2011 I finally got fed up with people in my life misunderstanding my “strange” sleep-work cycle so I wrote an essay explaining why programmers like to work at night. Much to my surprise it garnered a huge response on the internet and I received numerous emails from people thanking me for helping them understand the programmer in their life.

Reasons for working at night are numerous and mostly have to do with distractions and the inner peace that comes from knowing nothing is going to distract you.

I am no longer sure about the Ballmer peak, but experience and research shows it is easier to power through boring tasks when your mind is just tired enough to stop running around in circles trying to find something exciting to do.

RM:
Do you think the way you can write text influences the way you write software? In other words has writing a book length essay helped you with writing software?
SZ:
It’s hard to say. Both writing and coding are about organising and decomposing your ideas so that you can explain them to another entity. A computer when you’re coding, a reader when you’re writing. So I’d say it goes hand in hand.
RM:
You say programmers tend to be more productive when working at night. What do you mean by productive in this sense?
SZ:
What I mean is that they solve more issues. Not necessarily write more code in terms of volume, but fix more bugs, add more features, stuff like that.
RM:
I’ve read your book and thought ‘Hang on, if all programmers end up working night and day how do they make their life work? All the things that aren’t their passion, how do they deal with finances and with their family and balancing it. Or is it the case of ‘To hell with everything else,’ and they just let it come crumbling down until they’ve got their work done?’
SZ:
As you can see with a lot of young people, especially when 20-somethings are running startups, they do say “To hell with everything” and just focus on work. Eventually they burn out and learn working like that isn’t sustainable.

In fact, an hour of work done when too tired means two hours of work fixing the mess you made.

The hidden reason I’m writing my book is tricking programmers into learning how to be productive without burning themselves out. A large part of which is realising you can only work a set number of hours per day, no matter where in the 24 hours you fit them.

RM:
Do you feel that have been times in your life where your programming ran amok to the detriment of other parts of your life? Do you think programming is a young person’s game?
SZ:
Yes, definitely! Programming always runs amok with other parts of my life. Sometimes I get a really good idea and the urge to work on it is so strong I forget to eat and sleep for two days. Then I crash and that basically ruins an entire week.

I don’t think programming is a young person’s game per se, but it’s important to guard your programming time viciously. People don’t understand you need a block of 3 or 4 hours to work in and they might call you annoying or bull-headed, even irresponsible, for taking that time and not letting anything distract you.

The less responsibilities you have, the easier taking that time is. Responsibilities tend to grow with age. But a lot of people do manage to pull it off, they’re the ones with results everyone else is in awe with.

RM:
What should young programmers learn from your experience of burning yourself out?
SZ:
Definitely that there’s more to life than work. Or at least, that there’s more to life than coding. As programmers we love code, but code is a tool to solve problems. It’s a means to an end. Our users don’t care how we solve their problem, just that we do.

And you’ll never be good at solving people’s problems, if all you think about is code. You have to go out there and experience life, talk to normal people, spend time understanding the problems they face. Only then will you be truly effective with your work.

Plus it’s relaxing to boot. Try taking a week off, you’ll be surprised how much more you get done when you’re back.

RM:
How do you define success in terms of your work?
SZ:
That’s a good question and I think it really depends. Sometimes success means closing a ticket in some task manager or another. Because that’s what the client cares about. Sometimes success is solving an important problem for a user. Other times it’s a reader leaving a comment or sending an email, saying that I’ve helped them understand themselves, their code, or their friend. Hell, sometimes success is just entertaining people.

But you always want to know what success means before you start. Otherwise you’ll never know you’ve finished.

RM:
Are you one of those programmer’s whose idea of relaxation is to come home from a day at work and sit down to work on someone else’s code?
SZ:
I used to be! But I find that the more time passes, the more I relax by doing things other than coding. My favourite these days is sport. I box, I run, I lift weights. It’s a good way to get away from the internet, which is a hard addiction for me to break.

But sometimes I do still stumble on a problem that consumes me. When that happens, writing code is extremely relaxing.