How to run a calm live demo or video interview without losing your place

Lee — Sat, 07 Nov 2026 01:22:55 +0000

Most developers now give a live demo, a sprint review or a technical interview over a video call every week. The code is usually fine. What goes wrong is the talking: losing your place, reading notes off to the side, or freezing when something breaks on screen.

These are the habits that helped me most.

1. Write talking points, not a script

A full script makes you sound like you are reading. Write one line per point instead:

what this part shows
the one thing to click
the result people should notice

Three to five words per line is enough to remind you without pulling your eyes down for long.

2. Keep your notes near the camera

Where your notes sit matters more than what they say. If they are in a window at the side of the screen, people see your eyes move away every few seconds.

Put them as close to the camera as you can:

Laptop: a narrow window at the top centre of the screen, just under the webcam.
External camera: move the camera to the screen you read from, not the other way round.
Shared screen: check that the notes window is not part of what you share. Share one app window rather than the whole screen, or use a tool that keeps notes out of the share. I use Glance, a free Mac teleprompter that sits under the camera and does not show in screen shares or recordings.

3. Prepare the demo state, not just the demo

Most broken demos break in the setup.

Log in to every account before the call.
Open each tab in the order you will use it.
Use seed data that looks real but contains nothing private.
Turn off notifications, and close chat apps and email.
Raise your font size: 16px code is hard to read in a compressed video stream.

4. Plan what to do when it breaks

Something will fail at some point. Decide in advance:

A short line to say: "That's a network issue. Let me show you the result I recorded earlier."
A fallback: a screenshot or a 30-second recording of each key step, in a folder you can open in one click.
A time limit: if a fix takes more than a minute, move on and follow up in writing.

People remember how you handled the problem more than the problem itself.

5. For technical interviews, practise out loud

Reading your answer in your head is not practice. Record yourself answering the common questions:

"Tell me about a project you're proud of."
"Describe a bug that took you a long time to find."
"How would you design this?"

Play the recording back once. Most people find they talk too fast, skip the result, or never say what they did themselves. A simple structure such as situation, task, action, result keeps answers short.

6. End with one clear next step

Close a demo with what you need: a review, a decision, or a date. Close an interview by asking what the next stage is and when you will hear back. Then write it down while the call is fresh.

None of this needs special software. Good notes in the right place, a prepared demo and a plan for failure cover most of what makes a call feel calm.

The Markdown File Changed Even Though I Only Edited One Word

Lee — Wed, 23 Sep 2026 10:03:16 +0000

I once opened a Markdown file, changed one word and saved it.

The preview looked exactly as expected. Then I checked the Git diff and found changes all over the document.

Paragraphs had been rewrapped. Blank lines had appeared between list items. A few characters had been escaped. My one-word edit was still there, but it was buried inside a much larger rewrite.

The editor had not simply changed the text I touched. It had parsed the whole document, converted it into an internal format, then generated new Markdown when I saved.

That process is called a round trip, and it can be surprisingly lossy.

The preview does not tell the whole story

These two Markdown paragraphs usually render the same way:

This paragraph is wrapped manually
at a comfortable source width.

This paragraph is written on one long line.

After parsing them, an editor may only know that each one is a paragraph. It may not remember how the original source was wrapped.

When the file is saved again, the editor has to decide what Markdown to produce. It might join the lines, rewrap them at a different width or preserve every newline as a visible break.

This gets more important when a line ends with two spaces or a backslash. Those can create an intentional hard break. Trimming what looks like unnecessary whitespace may change how the document renders. I ended up documenting the difference between soft and hard Markdown line breaks because it is an easy detail to miss.

Lists have the same problem

This is a tight list:

- Alpha
- Beta
- Gamma

This is a loose list:

- Alpha

- Beta

- Gamma

They may look almost identical under some themes, but their Markdown structure is different. If an editor always saves lists in its preferred style, a tiny edit can produce a very noisy diff.

The same thing happens with indentation in nested lists, aligned table columns and reference-style links. The document may still render correctly, but the source is no longer the source you opened.

App-specific Markdown makes it harder

Real Markdown files often contain syntax that is not part of standard Markdown:

[[Project Roadmap]]
#release
> [!NOTE]
> This ships on Friday.

One app may understand those as a wiki-link, a tag and a callout. Another editor may see ordinary punctuation and escape it when saving.

That is why “supports Markdown” can mean very different things. CommonMark, GitHub Flavored Markdown, Pandoc and apps such as Obsidian do not all understand the same syntax.

If an editor does not recognise something, leaving it untouched is often safer than trying to correct it.

A simple test

There is an easy way to check an editor before trusting it with important files:

Copy a representative .md file.
Open it and change one ordinary word.
Save and close it.
Compare the saved file with the original.

The diff should show the word you changed and nothing unrelated.

Try the same test without editing anything. Just open and save the file. Ideally, it should remain identical.

Use a real document containing the things you normally write, such as nested lists, tables, code blocks, maths, images, front matter or wiki-links. A perfect five-line README will not expose much.

Opinionated formatting is not always bad. A team may deliberately choose one Markdown style and format every file consistently. The important thing is that the behaviour is clear and expected.

But if the editor promises to work with existing Markdown files, the source matters as much as the preview.

Change one word, save the file, and check what else changed.

DEV Community: Lee