Live coding during a presentation

I’ve done a few talks in my time, and some of them have involved live coding to help take the audience on a journey to understand the lesson I want to teach. It’s a technique I use rarely however as it can easily get problematic.

Live coding for a presentation is not the same thing as coding for your job or a mob session. Live coding for a presentation has to be as slick and as polished as the rest of the talk. No googling the API docs, no stumbling over syntax errors (although don’t worry if you don’t spot them, someone will.)

If you’re nervous with slides, live coding can help relieve some of the pressure. It certainly helped me when I was starting out, as I could pretend I was having a conversation with my computer for some of the talk. Fortunately, it was a conference with microphones.

Live coding is also great for presenting something novel (or at least novel for most of the audience) as it gets to demonstrate that it’s real and it works. I used it, in one presentation, to demonstrate TDD.

Be careful though. Technology can let you down, so have a think about how you might demonstrate another way. Do you have a video you can show on someone else’s laptop? Can you demonstrate with screenshots? Could you whiteboard a solution?

If you don’t feel comfortable writing code in front of an audience, don’t. Can the code (I use VS code snippets, but there’s plenty of macro choices), so you can reveal it gradually. Or pre-build it and uncomment as you go.

If you are preparing code in advance, to distribute with the slides, heavily comment the code so that when people download it afterwards they understand the context.

I do love to see live coding done well in a presentation, but unless you’ve prepared it meticulously, it won’t go well. Think about the story, and how and when you’re introducing new concepts. Don’t be afraid to go back to something later (“Here’s how to connect, but I want to show you search first. I’ll come back to the parameters here once you’ve seen the search results.”) It’s OK to refer to your notes, especially if you’ve just thrown up a screenful of code for the audience to read. Make every interaction useful.

It’s OK to backtrack. Show the mistakes you made, the error messages you saw, and how you corrected them. You won’t be the last person to make that mistake.

Relax and enjoy it. If code is what you do, be comfortable with it, even if the nerves are trying to turn you inside out from your stomach.

Advertisement

Inclusion is not a zero sum game

Look around your office. How many people look like you? How does that compare to the people you saw on your commute, or in the supermarket? How does that compare to your users? Do you even know?

Are you making space?

How many people are struggling with mental illness? How many have accessibility challenges? How many are white, straight, cis-gender, able bodied men?

Is there a mismatch? And if so, what are you doing to change it? Are your job adverts inclusive and on inclusive sites? (hint: look at the StackOverflow developer survey before posting your job there) Do you have a network outside work that you can tap into to find new candidates?

Are you creating a safe space for everyone? Are company events open to new parents, to non-drinkers, to vegans, to women? Do people have to out themselves to attend a family day, or to avoid travel to a certain customer site? Do you support staff who need to transition? Staff who need quiet spaces? Staff who are fasting, or need non-Christian holidays?

Can your staff find somewhere to learn to sign? Or to write simplified for language learners, for those who have struggled to attain or retain language?

Which three of these questions are the most important to achieve for you this year? And how will you do it?

If you need somewhere to start, have a look at Inclusive 101 from the Microsoft Inclusive Design Toolkit, and ask yourself if that’s you, or pick an episode from the Cause a Scene podcast and listen, especially if it makes you uncomfortable.

Things I don’t know as of 2018

At the end of last year, Dan Abramov talked about the things he doesn’t know. It’s a useful framework to reflect, and as a privileged, experienced developer, I am comfortable talking about this, in the hope it might help others understand that experienced developers don’t know everything.

I’ll echo what he says about Imposter Syndrome and Dunning-Kruger and how it absolutely sucks to see truly smart developers I know, or that I follow, having to constantly prove their credentials just because they’re not cis, straight, able-bodied white men. If I’m in a position to support you or amplify you, I will try to do so. Your experience is definitely a thing I don’t know, but I can listen.

I covered a few things I know enough to be confident in for my 2018 in Review post. I’ve had to care about DevOps and containers and pipelines because they solved real problems my team was having. I love graphics because trigonometry and fractals are why I got into programming, but I work in the network, looking at architecture, security, interfaces and data. That leaves a big wide world out there, and this doesn’t include the unknown unknowns.

Ruby

I’ve tried to get into it a few times, but it still just looks like old-school Perl to me. Lots of punctuation occasionally interrupted by domain language. This actually sounds like a good idea to me – an almost complete separation of concerns – but I keep finding the learning curve too steep and so I retreat back to Python and C#.

CSS

I’ve been building websites since Mosaic was a browser. I can style things with CSS. It’s not hard to put red text on a green background (you monster), or fix a navigation bar to the top of the screen, but look at the fancy grid layouts, or parallax scrolling effects, or CSS icons, and I couldn’t tell you where to start. I don’t know how to unit test it, so my tools don’t work here. Just as well I work with some very smart CSS developers.

Markdown

I use Markdown a lot. For README, for Architecture Decisions, and for drafting blog posts, but I always need to google how to insert a link, or a table, or an image. And I feel like an idiot each time.

gulp, npm and webpack

I know these are essential tools when I’m building React. I know they turn my code into something the the browser runs. I know how dependency management works (I can bore you about HORN over a drink if you like), but I’ve only ever used these JavaScript tools preconfigured in a template or an existing codebase, so I could not create a JS or TypeScript build pipeline from scratch, or fix a broken one.

I really couldn’t tell you anything intelligent about how those fit into the ecosystem alongside Grunt, Yarn, bower, sass, scss or anything else. So long as I can write a script to install and run them, I’m happy not to have to dig into them. All I care about is if it runs and if the dependencies are secure.

I suspect I’ll need to learn more about these tools this year though.

You don’t need to know everything

You’ll have your resolutions to learn more, whether weekly or yearly. There’s more to learn than you will ever get the time to – that’s why we work in terms. Pick one thing to learn next because it’s important to you, because it’s interesting, because your project requires it, or because thats where the money is. Forget the rest until you’re over the Dunning-Kruger curve and you know enough about that new thing to see all the possible next things to learn.

2018 in review

It’s been a big, small year for me. Big personally with a new job, but smaller publicly, although I’m now in a position to make more time for conferences following DDD Scotland and CodeCraftConf this year.

I’m still adjusting to agency life, but that might be because it’s been a big, amazing year for Screenmedia.

Looking at my stats, it’s good to see web dev and security are high in my logs, as that’s where this blog started, although there’s a bit more tech leadership content these days as well.

I’ve also got an account over at dev.to, which is a community of developer bloggers, and a couple of posts got some interest over there, so I’ll keep cross-posting to there, please say hi 🙂

I passed my CosmosDb exam last year, so expect to hear a bit more about that. I also have some thoughts on technical architecture and team building I want to explore further. If there’s anything else you’d like to hear about, please let me know.

I’m looking at a technical leads meetup/support group in Glasgow. More details to follow, but ping me if you want to make sure you don’t miss the details.

I’m looking forward to the new year. Thanks to all of you for reading.

Here are my highlights from 2018.

Top older posts

• https://craignicol.wordpress.com/2016/07/19/excellent-export-and-the-chrome-url-limit/
• https://craignicol.wordpress.com/2015/05/05/losing-tokens-2-factor-authentication-recovery/

Top 3 written this year (WordPress Stats):

• https://craignicol.wordpress.com/2018/01/26/new-job-welcome-to-screenmedia/
• https://craignicol.wordpress.com/2018/08/03/translations-with-react-redux-and-asp-net/
• https://craignicol.wordpress.com/2018/04/03/who-do-you-work-with/ (and the canary in the coalmine)

Top on dev.to:

• https://craignicol.wordpress.com/2018/12/19/how-i-approach-coding-challenges/
• https://craignicol.wordpress.com/2018/12/07/tribe-of-mentors-11-questions/
• https://craignicol.wordpress.com/2018/04/03/who-do-you-work-with/ (and the canary in the coalmine)