Ask vs. Guess Culture Communications

This talk was presented in Detroit at self.conference 2015, in Berlin at eurucamp 2015, in Chicago at Write/Speak/Code 2016, in Braga at RubyConf Portugal 2016, and in London at The Lead Developer UK 2017.

Abstract:

Have you ever been told you’re “too direct,” or feel like you don’t understand what others want? Or on the other side, do you think others are often too confrontational? These are Ask vs Guess Culture differences. Ask folks believe it’s ok to ask anything, because it’s ok to say no, while Guess folks prioritize not imposing on others. It’s a culture clash that isn’t often recognized, yet causes quite a bit of tension and frustration. This talk will cover the nuances of these different communication styles, as well as strategies for bridging the gap. Gaining an understanding of these differences and learning specific tactics for a professional context will make you a drastically more effective communicator.

eurucamp slides, Storify:

The Lead Developer UK: slides, Storify
RubyConf Portugal: slides, Storify
Write/Speak/Code: slides, Storify
self.conference: slides, Storify

This was the original ~9min lightning talk I gave at a company engineering offsite:

How do you know if you would like programming?

I’d had some scrawled out notes for this post sitting around for ages but fortunately, Alan went ahead and wrote an excellent post on the topic! Some of my favorite points from his post:

• Your current technical ability with a computer is not a good measure of your technical aptitude.
• "You don’t actually need to know much math to be a programmer"
• "It’s not that you’re not smart enough, it’s just that programming can be really difficult"
• "When I say ‘you enjoy programming,’ what I don’t mean is that you are having an enjoyable experience the whole time."

I would recharacterize the “mental endurance”/grit section of it a bit. I think it’s a particular kind of grit, or tolerance for frustration, when it comes to programming. This is my favorite comic for describing what it feels like to be a programmer:

I also tell people from my old career that coding brings me really high highs and really low lows, but the highs are high enough *for me* to put up with the lows. And I don’t mind this particular kind of low as much, where some small detail missed somewhere is the actual cause of the problem, or it turns out that what we thought we were telling the computer to do isn’t what we were actually telling the computer to do.

Computers are really dumb! We all want to throw them out of the window, often! But when you get that feeling, are you the kind of stubborn to dig in your heels and get into a battle of wills with this inanimate object? That’s what helps you keep going until you get another hit from a successful solution. I think this tolerance for frustration is a kind of muscle that you can build over time, but I also think it’s not a coincidence that many programmers are really annoying to argue with or get to change their minds.

Alan put in some questions to ask yourself for the aptitude part:

• Do you enjoy puzzles? 
• Do you speak another language? 
• Are you able to describe and explain news events to people? 
• Have you helped plan a large event before? 
• Do you play an instrument?

Here are some more questions that might help:

• Do you enjoy hobbies where you have to put things together from smaller pieces? Example include: cooking, knitting, crocheting, sewing, woodworking, mechanic…
• Do you like organizing things, either in real life, or in things like spreadsheets?
• Do you have and enjoy using a label-maker?
• Do you like puzzles, either the physical kind or like those math logic puzzles where you have to fill out the charts based on your deductions from given statements?
• Are you a DIY type?
• Do you like figuring out how things work and building them?
• Do you like tinkering with things just to make them a bit better?
• Are you at least a bit lazy and will spend extra time overall so you can use your brain to figure out an easier solution to something (relevant xkcd comics: one, two)?
• Are you able to hold arbitrary rules in your head and compartmentalize to set aside certain things that you don’t quite understand right now but will think about later? 

But ultimately, Alan is also completely right that the barrier to testing out whether or not you’ll like programming is fortunately pretty low—there are plenty of places to get started! I’m hoping questions like those above and in this post will help encourage people from all backgrounds and ages to consider learning programming and we can leave the old “good at math and science” heuristic behind.

How to decide on companies after graduating from a coding bootcamp

Someone asked* me about how I judged whether companies were a good fit for me after graduating from a bootcamp, so here are some scattered thoughts on that.

First, I hated feeling like I was a supplicant begging for these companies to take a chance on me. That’s a fair viewpoint from a particular perspective, but generally not a very useful one for my confidence levels, and one that I would strongly argue away if it were happening to a friend of mine instead.** I believe strongly that everyone has their particular strengths they can bring to a position, regardless of their experience***, so with focusing on that, I wasn’t going to run after a company that didn’t like me, after I’d done the best I could in whatever their interview process was.

The company should understand that they’re taking me based on my potential and learning aptitude. I wanted to be somewhere that I’d have to room to learn on the job and not feel pressure to Already Know All The Things. I was very clear in all my interviews that I didn’t care so much about the content I was learning as the support and mentoring I might receive, and patience and good faith, in return for me working hard to get up to speed.****

One way I evaluated that was whether the company had taken on other bootcamp grads before, ideally from Hackbright as well. I figured that way, the company would have more reasonable expectations for what having me as an employee would be like. I admire people that are trailblazers, but I think being one is probably often a bit lonely and frustrating, so it’s easier to ride on someone else’s coattails a little, if you can.

Then I had the general things I personally look for in a working environment. There are some great blog posts out there on good questions to ask during interviews, like this one from Julia Evans, or this article on getting the inside scoop at a company before accepting an offer. For me, it’s very important for it to be a place where people learn from missteps made in the past, to be able to make different mistakes in the future, while being honest that it’s impossible for things to be 100% sunshine all the time.

I’d ask questions like, “what’s a mistake people at the company have made and how was it addressed?” I’d want to know whether the pep talks given by management seemed grounded in reality and humility. And at the same time as all that, that there wouldn’t be much time or energy wasted in just general grumbling or pure complaining and whining.

Finally, I know people will consider taking “less than ideal” jobs to get a foot in the door at desirable companies. I think this can go different ways depending on people’s circumstances and temperament. Finances and desire for stability are also a huge part of it, and there are plenty of successful post-bootcamp careers that aren’t with the title “software engineer.”

But in general I think if you accept something with the idea that you actually already know you want to move to a different position at that company, do your due diligence in having informational interviews on what their policy on internal transfers is. Be prepared for a more uphill battle than what they try to sell you on during interviews. Not that people are going to lie to you, it’ll just be the rosiest view of the possibilities due to their incentives for getting you to fill the role they currently have open, so go in with your appropriately sized sprinkling of salt.

* over a year ago…when I was giving practice talks for How To Be a Better Junior Developer…so this draft has, uh, aged a bit. But thanks again to whoever suggested that idea! Delay not due to you or the quality of the idea in the slightest, but pretty much only because it’s hard for me to summon up the energy for writing since I inevitable end up rambling for a while.
** One of my favorite tactics for stopping negativity spirals in my head is to remind myself, if a friend of mine were in that situation, would I say (or even just think!) such mean things to her as I was doing to myself? Never! And I would be absolutely outraged if anyone dared to treat her the way my internal monologue sometimes treats me! And then I tell myself, even if I don’t feel deserving of kindness for myself right then, I am a sufficiently not-awful human being to have friends around who would come to my defense as well, so I owe it to them not to be so mean to me. A bit meta and circular, but effective for me.
*** If you need help figuring this out, it helps to talk to someone else to get an outside perspective. Even with fixing up my resume or writing my quarterly accomplishments, it’s always felt easier to talk about how to enhance other people’s descriptions of their work than my own necessarily, so you can do a trade. Also my How To Be a Better Junior Developer talk is pretty much all about how you can contribute even when you’re new, so check that out for more of my thoughts on the matter.
**** Some of the hiring managers at New Relic would get slightly fondly exasperated with us from Hackbright all just being like “we just want to learn!!!” and wanted more specifics, to help figure out good fits for us, especially if multiple teams like a certain candidate. So it’s useful to figure out more detailed answers, to expand from “I want to learn everything” to “I have more of a preference of learning this backend part of your stack because I think it’s cool that _____ but I’m also interested in the frontend too because _____” which if you think about it, pretty much sums up to “everything” anyway.

Advice for your first talk

I’m going through and clearing out very old blog post drafts. This is from a randomly long email I wrote to the Hackbright listserv of advice for someone giving their first talk, after I’d given my first talk How to be a Better Junior Developer at RailsConf last year. The main point I’d add to all this is that you don’t have to succeed at All The Public Speaking Things all at once, on your first few talks. It’s easy to get swallowed by all the information on public speaking out there, so if you’re getting too overwhelmed by it all, I think it’s more effective to ask yourself:

1. What do you want your audience to get out of your talk?
2. What do you want to get out of having given the talk?

For example, for my How to be a Better Junior Developer talk, the answers to these questions were essentially “get them thinking about all the non-traditional strengths they bring to a team” and “give a talk at a tech conference.” Then later I could know that I succeeded, since I’ve had lots of conversations with people about the former, and I didn’t literally die, so I succeeded at the latter as well!

One of the reasons I wasn’t super thrilled immediately after that talk was that I had some secret (even to myself!) goals that I was caring too much about, like wanting to be validated by getting the audience to laugh, or having a flawless delivery that matched up exactly with the script I’d written out. It would’ve been better to save those for future talks, not to mention explicitly stating them, which would let me see when they’d need to be adjusted to be more productive (no one else cares about how well it matches against my script).

For example, it’s a future goal of mine to be able to do the thing where you don’t need to refer to speaker notes at all and can just wander around out in front of the protection of the podium. But for my Slighty Less Painful Time Zones talk, my goal was to give a talk with code in it, with clear explanations and generalizable lessons for the audience. So it was ok that I still wanted to stay behind the safety of the podium and reference my speaker notes there.

Finally, related to all the above, getting better at public speaking is a continual quest. One of the reasons I started reading about improving at public speaking was that I figured this was one of those skills where no one would ever be like, "oh, so-and-so is too good at public speaking." There’s always room for improvement! To that end, these are the resources I use to learn more about how to improve:

• Observing what I like/dislike in other people’s talks (sometimes I get distracted by the meta-ness and have to remind myself to be paying attention to the content too, not just the delivery style)
• Reflecting after each talk to note to give future-me a list of what to do better next time (like after RailsConf 2014 and RailsConf 2015)
• The Eloquent Woman (blog)
• Technically Speaking (newsletter)
• Presentation Zen (blog, doesn't update that frequently)
• Femgineer’s Confident Communicator course looked excellent in the preview webinar I attended, hopefully I’ll get to take it some time!

Talk content:

• Once I knew I was going to give a talk, I kept a running doc of all the random ideas that came to mind that I thought I might want to fit in, other articles that came up that seemed like they'd be relevant, until I had enough of a mass of material that I could cut down to fit 30 minutes, vs. like with writing papers when I always felt like I was stretching to reach the word count.
• Write up at least your talk outline first, outside of making slides. Much more work to fiddle with slides later if the structure of your talk isn't pinned down yet.
• Sometimes I write out an exact script and practice it until I can do it off referencing bullet points or ideally no speaker notes at all, but that takes a lot of time. Practicing it out loud helps me realize which turns of phrase are fine in writing but sound awkward out loud, or that I have trouble remembering. I'm trying to become more flexible about this kind of thing though, so I think it depends on how much you would benefit from the extra structure.
• People love personal stories, make yourself relatable to evoke empathy and help people feel like they're getting more out of your talk. Basically you’re like, “I’ve been where you are, I understand you, here's how I got out and how you can do it too" and it gets received as, “I’m like this person, so what this person says is relevant to me...that was such a great talk!!"
• Asking rhetorical questions are an easy way to get "audience participation" without feeling like it's too much of a strain. I did a ton of, “Show of hands, how many people have felt this way before??" and raised up my own hand to get people to see that I expected a response.

Talk length:

• If you think about it, few people ever say, "man, I wish that speech was a lot longer." So it's better to hit 20 minutes and leave them wanting more, than going way over time allotted for a 30 minute talk to 40 minutes instead.
• Related to that, I’m always reminding myself to try to sloooooow dooooown. My default speaking speed is on the faster end of things, and when I get nervous on stage it can get jerkier and squeaky--not a very effective delivery mode for me. So adding in uncertainty for whether I can finish in the allotted time doesn’t help, and it’s better to think I can slow down as much as I want and not go over.
• Or, think about the talk as a series of mini-talks that you're stitching together. Might be less intimidating to pull together three 10-minute talks than one 30-minute talk?

Technical details:

• I used Keynote for the first time and loved it, if you have a Mac and can get access to it, it's definitely worth trying out because they basically set it up so that it's hard to make ugly slides. Could be worth seeing if you can expense it. (see this post I wrote on slide building tips)
• Look at a handful (but not too many) other speaker decks to get a general sense of designs/formats/structures that you like. Then just blatantly copy one of them and sub out for your own content--unless this is a talk about design, people won't really care that much about the slides themselves for you to spend enormous amounts of time on them. My slides, other random sets I liked. 

Dealing with nerves:

• Power pose
• Put a positive frame on the stress you feel
• Doing a handful of jumping jacks right beforehand (this way I can tell myself my elevated heart rate is due to exercise instead of nervousness)
• Whatever else you need for you, even (especially) if that means being completely anti-social and not talking to anyone beforehand
• Don't apologize for being new or not having a lot of time to prepare, but you can expose your vulnerability to get people on your side to root for you, if that works for you. So like, instead of "sorry this talk was kind of last minute...", you can say "I'm so excited to be here! I'm a little nervous though, so I'd really appreciate it if you all _____" (a friend of mine filled this in with "encouraged me by clapping whenever I get to a section title slide or take too long a pause" which worked really well for him, but he's also just kind of very charming and adorable)
• "How to Talk to Developers" by Ben Orenstein is good, ~30 min long. There's a really good set of practical tips around body language and such near the end, so stick with it.

Other:

• Practice practice practice. Don’t be shy, corral people you know to be guinea pigs and get feedback from them before the real thing. Practice at local meet ups, go to local code schools to be a guest speaker, etc.
• Practicing in front of the bathroom mirror is something I find helpful, because I know immediately if I'm making eye contact with myself.
• Including practicing taking breaks to drink water!
• Include practicing with a clicker, there are lots of remotes you can set up to use as a clicker. It lets you be a bit looser than if you’re tied to hitting an arrow button.
• You will probably forget to say something you planned on saying during your talk. Who cares! It's more important to convey your overall message and connect with the audience than to remember every detail of your planned talk.
• Relax and enjoy the experience; the audience will too! It is the most amazing adrenaline rush you're done and it's gone really well, so use those nerves to pump energy and enthusiasm into your talk.

Slide building tips

Kind of a grab bag of things I learned last year while building slide decks for my talks in Keynote. Keynote has a lot of really nice features and defaults to help you make a visually appealing set of slides even if you’re not a designer.

Keynote things:

• My favorite thing about Keynote is the ability to group slides together. It's really useful to be able to deal with sections of slides at a time by collapsing/uncollapsing, and you can even nest these groups for further sub-sections.

• You can also "Skip" slides to hide them from view without having to delete them...sometimes I'll put an Appendix section at the end for slides I'm not sure about and then I can Skip them all as a group to hide them from the printed PDF version for uploading to speakerdeck.
• There's a lot of power in customizing the master slide templates and doing so early on so that similar sets of slides (section headers, repeats of the agenda, etc.) can be updated in one fell swoop later on
• You can set text fields to be editable in order to have placeholders with the right styles applied, but being able to customize the content. I did this with the navigation breadcrumbs along the top of the slides in How To Be a Better Junior Developer
• Do a couple runthroughs where you click through your slides really quickly, which helps you notice mistakes in alignment/spacing that aren’t consistent
• If you want to practice on own computer w/o display and see speaker notes, choose “View > Rehearse Slideshow”
• I like the orientation of slides where the current slide is on the left, the next slide or action build is on the right, and your notes are on the bottom, as well as having the timer at the top:

Visuals:

• color.adobe.com for color schemes, use hex code converted into numbers to figure out what the RGB color equivalent is. Apparently you can also use Mac color palettes? I need to learn how to do this.
• Getting photos: search on flickr under Creative Commons 
• Icons: The Noun Project
• The font in my slides is all just Helvetica, altering between light and bold (but avoid Helvetica Light on a dark background, becomes hard to read).
• When it was bold, especially for headers I also set the letter spacing so that the letters would be a lot closer together, based on my designer friend's advice. See this example slide.
• Don't be afraid to move up text closer to header from the default in the template for better spacing

Uploading slides:

• To get a PDF to upload to something like Speaker Deck, “Export to PDF” instead of printing and saving to PDF; the latter leaves you with a white border above and below the slides
• As a viewer, I like it when people have detailed speaker notes with their uploaded slides because it’s faster for me to skim through those than to listen to the talk to see how much I might get out of it. As a speaker, it would take a fair amount of extra effort on top of what I already put into building the slides and practicing the talk to make the speaker notes readable and not embarrassing :) so as a result I’ve only just uploaded the slides, plus hypocritically, even though I don’t like watching videos that much, I kind of want other people to watch mine.

Putting code snippets on slides

[Update 5/17] This presentation has excellent advice on putting code on slides, with examples.

My Slightly Less Painful Time Zones talk was the first talk I’ve done that had code in it, so I learned some new things about making slides that have code on them.

Setting up the slides

According to trusted references, it’s best to go with a dark-on-light color scheme than a light-on-dark one you might work with normally. The reason for this is how projectors work, apparently? I didn’t test or question this too much but I’m happy to accept it as true.

When I first put together some draft slides, I just did quick screenshots of my code in the text editor. This become unwieldy pretty quickly; the inconsistent sizes of the images bothered me and it was annoying to have to take a new screenshot every time I noticed a small error or correction that I needed to make.

Then I learned about plugins that let you copy code with syntax highlighting in them! I found this SublimeHighlight plugin that lets you copy your code with its own specified color scheme independent of your actual Sublime theme. Pretty neat! The default color schemes available weren’t perfect when I tested them but I ran out of time to tweak the tool setup and did end up adjusting some of the colors directly in the slides. I decided I vastly preferred code as text on the slides, rather than images.

For console output, normally I use iTerm (to have numbered keyboard shortcuts to move between tabs), but it wouldn’t copy over output with RTF. The Terminal program does, though, so I just used that.

What to show on the slides

I had gone into the slide-making process thinking that I needed the code on the slides to prove I wasn’t making up the stuff I was talking about, so it was kind of a defensive attitude at first. After a practice run, my talk mentor Jason made this excellent point:

Code slides are generally primarily meant to convey information and are not meant to be code that can be immediately downloaded as is to be run. 

So a better approach is to figure out what’s actually important to highlight for the points of discussion in that section of the talk and only show those pieces of code on the slide.

Thinking back to my own experiences, there’s a fairly low limit to how much code on one slide that people can absorb, so removing some of the extraneous stuff needed for setup or breaking things down into smaller pieces by using helper methods (that you don’t actually have to show) is totally fine. Other tactics include showing the whole block of code at once, fade out, then highlight the code line by line again to review.

The main way I ended up doing it was judging based on each slide whether I wanted to build it line-by-line (often useful for console output) or if there were certain sections that I’d just build as a paragraph group together to go with an explanation like “these lines do __this one thing__.” If you peruse the slides, you should be able to get a rough sense of this since I exported the PDF to have the different slide builds all in there.

Atlanta

I got the general impression that people were a little less excited about RailsConf being in Atlanta last year as compared to last year in Chicago, but I left with a very positive impression after my 3 days and 3 nights there.

I’ve only been to places in the American South a handful of times, but it’s really true that people are friendlier and chattier there than the brusque NE environments I’m used to. Andre here chatted me up while I was walking out and about and then called over his niece Tamara for us to exchange contact info and for us to take this selfie:

Also when I was waiting for my shuttle to the airport, one of the bellhops started a conversation with me about my Harry Potter t-shirt and it turns out this 6’ tall broad black dude and I have a ton in common for Harry Potter nerdom, re-reading the whole series every so often, an enthusiasm for weightlifting, and growing up as adults to not be embarrassed about the things we’re into.

Food

The speaker dinner was across the street from the hotel at Alma Cocina, which had quite good Mexican food! The shrimp enchiladas and the spicy chocolate cookies for dessert were especially tasty.

I discovered The Food Shoppe when I was trying to find a breakfast place nearby for meeting up with my Opportunity Scholar. They didn’t open up early enough for us, but the Yelp reviews were so effusive that I was determined to make my way there for some other meal. They really do give out samples for pretty much everything! The mac & cheese tasted delicious and of course I had to get the bread pudding, even though I knew I wouldn’t be able to finish the whole serving. My favorite was probably the corn bread though, it was spicy and cheesy and not-too-sweet and way more amazing than this crappy photo:

At the airport, I followed this airport foods guide (did you know that airport food guides are a thing? How helpful!) and went to a different terminal than where my gate was actually at to get dinner from Paschal’s. The fried chicken is indeed surprisingly good for what looks like a cafeteria buffet line. A little too salty for my taste, but not as salty (or crispy, really) as the fried chicken I had at Willie Mae’s in New Orleans.

Transportation

I used Super Shuttle to get between the airport and the hotel. It was pretty quick and convenient, though it seems I could’ve also just taken the MARTA since it has a stop right by the Westin we were at. Speaking of MARTA, I used it twice to get to the Thoughtworks office and it was plenty efficient/clean/inexpensive for big city public transit.

College for the (Older) Masses

Given that this piece was from the New York Times and I’d seen it floating around on Twitter with the quote pulled from the end:

Americans agree that "our kids" should go to college. The debate is really about who qualifies as "our kids."

I had fairly low expectations about how fairly and seriously it would take the arguments for “college isn’t for everyone.” It actually wasn’t that bad, giving a fair amount of space for paragraphs like this:

A question that has always hung over these findings is whether college itself deserves any credit for the patterns. You can imagine a scenario in which college graduates would thrive regardless of whether they went to college, because of their own skills and drives. By this same logic, helping more people become college graduates might not necessarily benefit them. But the new findings are the latest, and maybe strongest, reason to believe that college matters. Much as staying in high school is generally a better life strategy than dropping out, continuing on to college seems like the better plan for a great majority of students.

This is a theme that Dan has written about where if the main benefit from college is the signaling and access to the network, or the maturity from being several years older, and the education itself doesn’t make that much of a difference, then pouring more of our society’s resources into getting everyone through that program doesn’t actually benefit us very much.

It seems to me, though, that the main area this article needed to point out (and would have if someone like Megan McArdle/Ross Douthat/Reihan Salam had been its author) is that while it may be true that college is “the better plan for a great majority of students,” how large is the harm to those students for whom college is a risk that panned out poorly?

This is is an incomplete prescription:

The biggest problem with the colleges that marginal students attend, like Florida International and several state colleges in Georgia, is how many students fall down and don’t figure out a way to keep going. Dropout rates typically hover around 50 percent, which leaves students with the grim combination of debt and no degree. Reducing these rates could bring big economic benefits. Until that happens, some people have been left to wonder whether many teenagers should simply give up on the idea of college.

because you can reduce dropout rates both through helping struggling students more and having a stronger filter for incoming students in the first place.

An interesting way to test for this would be to have greater support for, say, people who are 25+ and getting their first degree than people who are 18. I generally think that like with healthcare, pushing the realizations of the true cost away from the consumer is a key driver of increasing prices, but I’d support experimenting with age-based (or work experience-based, if you were able to measure that—like, you’ve been supporting yourself and filing your own taxes for the last 7 years) funding.

Very few teenagers really understand the decisions they’re making when they go straight to college after spending the vast majority of their lives in a classroom, not like ye olde teenagers that have been working in full-time apprenticeships and such. So let’s try borrowing the idea of some gap years into our culture and see if it helps those that go to college get more out of it.