Bookmarks tagged Working-Well and how-to-work

I love this idea of issue-driven development. Everything (no matter how small) gets an issue, and the steps taken in resolving that issue each get a comment (and even better a screenshot) until the issue is closed with a relevant commit.
“What goes in an issue? Background: the reasons for the change. In six months time you’ll want to know why you did this. State of play before-hand: embed existing code, link to existing docs. I like to start my issues with “I’m going to change this code right here”—that way if I come back the next day I don’t have to repeat that little piece of research. Links to things! Documentation, inspiration, clues found on StackOverflow. The idea is to capture all of the loose information floating around that topic. Code snippets illustrating potential designs and false-starts. Decisions. What did you consider? What did you decide? As programmers we make decisions constantly, all day, about everything. That work doesn’t have to be invisible. Writing them down also avoids having to re-litigate them several months later when you’ve forgotten your original reasoning. Screenshots—of everything! Animated screenshots even better. I even take screenshots of things like the AWS console to remind me what I did there. When you close it: a link to the updated documentation and demo”

“Don’t get me wrong, I love having a whole afternoon to work on something without interruption. It’s probably ideal for most people. But it’s an exaggeration to say that it’s impossible to program well in units of an hour.”