Our second interview unveils the thoughts of Linus Torvalds, a man who created the Linux kernel. Linux is an operating system kernel used by many Unix-like operating systems (like Ubuntu, Fedora, openSUSE and Debian GNU/Linux) and it is an excellent example of free/open source software. Linus Torvalds initiated Linux in 1991 and now acts as the project’s coordinator. Torvalds’ work is sponsored by The Linux Foundation.

How did you start your programming career?

It didn’t start as much of a “career”, it started when I was something like eleven or twelve, and my grandfather (on my mothers side) bought a computer.

He used it for incomprehensible calculations – he was a professor of statistics at the University of Helsinki – and he would write his BASIC programs for doing calculations on paper, and I’d help him type them in without really understanding any of it. Not to say that he didn’t try to teach me: I still remember him teaching me to do simplification of rational algebraic expressions, but even later on when I did math as a minor at university I never got into statistics.

I played around with the computer, though, typing in programs from computer magazines and books of the time, and eventually moving on from typing other peoples programs to doing my own. And switching from BASIC to assembly language (or rather – machine code, since I ended up assembling things by hand and eventually just being pretty good at just writing out the numbers directly) for performance reasons when I started doing games.

My games were always pretty bad, but my interest was never in the end result as much as in just making the computer do what I wanted. So the games would not be designed around game-play, but around some clever routine I’d written to move things around on the screen or whatever.

I moved on from that original VIC-20 computer, and moved on from writing crappy games, but when everything else changed the one thing that stayed constant was the fact that I kept writing my own programs for whatever need I had. And that I kept enjoying doing it.

Which programming languages, tools and frameworks do you utilize?

I work almost exclusively in C, since everything I do is pretty low-level systems programming. Even when I don’t work on the Linux kernel, I’m still working on code where performance and low-level details matter more than almost anything else.

My tools are similarly fairly spartan – no fancy development environment, just text editors, “make” and a compiler. My “graphical environment” is having a lot of windows of text open at the same time. One of which is my email window, which is arguably how I do most of my work – it’s less about programming and more about communication these days.

What are the best parts of programming?

To me, it’s just the mental challenge of writing code, but also figuring out where things went wrong when we get a bug report (especially one that can’t be easily reproduced, so that you have to figure things out on some fairly limited information).

And the communication. I like working with people, and while I sit alone in my downstairs office (my “basement lair”), it’s actually very social, since most of the issues require people to communicate to resolve.

What are the worst parts of programming?

The worst part is probably the frustration when some bug report just doesn’t have enough information to really even know where to start. We end up having to ignore those, until enough of them come in that some pattern emerges and you get a handle on it. But it can be very frustrating to know that something is going badly wrong, but there’s no way to really figure out what.

And the most frustrating part of that tends to be the social side, when the person who reports the problem is obviously also going to be very annoyed at it not getting fixed. Or just the frustration when working with other developers doesn’t work well – the social part of the development process is the most enjoyable one, but perhaps exactly for that reason it’s then also the most furstrating when it doesn’t work well.

There are times programming feels overwhelming and you can’t get anything done – how do you cope with it?

Usually I just take a break. It doesn’t happen all that often, and quite often it’s a matter of “ok, I’ll go upstairs, make myself a latte, and come back down in five minutes and then just work on something else for a while”.

Sometimes the five minutes might be a couple of hours, when I take a break to go outside or (more commonly) just go away and read a book for a while. The most common reason for that isn’t really frustration, though: it’s seldom that I really get that frustrated. So more commonly it’s about there being a few outstanding issues, but all the people working on them are in different timezones, and so there are times when I often end up just waiting for either a test-result or on people fixing a problem, and I just take a break because there’s no point in me sitting around the computer.

What is the optimal environment and time of day to get the best results?

That seems to be very different for people. In fact, it’s been different for me. Long ago, I used to pull a lot of all-nighters when I would be really “in the zone” and get a lot of programming done, and then I’d crash at 4AM or something. That works well for very intense sessions.

But these days, little of what I do is “intense programming sessions”, and most is about reading and writing email, and that’s different: I seem to do that mostly in the morning. So these days I have my most effective time between 8AM-noon. Part of it is the different work, but part of it is probably simply that with everybody spread out over the world, a lot of my work email comes in during the night, so int he morning I have that piled up, and then in the afternoon it’s more of a trickle of new reports and new code.

As to the environment – I don’t need much. I want it to be quiet, though. I hate noisy computers with a passion. I like my computers fast, but at the same time, noisy fans or even noisy clicking from some harddisks will just make me very irritated.

Oh, and one important environmental details: a big nice screen with lots of pixels, so that I can have lots of sharp text in several windows open at the same time.

How would you like to improve your programming skills?

I’m a big believer in learning by doing, so I think the best thing to do is to “just do it” like the Nike slogan said. But one of the things I occasionally think about is to try to do a different kind of project, and perhaps work on a higher level, or perhaps just with a different model of programming. I’ve been occasionally thinking about learning to “write hardware” instead of software – ie working with FPGA’s.

But realistically, I’ve got enough on my plate, so I’ve kept to the kernel and the few other projects I work on.

Do you comment your code?

Yes, but not very much. I’m a big believer in trying to write readable code, and comments aren’t part of that. Rather than write comments, I prefer using good variable and function naming, and work very hard at making my functions do one thing, and do it obviously (and have a name that explains what that function is).

So comments for me are relegated to when something surprising is going on, not to explain normal code.

Your message to ViopeProgramming.com users and other beginning programmers?

I’m not very good at the whole “message” thing. I didn’t get into programming because I planned it or had a vision, it all just happened. It’s hard to take away a “message” from that.

One thing I like to caution people against, though, is to not aim too high. I realize that sounds odd – people are often taught to try to aim for the stars, and even if you don’t succeed, maybe you’ll have gotten close, and if you aimed high enough, that may still be better than somebody who didn’t even try.

But I think that’s not true. People who aim too high not only miss the mark, but they’ll be frustrated by all the small details. And those small details matter a _lot_. I’ve never started a big project, for example. I’ve only started small projects, and then they have grown larger than I expected them to. And I think that’s a good way to do things: concentrate on the details that matter rather than looking for some lofty goal.

Thank you, Linus!

Tags: interview, linus torvalds, linux