In an attempt to dispel the idea that if you have to google stuff you’re not a proper engineer, this is a list of nearly everything I googled in a week at work, where I’m a software engineer with several years’ experience.

Obviously these weren’t all googled in a row (although you can probably spot that a few were), but throughout the day. I can’t remember the context of everything I was googling, but hopefully it’ll make you feel a little better next time you have to google something.

Monday

npm react-testing-library - during a React upgrade, looking at dependencies to see latest versions and checking for breaking changes.

Expecting a parsed GraphQL document. Perhaps you need to wrap the query string in a "gql" tag? - said React upgrade then started causing some super fun errors.

react-apollo release notes

react-apollo/test-utils - tests were throwing some odd errors with our graphQL components.

undo a rebase - oops.

react testing library apollo "invariant violation" - package upgrades are so much fun!

jest silence warnings - don’t judge me, ok?

semantic HTML contact details - wanted to check if the <address> tag was relevant here

aa contrast checker

temporary visual impairment - fact checking for an accessibility talk I was giving that week

dominos accessibility - popcorn.gif

shame gif - an important part of any presentation

Tuesday

javascript get array of unique dates - if I have an array of Dates, how can I filter them so they are unique? (reduce, naturally, but I can rarely use that without googling it first)

date to locale string

js date to locale string - after I got a load of Java results

alternatives to Moment.js - it’s large

group array items by date - more reduce fun

sort object keys javascript

react fragment keys

next link - needed a reminder of how to use the Link component in Next.JS

React.Children.only expected to receive a single React element child.

visual studio code disable autocomplete html - it keeps autoclosing HTML elements on the same line, and I still can’t switch it off

dt dd dl - couldn’t remember what the example use for these was.

html nested sections - is it ok to have <section> inside <section>?

display dl in pairs

veggie ipsum - the best lorem ipsum generator

css keyframes

css animate underline text

dl vs ul

react generating keys - should I use some kind of hash, or should I use data in the props? (I ended up constructing a string with unique timestamp data)

css checkbox - can we style checkboxes yet? (no)

flexbox center span - it was 17:24 and I was tired by this point

grid minmax

flexible grid row - I don’t have a whole lot of CSS Grid experience, so I always end up googling a ton with this.

grid row height auto

cauliflower shortage - someone told me about this and I panicked

next.js hooks - we can use them, right? (we can, and I did)

Wednesday

cors - today is going to be bleak

the corrs - once I hit some CORS errors I decided I needed to make a meme, and I needed to find the perfect image. It took a surprisingly long time.

git patch trailing whitespace - I was sent a git patch with some whitespace that prevented it from actually patching

jsx annotation

web api fetch preflight - in my CORS adventures I wanted to read up a bit more about preflight requests.

web api fetch origin header

discriminated union flow - trying to diagnose problems with my Flow types.

whitespace regex - is it \w? (no, that’s a word - it’s \s)

regex not letter

pat butcher emoji - what can I say, I google important things

woman shouting at cat

google oauth

next.js authentication - sometimes it’s helpful to google stuff to see if anyone has written examples of how to do common flows in the framework or tool that you’re using

component displayname - do I need to do this with my higher-order components?

nextCookie - starting to mess around with oauth cookies

reading cookies in react - there must be a better way than document.cookie

js-cookie npm

cookies-js

npm cookie

universal-cookie

google oauth cookie

🍪

Thursday

"log in with google" localhost - was having all sorts of problems getting this to work

httpserverrequest javascript - I have a feeling this was something to do with Flow types

nextjs flowtypes - yep, there you go

"python-social-auth" react - trying to figure out if the django backend I was working with would play nicely with my React frontend

google social login

vary header

get cookie from 302

google social login cookies - I was having a really fun time with this as you can tell

google oauth cookie

python-social-auth set-cookie

python-social-auth site:stackoverflow.com

python-social-auth react site:stackoverflow.com

django - I think I gave up at this point and just googled Django because I have literally never used it

fetch send cookies

testing same origin credentials locally

cross origin cookies - spoiler alert: not a thing

useState default value

"The value of the 'Access-Control-Allow-Origin' header in the response must not be the wildcard '*' when when the request's credentials mode is 'include'. - googling error messages is only second to console.log() as a debugging method

useState with empty array

react hooks initial state empty array

"Provisional headers are shown" - this is where the requests weren’t going through and I couldn’t see what the actual headers being sent were

fetch send cookies

how to see request headers in chrome

fetch not sending cookies

Thursday was a whole lot of fun D:

Friday

provisional headers are shown - still at it.

sending cookies from localhost - have I mentioned that I hate cookies?

editing host file - desperate times (and it didn’t even work)

sending cookies with different domain

next cookie

getinitialprops functional component

getting cookies from document

js find - to check the usage and return types

string contains

string methods js - I can’t keep any of these in my head

js string methods - 20 mins later

js fetch manual cookie

django react cookies localhost

django react cookies localhost site:stackoverflow.com

httponly cookie

django httponly

async await promise.all

nextjs port

google appengine node ports

next rename static

install gcloud cli

method patch - couldn’t remember what the HTTP method PATCH does.

nextjs env

next.js environment variables

next js docs

editing data with hooks - literally no idea what I was trying to google here but this was past 5pm so I was evidently quite tired

react form submit

dayjs - I needed the documentation again.

What I’m trying to show with all this is that you can do something 100 times but still not remember how to do it off the top of your head. Never be ashamed of googling, even if it seems like the most basic thing you’re looking up. I can never remember how Date works. I’ve built plenty of forms in React but couldn’t remember how onSubmit worked on the Friday evening at 5:30pm. I constantly have to google JS string methods. Cookies are terrible. (Incidentally, we fixed the cookie issue by running everything in a docker container and tunneling with ngrok, so everything’s on the same domain.)

Tech job interviews are often different flavours of the same thing, regardless of where you apply. Interviewers are likely to ask you questions about your experiences, perhaps a hypothetical question about what you might do in a certain situation, or delve into some of the how-it-works stuff under the hood of whatever programming language you’ll be using. However, there’s one question that you can guarantee will come up:

“Do you have any questions for us?”

(At this point you’ll probably sigh with relief - internally, at least - as you’ve reached the end of the interview.)

It might be tempting to just skip over this with a “no, thank you” - maybe the job description gave you enough information for now - but you should always ask at least one question. It’s a surprisingly important part of the interview. Firstly, it’s an opportunity for you to squash any worries you might have, or find out the answers to anything that wasn’t quite clear before. Secondly, it’s a chance for you to peek into how things really are at Company X before you get too far in and realise you’ve Made A Huge Mistake. An interview should be as much you interviewing them as it is them interviewing you, as you need to find out whether the company is a good fit for you.

Of course, you don’t have to wait until the very end of the interview to ask questions - it’s great to ask relevant questions throughout (though be careful that you don’t end up answering every question with another question)!

What your questions say about you

This part of the interview is not just for your benefit: the questions you ask tell the interviewer more about you than you might think. For starters, it shows how engaged you are, what your priorities are and the kind of things you value in your role. It’s an opportunity to show off your knowledge and experience by asking questions tailored to the work that you’re looking for.

How many questions is too many? It depends how much time you’ve got left, but don’t be afraid to turn up with a list. I brought a notebook into mine, and I took notes while they answered.

So, what kind of questions might you ask? Obviously it’s a chance for you to get answers to things that weren’t clear about the application process or the job itself. You can ask about the kind of learning and development opportunities, or ask the old favourite of “what do you like most about working here”? Don’t be afraid to spin questions that the interviewer asked you back around on them, as long as it’s relevant and reasonable.

My favourite interview question tactic is to think about things from my previous roles that frustrate you or that you know you don’t want to experience again. Asking questions about these things can give you an idea of whether they do things differently at this place, or whether you’re walking into the same job all over again. (Alternatively, if there’s something you particuarly enjoy about your current role, it’s a good way of finding out whether it’ll be the same at this new place too.)

I’ll give you some questions that I might ask as a starter (and in some cases, what these questions are really asking). I’m not saying you should ask all of these questions - that would probably take all afternoon - but feel free to pick and choose depending on where you’re applying and what’s important to you. They’re here as a starting point.

The “how does this work here?” questions

These are the questions based on your past experience. It’s a great way to understand more about processes at the company, as well as making sure you won’t end up working at somewhere that’s exactly the same as your last place (unless that’s something you want).

Working in product teams

How closely do the dev team work with business stakeholders/customers?

Is this a case of “IT vs The Business” or are engineers embedded throughout the company? I’ve worked in both situations, and it’s much nicer being considered a core part of the business rather than a “supporting function” building a product for someone else’s business needs. Is there a product manager on the team who represents the needs of the customer? Are there regular demos with relevant stakeholders? Do they do any user testing?

How does work come in to the team?

How involved are engineers with deciding what to build?

Am I going to be involved in the decision making and the shaping of what we’re building or am I going to be blindly picking up JIRA tickets? Is it an iterative development process, or is it a case of “requirements come in, code comes out 6 months later”?

It took a bit of getting used to, but now I love being involved right at the beginning, helping to decide what it is we’re going to build and how we’re going to build it. It’s related to the first question in that it shows that engineering is a core part of the company and not just something that you do to achieve the thing for the business.

Who makes technical decisions? How much independence do product teams have to make technical decisions?

This question is about autonomy in what you’re building. Is it going to be a case of “here is the work, go and do it” or “how shall we build this? What do you think?”

Some degree of uniformity is vital, especially if you’re working with lots of microservices. But having strategies for the way you work and the technologies you use is one thing; being told exactly what to do and having no independence or flexibility is another thing entirely.

Code, deployment and infrastructure

Who looks after the live applications?

Is it “you build it, you run it” or is it “you build it, and throw it over the wall”? Do engineers have ownership of the apps they build, and are they trusted to look after them?

It’s also worth finding out how on-call works, because if that’s something that you can accommodate, it’s a great opportunity to learn about the tech and how things work.

What’s your deployment process like?

What does an average path to production look like for a service or application?

Do you practice continuous integration?

How often do you release to production?

Can I deploy stuff myself on an ad-hoc basis, or is it once a week/every three months? Is it going to be six months before you let me put it into the wild?

This is about finding out how much friction there is in the path to production. The more obstacles and Process With A Capital P, the more obstacles to innovation and experimentation. That said, there is a happy medium, and I don’t believe you should be firing off software into prod without due diligence, some process and quality control, especially when you’re working with people’s data. It’s worth finding out how the company handles that delicate balance.

Bonus points for continuous deployment.

Say I wanted to spin up a new service. How would I do that?

Would I need to get permission from the Change Advisory Board in a distant ivory tower? Would I need to write numerous documents and have handover meetings for deployment and maintenance?

The answer I got in my Monzo interview was “there’s a command line script to generate a new service” and I nearly wept with joy.

How do you do version control?

If they say “Subversion”, it’s time to question why. Is there a big beast of a monolith that was written in Java 6 and nobody has quite had the guts to move it off SVN because they aren’t quite sure where all the code lives, and do you really want to work with that every day?

How are architectural decisions made?

Do you have an architecture team? What do they do?

Do you have people whose job title is literally “Architect”? If so, are they hands-on and technical, or do they come in and tell you how to build stuff and then leave again? Am I going to be allowed to make my own decisions about the structure of the software I’m building?

I’ve definitely met some good architects, but really things like solution architecture should be done by the team building the actual thing.

What’s your testing strategy?

Do your developers do any testing? (Conversely, are you obsessed with as high test coverage as possible?) And if there’s pretty poor test coverage, are they open to improving it or do they see it as a waste of time?

The “how is it really?” questions

The questions that help you delve into day-to-day life at the company.

What does a typical day look like for you?

What are the working hours like here?

Will I be working until 8pm, or can I go to my clay pigeon shooting evening class without getting Meaningful Glances from my colleagues behind their screens?

Perhaps I’m naïve, but I firmly believe in a work-life balance. I was very lucky to have that in my previous job, and I have it in my current job. I don’t believe working later makes you a better contributor, as I think the more tired and burned out you get the worse your work is going to be in the long run. I want to know what kind of hours people keep so I can factor it into my decision.

Are there many parents here?

How does parental leave work here?

What facilities do you have for new parents?

This one is not a question I’ve asked, as I don’t have children and don’t plan to have them any time soon, but if you’re a parent or at that stage in your life where it’s something you’re thinking about, you want to know whether it’s a parent-friendly workplace, whether there’s anywhere to go and breastfeed, and what kind of caregiver leave they offer.

I know that some places can be a bit funny if women of childbearing age ask about this kind of thing in interviews; if that’s the case, I would question whether it’s really somewhere you want to work.

What kind of diversity and inclusion initiatives do you have here?

Does the company take diversity and inclusion seriously? Many (if not most) tech companies have traditionally very poor diversity in terms of gender and ethnicity - and often age, too. Trying to hire from a more diverse pool of candidates is one thing, but how are they trying to make things better in order to get people to stay? Are they hiring a diversity and inclusion lead? Do they have groups or networks?

The “where can I go from here?” questions

What kind of learning and development opportunities are there for employees?

A good way to find out whether they have a learning budget, or whether you can ask for books/courses/conference tickets.

Do you ever host meetups or community events?

Perhas not important to everyone, but as someone who owes a lot of my professional development to the community as a whole, it’s really important that wherever I work has a good community spirit.

Do people here ever speak at conferences?

This one is a bit less helpful as (especially if it’s a small team) it could be that the employees don’t want to speak at a conference, and that’s totally fine. But if it’s a huge company and nobody really speaks at conferences, it kind of raises the question of whether anyone does anything worth talking about (or, if they are, whether the company isn’t keen on letting them talk about it.)

I hope this has given you an idea of the kind of questions you might want to ask at an interview, but more importantly, the value you can get from asking them. If you’ve got any more thoughts or ideas for interview questions, share this on Twitter with the link below and join the conversation!

When you’re talking about what you’re working on, do you ever stop to think about what you’re saying and whether the person you’re talking to can actually understand it?

There’s more to being a software engineer than coding. What people often underestimate are the so-called “soft skills” (the worst term for something that’s really vital) - the way that you interact with others around you. In particular, how you communicate what you’re doing to people with different skillsets.

Imagine you’re in a standup and someone gives this update:

I’ll synthesize the haptic DDR3 network, that should shut down the SDD capacitor!

This came straight from the brilliant Hollywood Jargon Generator, but to anyone who doesn’t have as much technical experience as you, that might as well have been what you just said.

u wot m8

One of the best pieces of advice I ever got was from a tech lead who took all of the engineers aside after a standup where we’d been discussing how we were getting on with the new authentication flow we were writing. She told us to make sure we didn’t go into too much technical detail in the standup, so that everyone could understand it. Sounds so simple, right?

We’d just spent ten minutes with the rest of the team - including our product manager and the marketing lead - and we’d been talking about refresh tokens and token expiry. It had meant absolutely nothing to several of the people there. The more we mentioned these arcane technical concepts, the less the rest of the team wanted to come along to standups because they felt it was irrelevant or above them in some way.

“But it’s a standup!” I hear you cry. “You’re only meant to give a quick high-level update anyway!”

You’d be surprised how easy it is to start talking in jargon without even realising for even the smallest of updates. Next time you give a standup update, ask yourself: if I weren’t technical, would I know what I was talking about?

How much technical detail do you really need to go into? If your standup tends to be “here’s what I did yesterday and here’s what I’m doing today”, do you need to say:

We’re still trying to get the auth service to store the user’s refresh token in the database and check it against the incoming requests.

or can you just say

We’re still trying to get authentication working in the backend.

To you the first example might look pretty easy to understand, but that’s probably because you’re an engineer. You know what a refresh token is. You know what a request is in this context. Non-technical folk probably knows what a database is, and what authentication is, but that’s about it, and they’ve switched off by the end of the sentence. By keeping the technical detail to a minimum you’ll be providing an update that the rest of the team understand, so they know what everyone’s working on.

What about if there’s a particular technical thing that’s blocking you that you wanted to mention in standup? Either mention that you’re generally blocked in the update and approach one of your fellow engineers afterwards, or maybe have a 5-minute dev-only standup after the main team standup where you can go into more technical detail.

Here’s another example:

Some of our ElasticSearch nodes went down last night, it turns out we are still using the old cluster so we’re going to migrate to the new cluster today.

vs.

Our search system went down last night, it turns out we’re using an old server* so we’re going to move it to the newer one today.

* I know this isn’t technically the same thing, but to someone who doesn’t know what a cluster is, it literally doesn’t matter. You can go into more detail in the relevant dev standup/slack channel/coffee break.

Use real-world analogies

Keeping your language simple works for technical people too. If you’re mentoring another engineer or helping someone work through a problem, being able to explain technical concepts in an easy-to-understand way and relating them to tangible concepts in the real world can really help others to learn from you. You’ll find it a useful skill for giving talks - there’s a real difference between “show me how” and “make me understand”. For example, in a talk about redux-saga I used pictures of dogs to illustrate the library of effects it provides. In pretty much every object-oriented programming language tutorial there is some kind of Person or Car class to help you understand the concept of an object, and the tutorials about composition and inheritance usually talk about different species of animals.

With the auth token example, I told my team a story about a secret members’ club involving an ever-changing secret handshake and a badge that let you learn the new secret handshake, which went down well and helped the others to get what we were trying to do, even though my product manager thought I was talking about a sex club.

Yeah, so we really need to reticulate the splines in our codebase

It’s not just standups where this skill comes in handy: in your day-to-day role, explaining technical things clearly and simply might be the thing that convinces them why you should take a break from delivering new features to go back and tackle the mountain of tech debt that’s been piling up:

We need to upgrade a lot of the packages, check for security vulnerabilities and replace a lot of deprecated code.

What does “deprecated” mean? What are packages in this context?

We’ve got some old code that needs updating because soon it won’t work any more, and it might pose a security risk.

It sounds so basic, but to a non-engineer, that’s all they need to know. They might ask some questions about what kind of risk it poses, or what “won’t work any more” means, but it’s a lot easier to follow.

Challenge yourself to keep it simple

It’s not always easy to translate the hard stuff in easy terms, especially when you’re working on things that involve kubernetes (true story). I still haven’t found a good layman’s explanation for what Docker does. But next time you’re in a standup, listen carefully to what your fellow engineers say and then catch up with your other team members afterwards to ask if they followed everything. If they say yes, then you’re fine, and you can just carry on as you were. But if they say no, consider getting your team to challenge themselves to deliver very simple standup for a a week. Make up ridiculous stories to illustrate migrating ElasticSearch clusters. At the end, ask those same people whether they feel like they know more about what you’ve been up to.

And if all else fails, there’s my old favourite fallback:

Everything’s slightly broken, but I’m working on making it not broken.

Congratulations, you’ve been accepted to speak at a conference!

But once the initial euphoria wears off, you might find the impostor syndrome starting to set in. What if I’m not good enough? Do I know enough about this topic? What if the audience hates me?

That’s me right now. I’m currently preparing my first ever conference talk for ReactFest 2018, which I was encouraged to apply to by the excellent folk at ReactJS Girls London. Having gained quite a few new followers on Twitter after my talk was announced, I thought I’d canvas a bit for helpful hints for a first time speaker. I figured a few people might respond.

People who have spoken at tech conferences: what's one thing you wish you'd known before your first talk?

(RT for reach please?)

— Sophie Koonin (@type__error) January 22, 2018

Just a few.

I got so many fantastic tips and suggestions—including some from experienced speakers like Sarah Drasner, Dan Abramov and Anjuan Simmons — that one user suggested I turn it into a blog post. So here it is. (Thanks to @sayzlim for the suggestion!)

These tips have come from the tech community, but I think the majority of them can apply to any public speaking event.

Preparing your talk: Slides and content

You’ve got the outline of your talk that you submitted to the Call for Papers, but how do you turn it into a full talk? Whether your talk is full-length or a shorter lightning talk, it can be quite stressful when you’re deciding what should go in and what you should leave out.

Find someone with speaking experience to help you put together your talk. The organisers of ReactFest put me in touch with a lovely volunteer who offered to give me some pointers. Find a friend, mentor or colleague with experience of giving conference talks, and ask if they will help you out.

One thing that came up repeatedly on Twitter was the concept of storytelling. Rather than just listing ideas or treating the talk like a tutorial, you want to tell a story . This makes the talk so much more engaging, and more likely to be remembered.

Share a story, not a series of facts. Took me far too long to figure that one out.

— Mark Dalgleish (@markdalgleish) January 23, 2018

It helps if you have one idea to center your talk around. Like in Inception movie, what’s the one thing you want to put in their heads? This helps you decide what to cut (and you might have to cut things when you realize you’re running over the day before the talk).

— Dan Abramov (@dan_abramov) January 23, 2018

When it comes to putting a deck together, most people tend to use Google Slides, Keynote or PowerPoint, but tech folks might also like to try out Reveal.JS, which lets you write fully responsive slides in HTML or Markdown (perfect for code snippets!). I used it for a talk I gave at a meetup, and had the entire talk hosted on GitHub Pages just in case I had to use someone else’s computer (which, in the end, I did!).

Once you’ve got the content nailed, you can focus on the design. Don’t worry about being too fancy — you want your audience to focus on what you are saying rather than what’s on the slides. Too many words on the slides will distract the audience, as will too many animated gifs! You can always create another version of your deck with more details on for sharing afterwards, as suggested by @henrihelvetica.

Take all those points off the slide and move to speaker notes, replace with cat* picture that represents that section.

People will focus on you rather than reading ahead and becoming bored.

*other options are available

— John Wards (@johnwards) January 23, 2018

Keep your slide theme nice and simple, and consider whether the theme you have chosen will be easily readable from the back of the room with a crappy projector. Put your name and Twitter handle (if you have one) at the bottom of every slide because people will forget it if you only put it at the beginning (thanks @claireinez).

If you’re putting code in your slides, don't go overboard. Sometimes it’s inevitable — for example if you’re talking about how a particular tool or library works —but as @alexmcpherson suggests, it’s best to keep them short, 8–10 lines of code maximum. You can always share a repo or a CodePen link with your audience afterwards.

The less code (or other technical jargon) you show, the better. Talk about the important concepts and why they matter, as succinctly as possible, and then put your full code samples online (URL given during the presentation).

— Mark Jaquith (@markjaquith) January 23, 2018

Practice makes perfect

Something that came up over and over again: rehearse your talk! Do it on your own, give it to your cat, make your colleagues listen to it and get their feedback. I got my fiancé to listen to my talk about redux-saga, and even though he didn’t know the content, he gave me some really helpful feedback about how I was delivering the talk. Your manner of delivery is just as important as what you're saying.

Local developer meetups can be a fantastic place to try out your talk before the conference and gather some feedback/see how it lands — a bit like how comedians try out new material in smaller venues before festivals and tours.

Rehearse three times:
- First alone
- Second with supportive audience (partner, friends, colleagues)
- Finally, a smaller local meetup

By the conference you'll know your timings & punchlines by heart and have ironed out any kinks, so you can focus on having fun

— PAPA SMOOSH (@jevakallio) January 22, 2018

Rehearsing your talk will also help you to get a feel for how long it takes to run . Your talk will be strictly timeboxed, so make sure you get your key points across in the time that you have.

If you haven’t practiced you will run over. My first talk at a local meetup was supposed to be 30 minutes, I only got through half of the slides. This is solved by practice: actually rehearse the whole talk (to an empty room, then to an audience).

— Dan Abramov (@dan_abramov) January 22, 2018

Don’t be tempted to script out your entire talk, as it’ll come across as a bit robotic (plus put a whole lot more pressure on you to learn it). Instead, become familiar with the key points of your talk and deliver those in a more improvised, natural way .

Technology isn’t always your friend

Make sure your talk works offline — you never know what’s going to happen. I’ve been to a tech conference before with no wifi or sockets for power. As @naomi_freeman suggests: “Don’t trust the wifi. Download any online content BEFORE travelling.”

test your talk in Airplane mode

— Scott Hanselman (@shanselman) January 24, 2018

Dan Abramov suggests having a backup of the slides online that will run on someone else’s laptop. Google Slides can be run from anywhere if you share the link, or you can host your Reveal.JS talk somewhere like GitHub Pages. Make sure you are comfortable giving your talk without prompts , as you might not be able to access your speaker notes.

If you can, find out beforehand what the setup will be like at the conference. The projector they are using, the size of the room and the equipment available will all affect things like font size, colour scheme and audio.

Whether the projector is DVI/VGA/HDMI etc. Whether it's 4:3 or 16:9. Whether the room is light or dark (should I use light slides or dark ones).

— Paul Bone (@Paul_Bone) January 23, 2018

Bring all of the dongles, bring your own clicker (usb) , plan for no presenter notes, always email yourself a pdf backup version

— Cynthia Savard (@CynthiaSavard) January 23, 2018

Don’t assume the organisers will provide the adaptor you need to connect your laptop! Bring it yourself just to be safe (and label it with your name so nobody steals it).

To demo or not to demo?

This was a bit of a divisive one — should you have a live demo in your talk?

People loooove demos.

— Sunil Pai (@threepointone) January 22, 2018

Demos won’t work

— Khang Hoang (@khanght) January 23, 2018

Mine worked tho

— Dan Abramov (@dan_abramov) January 23, 2018

A demo can be a fantastic way of, well, demonstrating a technical concept. But there’s always a risk that something will go wrong on the night — whether it’s down to nerves, technical issues or just plain bad luck. You can avoid this by making a recording of it beforehand that you can play to the audience and narrate what you’re doing. Or have a working copy that you can check out from Git in case of emergency (thanks to Laura Wilson for that tip).

make 'em work offline and have a backup screen recording of it in action

— Sarah Drasner (@sarah_edo) January 22, 2018

Mac users can use Kap to record screen captures in video or GIF format. There’s also Kazam for Linux and CamStudio for Windows.

In some cases screen captures might even be better than live demos:

Yes, I don't recommend any live coding in your first one. No reason to add one more thing to be nervous about. And I've seen Sarah's recordings, they work great for talks! She can describe what's going on without having to type at the same time.

— Kyle Shevlin @ ReactRally (@kyleshevlin) January 22, 2018

And as @fforres points out, don’t rely on your audience to be sensible — if your demo involves live input from the audience, be warned, people might send in something rude!

On the day

The dress code at tech conferences can be pretty casual, but if you’re wearing a dress, make sure it has pockets as you’ll need to attach a mic battery pack! @knitcodemonkey says: “Wear something with a collar and a waistband for the mic. Wear comfy shoes.”

Bring a water bottle and don’t forget to drink from it to keep your voice happy.

Take off your lanyard or any heavy jewellery before you go on, because microphones will pick up the sound of it rattling around.

Make sure your laptop is ready for the talk: close all other programs, have the slides up and ready, and turn all notifications off. Put your laptop on airplane mode if you can. If you have a smart watch or phone on you, don’t forget to silence that as well.

The lanyard bit is 100%! Add jewelry to that.
Btw, ✈️ mode AND shut off wifi.
Someone who loved my talk was kindly tweeting non stop about it and I kept getting notifications on my watch - I actually thought it was an emergency 🚨.

— Henri Helvetica 👨🏾‍🚀 (@HenriHelvetica) January 23, 2018

And turn the notifications off! Otherwise you risk exposing private messages hopping on the screen during the talk 😛

— Dan Abramov (@dan_abramov) January 23, 2018

As you’re about to go on, you might feel the nerves. The audience is waiting! Take a deep breath and try to radiate confidence , even if it doesn’t come naturally to you. The audience won’t know you’re faking confidence (and soon you won’t be). You know your stuff, you love your topic, you’ve rehearsed it time and time again — you are ready . Enjoy it.

Peak scary is ten seconds before the talk. I didn’t anticipate it to be this scary. But once you get into your element (by talking about things you care about) the fear goes away completely, it even becomes fun. At least it did for me.

— Dan Abramov (@dan_abramov) January 22, 2018

Projecting confidence is as good as having it. Even if you are not 100% happy with your talk, nobody knows what it was supposed to look like, so just rock your stuff and don't apologise for a thing

— PAPA SMOOSH (@jevakallio) January 22, 2018

Be aware you might not be able to see anyone in the audience…

One thing I didn't know and really surprised me is that you probably will not be able to see anything, the lights pointing at the stage will most likely almost blind you 🙁
And you are going to rock!

— Sara Vieira (@NikkitaFTW) January 23, 2018

Move around a bit , rather than standing still behind the podium. It can be tempting to just keep talking — don’t forget to pause now and again.

Breathe.

(seriously)

— Sarah Drasner (@sarah_edo) January 22, 2018

Plan out when you're going to pause during your talk. "Letting it land" is really important for the audience. It also keeps you from rambling at light speed (a habit I still have to unlearn for each and every talk)

— FIREBAE (@_davideast) January 23, 2018

Whenever you get nervous just take a pause. Breathe. Drink some water. It’s empowering to realize you can even make an awkward pause and everyone will just sit silently because you control the room 😎

— Dan Abramov (@dan_abramov) January 23, 2018

Be mindful how you address the audience — don’t just fall back on “guys” considering your audience is likely to be a mix of genders (thanks @fforres). Jokes are a fantastic way of lightening the mood and keeping the audience engaged, but avoid any risqué/potentially inappropriate jokes.

Risque' jokes are a *really* bad idea in a public presentation.

— Kuberkus 1.49.8 (@fuzzychef) January 23, 2018

Don’t be put off if you make a mistake! If you leave something out or stumble over something, nobody will know. Keep going!

You'll notice your own "mistakes" 100 times more than anyone else. But no one else knows what you were planning to say. So if you take a breath and keep going, probably no one else will know there was even a blip. Also, bring extra clothes. I spilled coffee😂

— Amanda Stockwell (@MandaLaceyS) January 23, 2018

Prep! Whatever the content, prep till you can wake up in the middle of the night and do the talk from memory

— Santosh Hari 🤔 (@_s_hari) January 23, 2018

And don’t forget the most important thing:

Everyone's rooting for you

— Justin Fagnani (@justinfagnani) January 22, 2018

The audience is on your side. They want you to succeed.

— Damian Brady 🥑 | 🏠 (@damovisa) January 23, 2018

If you enjoy yourself (and your topic) then other people will enjoy the talk. Enthusiasm is viral. People remember good talks. People forget bad talks. People really remember and hate on *nasty* (sexist, racist etc) talks; never be worse than yourself just to be memorable.

— Jon Skeet (@jonskeet) January 22, 2018

You’re at the conference because you love your topic, and so does everyone else there. You’re all on the same team. As @tlakomy assures me: “It’s going to be okay”.

Taking questions?

Sarah Drasner recommends not taking questions during your first talk:

Best answer I ever gave to a “why would you do it this way” was “why not? Seemed like a good place to start. Next question?” I don’t know why it took me so long to learn it

— Fernanda Foertter 🇧🇷🇺🇸 (@hpcprogrammer) January 23, 2018

That said, it’s a personal choice — if you feel comfortable (and time allows it) you can take as many questions as you want. An excellent tip from @bradwaynemartin: always repeat the questions back to the audience , as the microphone won’t pick them up.

But if anyone does challenge any decisions you made, you can fire this straight back:

oh! a better one: don't take questions your first time. I don't recommend it because you get done with the tada! and then it just kind of tapers off from there. plus the best questions aren't performative, they're the ones that happen off the stage face to face

— Sarah Drasner (@sarah_edo) January 22, 2018

Good luck!

To all first-time or aspiring speakers: you’ve got this!.

If you’re looking to get into the world of conference speaking, a great place to start is local developer meetups (if you can’t find one, start one!). You might even start by giving talks at work to your colleagues. The more you do it, and the more feedback you gather, the more comfortable you’ll become.

I also recommend taking a look at Jo Francetti’s guide to Public Speaking For Beginners and Emily Webber’s list of things that speakers need from conference organisers.

Thank you to everyone who contributed to the enormous Twitter thread that led to the creation of this post. If I have forgotten to credit anyone, or you would prefer not to be included, please get in touch.