Joel Spolsky’s love letter to program management

Joel Spolsky wrote a love letter to program management on his blog. For the most part, it is a pretty reasoned and reasonable description of what a “good” program manager at Microsoft (and Fog Creek) is like. In my career at Microsoft, about 25% of the program managers fit that bill. The problem was that they had too many conflicting roles and required skillsets to be effective. At Microsoft, Program Managers are not only responsible to be user advocates, they are also responsible for functional specifications, user interfaces and schedules. A single person can’t be a user representative, a UI designer/interaction specialist, and a project manager. Combining them into a single role worked for Microsoft initially, but in the modern world each of these roles are full disciplines of their own.

Joel claims that PMs are partners with development and that developers have the upper hand over PMs because they write the code. This might have been true of Microsoft in Joel’s (and my) time, but as MS switched from being an engineering-driven company since Ballmer took over to a program management-driven one, it isn’t true any more. PMs took the upper hand because they had far too much control over the final look and feel of the product and could essentially name themselves the final arbiters. Development and QE were isolated from the customers. PMs dictated the features; meaningless meetings and committees abounded and the products suffered (every MS product in the last 8 years for example).

How to be a program manager – Joel on Software

Writing a functional specification is at the very heart of agile development, because it lets you iterate rapidly over many possible designs before you write code. Compared to code, a written spec is trivial to change. The very act of writing a specification forces you to think through the design you thought you had in your head, and helps you see the flaws in it quickly so that you can iterate and try more designs. Teams that use functional specifications have better designed products, because they had the opportunity to explore more possible solutions quickly. They also write code faster, because they have a clearer picture when they start of what’s going to be needed.

This claim is just wrong, or rather, doing this in the large scale is just wrong. I’ve worked under that system at Microsoft for years and I never saw it be very successful in practice. Maybe for a small part of a product, or a small iteration in a larger cycle it might work; but at the product level it is nearly always a bust. Why? Because you will not anticipate everything in your functional specs. Ever. A competing product will be released with better features. Flange A will not fit Bracket B. User testing will hand you your hat. Beta testers will tell you that it wasn’t really what they needed. And then you are back to the drawing board. Except you are two-thirds of the way through the cycle because you spent a huge amount of time iterating over the spec and then building to that spec. Now everything is screwed up, but QE needs to start testing to the spec RIGHT NOW. So what do you do? You hack. The spec goes out the window and development codes for dear life while program management throws out ideas and changes like pieces of spaghetti against the wall. At the end of the cycle you have a tarball mess of code with incongrous, hacked, features that came crashing onto the deck of the carrier and just caught the last wire. Watefall development is resistant to change, agile development embraces it. Change happens faster in our industry every year, why lock your developers into software methodologies from the 70s?

Is there a role for Program Management? Absolutely. Not for the Microsoft-style Program Manager, but certainly for the jobs that the Microsoft Program Manager has. UI design and look and feel is best managed by professional user interaction specialists working with a project manager and development. The project manager can also be the primary representative of the client, but not the sole conduit. One of the primary jobs of QE is to be a user representative. Isolating development from the users just means that they don’t understand why they are doing what they do. Isolating QE from the users mean that they can’t represent a user of a product in their testing. The Program Manager can also work with development and QE to manage the schedule.

My experience with great program mangers post-Microsoft are folks that coordinate across all the functional groups to make sure that development has what they need, QE understands the user, experience design is delivering on time and all the clients are feeling well represented. In this view, the program manager acts as a lynchpin connecting development, QE and XD to their customers. Do they set the schedule? no. Do they write the specs? Maybe (in a non-agile team, working with the other groups). Is that less fun for the program manager? Maybe, but it produces much better products in my experience.

Did a mock technical interview event tonight at UW (more tips for college CS students looking for a job)

It was actually a lot of fun. Usually when you are doing a real interview, you can’t really take the time or energy to explain to the candidate what they did wrong and how they could improve. Also, I was very impressed with the quality of the candidates. At Microsoft, I interviewed a lot of college grads in the last few years from schools like Berkeley, Stanford, Princeton and other CS powerhouses. Most of those students were pretty weak compared to the students I talked to tonight.

There were a couple pieces of advice I offered to all three candidates. Most of this is only relevant for recent college grads, but some may apply to others as well.

  • Learn more C++. A lot of CS schools like teaching Java. It is fairly good for teaching some of the fundamentals of Computer Science. However, it is still not very popular in the software industry outside of server software. If you are looking to be a developer at a software company, you will almost certainly be writing in C++ and you will have an edge if you can write good C++ in your interview.
  • Practice programming problems. Most software companies that I know (including Adobe, Microsoft, Google and Amazon) do whiteboard-style interviews. You will be given a programming problem and will be expected to write code to solve it. You may also be asked a logic problem. There are many web pages that have actual technical interview questions, you should use them to practice with.
  • Wear appropriate clothing. Unless you are doing software development as part of a consulting company or at a bank or insurance company or something, developers wear jeans. Wear nice jeans, without holes. Don’t wear gym shoes (even cool, expensive ones). Wear a nice shirt. Do not wear a tie or jacket: you will be uncomfortable and will feel out of place. You want to look nice, but comfortable.
  • Be honest about your abilities. Don’t lie about what you know. We’ll figure you out pretty fast.
  • You are not a 9/10 in C++. This is one of my pet peeves and I’ve written about it before.

Now about your resume

  • It should fit on one page. Unless you were working in the industry for years and years, you should be able to fit all your info on one page.
  • Your hobbies and outside interests are not relevant. It is resume filler and will have no bearing on if you get an interview or not.
  • Your job experience outside of the industry isn’t important unless it is relevant to the position you are seeking. If you have relevant or significant full-time job experience (ie: not retail or food service), you should list it. If you were a manager in a non-tech business, that might be relevant if you are looking for a management position, but not an individual contributor position.
  • Put the most important stuff first. People read top to bottom. If the top of your resume isn’t compelling, people reading it won’t make it to the bottom. When I was younger, I used to have my education at the top of my resume, because I didn’t have as much experience. Now my experience is at the top since I’ve been out of school for 15 years. When I look at college grad’s resumes, I look at the school (do I know it?), then I look at their job experience (have they programmed professionally?), then I look at their skill sets (do they know C++?). Unless one of those things stands out to me, I won’t bother looking at the rest.
  • List classes taken which relate to the position you are applying for. I don’t need to know every class you took in college, but if I’m hiring a graphics programmer and you took 3 undergrad classes and a graduate seminar in computer graphics, I want to know.
  • Think about keywords. Most resumes come in electronically now, via a company’s website. There they go into a database. When a position is opened, recruiting will do a search on their database looking for keywords: C++, graphics, windows, etc… Make sure that your resume will be found in those searches.
  • Target your resume to the position you are interviewing for. This could be a lot of work, but it is worth it. You may not need to change everything, but at least change your objective. If you are applying for a lot of jobs, you may want to make different versions of your resume for different classes of positions. I have three different versions of my resume which emphasize different skillsets depending on what kind of job I am applying for.
  • Don’t write a wishy-washy objective statement. I’m kinda over the whole “Objectives” thing on a resume. Obviously, you want a job. Everyone wants “a challenging position with an interesting company, utilizing their skills and allowing growth potential.” Yawn. This is the one place where it really is important to tailor your resume to the position you are applying for. Especially, if you are moving from one area (QE) to another (Development).
  • Use good ideas from other resumes. The Microsoft Word resume templates are not your friend. Everyone knows them now. Luckily, you kids have this thing called the interwebnet which allows you to find a zillion resumes and look at the best ideas from each. Everytime I see a good idea from a resume (a better way of listing experience, a more consise way to describe skills), I see if it is something that can help make my resume better. The actual graphic design and layout of my resume grew over years, incorporating ideas from a dozen other resumes. (Please do not directly steal the design of my resume (I’ll make sure that you’ll never work in this town again), but feel free to incorporate some of the ideas for your own).
  • Have someone you know, someone who actually knows how to write well, go over your resume. Engineers are not known for their command of grammar, punctuation or command of the English language. You only need to look at this post to see what I mean.

If other people have more suggestions, I’d love to hear them.