Difference between revisions of "Things Real Dreamwidth Programmers Do"

Revision as of 03:00, 6 April 2013

Wading into an open source project for the first time can be intimidating. There's a tendency to put established open source programmers up on a pedestal, especially when evaluating one's own abilities in comparison. (Hello, impostor syndrome!)

Real Open Source Programmers are the crème de la crème, the best of the best, the veritable titans of the programming world, right? They never make mistakes; they write flawless SQL queries in their sleep; they instantaneously comprehend any and all code they survey. Surely no mere mortal could ever hope to enter their exalted domain.

Reality, of course, is far, far removed from this caricature. Real Open Source Programmers are humans like the rest of us, with the same foibles, insecurities, and quirks common to all. Very few contributors have supernatural abilities, decades of programming experience, or an encyclopedic knowledge of computing arcana, and we are all far, far from perfect. =)

Thus, when azurelunatic wrote a marvellous Dreamwidth Dev Pep Talk, jeshyr came up with the idea of collecting an Epic List of Things Real Dreamwidth Programmers do. If you're a new or new-to-DW contributor, hopefully the list below will help disabuse you of any notion that you're somehow "not good enough" to contribute code -- you are more than good enough, and your contributions are heartily welcomed. And if you program, design, sysadmin, or interact with computers in any way, feel free to add any anecdotes you might have -- either signing your name or not.

With that, we present the Epic List of Things Real Dreamwidth Programmers Do.

Ask for Help

• I cannot count the number of times I asked someone who knew more about the documentation system how to do something, or to double-check to make sure I got it right. - azurelunatic
• It's the rare code tour that I can complete without at least once asking what some bug was about. That's some deep, deep magic. - azurelunatic

Make Mistakes

• Forgot that you can't treat a null as a zero enough times that I printed out "Null To Zero" in a fancy font with an ornate border, and stapled it to my wall as a reminder. - azurelunatic
• Started the arguments of a mailto: link in a wiki with an ampersand instead of a question mark, got garbage results after the address when testing it, blamed the (touchy, obscure, belligerent) mail application to its developers, and was schooled on my mailto: syntax in front of an audience of about 1,300. - azurelunatic
• For bug 4282, I misunderstood what the request in bugzilla was asking and what the current behaviour was, and so my patch didn't fix what it was meant to fix AND it didn't even actually fix what I thought it was meant to fix! So it was doubly broken ... and then I got sick and had to unassign the bug, so I never got it fixed. - jeshyr

Forget How Things Work

• I feel like I end up looking up most Perl functions with perldoc -f function_name every time I use them. Especially open and split, for some reason. O_o - shadowspar
• Have to look at the Template Toolkit documentation every time I have to do anything -exor674 ( I should note that I am in charge of the BML to TT conversion )
• About half the time, the morning after I write something I have to figure out what I did and how the hell it works ... it never stays in my brain! - jeshyr

Break Production (the Live Website)

• kicked over production Apache at work the other day when I thought I was merely recycling the dev website. oops... - shadowspar

Break Sundry Other Things

• my first act at one of my early contracting gigs: creating a mail routing loop that made our own servers bury themselves under a deluge of junk email - shadowspar
• back in the days (!!) of Mercurial Queues, I managed to mess up deleting patches that had been committed from my Dreamhack so badly that it took a lot of WTFing and a goodly amount of new documentation to sort it out without losing all my part-finished patches - kaberett

Overcommit Themselves

• time elapsed between me showing up on DW and saying I wanted to contribute code, and actually submitting my first patch: about three years. ^_^; - shadowspar
• assigning bugs to oneself in a fit of hopefulness, realise you can't manage them and sadly unassigning. Rinse, repeat :) - jeshyr
• pick up an effort-minor bug, stare at it for a while, start hashing out a spec in bugzilla comments, and before you know it end up with an entire dw_dev discussion post about what you're actually trying to achieve, with reference to several ISO standards... and then bury your head in the sand and pretend none of it ever happened. - kaberett

Complain

• a lot
• in IRC
• out loud when the code is not making sense (as some sections of it frequently fail to do)
• including wondering what elder god infested Brad's head when he wrote THAT omg
• at code they wrote themselves just six months ago but never got around to properly commenting

Help Others

• I'm kind of thrilled when someone asks for help with the code tour and I can actually sort-of explain what some of the fixes do. ^_^; - shadowspar
• spend two straight days rummaging around with something or other, and in a fit of FOR CRYING OUT LOUD write up some documentation for the wiki so at least the next person doesn't have to reinvent the wheel - kaberett