Archive of published articles on February, 2011

Back home

Hello San Francisco and GDC 2011!


I’ll be giving a talk as part of the TA Bootcamp on Tuesday, entitled “Ending the Culture War: Building a Better Pipeline by Uniting Tech Art and Engineering”. I’ll have the slides up after the talk, with full text narration (as I did last year and will continue to do going forward).

If you’re in town and want to meet up, just send me an email! I’ll also be at the meetup on Tuesday night.

1 Comment

SmartBear’s Code Collaborator for Code Reviews


We’ve been using SmartBear’s Code Collaborator at BWA on the engineering side for a few months and I think it has worked out real well. I recently forced it upon Tech Art and we’re seeing immediate gains and I’d highly recommend the product.

The big problem we had (on Tech Art and Engineering teams other than the Tools team I’m on) is that we had no ‘culture of code reviews.’ Everyone just paid lip service to them- even me, because I was never really allowed to be as forceful with requiring over-the-shoulder reviews before all check-ins as I wanted to be. So I’d do most reviews after-the-fact, which was slow, via the clunky format of email, and would often go unheeded.

Code Collaborator, most of all, provides an automatic culture adjustment, because suddenly code reviews are a formal part of the checkin process. This may be obvious or absurd, depending on your experience. But it took a true formalization of the concept via a concrete (and polished!) tool like Code Collaborator to get us where we need to be regarding code quality and code reviews.

I just wanted to put that out there, as I’m up at midnight doing code reviews…

No Comments

Bill Gates on great programmers


Excerpt from an interview with Bill Gates in the 1986 book Programmers at Work:

I think after the first three or four years, it’s pretty cast in concrete whether you’re a good programmer or not. After a few years, you may know more about managing large projects and personalities, but after three or four years, it’s clear what you’re going to be. There’s no one at Microsoft who was just kind of mediocre for a couple of years, and then just out of the blue started optimizing everything in sight.

I agree with a caveat (that may not have existed in 1986 but does now). I think certain people’s minds are better set up to do different types of programming, and it may take a few years for them to find that type of programming- and once they do, they may shine, perform significantly better. Different types of programming could be programming at a different level of abstraction (managed vs. unmanaged code), different areas (database, client, graphics, applications), or practices (OOP vs. FP).

That said, I feel like the caveat only applies to maybe 5-10% of the people that wouldn’t otherwise be good programmers.

I think the quote is important to keep in mind when doing hiring- experience can be a very poor indication of competency, skill, and mentoring ability. If you get a veteran, their potential is known, whereas someone with less than three or four years experience has some of his or her fastest growth ahead. So if you consider it that way, all other things being equal, you may be better off hiring someone with less experience.

No Comments

Fixing things is easy, but you must be careful about what you fix


On NPR/KUT a few months ago, I was listening to a short story called ‘The Fix’ by Percival Everett. It was about a character Sherman Olney, who could fix anything- refrigerators, car engines, relationships- even bring people back to life. When asked by his employer (the owner of some sandwich shop) about his ability, he says:

Fixing things is easy. You just need to know how things work.

Once things once again spiral out of control, he has these cautionary words:

You have to be careful about what you fix. If you fix the valves in an engine, but the bearings are shot, you’ll get more compression, but the engine will still burn up. If you irrigate a desert, you might empty a sea. It’s a complicated business, fixing things.

I really like these words. Knowing how things work is part of our jobs as engineers. But it can easily get you into trouble- what you really need to know is how things work together. Knowing how a system works, not just at its formal level- we can all look at a diagram of a simple engine and understand the parts- but at the micro, atomic level and the high, contextual, historical level, is vital to truly understanding any complex system.

So the hard part is identifying when you know how things work, and when you know how things work together. It’s worth the extra inspection and discussion and prudence to figure it out, and make sure others figure it out.

No Comments