Bookmarks tagged 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.”

“I dare you to fail”
For people to take J Curve risks and be willing to jump off the cliff with you, they need to know that you’re gonna catch them if they fall. It’s important to set them up mentally to understand that their main job is not to be perfect but to learn as fast as they can. And that comes with mistakes. If they fail, they need to know that they still have a job and you’ll still think well of them. Because many high performers are used to being perfect or exceptional at their jobs, I often use the phrase “I dare you to…” followed by “fail” or “make a mistake” or “prove me wrong” to help them see that taking risks, struggling, making mistakes, etc., is an expected part of this journey.

"Slides and notes for the Being Glue talk."

"When starting a new job as a software engineer, it’s natural to feel the pressure of delivering immediate value and meeting the expectations of your role...."