From ba710ee7ca0cc08f77bda5a4cb0912de9d96ad53 Mon Sep 17 00:00:00 2001 From: Kai Date: Tue, 2 Oct 2018 20:38:06 -0700 Subject: [PATCH 1/8] add slack post --- _notes/2018-09-01-slack-etiquette.md | 117 +++++++++++++++++++++++++++ 1 file changed, 117 insertions(+) create mode 100644 _notes/2018-09-01-slack-etiquette.md diff --git a/_notes/2018-09-01-slack-etiquette.md b/_notes/2018-09-01-slack-etiquette.md new file mode 100644 index 0000000..b954150 --- /dev/null +++ b/_notes/2018-09-01-slack-etiquette.md @@ -0,0 +1,117 @@ +--- +layout: note +date: 2018-9-1 +title: Slack Etiquette +description: Some ground-rules and protips for folks getting to know Slack, which I wrote while working with a bug group of Slack n00bs. +tags: temple slack communication +hidden: false + +--- + +

+ +
This year we used a Slack team for organizing the Temple, and it was quite an adventure. We had a wide range of folks, from people with no computer experience at all to people who already used Slack every day. I looked but didn't find a good intro to Slack etiquette, which would explain things like "please don't @channel every time you have a question." I wrote up this quick doc to share with the crew, in an effort to get everyone the same page. Some of it's Temple specific, but a lot of it applies more generally! Let me know if you think of things to add; this is a work in progress.
+ +

+ +
Alerts
+ +
+ +There's different levels of alerts, and with great power comes great responsibility. Use them carefully. + +
+ +
+ @here notifies everyone in the channel who is currently online. This includes folks using the mobile client, so be especially careful if your message might be late at night in someone's timezone. ONLY use this when you need an IMMEDIATE answer. + + +
+ +
+ @channel notifies everyone in the channel, often sending email to folks that aren't online. This is rarrrrrreeeely the right choice- only use it when you want absolutely everyone in that channel to see the message. + + +
+
+ +
+ @[group] Slack allows you to create "groups" of people, which are perfect for making sure a whole team of folks gets a certain alert. Scheduling a meeting and don't want to use `@here` because not everyone is online? Create groups of folks instead, so you can contact the whole team with one handle. For example, @volunteer-coordinators messages Kai, Peggy, and Kristen, and is a great way to get our attention if you have a question about volunteer stuff. +
+ +
+ +
+ @[individual] use anytime you have a specific question for them or want them to see something! People can snooze alerts if they want. If you @ someone who isn't in a channel, *they won't know about it* unless you invite them to the channel. Slack is nice and tells you when this is this case, so you can choose to invite them or send them a message about it. Please watch for this, to make sure people get the messages you're trying to send. +
+ +
+ +
+You can check your notifications by clicking on the @ in the upper right hand corner, which shows you a list of everywhere that someone used an alert in which you're included (and emoji responses to your messages!) +
+ +
+ +
Channels
+ +
+ +
Keeping track
+ +
+ +
+ There's lots! Channels help us keep conversations separate and organized. +
+ + + +
+ +
Organizing
+ +
+ + +
+ +Staying in the Loop + +
+ + From 4aede56a247c16e65e90bc64c557edd16b370afd Mon Sep 17 00:00:00 2001 From: Kai Date: Tue, 2 Oct 2018 22:31:28 -0700 Subject: [PATCH 2/8] you know, maybe some css would help here instead of writing raw html like an animal --- _layouts/note.html | 2 +- assets/base.css | 72 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+), 1 deletion(-) diff --git a/_layouts/note.html b/_layouts/note.html index 9256366..f082119 100644 --- a/_layouts/note.html +++ b/_layouts/note.html @@ -13,7 +13,7 @@ {{ page.date | date: '%B %d, %Y' }} -
+
{{ content }}
{% include related.html %} diff --git a/assets/base.css b/assets/base.css index e69de29..20aded2 100644 --- a/assets/base.css +++ b/assets/base.css @@ -0,0 +1,72 @@ +body { + font-size: 18px; + line-height: 24px; +} + +/* Layouts */ +p { + margin-bottom: 18px; +} + +/* Headlines */ +h1 { + font-size: 45px; + line-height: 54px; + margin-bottom: 54px; + margin-top: 54px; +} + +h2 { + font-size: 35px; + line-height: 42px; + margin-bottom: 42px; + margin-top: 42px; +} + +h3 { + font-size: 30px; + line-height: 36px; + margin-bottom: 36px; + margin-top: 36px; +} + +h4 { + font-size: 18px; + line-height: 24px; + margin-bottom: 24px; + margin-top: 24px; +} + +h5 { + font-size: 15px; + line-height: 18px; + margin-bottom: 18px; + margin-top: 18px; +} + +/* Lists */ + +ol, +ul { + list-style-type: disc; + margin-left: 5%; /* offset list styling */ + margin-bottom: 2%; +} + +/* Less margin bottom for nested lists */ +ol ol, +ul ul, +ol ol ol, +ul ul ul{ + margin-bottom: 0.5%; +} + +/* Blockquotes */ + +blockquote { + margin-left: 5%; + font-style: italic; + color: grey; + border-left: 5px solid lightgrey; + padding-left: 5px; +} From cfc1a0ad21ad975542c6f9fc27bb2c03d3f496b3 Mon Sep 17 00:00:00 2001 From: Kai Date: Tue, 2 Oct 2018 22:32:03 -0700 Subject: [PATCH 3/8] add starts for pairing and spirit guiding notes --- _notes/2018-08-01-pair-programming.md | 11 +++ _notes/2018-10-02-spirit-guidance.md | 114 ++++++++++++++++++++++++++ 2 files changed, 125 insertions(+) create mode 100644 _notes/2018-08-01-pair-programming.md create mode 100644 _notes/2018-10-02-spirit-guidance.md diff --git a/_notes/2018-08-01-pair-programming.md b/_notes/2018-08-01-pair-programming.md new file mode 100644 index 0000000..8c77fbf --- /dev/null +++ b/_notes/2018-08-01-pair-programming.md @@ -0,0 +1,11 @@ +--- +layout: note +date: 2018-8-1 +title: Pair Programming KaiStyle +description: An intro to pairing, with helpful communication tips +tags: code +hidden: false + +--- + +Hey this is a test post. \ No newline at end of file diff --git a/_notes/2018-10-02-spirit-guidance.md b/_notes/2018-10-02-spirit-guidance.md new file mode 100644 index 0000000..72beca6 --- /dev/null +++ b/_notes/2018-10-02-spirit-guidance.md @@ -0,0 +1,114 @@ +--- +layout: note +date: 2018-10-02 +title: Spirit Guidance +description: Ramping up the people around you +tags: communication code teaching +hidden: false +--- + +There's nothing quite like the feeling of starting a new job, working on a new codebase, or learning a new skill, and realizing you have no fucking clue what's going on. I've never met anyone who enjoys that feeling, but it's hard to avoid both as the learner and the more experience teammate/manager/teacher. Spirit guiding is a way to help people through that learner phase, so they can ramp up quickly and comfortably. A spirit guide is someone who helps someone else along on their quest, whether that quest is getting up to speed in a new codebase, learning a new technology, or growing into any other area or role that they haven't done before. + +To illustrate this concept, let's bake a cake with someone who has never baked before. + +Kendra, an experienced pastry chef, tells the new chef, Pico, to "go bake tomorrow's cakes." She knows, as someone with experience in this restaurant and in this role, that we'll need 5 chocolate cakes and 3 ginger cakes for the night. She knows where the recipes are (or maybe even has them memorized). She knows where to find the ingredients, and about how long the process will take. She knows if the oven catches on fire, something has gone very very wrong. + +Pico might not know any of things. Kendra said cakes, plural, but didn't say how many there should be. Do we have a typical kind of cake? Do we have a set of recipes? Maybe the first step is figuring out how many people we expect, then doing a survey to see what kind of cakes are popular. Pico-the-new-chef doesn't even know where to start, and might spend a lot of time spinning their wheels on tasks that don't need to be done (like researching the best cake recipe). + +Enter, *spirit guidance.* + +If Kendra was being a good spirit guide, she would think about the problem with a beginners' mindset, and realize she’s making some assumptions about what Pico already knows. Sure, Kendra makes some assumptions that are probably safe for a commercial kitchen- she assumes that Pico would know they already have cake recipes, and already have the tools they'd need to bake. There are layers of assumptions, though, that are only revealed by thinking through the steps as a beginner. Is it safe to assume that the first type of cocoa powder they find on the shelf is the one mentioned in the recipe? What if there's special raw cocoa powder that we've been trying out? For a real-world example, maybe every engineer on your team knows that the "lint.py" script in the root directory hasn't worked in years, but a new engineer might safely assume that that's how folks lint their code (this is an actual example). + +## Key Tips For Success + +### Levelling +"Bake a cake" can be a large, overwhelming task for someone who has never set foot in a kitchen. It can also be a lot to learn for someone who worked for years as a line cook at a burger joint, but never baked! Just because someone has experience doesn't mean they have the same knowledge that you do. +A good spirit guide will meet their learner at their current level, and that takes practice. If the learner is an experienced engineer that is learning a new codebase, it might be enough to say "we use php 7." If they're a new engineer, instructions about how to check whether php is installed on their computer and which version it is might come in handy. The point of spirit guidance isn't to write down every possible step, it's to meet people where they're at and make sure that they're able to make progress and learn in a way that feels productive for everyone. + +### Think About Potential Blockers +You don't need to explicitly make sure everything is perfect and prepared. If everything is perfect, the person you're spirit guiding might miss out on some valuable debugging experience. That said, do call out potential traps. Let folks know about potential challenges to keep them from wasting time or getting completely blocked. + +**For example:** +- If I'm baking and can't find an ingredient, I don't know if: + - We're out. + - I'm looking in the wrong place. + - We normally substitute something else because a teammate has an allergy. + - It's in some "totally obvious" place and if I ask where it is I will feel like an idiot, oh no! + +If you think of something that might be a problem, don't feel like you *have* to fix it in advance. Ask yourself, will this block the person in a way they can't eventually resolve? Will working through this problem teach them something? Will it be demoralizing? If it's something you think they can handle, give them the tools and let them do the work. + +> "we might be out of cocoa powder; it usually lives in the spice cupboard, but if there isn't any there, reach out to @shopping to get help on a trip to the store." + +**In that sentence, we:** + +- let them know about a potential problem: you might not find any cocoa powder, and that's okay. +- tell them how they'd know it was a problem: it should be in the spice cupboard, and if they checked there already they don't need to look anywhere else. +- tell them what to do if they run into the problem: reach out to a *specific* someone else for help on the next step. + +This last one is important. You don't need or want to have a whole choose-your-own-adventure flow chart of potential problems, because you'll end up writing an overwhelming amount of instructions, most of which won't be used. Instead, tell folks explicitly when to ask for help. If they hit that point, you can guide them through it by pairing, sending them resources to read through, or writing up next steps. + +### Break up Tasks into Phases or Steps +An experienced baker might intuitively know there will be some stages to baking a cake- gathering ingredients, mixing dry and wet separately, mixing together, and baking in the oven. Do the work of making those phases explicit. Even if the learner already knows those phases, having them broken down into separate sections with their own checklists and goals makes it easier for everyone to keep an eye on progress, and have a feeling of accomplishment when each phase is complete. It also takes away that sense of overwhelm, allowing folks to think "I'm not sure of all the steps, but I know what to do in this phase. I can focus on the rest later." + +Each phase should have its own brief overview, steps to follow, and a way to tell when the phase is done. For code projects, the end of each phase is a great time to have the learner submit a pull request and ask for review. + +**To stick with our cake example, a phase might look like this:** + +> Phase 3: Combining Dry and Wet Ingredients +> You already have a bowl of dry ingredients and a bowl of wet ingredients from Phase 2. Let's mix them together to finish our cake batter! +> +> - Preheat the oven to 300f; we'll need it hot for Phase 4: Baking +> - Gather your tools: a baking pan and a spatula +- Add the dry ingredients to the wet ingredients slowly while mixing. Stop when everything is combined and the lumps are less than 1cm wide; if we over-mix it the cake will be too chewy. +> - After mixing, pour batter into the baking pan +> - Ask for a review before moving on to Phase 4: Baking + +**In the instructions for this phase, we:** +- make sure they have all the prerequisites they need (results of earlier phases, tools) +- explain the task, including the desired result +- are explicit about what to do when they're done + +Phases also give you, the spirit guide, an opportunity to adjust your approach. If the learner zooms through the first couple phases, or seems to be getting stuck every few minutes, you can adjust the level of detail in future phases. + +### Phase 0: Setup +Don't forget about set up! There's nothing more frustrating than spending time debugging errors that are actually just missing libraries or misconfigured tools. Go through the project and think about the requirements beforehand, so that you can do all the setup in a discrete phase. If you've written all the instructions for a specific environment/IDE/language, make sure that you're explicit about that so that the learner can follow along without having to translate. + +This is also a great place to drop links to outside resources and docs for the learner to refer back to. + +**Here's a general tech checklist to get you started:** + +- access to any internal systems, like AWS accounts or github organizations +- required tools, like `homebrew` +- the correct version of things like languages/package managers/databases, if it matters for your work +- extensions and addons, like postgis or gnu utilities +- links to resources that will be helpful along the way + +### Debugging Tips +Sometimes folks follow the steps exactly, and things still don't work, because following the steps isn't always enough. As engineers we learn to watch for error messages after each command that other folks might miss. As people experienced in a particular problem space, we know how to check if each step worked. Learners don't have that advantage, so be sure to share. A great way to do this is to be explicit about what success and/or failure looks like for each step. If there's 10 installation steps and then you run a script that requires all of them, it might be tough to track down the one dependency that didn't get installed correctly. Instead, let's explicitly check that everything worked as we complete each step. + +To use our cake example, we don't want to wait until we're pulling the cake out of the oven to find out we accidentally used blue cornmeal instead of flour. Instead, we might say, "Mix the dry ingredients together. When you're done, it should be an even, pale brown color." + +If we're having the learner install something like npm, we can say: + +> - Install `npm`. `npm` is a tool to manage our project's dependencies; we'll need it to install helper libraries as we go along. To install, run `brew install npm` from your terminal. After it completes, you should be able to run `npm -v` and see the version number output. + +**In this line, we:** + +- explain what we want and why we want it +- tell them how, with the exact command +- explain how to tell whether it worked + +If we're having the learner work on a specific piece of code, we can point out which tests to run and how to run them to see if their changes worked. If there aren't tests for that function or chunk of code, start out by writing some! Writing a test is a great way to get familiar with the problem, especially for folks inexperienced in a particular codebase. + +One of the fantastic things about pairing with learners on a codebase is finding all the gaps in understanding and instruction, because if something can go wrong, it probably will! Use this as an opportunity to spruce up your docs with that missing info. + +### Stay Engaged +Once you've written up some instructions and gotten them started, don't disappear! You don't want to find out about oven problems by coming back to a kitchen burned down to the ground. Building reviews into each phase is an easy way to keep an eye on things, but you should also be checking in every now and then to make sure everything is on track. Try to predict how long each step phase will take, and check in with the learner one or two times while they're working. You don't need to contrive a reason; all you need is a quick "How are things going?" to start a conversation about their progress. + +## That's a Lot +Following every suggestion here takes an investment of time. Sometimes it feels worth it, like when you're onboarding a new engineer and need to introduce them to a bunch of topics at once. Other times, it makes more sense to do only some of these things. The most important thing is to pause, and remember to use your beginners' mindset to think about things as they arise. That helps you give good directions, and keeps the people you're working with from feeling frustrated or having negative thoughts about themselves (or you!) + +## Wrap Up +Many of us have a voice in our heads telling us we're not good enough to do something for some reason or another, whether it's our background, our gender, our race, or any number of things. Every time we hear something like "oh, you haven't installed xyz yet?" or "you've never heard of *this obvious thing*?!" that voice gets a little louder. Good spirit guidance keeps people moving quickly enough to escape that voice. Partnering with folks non-judgmentally to help them accomplish tasks allows them to feel more confident in their skills, and empowers them to keep learning and progressing. The cake example might feel a little contrived, but I've used this teaching method for plenty of things besides software projects, including construction, martial arts, and sewing. I'm still iterating on spirit guidance and learning ways to improve, so please give it a shot, and let me know what you think! You can find me online at any of the links below. + +Huge shoutout to the folks at Mapbox, where I was introduced to the concept of spirit guidance while working as an engineer on the geocoding team. I learned so much working with the folks at Mapbox, and some of the most important takeaways were around learning and teaching. If this post resonated with you, you might also enjoy Emily McCaffee's great post on [How to work with someone that is learning], with lots of tips that complement spirit guidance. From 9b31509d3fdb762b5a63394bd9f5bdf5c0eb80f4 Mon Sep 17 00:00:00 2001 From: Kai Date: Thu, 4 Oct 2018 20:30:50 -0700 Subject: [PATCH 4/8] tidy spirit post, add link css --- _notes/2018-10-02-spirit-guidance.md | 9 +++++---- assets/base.css | 8 ++++++++ 2 files changed, 13 insertions(+), 4 deletions(-) diff --git a/_notes/2018-10-02-spirit-guidance.md b/_notes/2018-10-02-spirit-guidance.md index 72beca6..9960504 100644 --- a/_notes/2018-10-02-spirit-guidance.md +++ b/_notes/2018-10-02-spirit-guidance.md @@ -55,6 +55,7 @@ Each phase should have its own brief overview, steps to follow, and a way to tel **To stick with our cake example, a phase might look like this:** > Phase 3: Combining Dry and Wet Ingredients +> > You already have a bowl of dry ingredients and a bowl of wet ingredients from Phase 2. Let's mix them together to finish our cake batter! > > - Preheat the oven to 300f; we'll need it hot for Phase 4: Baking @@ -105,10 +106,10 @@ One of the fantastic things about pairing with learners on a codebase is finding ### Stay Engaged Once you've written up some instructions and gotten them started, don't disappear! You don't want to find out about oven problems by coming back to a kitchen burned down to the ground. Building reviews into each phase is an easy way to keep an eye on things, but you should also be checking in every now and then to make sure everything is on track. Try to predict how long each step phase will take, and check in with the learner one or two times while they're working. You don't need to contrive a reason; all you need is a quick "How are things going?" to start a conversation about their progress. -## That's a Lot +## Sound Like a Lot? Following every suggestion here takes an investment of time. Sometimes it feels worth it, like when you're onboarding a new engineer and need to introduce them to a bunch of topics at once. Other times, it makes more sense to do only some of these things. The most important thing is to pause, and remember to use your beginners' mindset to think about things as they arise. That helps you give good directions, and keeps the people you're working with from feeling frustrated or having negative thoughts about themselves (or you!) -## Wrap Up -Many of us have a voice in our heads telling us we're not good enough to do something for some reason or another, whether it's our background, our gender, our race, or any number of things. Every time we hear something like "oh, you haven't installed xyz yet?" or "you've never heard of *this obvious thing*?!" that voice gets a little louder. Good spirit guidance keeps people moving quickly enough to escape that voice. Partnering with folks non-judgmentally to help them accomplish tasks allows them to feel more confident in their skills, and empowers them to keep learning and progressing. The cake example might feel a little contrived, but I've used this teaching method for plenty of things besides software projects, including construction, martial arts, and sewing. I'm still iterating on spirit guidance and learning ways to improve, so please give it a shot, and let me know what you think! You can find me online at any of the links below. +## Give it a Shot! +Many of us have a voice in our heads telling us we're not good enough to do something for some reason or another, whether it's our background, our gender, our race, or any number of things. Every time we hear something like "oh, you haven't installed xyz yet?" or "you've never heard of *this obvious thing*?!" that voice gets a little louder. Good spirit guidance keeps people moving quickly enough to escape that voice. Partnering with folks non-judgmentally to help them accomplish tasks allows them to feel more confident in their skills, and empowers them to keep learning and progressing. The cake example might feel a little contrived, but I've used this teaching method for plenty of things besides software projects, including construction, martial arts, and sewing. I'm still iterating on spirit guidance and learning ways to improve, so please give it a shot, and let me know what you think! -Huge shoutout to the folks at Mapbox, where I was introduced to the concept of spirit guidance while working as an engineer on the geocoding team. I learned so much working with the folks at Mapbox, and some of the most important takeaways were around learning and teaching. If this post resonated with you, you might also enjoy Emily McCaffee's great post on [How to work with someone that is learning], with lots of tips that complement spirit guidance. +Also, huge shoutout to the folks at Mapbox, where I was introduced to the concept of spirit guidance while working as an engineer on the geocoding team. I learned so much working with the folks there, and some of the most important takeaways were around learning and teaching. If this post resonated with you, you might also enjoy Emily McAfee's great post on [how to work with someone that is learning](https://blog.mapbox.com/how-i-work-with-someone-who-is-learning-d6c53e460625), with lots of tips that complement spirit guidance. diff --git a/assets/base.css b/assets/base.css index 20aded2..624d533 100644 --- a/assets/base.css +++ b/assets/base.css @@ -3,6 +3,14 @@ body { line-height: 24px; } +a { + font-style: underline; +} + +a:hover { + color: LimeGreen; +} + /* Layouts */ p { margin-bottom: 18px; From 77fb16b0f6f1a3caae0dc16620490f16e01dcfba Mon Sep 17 00:00:00 2001 From: Kai Date: Thu, 4 Oct 2018 20:34:02 -0700 Subject: [PATCH 5/8] actually green links look like crap for the cards - keep them unstyled --- assets/base.css | 8 -------- 1 file changed, 8 deletions(-) diff --git a/assets/base.css b/assets/base.css index 624d533..20aded2 100644 --- a/assets/base.css +++ b/assets/base.css @@ -3,14 +3,6 @@ body { line-height: 24px; } -a { - font-style: underline; -} - -a:hover { - color: LimeGreen; -} - /* Layouts */ p { margin-bottom: 18px; From bb64b21ce326fb6c9580039037397478eef5d0ab Mon Sep 17 00:00:00 2001 From: Kai Date: Thu, 4 Oct 2018 20:45:15 -0700 Subject: [PATCH 6/8] change slack post to markdown instead of html --- _notes/2018-09-01-slack-etiquette.md | 117 ++++++++------------------- 1 file changed, 34 insertions(+), 83 deletions(-) diff --git a/_notes/2018-09-01-slack-etiquette.md b/_notes/2018-09-01-slack-etiquette.md index b954150..e4924ed 100644 --- a/_notes/2018-09-01-slack-etiquette.md +++ b/_notes/2018-09-01-slack-etiquette.md @@ -8,110 +8,61 @@ hidden: false --- -

+*This year we used a Slack team for organizing the Temple, and it was quite an adventure. We had a wide range of folks, from people with no computer experience at all to people who already used Slack every day. I looked but didn't find a good intro to Slack etiquette, which would explain things like "please don't @channel every time you have a question." I wrote up this quick doc to share with the crew, in an effort to get everyone the same page. Some of it's Temple specific, but a lot of it applies more generally! Let me know if you think of things to add; this is a work in progress.* -
This year we used a Slack team for organizing the Temple, and it was quite an adventure. We had a wide range of folks, from people with no computer experience at all to people who already used Slack every day. I looked but didn't find a good intro to Slack etiquette, which would explain things like "please don't @channel every time you have a question." I wrote up this quick doc to share with the crew, in an effort to get everyone the same page. Some of it's Temple specific, but a lot of it applies more generally! Let me know if you think of things to add; this is a work in progress.
- -

- -
Alerts
- -
+### Alerts There's different levels of alerts, and with great power comes great responsibility. Use them carefully. -
- -
- @here notifies everyone in the channel who is currently online. This includes folks using the mobile client, so be especially careful if your message might be late at night in someone's timezone. ONLY use this when you need an IMMEDIATE answer. - -
    -
  • Great use case: in #bay_area "@here what's the new combo for the gate? I'm out front". This is both urgent, and can be addressed by multiple people.
    • -
  • Bad use case: "@here when are we meeting next Tuesday?" This can be addressed by multiple people, but isn't urgent.
    • -
  • Bad use case: "@here let's meet next Tuesday at 11am" Anyone not currently online won't get this alert- you might think you've told everyone but someone may miss it.
    • -
-
- -
- @channel notifies everyone in the channel, often sending email to folks that aren't online. This is rarrrrrreeeely the right choice- only use it when you want absolutely everyone in that channel to see the message. - -
    -
  • Great use case: in #general "@channel we're sending out tickets tonight, please confirm your email address in this spreadsheet [link] in the next 2 hours"
    • -
  • Bad use case: in #general "@channel where are we at with the triangle plates?"
    • -
-
-
- -
- @[group] Slack allows you to create "groups" of people, which are perfect for making sure a whole team of folks gets a certain alert. Scheduling a meeting and don't want to use `@here` because not everyone is online? Create groups of folks instead, so you can contact the whole team with one handle. For example, @volunteer-coordinators messages Kai, Peggy, and Kristen, and is a great way to get our attention if you have a question about volunteer stuff. -
- -
- -
- @[individual] use anytime you have a specific question for them or want them to see something! People can snooze alerts if they want. If you @ someone who isn't in a channel, *they won't know about it* unless you invite them to the channel. Slack is nice and tells you when this is this case, so you can choose to invite them or send them a message about it. Please watch for this, to make sure people get the messages you're trying to send. -
- -
- -
-You can check your notifications by clicking on the @ in the upper right hand corner, which shows you a list of everywhere that someone used an alert in which you're included (and emoji responses to your messages!) -
- -
- -
Channels
+#### **`@here`** +Notifies everyone in the channel who is currently online. This includes folks using the mobile client, so be especially careful if your message might be late at night in someone's timezone. ONLY use this when you need an IMMEDIATE answer. -
+- **Great use case:** in #bay_area "@here what's the new combo for the gate? I'm out front". This is both urgent, and can be addressed by multiple people. +- **Bad use case:** "@here when are we meeting next Tuesday?" This can be addressed by multiple people, but isn't urgent. +- **Bad use case:** "@here let's meet next Tuesday at 11am" Anyone not currently online won't get this alert- you might think you've told everyone but someone may miss it. -
Keeping track
+#### **`@channel`** +Notifies everyone in the channel, often sending email to folks that aren't online. This is rarrrrrreeeely the right choice- only use it when you want absolutely everyone in that channel to see the message. -
+- **Great use case:** in #general "@channel we're sending out tickets tonight, please confirm your email address in this spreadsheet [link] in the next 2 hours" +- **Bad use case:** in #general "@channel where are we at with the triangle plates?" -
- There's lots! Channels help us keep conversations separate and organized. -
+#### **`@[group]`** +Slack allows you to create "groups" of people, which are perfect for making sure a whole team of folks gets a certain alert. Scheduling a meeting and don't want to use `@here` because not everyone is online? Create groups of folks instead, so you can contact the whole team with one handle. For example, @volunteer-coordinators messages Kai, Peggy, and Kristen, and is a great way to get our attention if you have a question about volunteer stuff. -
    +#### **`@[individual]`** +Use anytime you have a specific question for them or want them to see something! People can snooze alerts if they want. If you @ someone who isn't in a channel, *they won't know about it* unless you invite them to the channel. Slack is nice and tells you when this is this case, so you can choose to invite them or send them a message about it. Please watch for this, to make sure people get the messages you're trying to send. -
  • If you make a new channel, announce it in #general so everyone knows where that conversation is happening now. EX: "hey folks, I'm gonna be working on unicorn herding over in #unicorns"
    • +You can check your notifications by clicking on the `@` in the upper right hand corner, which shows you a list of everywhere that someone used an alert in which you're included (and emoji responses to your messages!) +## Channels +### Keeping track -
  • If you see conversations happening that should be in a specific channel, please help redirect them there: -
    - @kelpie: "hey I have a blue unicorn asking about tasks"
    @fawn: "@kelpie want to ask over in #unicorns?"     -
    • -
+There's lots! Channels help us keep conversations separate and organized. -
+- If you make a new channel, announce it in #general so everyone knows where that conversation is happening now. EX: "hey folks, I'm gonna be working on unicorn herding over in #unicorns" -
Organizing
+- If you see conversations happening that should be in a specific channel, please help redirect them there: +> @kelpie: "hey I have a blue unicorn asking about tasks" +> +> @fawn: "@kelpie want to ask over in #unicorns?" -
-
    -
  • Take advantage of the channel topic. For example, in the #crew-manual channel, we linked to the rough draft in the topic so anyone can find it when they join the channel. In a #techhelp channel, we might say "computer doing backflips? First try jumping jacks; if that doesn't work ping @samantha" Keep important docs and info there, and when you join a channel and have questions look there first!
    • +### Organizing -
  • You can mute/unmute channels by typing /mute. That means you stay in the channel, but don't get notifications from it, and don't see every time there's a new message. It's super helpful if you're an inbox-zero kind of person but don't want to completely leave channels.
    • +- Take advantage of the channel topic. For example, in the #crew-manual channel, we linked to the rough draft in the topic so anyone can find it when they join the channel. In a `#techhelp` channel, we might say "computer doing backflips? First try jumping jacks; if that doesn't work ping @samantha" Keep important docs and info there, and when you join a channel and have questions look there first! -
-
+- You can mute/unmute channels by typing `/mute`. That means you stay in the channel, but don't get notifications from it, and don't see every time there's a new message. It's super helpful if you're an inbox-zero kind of person but don't want to completely leave channels. -Staying in the Loop +## Staying in the Loop -
+- If at all possible, keep the conversation in public channels. + - It helps people understand how decisions were made, even when they're not participating + - It helps people know that things are getting done, which helps out the more anxious teammates :P + - It keeps us from having to repeat ourselves endlessly, because anyone can follow along or search for the info later -
    -
  • if at all possible, keep the conversation in public channels. -
      -
    • It helps people understand how decisions were made, even when they're not participating
      • -
    • It helps people know that things are getting done, which helps out the more anxious teammates :P
      • -
    • It keeps us from having to repeat ourselves endlessly, because anyone can follow along or search for the info later
      • -
    -
    • +- If you have a meeting in a different format (call, face-to-face, etc) take notes and post them back to slack. Keeping a record of conversations helps other people get caught up and helps you remember what you all decided together so you don't have to rehash it later. -
  • If you have a meeting in a different format (call, face-to-face, etc) take notes and post them back to slack. Keeping a record of conversations helps other people get caught up and helps you remember what you all decided together so you don't have to rehash it later.
    • +- If you plan a call or scheduled event, add it the temple calendar (linked in the #general topic)! It will automatically make a post in slack telling everyone, and handles timezones so everyone shows up at the same time. -
  • If you plan a call or scheduled event, add it the temple calendar (linked in the #general topic)! It will automatically make a post in slack telling everyone, and handles timezones so everyone shows up at the same time.
    • -
From ef60c08ae2349a860c5faaff233bca391d4fb76a Mon Sep 17 00:00:00 2001 From: Kai Date: Thu, 4 Oct 2018 21:02:59 -0700 Subject: [PATCH 7/8] remove buggy tag filter from notes for now --- _notes/2017-12-30-testing.md | 2 +- _notes/2018-09-01-slack-etiquette.md | 2 +- notes.html | 5 +---- 3 files changed, 3 insertions(+), 6 deletions(-) diff --git a/_notes/2017-12-30-testing.md b/_notes/2017-12-30-testing.md index fae4a4d..7647b5f 100644 --- a/_notes/2017-12-30-testing.md +++ b/_notes/2017-12-30-testing.md @@ -4,7 +4,7 @@ date: 2018-2-25 title: Testing, testing, 1 2 3 description: A quick test of the emergency broadcast system tags: writing test sirens -hidden: false +hidden: true --- diff --git a/_notes/2018-09-01-slack-etiquette.md b/_notes/2018-09-01-slack-etiquette.md index e4924ed..9aea61a 100644 --- a/_notes/2018-09-01-slack-etiquette.md +++ b/_notes/2018-09-01-slack-etiquette.md @@ -2,7 +2,7 @@ layout: note date: 2018-9-1 title: Slack Etiquette -description: Some ground-rules and protips for folks getting to know Slack, which I wrote while working with a bug group of Slack n00bs. +description: Some ground-rules and protips for folks getting to know Slack, which I wrote while working with a big group of Slack n00bs. tags: temple slack communication hidden: false diff --git a/notes.html b/notes.html index 1d2ecce..9b4a34c 100644 --- a/notes.html +++ b/notes.html @@ -2,16 +2,13 @@ layout: default description: Notes customScripts: - - tags.js ---
- {% include postFilter.html %} - {% assign notes = site.notes | where: 'hidden', 'false' %} - {% for note in notes %} + {% for note in notes reversed %}
From 7c66f135dce62100ac3871055da08e3d94642f41 Mon Sep 17 00:00:00 2001 From: Kai Date: Thu, 4 Oct 2018 21:25:29 -0700 Subject: [PATCH 8/8] add pairing post --- _notes/2018-08-01-pair-programming.md | 99 ++++++++++++++++++++++++++- 1 file changed, 96 insertions(+), 3 deletions(-) diff --git a/_notes/2018-08-01-pair-programming.md b/_notes/2018-08-01-pair-programming.md index 8c77fbf..cf3a628 100644 --- a/_notes/2018-08-01-pair-programming.md +++ b/_notes/2018-08-01-pair-programming.md @@ -1,11 +1,104 @@ --- layout: note date: 2018-8-1 -title: Pair Programming KaiStyle +title: How I like to Pair Program description: An intro to pairing, with helpful communication tips -tags: code +tags: code communication hidden: false --- -Hey this is a test post. \ No newline at end of file +Pair programming has a ton of benefits, but it’s also a skill that takes some practice to do well. At Mapbox, [Aarthy](https://twitter.com/aarthykaycee) and I worked together to refactor a gnarly part of our core codebase. We started the project by each taking chunks and working separately, but both of us got stuck in different areas and ended up working in circles. We had an on-site sprint lined up, so we used that opportunity to try out pair programming, with great success! Once we started working together instead of solo, we settled on a solution quickly and made steady progress. I’d learned pair programming in a teaching context, but using it to write production code had many of the same benefits. It does take some patience and thoughtfulness to do well, and a little prep goes a long way. With that in mind, here’s some of the things I’ve learned about pairing! + + + +### Pair Programming, What's That?! +So, you may ask, what exactly is pair programming? Pair programming is two developers working together on one computer. Each developer plays a role: + +**“Driver”** + - (Moves the wheel, presses the pedals) + - Types code + - Helps figure out syntax + - Asks clarifying questions + +**“Navigator”** + - (Checks map, tells the driver where to turn) + - Provides plan of action + - Tells driver what to type, and checks for understanding + - Helps pair stay on course + +Switch roles often, so that each person gets a chance to put their hands on the keyboard. Find the timing that works for your pair, but lean towards shorter intervals where possible. That’s a great way to make sure everyone stays on the same page, because each person needs to understand the work in order to accomplish both roles. + + +### But Why?! + +>"If you want to go fast, go alone. If you want to go far, go together." +> +>[Fake African Proverb](http://jezebel.com/on-the-origin-of-certain-quotable-african-proverbs-1766664089) + +If two developers are working on one thing, we're only getting half as much work done, right? Not at all! Pair programming has a ton of benefits: + +**Stronger Codebase/Team** +- **Produce Fewer Bugs:** With another set of eyes to think things through and watch for typos, you'll save a lot of debugging time. + +- **Spread Knowledge:** Pairing is a great way to ramp each other up on particular parts of the team's codebase. Having someone around to confirm your understanding and give more context means you can grasp code much more quickly than just reading it. + +- **More Effective than Code Reviews Alone:** It's easy to skim during code reviews, and most people only look at the diff. That means it's easy to miss code that didn't get changed but should have, or pass over something that had unintended consequences. Two people are more likely to remember to update everything and check each others' assumptions, and working together means you both have enough context to understand changes completely. + +**You’ll Learn a Lot, Fast** +- **Having a buddy helps get you unstuck:** Sometimes it's hard to hold a whole problem in your head. Having a buddy to bounce ideas off of or talk things through means you can keep moving forward even when you get confused. + +- **You see, hear, speak, and type:** Pairing is a constant cycle of different ways of processing information. That combination helps you retain knowledge. In particular, explaining your ideas and code to others helps you deepen your own understanding. + +- **You'll learn new ways to do things:** Both of us learned shortcuts, debugging tactics, and new ways to do things from each other. For example, at the time I had very little vim experience, but having Aarthy around to bail me out gave me the confidence to use it when we worked on remote servers. + +**It’s Great Practice** +- **You get used to explaining your thinking & your code:** Communicating about code doesn't always come naturally; it's a skill we should all develop. + +- **You feel more comfortable with your code & ideas:** Practice talking through ideas helps folks develop confidence about their work. + +- **You plan before you type:** It's easy to say "[YOLO](https://en.oxforddictionaries.com/definition/yolo)" and make a mess when you're working alone. Working with another person means you need to justify the steps you're taking, and can help prevent messy or non-functional code from happening in the first place. + +### But How?! + +**In-person Pairing** + +If you’re in the same location as your pair, you don’t need much extra equipment. An external monitor makes it much easier to read the same screen without invading each other’s space. Bonus points if you also have an extra keyboard and mouse, to make switching back and forth even easier! + +**Remote Pairing** + +If you work on a distributed team, pairing can be a little harder. Luckily, there’s plenty of tools to help! Slack, Zoom, and Hangouts all have built-in screenshare options. You do lose some of the non-verbal feedback you’d get from being in the same room. Here’s some tips to help with that: + +- **Be explicit:** Be extra careful to express your thoughts out loud and talk through each part of what you’re doing. + +- **Leave space:** Make sure you’re not programming with a silent screen buddy instead of actually pairing- it’s easy to take over the keyboard when you’re on your own computer. Keep the driver/navigator roles in mind and make sure you’re both participating. + +- **Watch:** Keep your pair’s face on your screen, so you can both keep track of how the other person is doing. Some folks are more expressive than others, and that extra signal is valuable. + +- **Get a feel for lag:** Working with video over a bad connection makes it extra difficult to keep up, so check in with your pair often and make sure they got everything. You can do things like pause after changes / typing out commands, to make sure your pair got a chance to see it before switching screens or hitting enter. + +- **Be sensitive to time differences:** You might be peppy and excited after your second morning coffee, but your pair might be settling down for the evening and in a different headspace. +Protips + +**Explicit Communication Goes a Long Way** + +For those of us used to working solo, pair programming can feel very different. Here's a couple tricks to keep everything working smoothly: + +- **Set the scene:** Questions like, “What’s your pairing style?”, “How often would you like to switch roles?”, and “Can you let me know if you want to slow down/speed up?” help make collaboration easier. + +- **Develop a game plan:** Before you start, talk about the problem together to get on the same page. This might include things like a tour through the existing code, or jotting down some user stories. + +- **Set a timer:** Pick a length of time for switching between roles, and set a timer to help you remember. I like to keep the interval almost uncomfortably short, and be super strict about switching, to make it really difficult to get out of sync with my pair. When pairing in person, try to switch every 5-10 minutes. When working with a remote pair, try switching every half hour, since changing screens takes a little longer. Feel free to stop when you reach a natural stopping point or when one of you feels like a change, too, as long as roles are shared. + +- **Take breaks:** For folks who are used to working alone, silently, collaborating intensely can be tiring. It's ok to take breaks, but take them together! Don't be tempted to keep working while your pair is doing something else. + +- **Step Up / Step Back:** If you're more experienced than your pair or tend to be more assertive, take this opportunity to step back a little; make sure your pair is heard and has the opportunity to lead. If you're less experienced or a little quieter, push yourself to step up more than usual. To get the benefits of pairing, both people need to participate as fully as they can. + +- **Ask lots of questions:** "Can we try...?", "What do you think of...?", "Do you think that will affect...?", "I was thinking [ ], can you think of a different way?" + +- **Give and receive feedback:** “Thanks for pairing!”, “Could I have done anything better?”, “I liked the way you ...”, “I would have liked more ..." + +![giphy](https://user-images.githubusercontent.com/11284580/29140147-4a5d6552-7cfe-11e7-9f0a-d4e8597efd9b.gif) + +### TL;DR +Pair programming is one more tool in our box, and it's worth trying out if you haven't done it before. It's a great way to learn from each other, build solid code, and develop strong communication skills.