Learning the craft

I went out to dinner with an old programming friend the other night, and as all old programmers do, over our Chillis burgers we started swapping war stories about the systems and projects we'd worked on. Neither of us had a formal computer science education, and as we ended up comparing great computer related books we'd both read, it started me wondering, “How did we learn this stuff ?”

Like anything that requires skill, programming is one of those things it's hard to do as “just a job”, clocking in Monday to Friday. At least it's hard to do well that way. The best programmers I have worked with have an obsessiveness about them, a desire to create perfection within the machine. It's probably why promising young programmers are so easily persuaded to work punishing hours for a start-up by smart business people who know how to motivate them, not by money but by interesting work.

I ended up in programming by accident, as many do. I was studying for a PhD and having to write software as part of the studies, only to find that writing the software was more interesting and fun than finishing the PhD. So I ran away and joined a small software house. But having arrived there, knowing barely more than assembly language and FORTRAN, how should I learn more ? And what if the other programmers found out how useless I was ?

Find yourself a mentor

I was lucky. The senior programmer I worked with had an amazing talent. I was so intimidated by him. He'd written his own Forth interpreter in Z80 machine language, and was a published adventure game author. I was so intimidated by him that initially I was frightened to ask questions in case he'd discover how little I knew. I used to listen in on conversations he'd have with his other knowledgeable friends and pretend I understood what they were talking about and I wouldn't look so ignorant. After work I'd go home and try and look up what they were talking about at the local computer bookshop (this was way, way, before the Internet and easy search engine availability).

Eventually I realized that I wasn't learning much. So one day (and I still remember the cold chill I got in my gut just before doing this) I simply interrupted his conversation with a “excuse me, I don't understand what you just said, can you explain it to me ?” I stood there waiting for the earth to swallow me up, or at the very least for him to unleash lightning bolts from his heights on Mount Olympus. To my complete surprise, he simply said, “oh, OK. What I meant was..”, and proceeded to explain in clear and full detail the technique he was discussing.

From then on I was hooked. I asked him anything and everything about programming, and he was happy to teach me. Since then I've discovered that the most talented programmers love to share what they know with younger colleagues. The old adage “the only stupid question is the one you don't ask” is really true. People love to share their area of expertise so don't be afraid to bug them to learn what you need to know (within reason I hope).

He also knew C. When I asked him how he'd learned C he told me he'd picked up a little book called “The C Programming Language” by Kernigan and Richie (who were the original authors of the language) and it was pretty simple once he'd read that. Anyone who has read this book themselves will realize just how good this guy really was, as it's an incredibly terse read. It tell you everything you need to know about C, but only once. No repetitions, not much in the way of examples and a crisp and functional style. But it's one of the classics of computer science literature.

Which brings me to my next point.

Read the right books.

Of course, when I say “books” these days I also mean Internet references. Even if you studied computer science your course notes are no match for the tomes of wisdom to be found on Amazon or your local bookshop. Once I found the classics of computer science I never looked back. I bought myself copies of Knuth's classic “The Art of Computer Programming” and started to haunt the computer bookshops in Sheffield, UK, avidly looking for my next fix of new information. The books I bought there ended up sending me to the USA for a programming job (the dream of any northern English lad in those days, I wonder if it still is ?). I still remember coming across W. Richard Stevens “UNIX Network Programming” and realizing I'd found a gem. Everything else he ever wrote was too. The book that got me to the USA was Asente and Swick's “X Window System Toolkit”, which I still refer to as the gold standard in how to document the internal and external API's of a programming library. The knowledge I learned from that book got me the job in Silicon Valley. Any of Andrew Tanenbaum's books are must-purchases too.

I ended up buying a lot of crap too. The problem is (and to a large extent still is) that it's hard to evaluate books or text to discover if they're any good until you've read them and tried to implement the techniques they're talking about. A lot of books look good on the surface, but actually are rubbish in disguise. How do you determine the wheat from the chaff ?

These days, for a UNIX system programming book I look at the section on signal handling (sorry for getting technical here but there's no other way to describe this). As signals are asynchronous (like threads) and so if you ever see a printf() call in a signal handler to demonstrate it being invoked, hurl the book across the bookshop with great force and never buy anything from that author again. It'll teach you to write code that will randomly fail in the real world.

After I moved house recently I finally dumped about three hundred books on the second hand bookshop in Mountain View. I realized I no longer need to keep references for old API's and libraries that you can now look up on the Internet. It was like saying goodbye to old friends, but I needed the room.

Read code. Lots of code.

Before the advent of ubiquitous Open Source/Free Software this used to be hard to do. I had to learn by reading the internals of Sun's (my employer at the time) X Windows libraries and Solaris kernel code. These days there's no excuse for not looking at the multi-millions of lines of high quality code free to review from the Open Source/Free Software communities. I know this is an obvious one, but most of the techniques I use and apply every day are things I first read in other people's code (this is one of the reasons software patents are so insidious for programmers). Occasionally you'll do something new, but mostly you'll just be applying the work of others in different ways. In fact, if you have to invent a new technique you're usually doing something wrong (unless you're really, really, good). Remember Pablo Picasso “Good artists copy. Great artists steal.”

Change jobs often.

Unless you're working for IBM (or I guess Microsoft these days), you'll never be in the sort of organization that has the breadth of interests you'll need to learn what truly interests you. Even if you are working for the aforementioned companies, you'll never be in the position to move across all the product groups you'd have to join. Once you find success, you'll get stuck. I was not originally known as a network or Windows interoperability engineer, I was a graphics wonk, working on X Windows. Until I left Sun Microsystems and went on an odyssey though the “Silicon Valley of Startups” here in California I never got the chance to learn about compilers, C++, Microsoft Windows system programming or ultimately the details of Windows interoperability (where I've found a happy and productive home). I worked a lot of hours, got issued a lot of worthless stock and got burned by many sleazy venture capitalists but more importantly I learned a lot about the incredibly interesting job of computer programming.

Let me know what you consider the most important elements of learning the craft, I'd love to hear from you !

Jeremy Allison,
Samba Team.
San Jose, California.
6th September 2008.


Great read

I really agree with the mentor part. Good programmer never mind answering ur qna.

Nice Read. I agree with the

Nice Read. I agree with the switching jobs often. I have been in the industry for four years and have had a new job each year. I have worked with microprocessors (mostly c/c++), .Net, Java, PHP, multiple database system and pretty much everything else under the sun. I may not be learning one direct skillset yet, but personally the experience from each and every one of these jobs was worth it.

you suck

php warnings at the top of your page do not help your cause. Why should we bother reading about "the craft of programming" from you?

Re: You suck

How about, person who writes the article doesn't host or maintain the website.

you sucker suck

Yeah you were like blaming a good driver because of the road. Come on you should blame the road engineer not the driver.
Hello...you sucker suck....

Good points

Well worth a read, although the first few lines of HTML rendered are somewhat ironic. Someone hasn’t learnt the craft of PHP very well!

Warning: Cannot modify header information - headers already sent by (output started at /home/tuxdel2/public_html/includes/database.mysql.inc:172) in /home/tuxdel2/public_html/includes/bootstrap.inc on line 531

It's Drupal!

I recognize the symptoms of a Drupal problem. Try reading this:


And try to ignore the grief from these folks who apparently have never seen any broken software before. Maybe all of their software comes in a shrinkwrapped package from the store.

Re: Drupal

MySQL corruption, in fact. Had to coincide with me putting this article up for Jeremy though, didn't it?


isn't a craft.. It is a mess! Really. Nice read, by the way..

Nice work

Well written, and good advice.

Thanks for the quality article.

Good article

I like your articles Jeremy. I liked this article, as it's in the same spirit as "working for the man" and I'm really glad when I can learn from other people whom I respect.

I live in a third world country, and jobs here in IT are usually outsourced consultancy contracts. Startups are not innovating, and big companies only come here for cheap labor.

So I have another advice from my limited 5 years of experience in the field: seek beauty, don't settle for mundane tasks. Only work on what you love, otherwise you're going to get burned.

UK was the same in the 1990's (probably still is).

When I started in the UK the most technical job I could find was working on the Sun "helpdesk" hotline. It was horrid. All the frustrated programmers (all of whom in the USA would have been in Sun engineering) busily working on their own side projects whilst they had to wear suits and answer "how to I fix my NIS server" problems :-).

So I sympathize. I certainly agree with the "only work on what you love" but sometimes that can be hard. After all, I ended up having to work 4-5 years on Win32 programming (porting UNIX daemons to Windows NT :-) so you can't always do what you want.


> As signals are synchronous

> As signals are synchronous (like threads)

You mean asynchronous =-)


Yep - thanks for spotting the typo. I thought "asynchronous" but typed the other :-(.
Guido van Rossum just pointed out to me I spelled "Tanenbaum" wrong too (apparently he was taught by the master himself !).


Re: Bum

Repaired, I hope, by the editor's magic wand

The Editor :-)

My stupid-if-not-asked question

What's wrong with using printf() in a signal handler?

printf causes an I/O trap

printf causes an I/O trap (signal) call, signal handlers should be re-entrant. (read more about re-entrant vs non-re-entrant functions)

signal handlers can be called in any program context.

Imagine you're in the middle of a malloc() call, updating some linked list of malloc'ed pointers. Then you get hit by a signal. The signal handler calls printf() - printf() can call malloc() to allocate buffer space and then oops, you've a corrupt malloc pool.

The only safe thing to do in a signal handler is to set a volatile sig_atomic_t variable, and call something like write() down a pipe to notify another file descriptor (being read by a select, poll or epoll call in the main loop of the process) that a signal arrived. Actually, even the write() might block if there are too many unread bytes in the pipe, but there are other ways of handling that.




I know so little about programming! I'm like a chimp amongst people who train chimps sign language (there is a word for that...I know).
Oh well... At least technology has advanced enough that I can make 2D games via drag and drop.
Horray! Do I get a cookie for re-making Asteroids?

On K&R

This is what Steve Yegge has to say about K&R:

This is an odd little book. It's frequently mistaken for an introductory programming book, which inevitably leads to frustration. It's not a good way to learn how to program; it expects that you're already familiar with machine architecture, assembly language, compilers, and at least one other high-level language.
It's not even a very good way to learn C. The idioms and best-practices for C programming have evolved substantially, even since the second edition was published, and some of the code samples look a bit dated.

and I tend to agree with him; the code for simple Unix command line tools is quite K&R-esque, but the kernel code looks like it was written in a completely different C. How would you refute this?

On K&R

Steve Yegge says this:

This is an odd little book. It's frequently mistaken for an introductory programming book, which inevitably leads to frustration. It's not a good way to learn how to program; it expects that you're already familiar with machine architecture, assembly language, compilers, and at least one other high-level language.
It's not even a very good way to learn C. The idioms and best-practices for C programming have evolved substantially, even since the second edition was published, and some of the code samples look a bit dated.

How will you refute this?

On K&R refute?

I was working as a resident visitor at Bell Labs and needed to learn C very quickly. I was given a copy of K&R. I am reasonably sure Jeremy Allison was still in his teens and Steve Yegge not yet a teenager at the time. Of the many, many programming books I have read, I still believe it to be one of the most useful. Everything Steve Yegge says in the quote is reasonable, but you must remember the book was written over thirty years ago. In the K&R introduction it says "a novice programmer should be able to read along and pick up the language, although access to a more knowledgeable colleague will help." The main points in Jeremy's article are echoed there. You learn to program and you remain relevant as a craftsman of programming by self education. Read the books, read the code, ask questions.

Refute, to prove wrong by argument or evidence... I can find nothing "wrong" in Jeremy's posting here. But, hey I'm just an old guy who has forgotten more than he remembers.

Good summary

If you find yourself not having fun (for a period of 4-6 months) or you find yourself not learning anything (ditto), then you should find a new job somewhere.

Always have someone around to learn from. If you're the technical heavy in your organization then you can always learn about the business side of things, or go on sales calls to customers, or mentor a few junior people.

Also, write lots of documentation. Whenever you can. Writing about stuff will make it clear where it is broken :-)

Great read, thank you

Great read, thank you Jeremy! There is something of the Tao of Programming in your article -- though perhaps told in a slightly less abstruse voice. :)

I will humbly suggest that the following are also important steps to be taken in the (probably endless?) process of learning "the craft":

- Write code. Lots of it. In your spare time. Reinvent as many wheels as possible. There's no better way to imprint the importance of "best practices" on your mind than by breaking things, tripping over your own mistakes, and encountering first hand all the same frustrations that led wise folks to discover the "best practices" in the first place and write books about them.

- Do not attempt to publish or distribute or patent all that rubbish code you write. Throw it away!

- Don't believe every "best practice" is best for every situation, for every programmer, and so on. Make sure you're willing and able to adapt your approaches, languages and systems of choice, methodologies, and so on, to the time, place, people, etc. Books are great, but gospels are dangerous. Anyone who tells you there is "one right way of doing things" will be unemployable in 5 years, because there will be a new follower of a new fad stepping in to take her place.

- Have someone else who is smarter, more experienced, and much nicer than you review your code. I can't stress how important this is for finding your blindspots. And in the age of the interweb, it's pretty easy to get your code reviewed by *many* smart, experienced, nice developers.

- Be a mentor to someone else. There is no better way to shape and tighten your own philosophies and designs than explaining them to someone who has no or little experience in the problem field at hand. If you're just starting out in "the craft", and you have a friend who is starting out with you, then mentor each other!

- Small is almost always more beautiful.

$0.02! Cheers,

Johann Tienhaara


aren't insidious, the problem is coders spend too much time coding and not enough learning skills outside. Many startups innovate then fail because of lack of focus on patenting their innovations to allow them to survive and innovate further.

Nicely Written

I've always told people that the trick to being happy is to get paid to do what you do for free.

As far as books, I've been recommending Randall Hyde's "Art of Assembly Language". It's a pretty thorough description of just about everything that happens inside a computer. Even for people who never plan to learn assembly language (and assembly is like Proto-Indo-European--every other language is built upon it), it's a good source for becoming familiar with machine architecture, assembly language, compilers, and at least one other high-level language.


Async-signal safety.

SUS is a superset of ISO-C and it has different requirements
for signal handlers, at least on the 'signal concepts' page
(while the 'signal' page appears to have been copied
from the C-standard independently). Specifically, SUS defines
a list of call which are supposed to be 'async signal safe' (printf
not being among then) and states that

All functions not in the above table are considered to be unsafe with respect to signals. In the presence of signals, all functions defined by this volume of IEEE Std 1003.1-2001 shall behave as defined when called from or interrupted by a signal-catching function, with a single exception: when a signal interrupts an unsafe function and the signal-catching function calls an unsafe function, the behavior is undefined.

Among other things, this implies that it is perfectly safe to
call any function from a signal handler, provided no other
signal handler can interrupt it (=> sa.sa_mask) and it is
known that no thread of execution is currently executing
an unsafe call, eg because signals are always blocked except
during a call to poll (or some other async-signal safe function).

And that is something which cannot be learned by memorizing
one million urban legends frozen to source code by people
who didn't know any better, either.

Use many differing languages and environments

Another great way to continue your own personal learning is to learn divergent languages. Know Java? Learn to be effective in Erlang, write in C++, do some Python, and so on.

A parallel path is, even if you don't anticipate creating a language, read all you can about the design of computer languages. Even outside of the direct application (we all write little languages from time to time), it increases understanding of programming in general.

Doing as learning

I would suggest also that both writing code and writing articles for journals are very useful. They are, I think, doubly useful if written purely for personal reasons. This allows you to take a personal idea and run with it; further you are forced to do it well enough to convince others.

The personal pride that comes with such things will help force you to "do it right" without sacrificing anything to real life demands. If you can't make your idea work without those restrictions, it's probably not a good idea. Back to the drawing board!

It is also an opportunity to crystallize your learning -- expressing something as tightly as possible, either through public code or articles, lets you take a good hard look at the essence of what you have learned. As you cut out areas of code / writing which are superfluous to your point of view, you also discover yourself what the essence of your learning is.

Just my 2c.
-Tennessee Leeuwenburg

Thank you for the good read


Thank you for the inspiring read, I am 46 and a newbie to development. I find too many experienced developers these days saying that people new to the craft just suck and will never get better than that, and have nothing good or inspiring to say.

It is refreshing to find an inspiring word=.

Thank you.

Not just a Mentor, a Community

My advice for anybody wanting to learn programming would be to find a free software project that interests you and which has a large and friendly developer community.

I never intended to be a professional programmer, but have ended up through necessity spending a fair proportion of my working hours coding. Because I had the good fortune to be working with Drupal, I am a much better programmer than I ever expected to be.

The huge amount of documentation (yes, it's currently quite disorganised - which means you also learn how to be a Google guru as well), the tutorials and screencasts people post, seeing the inner workings of the minds of the gurus on Planet Drupal, groups.drupal.org, the podcasts, the conferences, the simple and straightforward issue tracking system, meant that almost by accident I picked up the community's best practices.

When I started in this line of work, I expected I'd be good enough to customise software where necessary with kludgy hacks; I never dreamed I'd be able to contribute to world-class publicly distributed software. Nothing I have experienced in five years of being a professional developer gives me as much satisfaction as posting a patch for some trivial bug, seeing it committed, with a cheery "thank you" from someone way more talented than myself, and knowing I've helped free software users all around the world.

Matthew Davidson

Yes, Open-Source Teaches

The statement made is definitely a true one! Getting involved with an Open-Source project is the best move one could make in trying to singlehandedly learn programming.

Though there were other options available for me to learn what I have, my best move was jumping in and getting involved with The GIMP, in it's early Win32 ports (back when Tor Lillqvist was handling the porting to Win32 and offering a handful of files from his portion of the GIMP's site). Programming is a 'gift' and an 'art' to itself. It's just not for everyone. Some people simply have a knack for it. If something wasn't right with a particular function or call, I'd dig in and figure out what the fault was. I found myself hooked. When I'd figured out a 'fix' for a particular problem, yes, the praise from the higher up was my motivating force. I'd found my niche.

Now I am more prominent within the Linux side of things, than the Win32, as Linux encourages development (while Windoze holds fast to proprietary software and coding by licensing issues). For this reason, things are just so much easier under the Linux platform.

Since my earlier days I have involved myself with quite a few projects. I enjoy the fact that so many stand to benefit from my input.

I've been an Artist all my life. I was a freelance illustrator for EasyRiders, BIKER and InTheWind magazines from 1981-1995 (under the pseudonym of Li'l Bro). Now, I'm 'drawing' with a PC... as well as working on the projects that I draw with. It's an addiction of sorts. As it was put to me, so many years ago... 'Not every Artist is a Programmer, Not every Programmer is an Artist. You just happen to be both'

You have posted a great piece here! Thanks for taking the time to post it. I am certain that there are those who will take to heart the advice given here and find their 'niche' within this world of 1's and 0's.

Gary Ingram


Yeah.. it really boils down to abstraction.. -- i really, really liked this post.. -- bottom line is that you have to learn how to build the solution from a dynamic mingling of intermediate solutions.. programming is art and i needed a reminder.. thanks for the post, best of!

The difference between code and English

I'm a technical writer with an interest in programming (which is why I read this article) and spotted the line in this article, "It tell you everything you need to know about C, but only once". It should read, "It tells you..." I'm not trying to be critical, but usually this sort of typo is missed when the writer relies on spellcheck to pick up errors. I know that you can debug a programming using automated tools but you can also do it reading line-by-line (which I'm sure is tedious in a program hundreds of lines long). It's just an interesting comparison and illustrates how much easier (in my opinion) it is for errors to creep into "plain text" writing than programming.

BTW, good article. I'd have liked to see you "flesh it out" a bit more, though. I'm sure you have more ideas about how to advise neophyte programmers in learning the craft. Cheers.

Great Article

I myself graduated with a art degree and got a job as a graphic designer for a small marketing firm. They didn't have anyone that could do websites and I was vaguely familiar with html and css so I took up that position. I'd taken one Java class in college so when I needed to use some php, javascript and actionscript I was able to. Since that time i've become a pretty strong php developer, and realized I really like programming more than anything. Your article was fascinating for me--as someone who is starting along similar lines to the way you started. Thanks!

Another one of those "stupid" questions...

You mention that aspiring programmers should: "Read code. Lots of code."

The trouble I have found is that while there is a lot of good quality code, there is also an enormous amount of truly atrocious code in Open Source projects.

What's worse is that sometimes the very worst code is held up as being a shining example of "good code" by an aspiring programmer who is trying to become a mentor before they are ready.

How does one tell the difference between the good code and the bad code without an innate knowledge of what constitutes good and bad code ?

Great article

Great article! I thoroughly enjoyed it.

I'm a real book swallower myself, have bought a lot of nonsense but in the long run, every single technical how-to book i ever bought has learned me at least something.

Another good advice nowadays is to find good podcasts on itunes and/or the web. It's a great tool of having a narrator explaining the code while you can see him typing it in.

A colleague at work, who really have been a sort of mentor, got me into ruby on rails web programming, and podcasts have really been a true delight in the ongoing learning progress.

Learning the craft

Mentor: It was a college project to write an assembler for the IBM 360 in assembler. My partner was only a little more practiced than I, but made two impressions. The first was that if you have an input field, over the long run anything that can be entered, will be entered. In the context of an assembler (or compiler) that means error recovery. In data input, it means sanity checking. An example is that if you are going to use a character as a delimiter, you had best deal with it, should it appear in the input stream. It left me with the downside of writing code more slowly, but an upside that it comes back at a far lower rate.
I was on a project where the PM said a piece of code was to be finished in a month. I told him it would take 2 to do it right. "But that is what I told the customer." It did take two months, and I got a "bad" review. However, on to another project, this time in Germany, I got an off-hours call that my code was not functional. I told him it was receiving incorrect answers from an object that was the other guy's responsibility. He had delivered his part in the requisite one month. However, he was still fixing it 3 months later.
Passion: The second thing I discovered on the assembler project was a passion for performance optimization. With my partner's short-lived lead (I quickly grabbed the reins of this one), we were doing instruction cycle counting, with the assistance of the POO (Principals of Operation) manual. That passion has continued since 1970, and has led to the IBM DeveloperWorks series on performance tuning the UniVerse database, "Travels with Mark". Perhaps I can be a mentor for others. So far, the series has been tutorials for mental models, described below. You tend to excel at something you love. With luck, you can make a living at it. Amateur, derives from the Latin amare, to love.
Learning languages: It is helpful to have something to play with, beyond examples, and helps if you know what you wish to do. Starting with Pascal, I have implemented, to some degree, a version of the game, Empire. Each language has its own limitations and freedoms. The quote in the front of the Pascal manual states that the language in which you think affects the thoughts you have (in essence). The game has provided the means to explore language features.
Object Orientation: My first OO language was Smalltalk. You almost cannot DO procedural code in Smalltalk, unlike Java or C++. Kent Beck's book on Best Practice Patterns really got me hooked on that. It also really changed my approach to the Empire game! Smalltalk can be a real pig in terms of needed memory and CPU resources. I was able to subvert my performance metric passion to the thought of optimizing maintenance programming over time, rather than code execution performance. And well-written OO does not need to suffer in performance.
Refactoring: Like Kent Beck's book, Martin Fowler's Refactoring book continued to reinforce those programming habits. I was really amused when I thought that the first half of the book is dedicated to changing design patterns from one pattern to another - and the second half of the book is to undo the damage of the first half of the book by showing you how to go the other way!
Unit Testing: Or as I call it, and have yet to publish the paper, You nit testing, because YOU are testing for NITs. I had a project to do a troff-like document generator. I built a suite of small mini documents and output standards. As I made changes to the code, I could tell if I broke something else. I also have an emulator for the IBM 360 in Java. It, too, has a suite of tests to ensure each instruction performs as expected. On another, a stupid unit test suite I wrote, found six bugs in a date conversion routine I was working on. But no customer saw them!
Assembler: Everyone should take at least one course in this - or more. If you only stick to structures and algorithms, and study big O notation, you may never learn the differences between two comparable order-something, routines. And if you do not understand machine language, you have no idea of what you are asking the machine to do.
Breaking things: I seem to have a knack for this. Perhaps it comes from pondering the effects of different inputs to a routine, or seeing a variety of ways that neophyte users can find to use a piece of code rather than the "intended" usages. It also helps to have access to source. Upon reviewing one C routine that input numbers, I entered 123.456.78, with two decimal points, not international thousands-separators. The coder: "That will never work." But it did! Was he shocked.
Problem analysis: This is not "thinking outside the box," although trite, is a different topic. I found a book that I found dreadful. However, a gem of an idea relates to thinking about problems. In an Algebra book, you get a technique, and then a problem set where that technique applies. Another section follows. The interesting issue comes when you finish the book, scramble the problem sets, select a problem. How do you determine which technique applies? Although I have never watched, so the analogy might be askew, consider, "Are you as smart as a sixth grader?" Here the techniques are in temporal congruence with the questions for the sixth grader, and an adult has a lifetime (as does the sixth grader, but it is a shorter life) of obfuscating and irrelevant material to the question at hand. Having a more complete toolbox makes selecting an appropriate, let alone optimal, tool an interesting problem.
Reading code: While useful in learning techniques, both good and bad, I find it useful to understand. Documentation often lacks sufficient detail to really comprehend what a library, for instance, is really doing. Reading code can illuminate that, particularly when you learn a new language or library; the "Oh, *that* is what that meant."
Mental models: Source access is really helpful here. When you have strong mental models of something, you can more easily detect when something is amiss - "That is not supposed to happen!" or, "That should not take that long." With closed source, another useful skill is figuring ways to poke at it so the results suggest what is happening inside. This probing may contribute to my ability to break things.
Being anal: I have not had time to contribute to open source, but when I find broken things, at least I can build reproducible cases. In a prior life, I owned QA, and one thing engineers liked was "Run this script and when it gets to the third step, this happens instead of that. Then run this to reset it to do it again."

Thank You!

This fell across my Twitter stream today, and I'm REALLY glad I spent the time to read this. My dad's a computer systems programmer, and I'm a web designer/developer, so I guess the nerdy genes really do run in my family. However, I am still learning (24 and still in college!), and CONSTANTLY have questions to ask.

This is great advice for anyone in any industry, but especially the intimidating specialties of programming.

Thanks again for the reminder!
Sara Reffler

Back to top