This is a referential piece of writing to catb or Cathedral and The Bazaar hacker files. I found these writings influential growing up in the computer space and feel like their influence still to this day has a foundational grip on me. So please come with me on this journey of How to Hacker. I hope this complete guide helps those young and old discover something new about themselves or re-kindle a love for the old web that maybe they lost.
Commonly in popular culture the depiction of a hacker is a black hood flaring over a laptop screen or a grained matrix style of "1" and "0"s falling across a green and black background. While this looks good in Hollywood movie drafts, it lays little value to real life. GNU/Linux users have Tux the penguin, BSD users have Beastie the daemon, but the closest thing to a consistent icon or image to represent the hacker is The Glider. The five dots in nine squares diagram that is seen above is called a glider. It is a simple pattern with some surprising properties in a mathematical simulation Conway's Game of Life that has fascinated hackers for many years. Clear, abstract, and a bit mysterious. This has been and most likely will be a cleanest and closest thing to a flag or emblem to represent all hacker culture.
The most basic and straightforward definition of a hacker is having to do with technical adeptness and a delight in solving problems and overcoming limits. If you want to know how to become a hacker, though, only two are really relevant. There is a community, a shared culture, of expert programmers and networking wizards that traces its history back through decades to the first time sharing minicomputers and the earliest ARPAnet experiments. The members of this culture originated the term ‘hacker’. Hackers built the Internet. Hackers made the Unix operating system what it is today. Hackers make the World Wide Web work. If you are part of this culture, if you have contributed to it and other people in it know who you are and call you a hacker, you are a hacker.
The hacker mind set is not confined to this software hacker culture. There are people who apply the hacker attitude to other things, like electronics or music. You can find it at the highest levels of any science or art. Software hackers recognize these kindred spirits elsewhere and may call them ‘hackers’ too, and some claim that the hacker nature is really independent of the particular medium the hacker works in. But in the rest of this document we will focus on the skills and attitudes of software hackers, and the traditions of the shared culture that originated the term ‘hacker’. People breaking with traditional long formed methods to form their own technical shortcuts, break down a system to hack together something more efficient, or cobbling together a system to share with others that would otherwise be pay-walled or restricted to the masses by overly complex technical know-how or cooperate locks.
There is another group of people who loudly call themselves hackers, but are a part of a criminal subculture of hackers. These are people who get a kick out of breaking into computers and phreaking the phone system. Scammers and the like I would also consider fall into this category by using Social Engineering techniques against elderly and similar. Real hackers call these people ‘crackers’ and want nothing to do with them. Real hackers mostly think crackers are lazy, irresponsible, and not very bright, and object that being able to break security does not make you a hacker any more than being able to hot-wire cars makes you an automotive engineer. Unfortunately, many journalists and writers have been fooled into using the word ‘hacker’ to describe crackers; this irritates real hackers no end.
The basic difference is this: hackers build things, crackers break them.
Those who want to be a hacker, feel free to read deeper for more information. For those wanting to learn cracking, there is many a basic tutorial on YouTube that will land you in prison. Feel free to look deeper there. For those in between I have tutorials here that can guide you deeper into the hacker mind-set while maintaining a moderate level of technical know-how.
Hackers solve problems and build things, and they believe in freedom and voluntary mutual help. To be accepted as a hacker, you have to behave as though you have this kind of attitude yourself. And to behave as though you have the attitude, you have to really believe the attitude. Being a hacker is being a part of a community of makers and doers. People who wonder not only if something works, but how it works. Innovation and creation. But if you think of cultivating hacker attitudes as just a way to gain acceptance in the culture, you will miss the point. Becoming the kind of person who believes these things is important for you, for helping you learn and keeping you motivated. As with all creative arts, the most effective way to become a master is to imitate the mindset of masters, not just intellectually but emotionally as well. There are some you can aspire to replicate in this journey.
The Apollo 17 mission is my personal landmark for this mindset. Commander Eugene “Gene” Cernan and Lunar Module pilot Harrison “Jack” Schmitt explored the lunar surface while Ron Evans remained in the Command Module, America. While on the surface, Cernan and Schmitt deployed various science experiments across their landing site, making essential use of their Lunar Rover Vehicle (LRV). However the LRV had a collection of issues that it simply was not designed to deal with, mainly dust, dust compounded in every crack and crevice of the LRV causing fenders and bumpers to fall off. The dust was of tough to deal with that there was a good possibility to call off the mission to explore the moon's surface. But American gray duct-tape saves the day. The dust was too thick to simply apply the tape to the rover and fix it's fallen off parts. But using scrapped maps and terry cloth the astronauts were able to recreate the fenders and mold the tape around them to stick. This kind of intuitive engineering is what hacker culture is all about. Fixing a million dollar Lunar Rover with thousands of man hours behind the design with duct-tape. Simple and elegant.
To further express this is a Zen poem
To follow the path: look to the master, follow the master, walk with the master, see through the master, become the master.
Being a hacker is lots of fun, but it is a kind of fun that takes lots of effort. The effort takes motivation. Successful athletes get their motivation from a kind of physical delight in making their bodies perform, in pushing themselves past their own physical limits. Similarly, to be a hacker you have to get a basic thrill from solving problems, sharpening your skills, and exercising your intelligence. If you are not the kind of person that feels this way naturally, you will need to become one in order to make it as a hacker. Otherwise you will find your hacking energy is sapped by distractions like sex, money, and social approval. (You also have to develop a kind of faith in your own learning capacity, a belief that even though you may not know all of what you need to solve a problem, if you tackle just a piece of it and learn from that, you will learn enough to solve the next piece, and so on, until you are done.)
Creative brains are a valuable, limited resource. They should not be wasted on reinventing the wheel when there are so many fascinating new problems waiting out there. To behave like a hacker, you have to believe that the thinking time of other hackers is precious, so much so that it's almost a moral duty for you to share information, solve problems and then give the solutions away just so other hackers can solve new problems instead of having to perpetually readdress old ones. Note, however, that "No problem should ever have to be solved twice." does not imply that you have to consider all existing solutions sacred, or that there is only one right solution to any given problem. Often, we learn a lot about the problem that we did not know before by studying the first cut at a solution. It is okay, and often necessary, to decide that we can do better. What is not okay is artificial technical, legal, or institutional barriers (like closed-source code) that prevent a good solution from being reused and force people to reinvent wheels.
(You do not have to believe that you are obligated to give all your creative product away, though the hackers that do are the ones that get most respect from other hackers. It is consistent with hacker values to sell enough of it to keep you in food and rent and computers. It is fine to use your hacking skills to support a family or even get rich, as long as you do not forget your loyalty to your art and your fellow hackers while doing it.)
Hackers (and creative people in general) should never be bored or have to drudge at stupid repetitive work, because when this happens it means they are not doing what only they can do, solve new problems. This wastefulness hurts everybody. Therefore boredom and drudgery are not just unpleasant but actually evil. To behave like a hacker, you have to believe this enough to want to automate away the boring bits as much as possible, not just for yourself but for everybody else (especially other hackers).
(There is one apparent exception to this. Hackers will sometimes do things that may seem repetitive or boring to an observer as a mind clearing exercise, or in order to acquire a skill or have some particular kind of experience you can not have otherwise. But this is by choice nobody who can think should ever be forced into a situation that bores them.)
Hackers are naturally anti-authoritarian. Anyone who can give you orders can stop you from solving whatever problem you're being fascinated by and, given the way authoritarian minds work, will generally find some appallingly stupid reason to do so. So the authoritarian attitude has to be fought wherever you find it, lest it smother you and other hackers. (This is not the same as fighting all authority. Children need to be guided and criminals restrained. A hacker may agree to accept some kinds of authority in order to get something he wants more than the time he spends following orders. But that is a limited, conscious bargain, the kind of personal surrender authoritarians want is not on offer.)
Authoritarians thrive on censorship and secrecy. And they distrust voluntary cooperation and information sharing, they only like ‘cooperation’ that they control. So to behave like a hacker, you have to develop an instinctive hostility to censorship, secrecy, and the use of force or deception to compel responsible adults. And you have to be willing to act on that belief.
To be a hacker, you have to develop some of these attitudes. But copping an attitude alone will not make you a hacker, any more than it will make you a champion athlete or a rock star. Becoming a hacker will take intelligence, practice, dedication, and hard work. Therefore, you have to learn to distrust attitude and respect competence of every kind. Hackers will not let posers waste their time, but they worship competence, especially competence at hacking, but competence at anything is valued. Competence at demanding skills that few can master is especially good, and competence at demanding skills that involve mental acuteness, craft, and concentration is best.
If you revere competence, you will enjoy developing it in yourself, the hard work and dedication will become a kind of intense play rather than drudgery. That attitude is vital to becoming a hacker.
The hacker attitude is vital, but skills are even more vital. Attitude is no substitute for competence, and there is a certain basic toolkit of skills which you have to have before any hacker will dream of calling you one. This toolkit changes slowly over time as technology creates new skills and makes old ones obsolete. For example, it used to include programming in machine language, and did not until recently involve HTML. But right now it pretty clearly includes the following...
This, of course, is the fundamental hacking skill. If you do not know any computer languages, I recommend starting with Python. It is cleanly designed, well documented, and relatively kind to beginners. Despite being a good first language, it is not just a toy; it is very powerful and flexible and well suited for large projects. Most of my early and current programs are in python, while given some grief for being a large and bloated language, I will always continue to use python for my quick projects and easy needs. Good tutorials are available at the python web site, there is an excellent third party one at Computer Science Circles. An additional set pair of languages that are highly recommended is C and LISP. I have sang many praises of the LISP language when referring to emacs.
There is perhaps a more general point here. If a language does too much for you, it may be simultaneously a good tool for production and a bad one for learning. It is not only languages that have this problem, web application frameworks like RubyOnRails, CakePHP, Django may make it too easy to reach a superficial sort of understanding that will leave you without resources when you have to tackle a hard problem, or even just debug the solution to an easy one. A better alternative to Java is to learn Go. It is pretty easy to move to from Python, and learning it give you a serious leg up on the possible next step, which is learning C.
If you get into serious programming, you will eventually have to learn C, the core language of Unix. C++ is very closely related to C, if you know one, learning the other will not be difficult. Neither language is a good one to try learning as your first, however. And, actually, the more you can avoid programming in C the more productive you will be. C is very efficient, and very sparing of your machine's resources. Unfortunately, C gets that efficiency by requiring you to do a lot of low level management of resources (like memory) by hand. All that low level code is complex and bug prone, and will soak up huge amounts of your time on debugging. With today's machines as powerful as they are, this is usually a bad trade off, it is smarter to use a language that uses the machine's time less efficiently, but your time much more efficiently. Thus, Python.
But be aware that you will not reach the skill level of a hacker or even merely a programmer simply by accumulating languages, you need to learn how to think about programming problems in a general way, independent of any one language. To be a real hacker, you need to get to the point where you can learn a new language in days by relating what is in the manual to what you already know. This means you should learn several very different languages. Finding good code to read used to be hard, because there were few large programs available in source for fledgling hackers to read and tinker with. This has changed dramatically, open-source software, programming tools, and operating systems (all built by hackers) are now widely available. Which brings me neatly to our next topic...
Since a majority of the world now has access to personal computers whether it be a desktop or laptop (take a moment to appreciate how much that means. The hacker culture originally evolved back when computers were so expensive that individuals could not own them). The single most important step any newbie can take toward acquiring hacker skills is to get a copy of GNU/Linux or one of the BSD-Unixes, install it on a personal machine, and run it. Yes, there are other operating systems in the world besides Unix. But they are distributed in binary, you cannot read the code, and you cannot modify it. Trying to learn to hack on a Microsoft Windows machine or under any other closed source system is like trying to learn to dance while wearing a body cast.
Unix is the operating system of the Internet. While you can use the Internet without knowing Unix, you cannot be an Internet hacker without understanding Unix. For this reason, the hacker culture today is pretty strongly Unix centered. So, bring up a Unix, I like GNU/Linux myself but there are other ways. Learn it. Run it. Tinker with it. Talk to the Internet with it. Read the code. Modify the code. You will get better programming tools (including C, LISP, Python, and Perl) than any Microsoft operating system can dream of hosting, you will have fun, and you will soak up more knowledge than you realize you are learning until you look back on it as a master hacker.
A good way to dip your toes in the water is to use a Live USB image, where the entirety of the operating system runs from the USB and RAM without changing anything on the native hard-drive. I have written extensively on the subject of GNU/Linux as an introduction to the system. and if you want to learn about Live USBs I have also written quite a bit about them as well. Finally if you are not quite sure what to choose I have a complete distribution list. to help out as well.
Most of the things the hacker culture has built do their work out of sight, helping run factories and offices and universities without any obvious impact on how non-hackers live. The Web is the one big exception, the huge shiny hacker toy that has changed the world, for better or for worse, is still debatable. For this reason alone (and a lot of other good ones as well) you need to learn how to work the Web.
This does not just mean learning how to drive a browser (anyone can do that), but learning how to write HTML, the Web's markup language. If you do not know how to program, writing HTML will teach you some mental habits that will help you learn. So build a home page. But just having a home page is not anywhere near good enough to make you a hacker. The Web is full of home pages. Most of them are pointless, zero-content sludge, very snazzy looking sludge, mind you, but sludge all the same. To be worthwhile, your page must have content, it must be interesting and/or useful to other hackers. Write about what you know, drop the social media snippets about nothing and write something that someone can find worth while. You can add your own flare or daily reader's digests. But you are on a journey, write about the experience. It will help you grow more fully into the hacker role and help process that information along the way.
As an American and native English speaker myself, I have previously been reluctant to suggest this, lest it be taken as a sort of cultural imperialism. But several native speakers of other languages have urged me to point out that English is the working language of the hacker culture and the Internet (with some others being German and Russian), but English tends to be the primary language all internet cultures tend to lean toward, and that you will need to know it to function in the hacker community.
Many hackers who have English as a second language use it in technical discussions even when they share a birth tongue; it was reported to me at the time that English has a richer technical vocabulary than any other language and is therefore simply a better tool for the job. For similar reasons, translations of technical books written in English are often unsatisfactory (when they get done at all). On the other hand I also urge many that have English as the primary language, learn a second language. It does not have to be complex. But keeping those pathways of your brain active is imperative to learning programming languages not only from a technical standpoint but from an artistic / linguistic one as well.
Linus Torvalds, a Finn, comments his code in English (it apparently never occurred to him to do otherwise). His fluency in English has been an important factor in his ability to recruit a worldwide community of developers for Linux. It is an example worth following. Being a native English speaker does not guarantee that you have language skills good enough to function as a hacker. If your writing is semi-literate, ungrammatical, and riddled with misspellings, many hackers (including myself) will tend to ignore you. While sloppy writing does not invariably mean sloppy thinking, we have generally found the correlation to be strong, and we have no use for sloppy thinkers. If you cannot yet write competently, learn to.
Like most cultures without a money economy, hackerdom runs on reputation. You are trying to solve interesting problems, but how interesting they are, and whether your solutions are really good, is something that only your technical peers or superiors are normally equipped to judge. Accordingly, when you play the hacker game, you learn to keep score primarily by what other hackers think of your skill (this is why you are not really a hacker until other hackers consistently call you one). This fact is obscured by the image of hacking as solitary work, also by a hacker cultural taboo (gradually decaying since the late 1990s but still potent) against admitting that ego or external validation are involved in one's motivation at all.
Specifically, hackerdom is what anthropologists call a gift culture. You gain status and reputation in it not by dominating other people, nor by being beautiful, nor by having things other people want, but rather by giving things away. Specifically, by giving away your time, your creativity, and the results of your skill. There are basically five kinds of things you can do to be respected by hackers...
The first (the most central and most traditional) is to write programs that other hackers think are fun or useful, and give the program sources away to the whole hacker culture to use. (We used to call these works “free software”, but this confused too many people who were not sure exactly what “free” was supposed to mean. Most of us now prefer the term “open-source” or "libre" software). Hackerdom's most revered demigods are people who have written large, capable programs that met a widespread need and given them away, so that now everyone uses them.
But there is a bit of a fine historical point here. While hackers have always looked up to the open-source developers among them as our community's hardest core, before the mid-1990s most hackers most of the time worked on closed source. It took the mainstreaming of open-source software after 1997 to change things. Today, "the hacker community" and "open-source developers" are two descriptions for what is essentially the same culture and population, but it is worth remembering that this was not always so.
They also serve who stand and debug open-source software. In this imperfect world, we will inevitably spend most of our software development time in the debugging phase. That is why any open-source author who is thinking will tell you that good beta-testers (who know how to describe symptoms clearly, localize problems well, can tolerate bugs in a quickie release, and are willing to apply a few simple diagnostic routines) are worth their weight in rubies. Even one of these can make the difference between a debugging phase that is a protracted, exhausting nightmare and one that is merely a salutary nuisance. If you are a newbie, try to find a program under development that you are interested in and be a good beta-tester. There's a natural progression from helping test programs to helping debug them to helping modify them. You will learn a lot this way, and generate good karma with people who will help you later on.
Another good thing is to collect and filter useful and interesting information into web pages or documents like Frequently Asked Questions (FAQ) lists, and make those generally available. Maintainers of major technical FAQs get almost as much respect as open-source authors. As I mentioned above, make a website. Completing a project and publishing it is great, writing about the process and how you maintained it also helps those on their journey as well. Write about things that interest you.
The hacker culture (and the engineering development of the Internet, for that matter) is run by volunteers. There is a lot of necessary but unglamorous work that needs done to keep it going, administering mailing lists, moderating newsgroups, maintaining large software archive sites, developing RFCs and other technical standards. People who do this sort of thing well get a lot of respect, because everybody knows these jobs are huge time sinks and not as much fun as playing with code. Doing them shows dedication.
Finally, you can serve and propagate the culture itself. For example, writing an accurate primer on how to become a hacker. This is not something you will be positioned to do until you have been around for while and become well known for one of the first four things. The hacker culture does not have leaders, exactly, but it does have culture heroes and tribal elders and historians and spokespeople. When you have been in the trenches long enough, you may grow into one of these. Beware, hackers distrust blatant ego in their tribal elders, so visibly reaching for this kind of fame is dangerous. Rather than striving for it, you have to sort of position yourself so it drops in your lap, and then be modest and gracious about your status.
Contrary to popular myth, you do not have to be a nerd to be a hacker. It does help, however, and many hackers are in fact nerds. Being something of a social outcast helps you stay concentrated on the really important things, like thinking and hacking. For this reason, many hackers have adopted the label ‘geek’ as a badge of pride, it is a way of declaring their independence from normal social expectations (as well as a fondness for other things like science fiction and strategy games that often go with being a hacker). The term 'nerd' used to be used this way back in the 1990s, back when 'nerd' was a mild pejorative and 'geek' a rather harsher one; sometime after 2000 they switched places, at least in U.S. popular culture, and there is now even a significant geek pride culture among people who are not techies.
If you can manage to concentrate enough on hacking to be good at it and still have a life, that is fine. Mainstream culture is much friendlier to tech nerds now. If you're attracted to hacking because you do not have a life, that is okay too, at least you will not have trouble concentrating. Developing skills and being a mutual member of a community will help you come out of your social bubble, you will have the opportunity to make friends and experience the fun of cooperation on a learning environment.
Again, to be a hacker, you have to enter the hacker mindset. There are some things you can do when you are not at a computer that seem to help. They are not substitutes for hacking (nothing is) but many hackers do them, and feel that they connect in some basic way with the essence of hacking.
The more of these things you already do, the more likely it is that you are natural hacker material. Why these things in particular is not completely clear, but they are connected with a mix of left and right brain skills that seems to be important. Hackers need to be able to both reason logically and step outside the apparent logic of a problem at a moment's notice. Work as intensely as you play and play as intensely as you work. For true hackers, the boundaries between "play", "work", "science" and "art" all tend to disappear, or to merge into a high level creative playfulness. Also, don't be content with a narrow range of skills. Though most hackers self describe as programmers, they are very likely to be more than competent in several related skills, system administration, web design, and PC hardware troubleshooting are common ones. A hacker who is a system administrator, on the other hand, is likely to be quite skilled at script programming and web design. Hackers do not do things by halves, if they invest in a skill at all, they tend to get very good at it.
Finally, a few things not to do.
The only reputation you will make doing any of these things is as a twit. Hackers have long memories, it could take you years to live your early blunders down enough to be accepted. The problem with screen names or handles deserves some amplification. Concealing your identity behind a handle is accepted in some spaces but please be aware this is an identity, keep it classy. In the hacker culture it will only mark you as a loser.
The “hacking” we will be talking about in this document is exploratory programming in an open-source environment. If you think “hacking” has anything to do with computer crime or security breaking and came here to learn that, you can go away now. There is nothing for you here. Hacking is primarily a style of programming, and following the recommendations in this document can be an effective way to acquire general purpose programming skills. This path is not guaranteed to work for everybody, it appears to work best for those who start with an above average talent for programming and a fair degree of mental flexibility. People who successfully learn this style tend to become generalists with skills that are not strongly tied to a particular application domain or language.
Note that one can be doing hacking without being a hacker. “Hacking”, broadly speaking, is a description of a method and style; “hacker” implies that you hack, and are also attached to a particular culture or historical tradition that uses this method. Properly, “hacker” is an honorific bestowed by other hackers.
Hacking does not have enough formal apparatus to be a full fledged methodology in the way the term is used in software engineering, but it does have some characteristics that tend to set it apart from other styles of programming.
The hacking style has been closely associated with the technical tradition of the Unix operating system. It has become evident that hacking blends well with the “agile programming” style. Agile techniques such as pair programming and feature stories adapt readily to hacking and vice-versa. In part this is because the early thought leaders of agile were influenced by the open source community. But there has since been traffic in the other direction as well, with open-source projects increasingly adopting techniques such as test driven development.
Learning to compose music has three stages. First, you have to learn the basic mechanical technique of an instrument, fingering and how to play scales. Then you have to train your ear to understand musical patterns. Finally, you must learn how to recombine musical patterns into original creations. Hacking is similar.
The hacking equivalent of fingering is learning the capabilities of programming languages, and the mechanics of using tools like editors, interpreters, and compilers. We will not cover those mechanics here as they vary too much according to what language you are using. Tutorials for all the languages you might want to use are available online. The equivalent of playing scales is writing small programs, alone. Unfortunately, playing scales A: Does not teach you anything about music, and B: Is boring as hell. Similarly, writing toy programs does not tend to teach you much about hacking, and A: Will tend to de-motivate you unless the program immediately solves a problem you care about.
Most formal programming instruction gets to playing scales and stops. Thus, it tends to produce coders who are poor at collaborating with each other and have the equivalent of no ear for music, a poor feel for software design and architecture.
There is a better way to learn. I call it the incremental hacking cycle.
1) Pick a program that does something you are interested in. Ideally, it should be a program you use regularly and have opinions about. The next best thing is a program you do not normally use, but that does something you think is interesting. For this learning method to work, you should avoid trying to hack on code that bores you. The program you choose does not have to do anything serious. Many programmers have honed their skills by improving games that they enjoyed. The only drawback to this is that modern games are often quite large and complicated, and may be beyond the grasp of a raw beginner. For this reason, you may want to investigate one of the classic text oriented games that still survive, net-hack is a prime example, and there are many others.
2) If you do not already know the program, learn how to use it. Read the documentation. Develop a mental model of how it works.
3) Pick a small feature to change or add.
4) Search the code until you find the part you need to modify. Note: you should specifically not try to read the entire program. You will just exhaust and frustrate yourself if you do that. Instead, use the module structure of the code to zero in on just the part you need to understand. Along the way, you will learn things about how the whole program fits together. It is a good exercise to add explanatory comments and notes to the code as you figure out things about it. This will help your memory, and will help you organize your thoughts as well.
5) Make, test, debug, and document your change. Documenting your change is important. If you develop the habit of doing this early, you will produce much higher quality work.
6) Send your change as a patch to the program maintainers. Sometimes your patches will be rejected. You need to learn to cope with this. It does not mean you are doomed to fail in your quest, usually what it does mean is that you have not read the code carefully enough, or you have missed something important about the culture and practices of the development group you are trying to contribute to. These mistakes can be repaired.
7) Now, ask yourself "Do I understand this entire program?" If yes, you are done. If "No", go back. This time, pick a different and perhaps slightly more difficult thing to change.
The point of this exercise is to learn how to sneak up on the problem of understanding a program, rather than trying to tackle all of the complexity at once. As you go through this loop several times, you will gradually develop a more complete representation in your mind of the way the whole program fits together. At some point you will reach a threshold where you understand it all or anyway enough of it for whatever your final purpose is.
To train yourself, start small. If possible, first do the incremental hacking cycle as an exercise on very small programs or scripts, 10-50 lines. These may be hard to find, as most programs of any use are larger than this. Most programs this small are scripts in shell, Perl, Python, or Tcl; that is a trait to look for when trawling the Web for them. When you have done the incremental hacking cycle on several very small programs (or if you are unlucky enough to not find any suitable very small ones), try it on slightly larger programs. Look for code bases in the range of 100-500 lines. When you master that level, go to the order of magnitude, 1000-5000 lines. By the time you master the 1K-5K level, you will have entered the bottom end of the capability range of what is usually considered a skilled programmer.
At or before the 1K-5K level, you should occasionally begin to notice that you are having itches to change the structure or organization of a program, not just its features. You may find yourself thinking “This code is ugly” and having feelings about making it prettier and cleaner. When this happens, pay attention. This is your design sense trying to wake up. Do not rush to patch in another feature. Instead, start to explore the program that gives you this itch at a higher level. Now might be a good time to try to read all the code, but don't be too concerned if you cannot, most programs are just too big and messy for gulping them down all at once to work. Just try to get a grip on what you need to know to clean things up.
You are now entering the intermediate portion of learning to hack. This involves not merely changing surface-visible features but doing what is called “refactoring”, reorganizing the code internally so that it is cleaner and has better architecture (better hiding of data, narrower interfaces between different parts, more functional separation among modules). Once your design sense (your equivalent of musical ear) is activated, you will often find that you start refactoring each program you work on as rapidly as the third or fourth time around the incremental hacking cycle. In fact, this is exactly how skilled hackers normally approach learning the code of large programs, by tinkering and refactoring and rewriting until they grok what is going on. You make small changes in order to learn how to make large ones.
If you successfully refactor three or four large systems, you will not just develop strong programming skills, you will be on your way to something much more rare and powerful, becoming a software architect, one who can do original design of large software systems. This is the only way I know of for fledgling software architects to train their design sense. It may be the only way there is.
In my analogy with music, I said that you eventually need to learn how to recombine musical patterns (which you have learned by listening to music and practicing performance) into original compositions. I chose that way of describing creativity carefully, because it applies to software even more than it does to music. Before you have read and absorbed the lessons of a lot of code, you will probably not have in your head the pattern library you need to be creative on scales larger than very small ones. One purpose of doing the incremental hacking cycle is to immerse yourself in a lot of code, at increasing complexity scales, under circumstances that provide you with motivation to keep reading. Eventually you will lead group projects and do entirely original work. Do not feel you have to rush this or force it. If you give your skills time to mature, your first original composition will be better for it. By contributing effectively to existing open-source projects you will learn the skills (including the communications skills) that you need to run your own projects.
