New Programmer's Survival Manual: Now For Sale!


Now for sale: my book for programmers entering industry, the New Programmer's Survival Manual, is available in "beta" ebook form. If you purchase the beta, you'll also get an upgrade to the final book which will be published around September.

I expect readers of this book to fall into a couple categories:

  • College students taking Computer Science classes and wondering, "is this what programming is like in the real world?" (Short answer: no.)
  • College grads already in industry, who have noticed first-hand that the answer to the first question is "no," trying to get their heads around the disparity.
  • Professionals from other backgrounds who got into programming as a hobby or side job, now wanting to take it on full-time.

Programming at industry level requires new skills--you'll build programs that dwarf anything you've done on your own. This book introduces you to practices for working on large-scale, long-lived programs at a professional level of quality. You'll find out how to work efficiently with your tools, and discover essential new tools.

But the tools are only part of the story; you've got to get street-smart too. Succeeding in the corporate working environment requires its own savvy. You'll learn how to navigate the office, work with your teammates, and how to deal with other people outside of your department. You'll understand where you fit into the big picture and how you contribute to the company's success. You'll also get a candid look at the tougher aspects of the job: stress, conflict, and office politics.

Finally, programming is a job you can do for the long haul. This book helps you look ahead to the years to come, and your future opportunities--either as a programmer or in another role you grow into.

There's nothing quite like the satisfaction of shipping a product and knowing, "I built that." Whether you work on embedded systems or web-based applications, in trendy technologies or legacy systems, this book helps you get from raw skill to an accomplished professional.

(Note: If you're read along with my previous writing on this subject, all of the best material (and lots more) is in the final book. And you'll be relieved to know I dropped the bits about assembly language.)

Essential Industry Skills

Allow me to consult the vast oracle of the interwebs on a perplexing problem. (That would be you.) I’ve got a lot of thoughts about on-the-job technical skills needed by industry programmers, each worthy of its own book. I have one chapter in the book I’m working on.

Here’s what I want to accomplish:

  • Give the newbie programmer a picture of programming topics that seem to come up again and again. I don’t intend to teach the topics, but give a brief discussion of what they are, why they keep coming up, and some good approaches to start on. (See examples below.)

  • Choose a reasonable subset of topics that apply across a broad cross-section of industry (80/20 rule).

  • Refer the reader to other resources to find out more.

This chapter is specifically focused on programming chops, not tools or bigger-picture practices. (I’ve got other material about that.) Let me give a few examples to clarify.

Continue reading "Essential Industry Skills" »

New to Programming in Industry? I Need Your Help

I'm working on a book for people new to programming in industry. My reader may be:

  • A college student looking to become a professional programmer, wondering what school's not teaching them;

  • A recent grad who's working but has noticed that there's a lot more to professional work than what you learned in school;

  • Someone coming to programming from a completely different field, who got their feet wet and now wants to make programming a career.

Is this you? Yes? Let's talk. I'm putting together an advisory panel of "target audience" readers, whose goal is to make sure I'm answering your questions. The scope of this topic is nearly infinite; the number of pages I've got to make a high-impact book is not. I need to keep it tight and focused on the topics that are most useful to you.

In return for your help, you'll get early access to chapters as I write them. I'll try to swing a copy of the paper book for you, too, when it's printed.

Interested? Send me an email.

Coming to a Bookstore Near You

First, thanks to all the readers who followed my PragProWriMo 2009 writing--your support was invaluable. I'm happy to announce that Pragmatic Bookshelf picked up my book in December and I'm busy finishing the first draft. I'm not sure how long the whole process will take, the optimist in me wants to believe I can finish by the end of the year. Either way I'm very excited to bring this book to fruition and the folks at Pragmatic are fantastic to work with.

Quality: Beginning vs. Afterward

Yes, PragProWriMo 2009 was over yesterday. However, I can’t introduce the topic of quality and then just stop there, can I? After this it’s time to start working on my book proposal.

There are two approaches to building a quality product: build it in from the beginning, or beat it in afterward. The former approach requires a lot of discipline and effort from the engineering team. The latter requires a lot of testing and, again, effort from the engineering team.

Continue reading "Quality: Beginning vs. Afterward" »

Quality is Job 0.99999

This is intended to introduce a chapter on quality. There’s a myriad of topics here; this post is merely setting the stage.

I take it as a given that any product should be a high-quality product. Why bother making it otherwise? This seems like a straightforward goal, but the technology industry has had a hell of a time figuring out how to build quality software. There’s a joke that’s been around for at least a decade:

There’s word in business circles that the computer industry likes to measure itself against the Big Three auto-makers. The comparison goes this way: If automotive technology had kept pace with Silicon Valley, motorists could buy a V-32 engine that goes 10,000 m.p.h. or a 30-pound car that gets 1,000 miles to the gallon—either one at a sticker price of less than $50. Detroit’s response: “OK. But who would want a car that crashes twice a day?”

Any good joke has an element of truth to it—this one especially so. Auto makers can build cars that’ll drive hundreds of thousands of miles, but Windows 95 would crash after 49.7 days of continuous operation—a bug that took four years to discover 1 because other bugs would crash Windows 95 long before 49.7 days could pass.

Continue reading "Quality is Job 0.99999" »


It used to be that the “user interface” for a computer was assembly language and its “user manual” was the programming manual. Back in those days, the distinction between the physical machine and its programming interface was somewhat academic.

These days, there’s a lot more layers involved. Taking the “simple” example of C++, the layers could look like this:

In this example, the physical machine is a x86, 64 bit. The machine’s architecture has various ramifications, for example a 64 bit machine can allow a single process to address much more memory than a 32 bit machine. The operating system has numerous implications; any “system call” like accessing a file goes through the operating system. Then there’s the libraries, for example the C standard library which provides functions like printf() for formatted output. Then there’s the programming language itself.

Continue reading "Platforms" »

Programming Languages

There are few topics that can get programmers riled up more than programming languages. Language flame-wars have been raging on Usenet since about the dawn of Usenet. They’ll continue burning until, as best I can tell, the end of time. Why? The programming language is your most-used tool (second only to your text editor) and it takes a long time to master, so it’s reasonable that people get attached to their languages.

In college you likely focused on one “do it all” language like Java. There’s nothing wrong with Java, in fact it’s a great language. The problem is the “do it all” part—no language does it all, at least not well. You simply cannot be productive and versatile without knowing a couple programming languages.

Continue reading "Programming Languages" »


In the 90’s Bare Bones Software released a text editor called BBEdit with the tagline “It Doesn’t Suck.” It retains the tagline to this day. Truly brilliant marketing. Who’s their market? Programmers.

Programmers are pessimistic and sarcastic lot. The vast majority will tell you about a hundred things that suck for every one thing that doesn’t. The highest praise a programmer will give a product is, “it doesn’t suck.”

Pessimist programmers are in good company. I’ve read various reports saying the vast majority of projects fail. 80 or 90 percent. Adding insult to injury, it’s not the good 10 or 20 percent that succeed, it’s some hodgepodge of good and bad. It almost seems that bland to downright crappy products are more successful, on average, than really good ones. When a programmer says such-and-such sucks, chances are he’s right.

Continue reading "Optimism" »

Corporate Myths

Author’s Note: it’s really hard coming up with good examples for the assembly language discussion. Either I make something meaningful that compiles into pages of assembly, or I make something too trivial that compiles into nice snippets. I’ve tried three times to write about pointers and the balance still isn’t right. So today I’m flipping back to corporate life.

Executives and managers like to think they’ve got it all together. Walk with some swagger, put on the game face, don’t show weakness. Just as you learned about your parents, your management doesn’t always know as much as they say they do. I’m a manager, I’d know.

So let’s take a tour of myths you’ll probably hear in the corporate world. When you hear these, make a mental note: this guy is a bozo.

Continue reading "Corporate Myths" »

Functions and Parameters

This entry is a day late because I started writing about pointers, but I realized I needed to discuss function calls first.

Now that we’ve got the foundation of stack frames and the debugger for exploring them, we can use the stack for more than just local variables. The stack is also used for passing and receiving parameters to functions.

Let’s say I’ve got this very-nearly-useless function:

int sum3(int a, int b, int c)
    return a + b + c;

int main()
    sum3(1, 2, 3);
    return 0;

Continue reading "Functions and Parameters" »

Investigating The Stack With the Debugger

This section assumes I already covered some basics of GDB earlier in the book, which I plan to do.

Once you have some concept of registers and the stack, it’s time to play. Take our original example and save this as stack.c:

int main()
    int i = 0x11223344;
    char s[4];
    s[0] = 'f';
    s[1] = 'o';
    s[2] = 'o';
    s[3] = '\0';
    return 0;

Continue reading "Investigating The Stack With the Debugger" »

The Stack

Every thread in every process has a stack. This is where local state is kept, including:

  • All variables declared on the stack.

  • Parameters to function calls.

  • The pointer to the calling function’s stack base.

Let’s look at an example. Say my C code defined some variables on the stack like so:

int i = 0x11223344;
char s[4];
s[0] = 'f';
s[1] = 'o';
s[2] = 'o';
s[3] = '\0';

Continue reading "The Stack" »

Introducing the Machine

As best I can tell, the Intel 8086/8088 processor and its successors were designed by sadists. In the future, Skynet will win and the machines will destroy humankind because the great-great-[…]-grandfathers of the 8086 became so unfathomable that nobody could comprehend their function and, therefore, their evil plot.

I will focus on the 32-bit i386 instruction set because:

  • i386 32-bit instructions will work on both 32-bit and 64-bit x86 processors.

  • Most of the existing documentation, on the web and in books, covers i386.

  • If you don’t have an i386-compatible machine, you can buy one cheap, cheap, cheap and run a free operating system on it.

I will use the GCC compiler and GDB debugger for my examples. You can get this free for most any operating system; for Windows I would recommend running GCC under cygwin.

Continue reading "Introducing the Machine" »

The Tao of Computing

Author’s note: This post is intended to introduce a larger section of the book (at least a chapter), not stand on its own.

Expert programmers have all had “ah-ha” moments where, all the sudden, several concepts that were all unclear crystalize into one revelation and become clear. An expert mechanical engineer described this concept as going “above the clouds;” one moment you were lost in the soup, the next moment you break through the clouds and you can see clearly where you are and where you’re going.

Continue reading "The Tao of Computing" »

Code Reviews

At some point your code will be the subject of a peer review. Many programmers loathe, detest, and double-plus unlike code reviews, but there’s really no reason to. In fact, experienced programmers look forward to code reviews—we’ll see why shortly.

Person and Perspective

The reason so many code reviews go bad is because the programmer makes a connection between the his code’s worth and his self worth. When reviewers point out problems in the code, the programmer takes insult, gets defensive, and things go downhill quickly.

Continue reading "Code Reviews" »

Methods of Software Development

As a product gets larger and more complex, the development team needs to answer certain questions:

  • “When will it be done?” The rest of the company is waiting for the product to ship. They’ve got a rollout plan, a marketing blitz, perhaps manufacturing… all kinds of stuff that hinges on when the product will be done. So are we there yet?

Continue reading "Methods of Software Development" »

Software Over Time

NOTE: I’m really skipping around here. Let’s get away from business principles for a bit and focus on software.

In school, the lifetime of your programs is often days, weeks, maybe months at the very most. You’re given an assignment, some input data, and expectations about what the output should be. Write the program, turn it in, and now that program is dead.

That’s not how it works in industry. We’ve got a saying, “bad code lives forever.” In reality, it seems like most code lives forever, good or bad. The lifetime of a program is at least measured in years, sometimes decades. This one factor, time, has tremendous implications for how you write and maintain programs.

Continue reading "Software Over Time" »

Products, Customers, and Value

Do I need to keep saying this is a first draft?

From here out I’ll refer to “product” in the generic sense; something the customer uses, whether it’s a product or a service. But while I simplify that, I need to expand on who exactly this “customer” is and what value they get from the product.

Continue reading "Products, Customers, and Value" »


NOTE: First draft.

Up until now I’ve been talking about a “product” that makes money. That’s a simplification of several factors. Let’s de-simplify.

Continue reading "Products" »

The Role of The Company

NOTE: I’m hopping around, and will continue to do so through the month. All usual “first draft” disclaimers apply, too.

Let’s say you’ve joined a company that’s setting out to change the world. When Frobnicator 1.0 ships, it’ll revolutionize people communicate, keep track of their kids, and do their laundry. That’s fine and good, but Frobnicator 1.0 is not the underlying reason the company exists.

Continue reading "The Role of The Company" »

Introduction: Overview

NOTICE: usual disclaimer applies. First draft. Structure of this book likely to change.

I obviously can’t teach you everything there is to know about industry. You’ll forge your own unique career path and no book could teach you exactly how to do that. But there’s a lot of common topics that I can address to help you get your career off on the right foot.

Here’s an overview of what’s to come:

Continue reading "Introduction: Overview" »

Introduction: Who Should Read This Book

So that’s where I’m coming from. Let’s talk about where you’re coming from. I expect fans of this book to fall into a couple broad categories:

  • College students taking Computer Science classes and wondering, “is this what programming is like in the real world?” (Short answer: no.)

  • College grads already in industry, who have noticed first-hand that the answer to the first question is “no,” trying to get their heads around the disparity.

  • People, young or not, who are considering a job in programming but want the skinny on what the books and classes aren’t telling them.

You’ll notice this isn’t a “…for Dummies” book. I assume you’re smart. You probably know a programming language or two. But until you’ve been in industry for a few years “you don’t know what you don’t know” about doing programming as a profession. That’s where this book comes in.

Introduction: Why I'm Writing This Book

NOTICE: this is a first draft for PragProgWriMo. It’s not polished. Posts may not be in sensible order. Read at your own risk.

Let me explain my motivation for this book with three stories.

The Advisor

First, my advisor at Duke University was known as the guy to have. He was young, bright, a Rhodes Scholar, and the star of the Electrical Engineering department. I went to him during my sophomore year and asked which of two courses I should take to fill a requirement, with the condition: which would be most useful in industry? He said, and I quote exactly, “I have no idea. I’ve never worked a day in industry in my life.” I left that meeting more than a little disillusioned—just what the hell kind of education was I getting here?

Continue reading "Introduction: Why I'm Writing This Book" »

PragProWriMo: My Book

The guys at Pragmatic Bookshelf are issuing a challenge: write the first draft of a tech book in a month. I'm taking them up on it. Every weekday in November I'll be posting a couple pages worth of my book, tentatively (and badly) titled What Your Comp Sci Degree Didn't Teach You About Professional Programming. My target is young and aspiring programmers who are still in school or recently graduated, trying to figure out what the "real world" of programming is like, and what they're missing.

Keep in mind every post here is a first draft. I will leave comments open, and I always read them, but I won't have a chance to respond to every one. I do, however, appreciate your feedback.

With any luck I'll convince the PragGuys to publish this—after many revisions—as a "real" book. But let's start with the November challenge and go from there.

Hacking MacOS X Tiger

Scott Knaster's new book Hacking Mac OS X Tiger is out! I had the great pleasure of contributing to two chapters in this book; one on creating Dashboard widgets and another on creating Spotlight importers. Scott is a long-time hero of mine, having authored the definitive books on old-skool Macintosh programming. Then he was a big player in getting me hired at General Magic, easily the coolest job I ever had. Now I actually have my grinning mug in his newest book. Wonders never cease.

So buy a copy already!

Great Ideas in Computer Science: A Gentle Introduction

Back in my university days I had the great honor of contributing to one of my professor's textbooks, Great Ideas in Computer Science - 2nd Edition: A Gentle Introduction by Dr. Alan Biermann. I contributed to the Simulations chapter, specifically pp. 198-202. I can't say I'm proud of the code (or any code I wrote in school) but it sure was fun.

The idea was modeling evolution with a genetic code that translated into operations (e.g. move, rotate, eat) and finding mates. Mating would produce offspring that spliced genes from each parent. Iterate until all the entities are dead. Then the exercise is to look at the final generations and the properties of their genetic code.

I did my simulation in C, but much cooler simulations have been done in Lisp where the genetic code really contained code that could be modified as part of procreation or random mutation. Some day I'll need to revisit this project.