![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
Entry tags:
ten things i am currently grooving on about the DW dev process
Ten things I am currently loving about the Dreamwidth development process:
1. We comment our code. We try to write code that reads like English, or at least like natural human syntax, and we put comments in there so that the next person who comes along (which might very well be the person who wrote it, four months later) can follow through all the logic and read along and know exactly what the logic was and why that one little fiddly bit is in there. If there's a $LJ::WILL_NOT_WORK_WITHOUT_STEAM_RADIATOR variable, we'll put a careful set of instructions for the dismantling and stowage of the steam radiator right above it in the code.
2. When you break something -- and you will break something, and the broken something will go live, and it will manifest in production when it didn't manifest in testing at all -- it isn't the end of the world, and nobody makes you feel like an idiot. Everyone just says "oh, yeah, I've done that too, need a hand patching it?" and the fix is committed and pushed live within like an hour.
3. When people point out that we're doing something wrong in our process, or could be doing something better, we work to fix it! (We also know that we're not going to make it 100% better immediately, and don't beat ourselves up about being imperfect.)
4. We view bugs as an opportunity to improve, not as something to roll our eyes over and sweep under the rug. We log bugs for everything from the really little to the really huge; we don't put off creating bugs to make our stats look better. We don't let bugs sit for ages, either: if something's broken, and it's negatively affecting people's use of the site, we're determined to fix it.
5. We're not afraid to rip out code that isn't used, or is really old, or that supports features we just won't use. We're also not afraid to tackle huge and sweeping projects to bring a ten-year-old legacy codebase up to our current coding standards. Even if this means touching every single file on the site, we're not afraid to update things.
6. When you screw something up in a patch, nobody makes you feel like you're an idiot who shouldn't be trusted anywhere near the code. It's just a case of "hey, you missed $thing, can you fix that and resubmit?" That kind of laid-back attitude means that it's a lot easier to reach out of your comfort zone and try something new; if you screw it up, you'll just get a hand with making it work, not any sort of feeling that you should go away and leave it to people who know better.
7. We'll work in steps if we have to. If someone has the know-how to do 60% of a project, and that 60% is a good stopping point -- meaning that things won't be utterly broken without the last 40% -- we'll check in the first 60% and let someone get the 40% later. (And, conversely, we don't let things wait at the 60% done state -- we make it a point to go back and finish them later.)
8. We move pretty fast! 90% of the time, a patch will be committed in a day or two. (The exceptions are things that have to go into the dw-nonfree repository, since only Mark has commit access there right now, and things that are big/scary and need more review.) This means that people see their name in lights -- or in![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png)
changelog -- pretty quickly!
9. Everyone's doing all this because they really care about the project! It's not that people just want to hack on the project because they want to show off their tech skills or want to do interesting things in code; they're here because they really care about Dreamwidth and about what we're doing, and so they're really engaged with making the site better. Everyone thinks about the good of the project as a whole when they do things, so the end result is better, sharper code and a good user experience.
10. If someone comes into irc and asks a question or mentions wanting to help, everyone falls all over themselves to be helpful and friendly! Unlike some projects, where any sort of question or beginner's confusion gets a response of "rtfm n00b" or the like, someone new to #dw will get an enthusiastic welcome with links of useful information for how to contribute (if they want to) or answers to their questions (if they have them). I'm really proud of the welcoming and friendly culture we've built, and especially proud of the way that newcomers are encouraged to learn how to program with us!
1. We comment our code. We try to write code that reads like English, or at least like natural human syntax, and we put comments in there so that the next person who comes along (which might very well be the person who wrote it, four months later) can follow through all the logic and read along and know exactly what the logic was and why that one little fiddly bit is in there. If there's a $LJ::WILL_NOT_WORK_WITHOUT_STEAM_RADIATOR variable, we'll put a careful set of instructions for the dismantling and stowage of the steam radiator right above it in the code.
2. When you break something -- and you will break something, and the broken something will go live, and it will manifest in production when it didn't manifest in testing at all -- it isn't the end of the world, and nobody makes you feel like an idiot. Everyone just says "oh, yeah, I've done that too, need a hand patching it?" and the fix is committed and pushed live within like an hour.
3. When people point out that we're doing something wrong in our process, or could be doing something better, we work to fix it! (We also know that we're not going to make it 100% better immediately, and don't beat ourselves up about being imperfect.)
4. We view bugs as an opportunity to improve, not as something to roll our eyes over and sweep under the rug. We log bugs for everything from the really little to the really huge; we don't put off creating bugs to make our stats look better. We don't let bugs sit for ages, either: if something's broken, and it's negatively affecting people's use of the site, we're determined to fix it.
5. We're not afraid to rip out code that isn't used, or is really old, or that supports features we just won't use. We're also not afraid to tackle huge and sweeping projects to bring a ten-year-old legacy codebase up to our current coding standards. Even if this means touching every single file on the site, we're not afraid to update things.
6. When you screw something up in a patch, nobody makes you feel like you're an idiot who shouldn't be trusted anywhere near the code. It's just a case of "hey, you missed $thing, can you fix that and resubmit?" That kind of laid-back attitude means that it's a lot easier to reach out of your comfort zone and try something new; if you screw it up, you'll just get a hand with making it work, not any sort of feeling that you should go away and leave it to people who know better.
7. We'll work in steps if we have to. If someone has the know-how to do 60% of a project, and that 60% is a good stopping point -- meaning that things won't be utterly broken without the last 40% -- we'll check in the first 60% and let someone get the 40% later. (And, conversely, we don't let things wait at the 60% done state -- we make it a point to go back and finish them later.)
8. We move pretty fast! 90% of the time, a patch will be committed in a day or two. (The exceptions are things that have to go into the dw-nonfree repository, since only Mark has commit access there right now, and things that are big/scary and need more review.) This means that people see their name in lights -- or in
changelog -- pretty quickly! 9. Everyone's doing all this because they really care about the project! It's not that people just want to hack on the project because they want to show off their tech skills or want to do interesting things in code; they're here because they really care about Dreamwidth and about what we're doing, and so they're really engaged with making the site better. Everyone thinks about the good of the project as a whole when they do things, so the end result is better, sharper code and a good user experience.
10. If someone comes into irc and asks a question or mentions wanting to help, everyone falls all over themselves to be helpful and friendly! Unlike some projects, where any sort of question or beginner's confusion gets a response of "rtfm n00b" or the like, someone new to #dw will get an enthusiastic welcome with links of useful information for how to contribute (if they want to) or answers to their questions (if they have them). I'm really proud of the welcoming and friendly culture we've built, and especially proud of the way that newcomers are encouraged to learn how to program with us!