Play nice and bait the nerds

The better part of software development: talking about it with your peers.
The better part of software development: talking about it with your peers.

Over the years, I’ve noticed that regardless of the work I’m thrown at, I usually get my work done, and more often than not, I get it done on time. However, there are a plethora of engineers that are wayyyy better than me. After all, I get to work with some of the brightest engineers I’ve ever met. Interestingly, however, not all of them get their patches in, or their work done in a timely fashion, which has got me thinking… call it old age, reminiscing, or too many beers.  What makes it easier to ship things on time when you need to appease so many people in an open source project?

I’m actually quite happy to be surrounded by very smart people. That in part, has been part of my secret. Surround yourself with people much smarter than you, and entice or coerce them to review your work. Everyone’s better in the process.

A colleague once told me, “in our industry, smart is a dime a dozen, but people you actually want to work with… that’s a very small subset”. I really hope he meant me. Then he added, “and people that also ship stuff on time– that’s very rare”. And that has been my goal at work for a long time: be that guy– be the guy that ships stuff on time, and is a joy to work with (well, mostly ;-)).

Working on free software projects is challenging to say the least, and GCC seems to be the poster child for difficult children that are hard to work with. Things have gotten better over the years, but it is by and large a playground filled with difficult people whose egos are too easily bruised.

So here are a few thoughts on getting engineering work done, but mostly from a social perspective. I hope I don’t offend anyone; it is certainly not my intention.

Get a global reviewer interested in your work (“core maintainer” in the parlance of other projects). According to the MAINTAINERS file there are 14 of them, and well over half of them are actively involved in GCC development. Getting one of them interested in your pet project not only makes it a lot easier to incorporate into the code base, but will likely give you a de facto reviewer, and a very valuable sounding board. You’re free to go about it alone, but if there’s no global reviewer on board there’s probably a reason for it– no one thinks it’s worthy to incorporate, making your life doubly hard. Don’t take me wrong, you may be right, and you may very well be smarter than all of us, but the task will be increasingly difficult.

If you can, get two global maintainers interested. That’s the holy grail in my opinion: two distinct and talented heavy hitter reviewers, preferably from different companies. If you manage to appease them both, your work will be so easy it will virtually write itself :).
Be on good terms with those that review your work. This works in life in general (usually spouses and partners ;-)).  The open source community is mostly a volunteer community, and even those of us that get paid to do it, can only be forced by our respective bosses. So unless your reviewer also works for your boss, no one is obligated to do anything for you. Remember this (here and in life).

You can get more bees with honey than with vinegar, goes the adage. The GCC community is a rabid beehive, but they respond very well to honey (and beer!). Face to face interaction goes a long ways, and knowing those you work with in a personal setting helps tremendously. It’s much harder to be an ass to those you’ve shared bread and beer with, than to an email address with funny symbols at the end.  Use the regular open source meetings to your advantage (GNU Cauldron, Usenix, Red Hat Summit, etc etc). Who knows, you may get some really good friends in the process: some of my best drinking buddies speak better C++ than English and have been reviewing my work for decades.

Do your homework before asking! It’s OK to periodically ask questions without first doing your homework (especially in a chat room). Something like “does anyone remember the name of the macro that does X on GCC?”. You can ask this on IRC every once in a while, but don’t use the mailing list for this. Generally, we like to know you did everything you could to answer your own question. Obviously, we don’t expect you to be an expert on everything, and some things are particularly tricky, so you can stop debugging at reload() and ask Vladimir Makarov ;-).

For example, a post like the following shows that not only did you do your homework, but that you are willing to help further: “I am getting a failure at point X because declaration Y was defined as Z and optimization B transformed its load into C. I compared the same scenario with other architectures and only architecture FOOFOO is affected. Is this something particular to FOOFOO, or am I overlooking something obvious? If this is a bug, I would be happy to open a bug report. I can also debug this thing further if someone can help me understand optimization B better”. That was quite a mouthful, but it shows good will instead of laziness on your part.

Even better, offer solutions (even though they may be incorrect). I secretly think that engineers love pointing out problems and gently rubbing your face in them. I think it’s a character trait most of us have (past wives and girlfriends have told me so). Use that to your advantage! Many engineers may not voluntarily offer suggestions for your problem, but will be more than happy to point out errors in your approach, sometimes even fixing the problem while they’re at it.

Pose your question in the form of a solution, and I bet you’ll get more responses than just asking straight out. I’m telling you, it’s a character flaw. We can’t help ourselves!

Over all, contrary to popular belief, open source communities are fun bunches and its members respond just like real people in the real world (*gasp*). I know, it’s weird.