jeshyr: Participating in #dw may cause you to end up leading a project team. (Dreamwidth - Project Leader)
Ricky Buchanan ([personal profile] jeshyr) wrote in [site community profile] dw_dev2012-02-24 07:12 pm
Entry tags:

Things Real Dreamwidth Programmers Do

Lots of new developers - including myself - are very nervous about screwing things up. Lots of old developers have told me not to worry, but I keep worrying. I don't want to seem stupid or break something important!

So I thought we could make a list of some wonderful hilarious things that Dreamwidth developers have done and still do. I've put the names of people who told me I could share these, but you can be sure that pretty much all of them make everybody around grin and admit that they do something very similar too, actually.

Our fearless leaders have commented on the topic when I told them I was making the list:

[staff profile] denise: you haven't arrived until you've made at least one mistake that brings the site to its knees ;)

[staff profile] mark, when told about this list's creation: if we're going to create a list of all the shit I've done over the years it will be a very long list.


Things Real Dreamwidth Programmers Do (Or Have Done)



Everybody: Spent ages searching for the bug, only to realise the file you're editing is not actually the same file you're running. [personal profile] fu managed to do this one while I was actually writing up this list, and not just on her Dreamhack but on Dreamwidth itself!

[personal profile] exor674 I STILL have to look at the TT docs every damn time I have to do things. and I mean the "how to make pages" not the scary "doing weird and obscure things in the plugins" (note: [personal profile] exor674 is the project head for TT conversion)

[personal profile] shadowspar: I spend a lot of time with 'perldoc -f <most-any-perl-function>'

[personal profile] azurelunatic: Forget to convert null entries to zeroes before doing mathematical operations that's likely to involve counting or dividing.

[staff profile] mark: the other day I oopsed a database and had to rebuild it. while debugging the slow page load thing, I installed something, that uninstalled MySQL :P

[personal profile] azurelunatic: And for my part, I totally submit suggestions all the time that are already logged in Bugzilla.

[staff profile] mark: when I was at Mozilla, I accidentally clobbered the database that contained the crash logs. i.e., every time Firefox crashes and you let it send in the crash log. this was at the Firefox 3 launch. I blew it away. no backups.

[staff profile] denise: like the time [staff profile] mark helped me troubleshoot my broken email for like three hours, only for me to discover the reason it wasn't working was because i'd let the domain registration lapse

[personal profile] azurelunatic: Forget to increment the serial number on the DNS file, and spend a half-hour cursing and weeping in class.


So next time you're feeling stupid, please remember that these things are all perfectly normal programmer behaviour:

  • Asking others for help

  • Forgetting how you did the same thing yesterday

  • Asking others for more help

  • Forgetting to restart Apache

  • Finding yourself looking up the same bit of Perl syntax for the 37th time

  • Forgetting to upload the file you edited

  • Making typos and not noticing

  • Forgetting to restart Apache again

  • Asking for help yet again


All of these are things that Mark, Denise, Fu, and all of our senior coders do on a regular basis, therefore we have proof they are totally normal and expected and no cause for shame or guilt.

If you care to, please share other silly things you've done in the comments!
geekosaur: Chuck the FreeBSD Daemon (geek)

[personal profile] geekosaur 2012-02-26 09:24 am (UTC)(link)
Backing this up: several of my friends and I jokingly identify as "human fuzzers". A "fuzzer" is network penetration testing terminology for a tool that builds nonsensical data packets to throw at a network service (including the network itself; some of them build invalid network packets at various levels) to look for combinations that cause various kinds of service failure.

In our case, we have a certain tendency to put together uses of various programs that are obvious to us, but which those programs' designers and testers apparently never considered.

The fact of the matter is that generally the people who design something (a tool, a program, a web service) have certain notions about how they will be used, and the more time they put into the design, the more likely they will overlook even apparently similar alternative ways of using them. (Think of it as hyperfocusing. And the more you think about something, the more likely you'll get stuck into certain ruts, usually without realizing it.) As someone who's been on both the using and designing side of this, I can say I'm always happy to hear about it if there's some option or possibility I've missed.

But I have certainly known designers and developers who become very annoyed in that case; sometimes because they're so caught up in their design that alternatives come across to them as being in some sense wrong, other times because they're kicking themselves in the butt for blindness but are bad at keeping their self-annoyance out of their interactions with others. (And I will also admit that at times I have had problems with the latter. I hope I've been getting better at catching myself and if necessary taking some deep breaths.)