Advice

I spent a lot of time reviewing resume tips (yes, my own, but also several others). I don’t update my resume very often, but when I do, I always look for advice. In the end, I actually threw away my original resume and completely rewrote it. The basic content was the same, but the style was entirely new (and very heavily influenced by resume articles I read). This took quite a bit of time, but was entirely worth it. The final product was much higher quality than what I started with.

One really important thing I did was have coworkers, professors, and my fiancée read my resume. I got some really good feedback from this. I got a few style pointers, but mostly I got substance advice. My fiancée pushed me to clarify and expand on my leadership experience. My coworkers recommended relevant technologies that I should have included. My academic advisor really pushed me to restructure the resume to make it more appropriate for the industry. In particular, he had me highlight my skills and work experience.

Formatting

Another thing I would wholeheartedly recommend everyone do is to prepare both a formatted (ahem, PDF) and a plaintext resume. I used my formatted resume almost everywhere. However, I did use a plaintext resume for a few places that I knew were going to strip my resume down to plaintext anyway. In general, plaintext resumes are not very pretty, but for places that I know are going to strip away the formatting, I would rather provide a plaintext resume of my own creation. Text extracted from formatted documents is rarely pleasant to read.

I do not, however, recommend using plaintext resumes for most job applications, because they still look like crap. Use them only when you really have to. And despite what Steve Yegge says, you don’t need to submit a plaintext resume to Google. I don’t know why he implies that resumes at Google are stripped of their formatting. I almost submitted a plaintext resume to Google because of his article. I’m glad I didn’t, though, because the first guy who interviewed me showed up with a printout of my resume exactly as I had formatted it.

The Cover Letter

Every resume I sent was with a custom cover letter. Form letters look lazy and half-assed, because that’s what they are. A custom cover letter indicates at least a little actual interest in the job. A generic cover letter screams “bulk mail”, which in turn yells “delete me”.

I also made my cover letters match my resume as closely as possible. Some of the positions that I applied for were via an online form, and the only place to provide a cover letter was a text box. For those, I submitted the cover letter in plaintext. For the rest, I made my cover letters match my resume fonts, margins, etc. I think this attention to detail is important. When printed, the cover letter and resume should look as if they came from the same document. This level of attention to detail may not be strictly necessary, but it definitely won’t hurt, and it really doesn’t take much time. Create a cover letter template and you only have to make it match once.

Oh, and I saved every single cover letter I sent. This allowed me to lift sentences when writing new cover letters, but it also gave me a lot of examples to read when I had trouble thinking of what to say. (And I have them saved for the future as well.) Whenever I had trouble deciding what to put into a new cover letter, I’d re-read the others, and several ideas would pop into my head. A little socket work here, a little C++ work there. Examples are extremely useful for me, even when they are my own.

Once I finished my resume and all those matching cover letters, I started sending them out to interesting positions. I had planned on talking about that more in this post, but the resume chatter got long enough, so I’m pushing that off to next time.

By the way, if you want a lot of other good tips, read the comments on my resume tips article. There were a lot of really good tips (as well as a few really bad tips) from the readers.

My first programming-related job was working as a systems administrator during my senior year of undergrad studies. I did a lot of network and computer maintenance that year, but I also had a chance to put together some custom software. After that, I had a grant as a Master’s student to develop science and math projects for elementary school students. As part of this job, I built a new website and database for the grant and all its associated projects. Most recently, I was developing radar software for a small defense contractor. This was my first full-time job, and also my first software-only job. However, it was not a job in a software-only company, and I’ve decided that’s where I want to be.

I don’t want to work for the software division of some company. I don’t want to work in network administration. I definitely don’t want to be anyone’s “computer guy”. I want to be a part of a dedicated software firm.

No one can truly thrive without continual learning. You learn or you fall behind, regardless of what field you are in. No matter how much you know, no matter how skilled you are, others will eventually surpass you if you don’t strive to stay ahead. I know that there are many things I need to learn about building quality software, and I feel that I am likely to learn some of these things best in a dedicated software company.

In a software company, the focus is on the software (or it should be). That means that there is more attention directed toward software quality, toward software development productivity. It means that a lot of the management grew out of the developer pool, and should know what it takes to build quality software. Most importantly, it means that there’s a wealth of talented and experienced developers to learn from. I want to know how to built large systems. I want to learn how hundreds of programmers can work together. I want to discover how world-class software is grown. Maybe I could learn these things at a non-software company, but it would certainly be harder.

There are a lot of software firms in the world, but I can tell you one place where most of them are not: Mississippi. You can probably guess where I used to live.

Since Mississippi has few software firms, it would be rather difficult for me to find my ideal job there. Besides, neither I nor my fiancée ever planned to live in Mississippi forever. Neither of us were born or raised in Mississippi, and neither of us have any wish to grow old there. We were destined to move eventually.

When my fiancée and I started investigating where we should live, we wanted to restrict our search to places that would have abundant jobs for both of us. She’s a psychologist. Most software companies are headquartered in or near large cities. A luck would have it, most people are also in or near large cities. Since more people imply more opportunities for psychologists, our fields’ job opportunities overlap best in major cities. (Funny how most opportunities seem to be where most people are . . . .)

We ranked some of the best cities for both of us, and three options came out on top: Boston, San Diego, and Silicon Valley. She applied for jobs in those three areas, and we decided we’d go wherever she got an offer. In the end, she received offers in both San Diego and Silicon Valley (specifically Palo Alto). Of those two, Palo Alto appeared to have more of a future for her, as well as more opportunities for me. That pretty much ended the discussion of where we should live. She accepted a position in Palo Alto and I began the process of applying for jobs myself.

So, where does a programmer apply for jobs in Silicon Valley? Lots and lots of places. I’ll talk more about that soon.

A few days ago, Half Sigma posted an article claiming that a career in programming sucks. I responded that no, it doesn’t. In turn, I got quite a few comments supporting Sigma. Several of them were centered around Sigma’s first argument, that programming knowledge becomes obsolete too quickly.

Rapid Obsoletion of Programming Knowledge

In an attempt to prove that programming knowledge has a very short expiration date, it’s easy — and common — to drag out an expired technology (Punchcards, Z80, Turbo Pascal, etc.) and then point at it and say, “Look! Look! How does any of that still apply?”

Quite frankly, if you have to drag out punch cards to make your point, you don’t have one. Punch cards died 30 years ago. If that’s the best you can do, the computer science field must not be moving very quickly at all. The Z80 died in the mid-1980s. Even Turbo Pascal was gone before Windows 95 hit the streets. Each of those technologies had more than a 10-year lifespan before it became obsolete. Is it so unreasonable to tell programmers that they need to learn a new technology at least once every ten years?

Hey, remember when plumbers used to use lead-based solder? Plumbing knowledge is obsoleted so fast!

Just like the basics of soldering are partially independent of any specific solder compound, so are the basics of computer science separate from any specific technology. Punch cards are just a storage medium, like hard disks, so much of the knowledge gained during the punch card era is still relevant. Similarly, a programmer who has good knowledge of the Z80 should be able to map much of his knowledge to modern processors. And a skilled programmer who used Turbo Pascal should still be a skilled programmer in a new language, given a brief acclimation period.

If tomorrow morning we all switch to PowerPC computers, programmed in Python, using some funky crystal matrix for storage, my knowledge will not all be obsolete. Certainly, my knowledge of the more quirky aspects of C++ won’t be useful anymore, but the basics won’t have changed. It’s still a Von Neumann machine. Algorithms are still important. Software design practices are still relevant.

Nothing fundamental really changes very quickly. The superficial stuff evolves rapidly, but if your knowledge is only superficial, that’s a different problem altogether.

The Example Game, from the Other Side

If we want to play the “look at this example” game, I’ll just trot out C and the x86 architecture. Both of those have been around for more than 30 years, and they’re both still going strong. They’ve been around since before I was born, and I still use both every day at work. Likewise, C++ and IPv4 have both been around for more than 20 years, and show no sign of dying soon. Even Java and PostgreSQL have been around for 10 years now.

There are many examples of technologies that have been around for more than a decade. In fact, I challenge anyone to demonstrate a dead technology that was once popular and considered important, which didn’t last for at least ten years. I doubt there are very many examples. I think there’s a minimum lifespan before anything can really even be considered important, if for no other reason than it takes a while before a given technology becomes well-developed enough to be utilized by business.

Knowledge Carry-Over

Even when particular technologies die, they still influence future technologies, and so the knowledge base doesn’t disappear or become useless.

Pick any current technology, and you can trace its roots back toward previous technologies. C# was influenced by Java. Python was influenced by Lisp. Ruby was influenced by Python, Smalltalk, and Perl.

Knowledge of any predecessor technology will spill over to the newer technology. Certainly, not everything remains relevant, but there’s definitely some knowledge carry-over. If you’re skilled with Java, C# is not a huge leap. Things are different, but not completely alien. If you’re comfortable with functional and object-oriented programming, you can pick up Ruby.

What Do Employers Want?

Some commenters argued that employers will only hire programmers who are already skilled in the latest technologies. I agree that’s true for some employers. However, I’d argue that it’s not true for most, shouldn’t be true for any, and won’t be true for the employers good programmers should want to work for.

Would I hire an experienced Clipper/dBASE programmer for work on an Oracle project? Yes. Would I hire a good C++ programmer to work on a C# project? Yes.

Good people are far more valuable than specific knowledge. Any decent programmer can learn the syntax and APIs. If you have demonstrated a strong knowledge of database programming, why wouldn’t your knowledge carry over to Oracle? If you are a good C++ programmer, why wouldn’t you be a good C# programmer? If you cannot move from one language to another, then your knowledge is purely superficial, and you are not a good programmer.

If a potential employer cannot recognize that a good programmer is much more valuable than a mediocre programmer “skilled” in the latest buzzwords, then you don’t want to work there. You will almost certainly not be treated well, because the employer clearly doesn’t understand the value of a good programmer.

If your boss doesn’t want you to learn new technologies, then you’ve got a bad boss. Your boss should want, and expect, you to be constantly learning. What kind of idiot thinks that he’s hiring programmers with all the knowledge they’ll ever need?

Technology Changes

You people complaining about the obsoletion of knowledge sound like luddites. It frankly sounds like you’re afraid of progress, and unwilling to learn new technologies. You picked a fast-moving field. Accept that some of your specific knowledge will be subject to attrition. Knowing, for example, a particular object-oriented language’s syntax is transient knowledge. Understanding how to program using good object-oriented methodologies is not transient.

Expect to learn new technologies. It’s part of the field. Learn them at work, or learn them on your own time. But don’t complain to me that your knowledge of Clipper isn’t useful anymore because the world now uses Oracle. If you didn’t learn anything useful while you were using Clipper that would be applicable to Oracle, then you probably didn’t do anything useful while working with Clipper.

Now, I’m not going to pretend that the computer science field doesn’t have any problems. Certainly it has problems. Life has problems. That’s just the way things are. But pretending that the problems are insurmountable doesn’t help anything. Pretending that technology evolves so fast that no one could possibly keep up long term is just a way of hiding the fact that you aren’t interested in keeping up.

If you want to switch fields because you can’t or won’t keep up with the pace of technology, please do so. If you find something you love, then that’s far better than doing something you don’t care about. And if you find a field where you knowledge base never needs to evolve, let me know. I’ll be sure to pass the news on to others who don’t want to program anymore. I have to say though, I can’t think of a faster way to obsolete all your knowledge than by switching to a different field.