Things Real Dreamwidth Programmers Do

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, 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

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

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

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