Things Real Dreamwidth Programmers Do

From Dreamwidth Notes
Revision as of 02:42, 21 April 2013 by Shadowspar (Talk | contribs)

Jump to: navigation, search

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 [info]azurelunatic shared the IRC logs of a marvellous Dreamwidth Dev Pep Talk, [info]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. - [info]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. - [info]azurelunatic
  • I'd like to patch this bug! Or try to! Really, I would! But... where do I find the existing code for it??? ;_; - [info]kaberett

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. - [info]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. - [info]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. - [info]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 - [info]shadowspar
  • Have to look at the Template Toolkit documentation every time I have to do anything -[info]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! - [info]jeshyr
  • I try to keep track of what features have actually been implemented, and what ones are still waiting, but I forget all the time. Then these get mixed in with things that LiveJournal has developed since the code fork, and again mixed with things that the shared codebase used to do, but doesn't anymore since it was ripped out by the bytes by whichever dev had the code-machete that week. - [info]azurelunatic
  • The best thing is when I think "Oh, we should totally do this thing," and then one of several things happen. One, there's already a suggestion for it. Two, the suggestion's already been migrated to Bugzilla. Three, I was the one who suggested it. Four, when it's actually already been implemented. Five, when all of the above is true -- and [info]denise lets the post to [info]dw_suggestions through anyway, because she forgot too. I have lost count of how many times that's happened. - [info]azurelunatic
  • I work with R scripts in my "day job", and I keep trying to write Perl in R, and R in Perl. Neither works too well. - [info]swaldman

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... - [info]shadowspar
  • Break the site (momentarily) during open beta launch: http://qdb.dreamwidth.net/dw/123

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 - [info]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 - [info]kaberett

Shoot Themselves in the Foot

  • Starting to rewrite a helper script. Think "What version of Perl does the DW codebase require?" Ah! Find it requires 5.10. Great, I can use the features that are new in 5.10! Write up a note in the wiki saying that Perl 5.10 is required, but it's unlikely to be a problem because any machine running 5.8 or earlier is likely to be quite decrepit indeed. Return to script, finish it, give it a try. Script refuses to run. Error message: Perl v5.10.0 required--this is only v5.8.9. [info]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. ^_^; - [info]shadowspar
  • assigning bugs to oneself in a fit of hopefulness, realise you can't manage them and sadly unassigning. Rinse, repeat :) - [info]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 [info]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. - [info]kaberett

Get Scared

  • I ask for reassurance ALL the time, usually via the IRC channel. Hell, I even asked for reassurance before creating this category in this document ... how silly is that?? - [info]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. ^_^; - [info]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 - [info]kaberett
  • Spent seriously like a week trying to look up over and over all the commands in the wiki for upgrading code, updating the database, using the version control, etc. and finally decide it was easier to just write a huge enormous omnibus script to remember them for me. The fact it helps other people is fun, too!

Learn

  • Better than half of our contributors have never programmed in Perl before, never contributed to an Open Source project before, or never programmed before, at all, period. I think that's amazing. (ref) [info]shadowspar