Programmer Insecurity and Mea Culpa.

June 13th, 2008 § 6 comments

sorry.jpgBen Sussman-Collins put up an excel­lent blog post on pro­gram­mer inse­cu­rity — this rings par­tic­u­larly loud with me for a few reasons.

The first rea­son is that I used to be that guy — never check­ing any­thing in until I felt it was “per­fect”, then I swung to the other extreme — putting things in too quickly/aggressively.

It’s a fine bal­ance between the two, but one thing he says is espe­cially per­ti­nent in both open, and closed source worlds:

Be trans­par­ent. Share your work con­stantly. Solicit feed­back. Appre­ci­ate cri­tiques. Let other peo­ple point out your mis­takes. You are not your code. Do not be afraid of day-to-day fail­ures — learn from them. (As they say at Google, “don’t run from fail­ure — fail often, fail quickly, and learn.”) Cher­ish your his­tory, both the suc­cesses and mis­takes. All of these behav­iors are the way to get bet­ter at pro­gram­ming. If you don’t fol­low them, you’re cheat­ing your own per­sonal development.

I’ve grown to truly appre­ci­ate peer-review and dis­cus­sion, I feel it makes all the par­ties involved that much bet­ter, and ulti­mately it improves the qual­ity of the code. I’ve grown to miss peer-reviews when I don’t have them — the chance to talk over the design of some­thing and step through the code and debate var­i­ous design points and pos­si­ble improve­ments is very, very valuable.

Fail­ure is not per­ma­nent with code: It is a tran­si­tional state which can be overcome.

That all being said: I must issue a mea culpa. Ear­lier this week I put together a patch for the mul­ti­pro­cess­ing pack­age inclu­sion into python-core. Note that I’ve been using this pack­age for some time, on mul­ti­ple plat­forms — the tests have not failed me, and I felt that things were A-OK.

Once in though, the build­bots started doing some­thing which reminds me of a par­tic­u­larly rowdy party at Lin­ux­World way back — namely, all of them started churn­ing away and promptly began puk­ing on them­selves. At least unlike me, they didn’t mis­place cloth­ing or their hotel.

So, I broke the core.

I’m still chas­ing down the prob­lems — we’re suf­fer­ing test lock-ups and a few com­pile errors on cer­tain plat­forms (debian ppc for the loose). I feel awful because I did drop a code-bomb on Tues­day in my urgency to make the beta on wednes­day. Drop­ping some­thing that big right before a dead­line is just poor form, and because of it — the betas didn’t ship.

With that said: The work Ben Peter­son, Adam Olsen, and many oth­ers have done to help (me/core) has been phe­nom­e­nal and it sim­ply reen­forces why work­ing in a com­mu­nity is so valu­able for me. Now I just have to fix it. Any­one else want to help?

  • Georg Brandl

    Don’t feel bad — there were lots of other issues marked “release blocker” at the time the beta should have been out, and gen­er­ally I feel that the new sched­ule fits our progress much bet­ter. Sure, mul­ti­pro­cess­ing came very late, but then it is a very nice new fea­ture and worth hold­ing up the beta by a week :)

  • http://theironlion.net Paul Hum­mer

    These rea­sons them­selves are why I’ve been a par­tic­u­lar fan of dis­trib­uted ver­sion con­trol, and par­tic­u­larly, Bazaar. It’s alright to check things in hastily. You’re the only one affected. Of course, before it can be merged into a main­line branch, it has to be peer reviewed (although I like peer reviews as a I go), and all the tests must pass, etc. This pro­motes a work­flow that pre­vents both stig­mas of “wait ’til it’s per­fect” and “check it in whenever”

  • http://theironlion.net Paul Hum­mer

    These rea­sons them­selves are why I’ve been a par­tic­u­lar fan of dis­trib­uted ver­sion con­trol, and par­tic­u­larly, Bazaar. It’s alright to check things in hastily. You’re the only one affected. Of course, before it can be merged into a main­line branch, it has to be peer reviewed (although I like peer reviews as a I go), and all the tests must pass, etc. This pro­motes a work­flow that pre­vents both stig­mas of “wait ’til it’s per­fect” and “check it in whenever”

  • Georg Brandl

    Don’t feel bad — there were lots of other issues marked “release blocker” at the time the beta should have been out, and gen­er­ally I feel that the new sched­ule fits our progress much bet­ter. Sure, mul­ti­pro­cess­ing came very late, but then it is a very nice new fea­ture and worth hold­ing up the beta by a week :)

  • http://theironlion.net Paul Hum­mer

    These rea­sons them­selves are why I’ve been a par­tic­u­lar fan of dis­trib­uted ver­sion con­trol, and par­tic­u­larly, Bazaar. It’s alright to check things in hastily. You’re the only one affected. Of course, before it can be merged into a main­line branch, it has to be peer reviewed (although I like peer reviews as a I go), and all the tests must pass, etc. This pro­motes a work­flow that pre­vents both stig­mas of “wait ’til it’s per­fect” and “check it in whenever”

  • http://theironlion.net Paul Hum­mer

    These rea­sons them­selves are why I’ve been a par­tic­u­lar fan of dis­trib­uted ver­sion con­trol, and par­tic­u­larly, Bazaar. It’s alright to check things in hastily. You’re the only one affected. Of course, before it can be merged into a main­line branch, it has to be peer reviewed (although I like peer reviews as a I go), and all the tests must pass, etc. This pro­motes a work­flow that pre­vents both stig­mas of “wait ’til it’s per­fect” and “check it in whenever”

What's this?

You are currently reading Programmer Insecurity and Mea Culpa. at jessenoller.com.

meta