DevOps Zone is brought to you in partnership with:

Cody Powell (@codypo) is the cofounder and CTO of Famigo. Famigo's main offering is a cross-platform recommendation engine for mobile content, helping families find things like the best android apps, best iPad apps, and free apps. He's a graduate of Trinity University, an ardent supporter of the Texas Rangers, and he makes a mean mojito. Cody is a DZone MVB and is not an employee of DZone and has posted 26 posts at DZone. You can read more from them at their website. View Full User Profile

A Unified Theory of Software Karma

01.21.2013
| 4026 views |
  • submit to reddit
I make a lot of jokes at work about code review karma.  Here's the idea: each time a person volunteers to review others' code, that person build their code review karma.  Then, when it comes time for that person's own code to be reviewed, the reviews go smoothly due to the store of code review karma.

Build karma works the same way.  When someone jumps in to help fix the build, they're accruing build karma.  Thanks to build karma, the builds that kick off from that person's own commits are far more likely to be successful.

If you have a lot of time on your hands, you can actually see software karma all over the place: QA karma by helping out your testers, refactoring karma by cleaning up the scariest bits of the code base, planning karma by leading sprint planning, etc.  The more you help, the more the software gods reward you in the future.

I see two explanations behind software karma.  The first is that there actually are software gods who sit upon Mount Codelympus and keep a running tally of all these helpful acts.  They probably keep this tally in Emacs, since that was clearly not designed for mortals.  If there is any truth to this explanation, then let's all quickly sacrifice a 'PHP for Dummies' book to appease them.

The other explanation is less exciting, but slightly more practical.  By reviewing others' code, you build a mental model around what great code looks like.  When you go to write your own code, you apply your model and reap the rewards immediately.  By fixing broken builds, you build a mental model around the build process and how it can go wrong; your own builds are far less likely to go wrong thanks to that model.  Same thing goes for helping QA, refactoring, sprint planning, and so forth.

I'm not taking sides on which explanation is correct, since I don't want to get struck by a lightning bolt or incite a plague.  All I do know is this: if you want to get better as a developer, boost your karma.
Published at DZone with permission of Cody Powell, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Willie Wheeler replied on Wed, 2013/01/23 - 2:53pm

Facebook incorporates a build karma metric into their actual release process. It is one of the factors that determines whether the release engineers will cherry pick your change for one of the daily releases.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.