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!

4 comments

One slight error... You made the comment "Programmer time is much more expensive than processor time. ". Yes, programming time IS more expensive, but it's the expense of the company who is developing the product. CPU time is at the expense of the user. Basically all bloatware does is move the expense to the customer. This is similar to having products manufactured in china or taiwan...get the expense out of the hands of the manufacturer...and slip it to the customer in the form of poor quality. This is what I consider bloatware to be, a poor quality product. It's inefficient, it's unreliable, and it's slow. Why? Because they want to develop it cheaply, like any other crappy product. The first thing I do when I review a new product for purchase is dig into it to see if it's written in A) Foxpro B) Visual Basic or C) Access. All of these things generate an immediate no.
By Mike Wyre on Sun, Feb 13, 00 at 01:00 · Reply
  Cancel
Mmm..Mmm...good This is the kind of resposible, intelligent, objective writting that I like to see out there. I am a java/c programmer in the industry with a background with micorsoft languages as well. I esspecially appreciate the objective view on the microsoft platform, 'for users' not for programmers'. I am a practitioner of extreme programming methodologies and think that the overall premise of design over technical specifics (monkey work) is very sound and shifts the ephasis in the right place.
By John Thomas on Sun, Feb 13, 00 at 01:00 · Reply
  Cancel
I as at a internet cafe, i have interest in knowing everything about hacking and be making use of it. I just developed interest in it and i know quite alright that with your help i'll reach there. my E-mail address is foli_2@yahoo.com
By Samuel Folorunsho on Sun, Feb 13, 00 at 01:00 · Reply
  Cancel
I have interest and everything it takes to become an hacker.
By Samuel Folorunsho on Sun, Feb 13, 00 at 01:00 · Reply
  Cancel

Leave a comment