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.)

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.

• 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.

As a hiring manager, my job is to make sure you can do the job you're applying for. For programming that means you need to be able to program. So when I whip out a laptop in our round-one interview and ask you to write some code, try to hide your terrified expression.

The Case For

Back in the 1990's I had my moment of revelation: a pal of mine, a far more experienced programmer than me, showed me how C code compiled into assembly. This was on the Motorola 68K instruction set. I learned to walk through how the stack works, how pointers work, how loops work... it all finally made sense. From that time forward, I've had no fear of C or C++ because I know how the language morphs the code I write into the code the computer sees.

My daughter Genevieve performing in her first ballet recital. Photo toned to black-and-white using Alien Skin Exposure.

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.

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.

Portrait of my grandmother. I don't consider myself a portrait artist but I do get lucky once in a while. On-site lighting was two flashes bounced off the ceiling. Photo toned to black-and-white using Exposure 2 and vignetted with Bokeh.

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.

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.

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.

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.

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;
}