How to become a hacker

There are two seperate and equally important parts to being a great programmer. You need absolute technical mastering of the technologies you use. But that’s the easy and boring part. The hard part is designing software so that it’s useful to the people using it.

I’ll present a lot of stuff here. Don’t be overwhelmed! You don’t have to learn everything at once. You don’t even have to learn everything I say here at all. But it does help to have some sense of direction in your adventures. That’s what I am trying to pass on.

Note: A hacker is a programmer. A cracker is a criminal.

The important part

Start right away by reading Alan Cooper’s

The Inmates are Running the Asylum

and

Philip and Alex’ Guide to Web Publishing. important books about how to design software today (they are, at least, to me). Cooper’s book is about software design in general. Philip’s book is focused on web programming and includes technical stuff. They’re both great eye-openers.

These are perhaps the two most

The bottom line is that you should focus on what the users of your software want to accomplish. Think as hard as possible about real users and their real needs, how you can anticipate and support them. Work hard to make the software and the computer work hard to help the users do what they want to do with as little effort and cognitive friction as possible. Help users in ways they never thought possible.

“No matter how cool you user interface, it was better if there were less of it” (Alan Cooper, About Face). Users don’t want to learn your user interface. They want to get a job done. You must know what job that is, what it takes, what the use situation is like, what the user is like. There is no substitute for knowing what goes through the user’s mind. This isn’t something that can be formalized. It takes empathy. You’ve got to be out there with her. See it with your users eyes.

When programmers face a design decision, the gut reaction is to refrain from making the choice and putting the burden on the user instead. Take use of screen real estate as an example. When programmers don’t know how to make best use of the user’s screen real estate, the gut reaction is to say “Oh well, we’ll just provide him a completely general mechanism to place all tool bars and menus arbitrarily and to redesign all menus and toolbars”. How many users do you know that does that with their MS Word? How many users you know have placed their Windows task bar anywhere else than along the bottom of the screen? None. Is that because everyone’s satisfied? No. The user still find the overuse of screen real estate annoying and wasteful, but spending time moving and rearranging toolbars is even more painful. It solves the wrong problem.

If your software needs a printed manual or a context-sensitive help system to use, you should go back to the drawing board and rethink it. I’m not saying you shouldn’t help your user. But contrary to mechanical items, computer software have the ability to explain themselves without breaking the flow. Help the user when necessary. Record relevant user behavior, learn as much as possible about the user, and let the software adapt itself to the user and the user’s situation. Don’t present options that aren’t relevant to the user.

The part that users couldn’t care less about

Now to the techinical part. It may sound like a lot, and of course it will take some time. But you’ll discover along the way, that it really is quite simple, if you take it one step at a time. You’ve probably been brought up to simultaneously think computers are easy (the Windows desktop) and at the same time immensely hard (troubleshooting the Windows desktop). But with the right tools and the right approach, you’ll hear yourself going “Whow! Is that all there is to it?!” over and over again.

For an example of that, try running

telnet www.amazon.com 80

in a Linux shell. Telnet will reply by saying

Trying 208.202.218.15...
Connected to www.amazon.com.
Escape character is '^]'.

Then write

GET / HTTP/1.0

followed by two returns, and watch what happens:

HTTP/1.1 302 Found
Date: Fri, 21 Jan 2000 09:41:59 GMT
Server: Stronghold/2.4.2 Apache/1.3.6 C2NetEU/2412 (Unix)
Location: http://www.amazon.com:80/exec/obidos/subst/home/home.html
Connection: close
Content-Type: text/html

followed by some HTML. Congratulations! You’ve just learned the basics of the HTTP protocol.

First step is to ditch everything with Microsoft’s name on it. Not because Microsoft is evil. But because Microsoft’s key vision is to shield users (including programmers) from the underlying technology. End users should be shielded from irrelevant technological aspects by designing software based on actual knowledge of the users and the use situation. Progammers should never be shielded from technology, because inevitably the programmer will run into some bug that can’t be solved on the upper, abstracted layer.

Install Linux on your Intel box. Not because Linux is the perfect operating system, but it’s one of the better, and it has a lot going for it. Take the time to learn to master all the command line utils and the inner workings, like configuration files and interaction between processes. Learn to master Emacs, the number one application you’ll be using. If you have a non-english keyboard, set it up, so the keys work like on a US keyboard. In the US keyboard setup, often used keys like <, >, [, ], {, }, /, |, \, ;, :, @, $, #, ”, ’, =, _, ?, etc., are placed so they’re much more easy to use.

Virtually every interesting computer program today is centered around networking, so you should also know about basic internet plumbing and learn key internet protocols, like TCP/IP, DNS, SMTP, HTTP. You don’t have to know everything about them, but you should have a solid idea of how they work and interact, so you can troubleshoot and learn more along the way. Key network command line utils like ssh, scp, wget, telnet, traceroute, whois and nslookup are also a necessity.

Along the same lines, you should seriously consider investing in a real internet connection. It’s still relatively expensive but just as a networked computer is a hundred times more useful than a standalone computer, an always-on internet connection is a hundred times more useful than a dial-up. No more annoying on-line/off-line dichotomy. The physical location of hardware, software and data becomes irrelevant.

Printing is outdated, so who needs word processors. Learn how to write casually in HTML by hand using Emacs, and use that for all your documents. If you really need printing, you can print from a browser. If you really need control over layout, you can learn LaTeX, which translates into Postscript, which in turn translates into a PDF.

If you’re going to build applications to support business, you’ll inevitably be using a RDBMS. Download free (for development) Oracle for Linux and learn how to do SQL and PL/SQL. Learn enough about administering to be able to troubleshoot and learn more as the need shows.

Programming languages are irrelevant. Which is why you should be familiar with at least ten and be able to do real programming in at least five. When you’ve reached that limit, you’ll realize that they’re all basically alike (they’re all turing machine capable), and you’ll be able to quickly determine which language is right for the job. Good candidates for languages to learn are C (but pray you’ll never have to use it), Java, Lisp, Tcl and bash scripts.

Integrated Development Environments

“But isn’t this business of hacking plain text files using an editor old-fashioned, now that we have visual development environments?” I hear you ask. No. Visual or integrated development environments like Visual Basic or Delphi solve the wrong problem. They assume that moving widgets around the screen with a mouse is easier than writing text in a text editor. And to a first approximation it is. But the visual environment shield you from what happens under the hood. If you’re a programmer you want to know what goes on under the hood. Eventually you’ll run into a bug where the upper layer doesn’t work as you expected. When that happens, there’s no alternative to debugging the actual code being executed, which is inevitably plain text source code. If you’re already familiar with that, you’ll find the bug much quicker.

What’s more important is that plain text files are easy to manipulate. Once you’ve learned the language in question, it’s much faster to use your favorite text editor (Emacs) to write the code by hand than drag widgets around the screen. Besides, there are a gazillion of tools that can do interesting things to plain text files. And writing up your own text-manipulating program is ridiculously simple. It’s easy to use grep to find every use of a specific function. It’s easy to use cvs for version control. It’s easy to edit remotely through a secure shell. If the source code is pure text, it’s easy to write a program that will output source code.

HTML is just plain text. That’s why it’s so easy to write a program that will output HTML. Bingo! You have a dynamic web site. SQL is just plain text, so it’s easy to write a program that will output SQL statements. There you go! You have a program that can do flexible queries in the database. If you really think you need a desktop user interface, there are programs that given a textual description in XML will produce the code that implement your GUI. Thus you can write a program that given a high-level description will produce the XML files, then translate those XML files into the actual code. That’s powerful.

Plain text files will never go out of fashion. They’re easy for humans to read and understand (as opposed to binary files), and they’re easy for computer to parse. Admittedly, a program operating on a carefully engineered binary format may perform slightly quicker. But programs are not primarily written for computers to execute. Programs should be written primarily for programmers to read and understand. Thanks to Microsoft’s CPU-consuming bloatware, Intel-processors are now so powerful and cheap that the performance loss is negligable. Programmer time is much more expensive than processor time.

I’ve experienced so-called programmers, living in a shielded world, that could spend a whole day figuring out how to manipulate the pathetic API of their bloatware of choice to do something as simple as select user_id from users where user_name=’larspind’. And to top that, he’d even, seriously, claim that the reason it was so hard, was because “in (product name) it’s so easy,” you can only use the functions they’ve decided to provide to you!