Foreword

---

You know what drives me crazy?

“Everything?” you ask. Well, OK, some of you know me a bit too well by now.

But seriously, folks, what drives me crazy is that most software developers don’t realize just how little they know about software development.

Take, for example, me.

When I was a teenager, as soon as I finished reading Peter Norton’s famous guide to programming the IBM-PC in Assembler, I was convinced that I knew everything there was to know about software development in general. Heck, I was ready to start a software company to make a word processor, you see, and it was going to be really good. My imaginary software company was going to have coffee breaks with free donuts every hour. A lot of my daydreams in those days involved donuts.

When I got out of the army, I headed off to college and got a degree in Computer Science. Now I really knew everything. I knew more than everything, because I had learned a bunch of computer-scientific junk about linear algebra and NP completeness and frigging lambda calculus which was obviously useless, so I thought they must have run out of useful things to teach us and were scraping the bottom of the barrel.

Nope. At my first job I noticed how many things there are that many Computer Science departments are too snooty to actually teach you. Things like software teamwork. Practical advice about user interface design. Professional tools like source code control, bug tracking databases, debuggers, and profilers. Business things. Computer Science departments in the most prestigious institutions just won’t teach you this stuff because they consider it “vocational,” not academic; the kind of thing that high school dropouts learn at the local technical institute so they can have a career as an auto mechanic, or an air-conditioner repairman, or a (holding nose between thumb and forefinger) “software developer.”

I can sort of understand that attitude. After all, many prestigious undergraduate institutions see their goal as preparing you for life, not teaching you a career, least of all a career in a field that changes so rapidly that any technologies you learn now will be obsolete in a decade.

Over the next decade I proceeded to learn an incredible amount about software development and all the things it takes to produce software. I worked at Microsoft on the Excel team, at Viacom on the web team, and at Juno on their e-mail client. And, you know what? At every point in the learning cycle, I was completely convinced that I knew everything there was to know about software development.

“Maybe you’re just an arrogant sod?” you ask, possibly using an even spicier word than “sod.” I beg your pardon: this is my foreword; if you want to be rude, write your own damn foreword, tear mine out of the book, and put yours in instead.

There’s something weird about software development, some mystical quality, that makes all kinds of people think they know how to do it. I’ve worked at dotcom-type companies full of liberal arts majors with no software experience or training who nevertheless were convinced that they knew how to manage software teams and design user interfaces. This is weird, because nobody thinks they know how to remove a burst appendix, or rebuild a car engine, unless they actually know how to do it, but for some reason there are all these people floating around who think they know everything there is to know about software development.

Anyway, the responsibility is going to fall on your shoulders. You’re probably going to have to learn how to do software development on your own. If you’re really lucky, you’ve had some experience working directly with top notch software developers who can teach you this stuff, but most people don’t have that opportunity. So I’m glad to see that Mike Gunderloy has taken it upon himself to write the book you hold in your hands. Here you will find a well-written and enjoyable introduction to many of the most important things that you’re going to need to know as you move from being a person who can write code to being a person who can develop software. Do those sound like the same thing? They’re not. That’s roughly the equivalent of going from being a six year old who can crayon some simple words, backwards N’s and all, to being a successful novelist who writes books that receive rave reviews and sell millions of copies. Being a software developer means you can take a concept, build a team, set up state of the art development processes, design a software product, the right software product, and produce it. Not just any software product: a high-quality software product that solves a problem and delights your users. With documentation. A web page. A setup program. Test cases. Norwegian versions. Bokm l and Nynorsk. Appetizers, dessert, and twenty seven eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was. ^[*]

And then, one day, finally, perhaps when it’s too late, you’ll wake up and say, “Hmm. Maybe I really don’t know what it really takes to develop software.” And on that day only, and not one minute before, but on that day and from that day forward, you will have earned the right to call yourself a software developer. In the meantime, all is not lost: you still have my blessing if you want to eat donuts every hour.

—Joel Spolsky
Founder, Fog Creek Software

^[*]Apologizes to Arlo Guthrie.

---