Sep. 6th, 2011

denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
In the past, some people have done walkthroughs of their process for fixing and testing bugs. I personally find them really helpful, and I hope that my own walkthroughs have been reasonably helpful in turn!

This month I'd like to ask you all to consider writing a walkthrough for at least one bug you patch. Even if you're an absolute beginner, even if you got totally lost while working on the bug, even if you think you did it all wrong and nobody could possibly learn from you, please consider doing a writeup anyway.

The reason for this is: there are tons of different styles and approaches. How you approach fixing a bug is incredibly individualist, and depends on a lot of things including your experience level, your comfort level, the way your brain works, the kinds of things you find logical and reasonable, and sometimes even who's around in irc or in this community when you ask!

Because none of us are exactly alike, our beginner documentation can address some of the approaches, but not all of them. If your brain works really differently from the way mine does, for instance, you'll approach a problem totally differently. And Nell Newbie who comes in next month may think more like you do than I do, and might find your walkthrough more helpful than mine.

If you made mistakes, meanwhile, don't worry about that, or think that it reflects badly on you. First off, nobody gets things 100% right on the first try every time -- that's why we have code review. Second, showing people with less thorough self-confidence, or who are frightened that they will do something wrong or break DW or something, that everybody makes mistakes and making mistakes is something we expect as part of the learning process, will do a lot of good. (I can't count the number of times newcomers to programming, not just newcomers to DW development, have told me that seeing me making visible and common mistakes helped them have the courage to get started!)

So, for the month of September, for every bug-patching walkthrough (similar to the ones already in the comm) I will give either one month of paid time (to an account of your choice) or 30 DW points (the equivalent cost). The walkthrough does have to be for a bug you patched, or are in the process of patching -- no walking through a bug you haven't taken, or don't plan on patching, but just want to write up as an interesting theoretical exercise. (I'm most interested in seeing your actual workflow, with your actual pitfalls and false starts and moments where it all clicked together.) The patch does not need to have been reviewed yet -- like your high school math teacher might've told you, this isn't about whether you got the answer right, it's showing your work for how you got the answer.

And please be sure to use the 'walkthrough' tag when you post it!
denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
[staff profile] denise
For the wiki, I'd like to build a list of "things we have learned where to look for" -- like, "I want to change this thing. Where in the code would i find it?"

Some examples of what I mean, quick 'cause my brain's melting:

text string on page $foo --> in $foo.text or in ~/bin/upgrading/en.dat
styles --> ~/bin/upgrading/s2layers
all the routines that make html controls --> ~/cgi-bin/htmlcontrols.pl
control strip --> ~/cgi-bin/weblib.pl

Stuff like that! What should be on that list?

Profile

dw_dev_training: The stylised 'd', with the word 'dev' above, and the word 'training' at the side, representing the dw_dev_training comm. (Default)
Dreamwidth Development Training

September 2022

S M T W T F S
    123
45678910
1112131415 1617
18192021222324
252627282930 

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags
Page generated Aug. 9th, 2025 08:36 pm
Powered by Dreamwidth Studios