Why I want to work at Fog Creek

I'm applying for a summer internship at Fog Creek Software, a well-respected software company in NYC. I'm going to be interviewed by one of their developers next Tuesday, so I've been trying to anticipate the questions I will be asked and give them some thought. Tonight, I asked myself a simple but important question: "Why do you want to work at Fog Creek?"

First, I thought I wanted the experience. An internship at a reputable software company would look great on my résumé. I briefly considered whether I was in it for the office. Then, I thought that I wanted to prove to the world that I could build software, not just make little toys and read big books. However, I quickly realized the true source of my motivation: I want to work at Fog Creek to prove to myself that I can build software.

Until now, my most substantial project has been my work on OpenInkpot last summer. Assembling a cross-toolchain is highly technical work, but it's not a creative act. I didn't design the structure of the toolchain; I just put the pieces together.

I've tried to prepare myself for a career as a software developer by reading books on software structure and construction, but I know that's not enough. I won't know that I'm ready until I've built something real.

To become a software developer, I must develop software.

I was dead wrong

More than a year ago, I posted Programming is more than pointers and recursion, arguing that CS students don't need to learn about pointers and recursion. I wrote it in response to The Perils of JavaSchools, a 2005 blog entry in the legendary programming blog Joel on Software. I realize now that I was dead wrong, and I've decided to explain why (not only because someone from Fog Creek Software will be evaluating my blog.)

My central argument was that since pointers and recursion aren't often used in the software development industry, they aren't necessary topics for CS curricula. I was high on Python and Design Patterns at the time and fervent in my belief that all problems could be solved with straightforward, readable code. What I failed to realize is that if you can't (not don't) understand pointers and recursion, you can't have a meaningful career in programming.

Understanding pointers means more than memorizing the illogical C pointer syntax. It's an understanding of the difference between reference and value, between creating lightweight pointers and copying massive objects. Any programming job that doesn't require you to think about whether a variable should be a pointer or a value probably doesn't provide any challenge or variety. It certainly wouldn't provide any job security or marketable skills. Pointers are fundamental to programming.

Likewise, recursion is more than replacing a function call with the function's body; it's an illustration of the encapsulation of functions. Recursion is a stepping stone to first-class functions and closures. These aren't academic knick knacks with no practical application; they are powerful features in many popular languages.

In summary, Spolsky was right and I was wrong. Pointers and recursion are powerful tools that belong in the belt of every software developer. If you can't learn them, stick to HTML and CSS.