Full SIGGRAPH Trip Report: day one | two | three | four | five

## Saturday, August 6, 2011

### The Passionate Programmer Review

Jon McCaffrey's review of The Passionate Programmer by Chad Fowler motivated me to read it myself. I used to read lots of books like these, but over the past six or seven years, I’ve buried myself so deep in graphics that I've read very little general development books. It’s time to change that.

The Passionate Programmer is well worth a read. At about 200 pages, it is short, readable, and inspiring. It contains 53 bitesize chapters on being productive, marketing yourself, staying sharp, etc. I agree with the vast majority of the book's advice. It is a particularly great read for students and new developers; it will get them in the proper mindset to be awesome developers as Chad would say. If you are more experienced, you are probably already doing many things in this book; if not, you should consider them.

One of my favor chapters is 4. Be the Worst, which suggests surrounding yourself with the best developers you can, because doing so makes you grow faster and perform better. I couldn't agree more!

You would think that 14. Be a Mentor contradicts the advice of being the worst, but it does not. It is important to be a mentor to new developers because teaching is one of the best ways to learn. Do I really know how the automated build and test system works? I will once I try to explain it to someone.

Being a mentor also helps a team gel and integrate new developers quickly. If there is one thing our industry needs to get better at, it is mentoring. Electricians, plumbers, and tattoo artists do apprenticeships. Software developers do not. How often do we sit down with the experts in our development teams and learn from them? Probably never, or not often enough at best.

In 28. Eight-Hour Burn, Chad argues to only work eight-hour days but work with the utmost intensity. Working longer days leads to burning out, wasting time, and less overall long-term productivity. I agree; however, I am a hypocrite. Given my outside writing and teaching activities, I am consistently over 70 hours a week, and sometimes much higher. The only justification I have is writing and teaching are different enough from developing that the burn out isn’t as severe. I know I can't maintain this pace forever though.

Perhaps 39. Let Your Voice Be Heard is my favorite piece of advice. Chad suggests thinking beyond your current employer and contributing to the industry as a whole, first with a weblog (I don't know why he didn't just say blog), and eventually through publications and presentations. I really like this advice because there are a lot of sharp people in our field, and it is great to have everyone share ideas.

I don't think any advice in the book is terrible, but some needs to be put into perspective. For example, in 27. Learn to Love Maintenance, it is argued that maintenance development can allow for freedom, creativity, and direct-customer interaction. For old, large applications, this isn't always true. If you are working on a twenty-year old, multi-million line application that has seen the hands of hundreds of developers at various stages in their careers, maintenance is often a test of patience. For example, do we really want to continue to design legacy APIs using COM? Is making our code const correct easy when all the code we call is not? Do we really want to integrate old code using a struct for vectors with new code using a class? No. we want to build our skills using modern technology and techniques.

I advise interns and new grads to get in on the ground floor of a new project. They will be given the best opportunity and most responsibly. They will see the big picture, and will accelerate their skills faster than being bogged down by long build-times, legacy code, and legacy mistakes. The contractor who built the house learned much more than the contractor who remodeled the bathroom. With all this said, if you get an opportunity to work on a large, outstanding piece of software - say the Linux kernel, for example - you should go for it.

One final comment: this book is a revised edition of the book My Job Went to India: 52 Ways to Save Your Job. Naming a book is really important, just like naming software, classes, functions, variables, etc. With the original title, I would not have paid this book any attention. The revised title – and I assume content – made it really appealing. Naming is hard.

Overall, The Passionate Programmer is an inspiring, worthwhile read.

## Tuesday, July 5, 2011

### Book Signing and More at SIGGRAPH 2011

Stop by the A K Peters / CRC Press booth at the SIGGRAPH exhibition on Tuesday, 08/09/2011, from 1:15-2pm for our virtual globe book book signing. Even if you don't have (or want) a copy of our book, stop by to chat about anything related: OpenGL, 3D engine design, computer science education, etc. If you have a copy you want me to sign but can't make the signing, email me (pjcozzi@siggraph.org), and we'll meetup sometime during the conference. If you're interesting in submitting a proposal for OpenGL Insights, also email me if you want to chat during SIGGRAPH.

If you really want to stalk me, and I fully encourage it, stop by the poster session either right before the book signing on Tuesday, 12:15-1pm, or on Wednesday, also 12:15-1pm. I will be presenting a poster I worked on with Deron Ohlarik called A screen-space approach to rendering polylines on terrain. We are quite happy with the technique and are even using it in commercial code. We are also honored that it was mentioned on the Real-Time Rendering blog (full disclaimer: Eric reviewed the abstract before we submitted it. He also reviewed the abstract for the poster I presented last year. Man, I owe him).

In other book-related news, Brano Kemen from Outerra wrote the first book review we are aware of, and there has been some book-related discussion on the NASA World Wind forums. We're excited that a lot of people are excited about our work.

## Saturday, July 2, 2011

We recently added several things to our book's website, including a zip of the example code with build instructions for Windows and Linux (Ubuntu); a zip of most of the book's figures, available under fair use; the bibliography with hyperlinks that all work as of today; and the back cover:

Posting the figures and bibliography is a great idea we borrowed from Real-Time Rendering, who has set the bar for book websites quite high.

More exciting news: Amazon says our book is "in stock but may require an extra 1-2 days to process." Hopefully it is shipping by the time you read this.

## Friday, June 24, 2011

### Resume Tips for Computer Science Students

Here are some resume tips I've learned over the years. I've interviewed about 100 computer science candidates, mostly interns, and have been a technical recruiter at least a dozen times at university career fairs. I've seen thousands of resumes, and have hopefully learned some things you will find useful. For the most part, I've left out obvious recommendations and, instead, focused on tips you may not have heard - or heard from the same point of view. In my youth, I was heavily influenced by Joel, so I probably borrowed some of these ideas from him.

Almost every computer science resume has a section that looks like:
Skills:  C, C++, C#, Java,.NET, WPF, OpenGL, Direct3D, GLSL, Visual Studio, Eclipse, NUnit, JUnit, NAnt,...

I'm tempted to recommend removing this section entirely. It does have some uses though; it is good for google searches and HR/manager buzzword hunters. It can also paint a quick profile: is this person a client-side graphics developer? a server-side PHP/MySQL developer? An architect astronaut?

In order to play the game with the less technical folks, I am OK with candidates including this section, but these skills need to be backed up throughout the resume. For example, if OpenCL is listed but I don't see any evidence elsewhere in the resume, I will be skeptical. If I ask about it in an interview and the candidate doesn't have any experience or even exposure to the topic, they have just lost integrity points.

If you list something in the skills section, make sure it is proven elsewhere in your resume, e.g., "Implemented a GPU-accelerated cloth simulation using OpenCL, which resulted in a 30x performance improvement over a multithreaded C++ version." The buzzword hunters will give you extra points for having multiple instances of the buzzword, and technical folks are more likely to believe you.

## 2. List Coursework Strategically

 This motorcycle has nothing to do with resumes but it sure is fun to ride.
For a student or recent graduate, it is a great idea to including a "Selected Courses" or, better yet, "Favorite Courses" section that highlights some unique courses you have taken. It is an even better idea to tailor this section, and your resume in general, to each employer. Applying to Google search? Include Distributed Systems and Machine Learning. Applying to