Ask HN: What are the things keep in mind while giving/preparing for a tech talk? - <AUTHOR> <comment><USER3> Know you're talking about. That alone will make the talk more natural, as you'll be able to adapt to your audience due to having knowledge outside of just your research.

This was the biggest change between the presentations I had to give in high school and the ones in college and above. In high school, the topic was usually given to us, whereas in college and later, I got to choose the topic I was most knowledgeable about. The latter meant I was more passionate, more able to answer audience questions and more able to tailor the delivery to the audience.

One piece of advice I heard was that if you absolutely have to talk about a topic you're not familiar with, talk about being a beginner in that topic. Talk about your perspective as an outsider learning that topic in the first place.

<comment><USER4> To expand on that with "obvious" advice: Know your audience. Present accordingly.

Are you an expert or a beginner _relative to your audience_? If I'm explaining something technical, I might take a more assertive tone when glossing over details with a novice but speak with more deference to an expert. (e.g. Throw in a few "I think ..." or "My understanding was that ...")

Getting a quick grasp of where the speaker is coming from helps the listener really engage at the right level. Should I double check what the speaker is saying or are they the authority on the matter? Nothing get's eyes rolling faster than someone making blatantly wrong factual errors overconfidently.

<comment><USER5> This x10. Being aware of "who" / "what" is in the room - and then (the tricky part) self-aware of how they may see you.

Use this ance-data to shape your tone and phrasing.

</comment></comment></comment><comment><USER6> A little bit of stage fright is generally healthy. It shows that you care enough to be concerned and you're not getting too cocky. That's an old lesson I learned doing (of all things) middle school acting class and it's proven itself to be true over and over again.

Think about your slide and presentation style. For example, I have enormous decks for most of my talks (think like 55 slides for 30 minutes) but I burn through them very quickly, usually less than 20 seconds per slide. I came from film editing before moving to software so I approach my Powerpoints like a movie, it's just my nature. Others have really short decks that are information dense so the emphasis is on the talking part of the talk and the slides just provide a reference in the background. Others forego slides in favor of straight-up demos, which is certainly slick if you can pull it off (high risk, high reward) and need little pictorial illustration.

Use the old 5 paragraph essay rules from high school as a starting point for structuring your talk: tell you're audience what you're about to tell them (thesis, topic, core argument) and how you're going to tell them (outline), then tell them (supporting paragraphs), then tell them at the end again what you told them and how you told them (conclusion, restating your intro).

Humor helps, generally. This isn't supposed to be a standup set so definitely don't go overboard, but it can really help. Particularly if you can tie it in with some empathy for your audience. ("We're gonna do this in Perl. I love writing Perl, you just hold shift and smash the number row for awhile.")

And for heaven's sake don't read your slides.

<comment><USER7> When the slides contain a lot of text, it is not possible for me to simultaneously read and comprehend the slide and understand what the speaker is saying. The slide appears, I start reading. You start talking, so I have to decide where my attention goes. Often it is neither the slides nor the speaker, just a jumble of words coming at me. Then the next slide comes up...

<comment><USER8> I feel like the solution to this is to have slides without a lot of text on them, but then include what you say in the "speaker notes" section when you distribute them so that people who didn't attend the talk understand them.

</comment></comment></comment><comment><USER9> Always do at least 1 full rehearsal with a timer, preferably two full rehearsals where the first one you do keep a timer but also have a notebook (physical) present to quickly write down adjustments you want to make.

Do a live demo, people love live demo's, but be prepared for when disaster strikes (it will), if possible run your live demo on a physical device with you during the presentation.

Most places allow you to have 2 devices connected, or quickly switch the HDMI cable to the demo machine.

Do not use a linux machine, I know this sounds harsh, but with all the types of beamers/screens out there, a windows or mac machine will just have a much higher success rate. (I learnt this the hard way, in the end I could choose between mirrored 640*480 or full hd on the beamer only, which makes live demos much harder).

Create short slides, the slides are there to guide you and the audience. Try to prevent reading the slides out loud.

Use images and videos, they can tell more then a thousand words.

I often use the STAR approach to tell my story, this helps structure your talk. You don't need to follow star exactly, but if trying to explain something, it often helps to first give a bit of background why you did what you did.

Make sure you let the audience know if and when you will be answering questions, some talks really benefit from interactivity, but if you are short on time, let people know they can ask their questions later (perhaps add a slide at the end with sources and your contact information).

Also, relax, the audience has already decided they want to listen to your presentation.

<comment><USER10> > Do a live demo, people love live demo's

It really depends on the topic of the talk. If it's something that can be demonstrated in a quick and straightforward way, do a demo by all means. But I've seen talks where people were forcing a demo into a talk about complicated concepts. There's little value in seeing someone type in a page of code, compile and run. Or seeing something run without understanding what is happening on screen. I would much rather have the speaker spend those minutes discussing the topic.

> Do not use a linux machine

Better advice: make sure you know how to setup an external screen on your laptop and how your presentation software works with it. Try it before hand with an old VGA monitor.

> Create short slides, the slides are there to guide you and the audience. Try > to prevent reading the slides out loud.

I would argue that the slides are there for the audience. Ideally, you need to be able to present your talk without seeing your slides. They are not cue cards for the speaker.

Very short slides light on content (e.g. memes, one word or sentence per slide) make for a terrible tech talk in my opinion. Do make your slides informative. They should complement what you are talking about. Show a relevant graph, code snippet, etc. related to what you are talking about. If you can't do that, fall back to a summary of your spoken content in a 3-4 bullet points per slide.

<comment><USER11> Edit: added headings!

STYLE

> [slides] are not cue cards for the speaker

Personally I disagree with this point and have developed a presentation style I'm happy with based on the slides being my cue cards (average 5-10 presentations / year for the last 15 years).

I do NOT read the talk from my slides and can't stand it when speakers do that! But, each slide should jog my memory of everything I need to say at that point. Maybe I'm talking about some stats as background, fine, the slide should be a bar chart of those stats, or a map, or an illustrative photo. Rarely a list of bullet points, though I don't prohibit them altogether and will tend to conclude with a list of bullets to leave in the background as a summary while I take questions. Overall the slides should complement the talk, not be a duplicate. But they serve a second function of reminding me of all the things I need to say.

As a programmer you will appreciate the reason for this: I have cut the number of entities I have to process in my head from three (slides, audience, notes) to two (slides, audience). Keeping track of and having rapport with the audience is essential to me, even if that just means looking at people to see how engaged they are. With notes/memory in the equation I used to get a lot more nervous and not pay enough attention to the audience. Cutting out the notes allows me to focus on communicating better. It's a shared context, the audience can see exactly[1] what I can see.

If you're in sales then I see another tactic used instead, which is to memorize the talk so thoroughly that you don't need notes or presenter view. Fair enough. I'm an academic researcher; while they say all our presentations are a sales pitch on some level or other they clearly aren't expected to be as slick as "sales" sales. My constraints are having limited time to prepare, and wanting to stay natural. I do rehearse but I don't over-rehearse as I find that kills my own interest in the talk as well as taking more time. Usually the minimum for me is two full run throughs, probably stopping the clock multiple times during each to apply edits as I see fit (hopefully only a few edits second time).

HANDLING CONTEXT SWITCHES

The one exception to [1] is context switches. As others have said, finding the perfect words for the _introduction_ to each new topic really helps get the flow going. These can be remembered, written on notes, written on slides, written on slide notes visible in presenter view, whatever.

I'm a big fan of presenter view, not for notes, but purely for the ability to see the next slide and introduce it slightly before the change. It helps to _leave_ each slide knowing what direction you're going in so you're not surprised by the next one. I do worry slightly that I'm dependent on presenter view and turn up early at each venue to make sure I can get it working (not all of them can).

NERVES

Someone said don't drink too much alcohol. Based on my experience as a performing musician this is true :) Same goes for caffeine for the opposite reason, it really heightens the nerves. On the subject of nerves, just accept that some talks seem to go better than others. If you find yourself having a failure of confidence, take a deep breath and keep going. Easier said than done I know, but it always feels worse on the inside than it really looks; I have had people come up to me after talks where I thought I did awfully and tell me how engaging they found it.

AUDIENCE ENGAGEMENT

If you can find a way to further engage the audience without forcing it - <USER2> questions, polls etc - go for it. Quiz questions can help set context for a new topic. Despite my love of the material I've never really been a lover of talks and can get pretty bored in the audience, so I really appreciate this sort of thing.

Example: on a few of my talks lately I've showed a picture of some protestors up trees by a road, asking who can name the incident. (Protests vs Newbury bypass construction). Followed by more protestors and an airstrip (former US nuclear base Greenham Common). Most of my UK audiences will get these right. Finally I asked what links these two things. They may or may not get the latter: the success of commercial development on Greenham Common, when it ceased to operate as an airbase, was blamed for the failure of transport models to correctly predict the effect of Newbury bypass. Doesn't matter whether anyone guessed the final answer, which is obviously a bit specialist. The point is I've now got people thinking about the many interconnected elements of simulating transport which is a great intro to the topic.

<comment><USER10> > If you're in sales then I see another tactic used instead, which is to > memorize the talk

Majority of my talks in the last years have been in academic settings, but I'm definitely on the side of "over-rehearsing" on your scale. I've never done a sales talk in my life.

I guess it depends on how well you can improvise on stage. I never managed to master that. For myself, I can only "stay natural" and not be nervous when I'm well prepared.

> quiz questions, polls

I personally don't like this when listening and rarely do it as a speaker. It can be a double-edged sword. I've often seen speakers fall into the trap of asking "how many of you are familiar with X", and then proceed to spend next 10 minutes explaining X even though it's obvious that the audience already knows X very well. If you're asking questions, you should be prepared to act on the answers.

<comment><USER11> Fair enough, there is diversity of preferences in both speakers and listeners :)

I agree on familiarity polls that you should adapt content based on audience familiarity with the topic.

Whether or not audience engagement is appropriate also depends a bit on the length of the talk. It can be great for a context switch in a 45 minute talk, like a mental reset button for the audience. If you only have 5 minutes it will detract from things unless you want it to be the main focus.

</comment></comment></comment></comment></comment><comment><USER12> People decide in the first 10 seconds whether they're going to listen to you or use your session to catch up on email. So make your intro good. Catch their attention. Surprise and intrigue them. Memorize and practise your intro over and over again so when you walk on stage you can get comfortable without having to worry about the specific words you're saying. Memorize your conclusion too so you can bring it home with a strong call to action (bonus points if you tie it back to your intro!). People remember the first and last things you say the most, so make those words count.

<comment><USER13> Somewhat off topic: I always wondered why people would bother showing up for a talk or conference if they're going to be on their phone or laptop during the entire thing.

Last time I went to a conference I was actually a little surprised by the number of people at the talks who where clearly working during the entire thing. Why bother, you most likely pay for the plane ticket, the hotel and the conference it self, and then not pay attention? If you're only interested in one talk, then just go to that one and then leave.

Given that people mostly show up to technical talks of their own free will, I don't think you need to trick them into paying attention. It's fair to assume that they are generally interested and focused on what you have to say.

<comment><USER14> Some people get paid to go to the conference and also for some its in their best interest to half pay attention while doing work.

On another level, sometimes I go to meetups in my area which are technically the same conference presentation as well. There are times when I regret going to the meetup (There's 10-20 people) because of how boring the speaker is or how overly technical it becomes, but I don't want to be rude and leave the area cause it'd reflect poorly. Its not like a convention where leaving is okay, everyone in the area knows each other.

</comment></comment></comment><comment><USER15> Lots of good advice here. I'd add:

\- Ask yourself what is your _real_ goal of the talk. Are you trying to teach people something? Or are you making a live-action advertisement for a product/service (or for yourself)? Optimize your talk ruthlessly for that goal.

\- If you're doing a talk in front of a small audience (say, 30 or less people), and you're going to discuss details of code or charts presented on slides, then put all those code snippets and charts you want to discuss in a single document and give everyone a printout. A printed document has much higher resolution and quality than a slide (especially for the people sitting in the back), and will allow them to look back (or forward) at an important figure if you're currently showing another slide. Paper is cheap and quite ecological, so don't worry about that.

</comment><comment><USER16> From Richard Hamming:

 _When I first started, I got practically physically ill while giving a speech, and I was very, very nervous. I realized I either had to learn to give speeches smoothly or I would essentially partially cripple my whole career. The first time IBM asked me to give a speech in New York one evening, I decided I was going to give a really good speech, a speech that was wanted, not a technical one but a broad one, and at the end if they liked it, I 'd quietly say, ``Any time you want one I'll come in and give you one.'' As a result, I got a great deal of practice giving speeches to a limited audience and I got over being afraid. Furthermore, I could also then study what methods were effective and what were ineffective.

While going to meetings I had already been studying why some papers are remembered and most are not. The technical person wants to give a highly limited technical talk. Most of the time the audience wants a broad general talk and wants much more survey and background than the speaker is willing to give. As a result, many talks are ineffective. The speaker names a topic and suddenly plunges into the details he's solved. Few people in the audience may follow. You should paint a general picture to say why it's important, and then slowly give a sketch of what was done. Then a larger number of people will say, ``Yes, Joe has done that,'' or ``Mary has done that; I really see where it is; yes, Mary really gave a good talk; I understand what Mary has done.'' The tendency is to give a highly restricted, safe talk; this is usually ineffective. Furthermore, many talks are filled with far too much information. So I say this idea of selling is obvious. _

[http://www.cs.virginia.edu/~robins/YouAndYourResearch.html](http://www.cs.virginia.edu/~robins/YouAndYourResearch.html)

</comment><comment><USER17> I have given many, many talks -- from dense technical presentations to generalized keynote addresses -- and have been doing it for over twenty years. Here, in my opinion, is the deal:

1\. Don't start your talk by apologizing. "Well, first I need to apologize. I'm insanely jet lagged, and so I'm not sure how coherent this is going to be." "First, I'd like to apologize. This is actually a revised version of a talk I gave in 2009." "Let me start with an apology. I have a terrible head cold."

Just stop. If the talk is incoherent, you'll just have to do your best on the spot. If you're tired, too bad. If you think people might have trouble hearing you, say so. But don't _apologize_. People do this because they're nervous, not because the audience has been insulted or aggrieved in some way, and while it might seem like a friendly gesture, it's more likely to communicate that you're unprepared. Or nervous. And it's a cliche.

2\. Do not ever go over time. In fact, go under time. As Edward Tufte once said, "No one ever left a presentation wishing it had gone on for another 45 minutes" (or something like that; you get the point).

3\. Do not read your goddamn slides to the audience. Please. That is not "giving a talk." You can maybe do that if it's a long quote, but don't read the bullet points that everyone can clearly see right in front of them. Expand on them, provide counterpoints to them, whatever, but do not read them. If you're thinking of your slides (when you're creating them) as "what I'm going _say_ ," you're probably doing it wrong.

4\. Use a laser pointer sparingly or not at all. Use it only to make a precise gesture necessary to point something out very specifically on a chart or map, and then shut the thing off. Making dizzying circles around every bullet point is incredibly annoying.

5\. "Never mind the mic. Can everyone here me? I'm just going to speak loud." Unless you're very experienced with this (professional teacher, actor, or something like that), you probably don't know how to project your voice for twenty minutes. Get the mic fixed and use it. If the mic can't be fixed, speak way louder than you think you have to (without shouting). This is a learned skill, and most people don't know how to do it (but think they do). If the venue is large enough to require amplification, it's there for a reason.

6\. Speak at a moderate pace. People speak fast when they're nervous. The proper pace will feel a bit slow to you, but perfectly natural to the audience. Check yourself periodically. Write it down on your notes. Slow down.

7\. If some parts of the information you're trying to communicate are very dense or there's some useful data that will help to contextualize your presentation, create a handout. Do not try to cram it all into a slide.

8\. Take some time to try to imagine every conceivable question you might get in the Q&A. You won't hit them all, and things do come out of left field, but you don't want to be caught totally off guard. Just review any common misconceptions or objections to what you're saying, and give some thought to how you're going to respond. Some people just want to comment. Thank them, briefly offer a comment if appropriate, and move on.

9\. If you feel the need to ask a question like, "Does everyone know what a frubazzle is?" don't. If the question is warranted, then you can be absolutely sure that someone in the audience doesn't know what that is. Just say, "Some of you may not be familiar with the term, 'frubazzle.' A frubazzle is a . . ."

10\. Commit to getting better and better at it. When I gave my first talk (in grad school), I thought, "It's going to be really embarrassing when I faint dead away in front of all these people," and I made a lot of mistakes. Today, I have only the slightest pang of nerves when I step up, and it goes away immediately. When you hear a good talk, try to figure what made it good. How did the speaker behave? How were the slides set up? Did they do anything that you can incorporate into your own presentation "style?" Public speaking is an ancient art, and you need to treat it as you would the art of writing or the art of coding: with care and study.

</comment><comment><USER18> You don't have to help people get from A-Z. Quite often they don't even know where to start so going from A-D is enough. Know your audience in advance though.

Remember to pause and speak slower. It gives the impression you are really considering what you are about to say next and allows you a break.

Don't drink alcohol before the talk (unless you need a shot to calm your nerves) and do have a bottle of water available as your mouth will most likely become dry.

Lastly relax. The audience is unlikely to call you out unless you make a total hash of it and they usually want you to succeed.

<comment><USER19> > Lastly relax. The audience [...] usually want you to succeed.

Great insight, and I've found that to be true. Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides.

</comment></comment><comment><USER20> Remember you're telling a story. Think hard, before you start with slides, what that story actually is. Continuity and flow really matter.

Usually the first part of the story of a tech talk explains what the problem is. Many tech talks fail because the audience either doesn't understand the problem, or doesn't believe your problem needs solving. Think carefully who your audience are, and ensure you explain the problem in enough detail that you connect with your audience.

The middle part of a tech talk then is usually spent on explaining your solution to the problem. If you've explained the problem well, that the outline of the solution will basically work should be reasonably self-evident. Many tech talks fail here, because they dive too deep into the details too fast. Again, know your audience, so you know how deep to dive. You can never fit all the details you have in your head into a talk, so think carefully about what the most important features of your solution are, and focus on those. Keep less important details for backup slides you can turn to if asked.

The third part is usually evidence that your solution works. Often this involves graphs. Again, focus on only the most important results - more than about three graphs and your audience will switch off. Explain the experiment, and explain what the axes represent. Way too many people don't spend enough time on this, so no matter how good the data, no-one understood.

Finally, your conclusions. What did you learn? How complete is it? What are its limitations? You're not entirely doing a sales job, and your audience are wise enough to know that your system will have limitations. You should be the one to explain them, rather than have them come out in questions (when they'll start to doubt eveything else you told them). Finally, what future directions do you think should be taken?

Of course, different talks have different shapes. Find what works for you. Sometimes you need to iterate between problem - solution - new problem - revised solution, etc.

When you present, know your first few sentences by heart, because you'll be nervous. After that, it matters less, you'll have settled into the talk, and you'll appear less stilted if you're not reciting a script. Most importantly, turn your excitement dial to 11. If the audience feel you're not excited by the work, why would they be?

</comment><comment><USER21> If you're projecting from your own laptop, shut down any apps that might give bouncing notifications. Really, just shut down all apps. And don't have your browser open with bookmarks tab and window tabs showing.

Don't spent 10 minutes on the introduction. A _very_ common mistake is people step too slowly through the setup material. Just lay out the problem and GO. In fact, even throughout the talk, assume the audience is smart and can fill in the obvious blanks.

<comment><USER22> I took to the habit of logging in with a "Presentation" user, so no weird things would pop up.

</comment></comment><comment><USER23> Best advice I had about giving talks (from a non-techie) was 'tell a story'. People like stories more than information. If they want information they can mine you for it afterwards.

<comment><USER24> Don't just tell a story. Use the tools of story telling. Have a three act structure (Setup, confrontation, resolution). Have a plot. Use foreshadowing. Use one of the common generic stories as a framework (Hero's journey, coming of age, etc). Make it personal - bring in either parts of the audiences life, or of yours. And close with a positive message

You know when you were a kid, and you had that one funny relative who'd always tell great stories? Be that relative.

<comment><USER10> Is it strictly a tech talk? As someone else said here, skip the cruft and get to the point. I came to your talk to learn about the technology, not your life story.

Some people are good at wrapping tech talks into interesting stories. But they are very rare in my experience. If you don't have a story to tell, don't force it. Don't try to present everything as this grand idea that's related to everything you've done since childhood. It gets old really fast.

I've seen students take a course in speaking where they hammer into them this "three act structure". Invariably, the talks they give would be much better if they would just stick to the technology.

</comment></comment></comment><comment><USER25> Try framing your material in the assertion-evidence [0] style. Not only does this lead to more informative presentations, I find it helps me organize my story better.

Briefly, rather than using topic titles ("Experimental Setup", "Results"), use assertions ("Sampling occurred over 5 days", "Sunlight causes significant degradation") as titles. Then the bulk of the slide is some information, preferably graphical, that supports the assertion. Reading the titles in order should give you a strong sense of the presentation content.

I strongly recommend "The Craft of Scientific Presentations" by Michael Alley, which covers the assertion-evidence approach, and a host of other practical topics.

[0] [https://www.assertion-evidence.com](https://www.assertion-evidence.com)

<comment><USER20> I'm also a fan of the assertion-evidence style, though I've found over the years that it works better for some talks than others. Animating in an explanation over a series of slides, for example, sometimes doesn't fit that style very well.

Even if you don't go all the way to using the assertion-evidence style, titles are a great place to summarize the main point of the slide. So rather than "Results (3)", use the space for something more descriptive like "Velocity vs time during reentry".

</comment></comment><comment><USER26> If you're being recorded for it to go on youtube, and you're doing a Q&A at the end, please repeat any questions that are asked for the benefit of the mic and those watching on youtube. Thanks

<comment><USER27> Just do this anyway, often the audience can't hear it.

</comment></comment><comment><USER28> Say at least something useful and new that most people in the audience do not know already. If this is not the case, better to rethink the talk from scratch. Audience should go aways thinking "I learned a few new things".

<comment><USER29> Whilst I personally agree that talks are better when you learn something new, there seem to be whole conferences dedicated to intentionally restating the same things over and over again. Its almost as if some people go to these events to have their ideas _confirmed_. Project management conferences I am looking at you!

<comment><USER28> I agree but I'm not sure this is intentional... I've the feeling that commercial conferences are just simpler to run that way: professional talk- giving persons always saying the same things over and over, with little efforts and without being part of any actual "research" in the field.

</comment></comment></comment><comment><USER30> There are quite some people who are writing full scripts. That's also what I prefer. It goes like this:

Before creating a single slide, write down sentence by sentence, word by word, what story you want to tell. You can use tools to get a very rough metric of how long your written text will translate being spoken. Stop when you reach your talk length.

Once you are done, you can start creating slides. Choose what you like the best and what fits your story. Few slides, many slides (e.g. Pecha Kucha), no slides.

I would never do live coding but show small videos instead. I have seen live coding fail more often than being a great success. But if you want to do so, have a fallback video at hands.

Now your rehearsal: Not 1 full, not 2 full rehearsals, do as much as you can! For my last and very first talk for a conference I did like 20 full rehearsals, 5 of them in front of people, some in the living room, some in front of the mirror. I bet this can be less in the future but it got me super confident. Rehearsal matters! Don't be lazy and you will be amazed how confident you can go into your talk.

When you black out during your talk, don't panic because you have a full script which you could theoretically read word for word. That always calms me down.

Good luck and have fun.

<comment><USER31> +1 for live coding being really hard. I've done many talks and by far the hardest was a live coding talk I did recently.

It has all the same difficulties as a regular talk, but with some added handicaps:

\- no ability to make eye contact with your audience and feel the room

\- no way to talk over small errors, if you get stuck on a bug it can take you 10 minutes to find your way back out

\- very difficult to keep the audience's attention since all they see is a wall of text

\- talking and typing at the same time is really hard, you get to enjoy stammering your way through fumble fingers

In short: only try a live coding talk after you have a lot of presentation experience.

</comment></comment><comment><USER32> Make sure that your talk fits the timeslot.

I find it helpful to go train the whole talk with a metronome (at a slowish tempo) to have an upper bound on how much time the talk will take.

<comment><USER33> Just as a guideline, I've found that about 1 slide per minute (with not a ton of text per slide) is pretty good. This has worked for me for topics ranging from graduate level math to programming topics.

<comment><USER34> But as an addendum, your talk should not depend on the slides - the slides should illustrate or add information, trigger people's visual memory for what you said during that slide.

If you write slides with bulletpoints and read them, then er, just, don't.

</comment></comment></comment><comment><USER35> I came across [https://speaking.io](https://speaking.io) _after_ I presented for the first time at a larger conference [1]. In hindsight it's so obvious -- Zach Holman really talks about the things that matter. So if you still have time, please do your future-self a favour and have a look at it.

Another point I found out _after_ I presented is to better avoid any caffeinated drinks -- apparently it makes your mouth dryer. Adding a bit of nervousness makes matters worse and you end up having to drink a sip of water every few minutes.

[1] [https://youtu.be/wNrTDEaDVwU](https://youtu.be/wNrTDEaDVwU)

<comment><USER19> Came here to say the same - [https://speaking.io/](https://speaking.io/) is very valuable in preparing, creating and delivering a (tech) conference presentation. Recommended resource!

</comment></comment><comment><USER36> Tell a good story. Humans love stories. Even the most deeply technical talk should have a narrative with a beginning, middle, and end.

Start with a bang. Have a controversial opinion? Lead with it. The slide with your name probably shouldn't be the first one, unless the conference makes you start that way. This goes back to point one -- telling a good story. You know how most movies start with something really exciting in the first few minutes? This is called the "inciting event" and is what drives the narrative. Your talk should have that too.

</comment><comment><USER37> The audience wants you to succeed and are generally very forgiving.

<comment><USER38> This! It's one of the most important thing to remember – people paid money and came to listen here, and you've been invited as a speaker, so that means that you have something important to tell, and people really want you to succeed.

I also recommend a fantastic book on the topic by head of TED conferences, Chris Anderson - "The Official TED Guide to Public Speaking". It helped me immensely when I was preparing to my first big public speaking event.

<comment><USER19> Agreed! As I wrote to a comment elsewhere on this page: "Most of the time, they selected your talk based on their interest in the contents (and less so on your delivery), and so they want to learn a thing or two. They will be graceful towards your presentation (style, delivery, slides) if at the end they got what they came for: you sharing data, knowledge, insights or wisdom. You don't want [to make] that too difficult for them, so you should work hard on improving your presentation delivery, but sharing knowledge is appreciated over sharing jokes or just well-designed slides."

</comment></comment></comment><comment><USER39> When rehearsing record yourself (i.e. with your phone mounted on the tripod or just against something). I realized, that before that I didn't do full rehearsal, just was repeating the talk in my mind or even if speaking aloud - I was sitting instead of standing, had lots of interruptions, etc. Then watch the recording. It's painful, but worth it. Observe your body language. Try to face the audience, not sit or stand with your back towards them to read the slides. Move a little bit, don't just stand there.

<comment><USER40> This. When rehearsing in your head, it's easy to gloss over parts that really need some working. When treating it as a proper presentation, those spots are painfully obvious. Better to find them alone, even if watching yourself is a bit awkward.

I also like to record myself because sometimes I find a good way to explain something, which I want to remember and explain the same way during my talk. It also helps with pacing. Am I too slow or too fast?

</comment></comment><comment><USER41> Plan to give the same talk several times. You can give it to your team, then to some local dev meeting, then on a larger conference. You can improve it over time.

Talk clearly, look at your audience, if it's hard to hear what you're saying at all then there is no point.

Make it clear what the problem you're solving is, why solving it would be nice, why obvious solutions aren't good enough, then work towards a big payoff at the end. Show that your tech solves the problem, and does it very neatly!

When explaining stuff, use _examples_.

</comment><comment><USER42> 1) Do not attempt to live code. change your code via version control, build small videos, copy and paste... whatever you do... do not try and live code

2) Read "The presentation secrets of Steve Jobs" ... its not really about Steve Jobs so much as its about how to be a great presenter.

3) building or writing a talk is significantly less important than the delivery... which means that more of your time should be spent on how to deliver the speech (recording I find is the best way to practice)

4) Pick a single thing and do it well, do not attempt to put too much into a talk or tackle something massively complex.

5) Make sure that everyone is walking away with something they can actually use. This doesn't require it be a hard skill... "Soft" or philosophical utilities are just as good

6) Have Fun and be funny... Speakers have a tendency to want to show off the size of their intellect, and the level their competency- having a speech be entertaining is way way more important.

7) DO NOT READ FROM YOUR SLIDES. know your shit. slides are supplementary

Extra Credit. Here's a collection of some fantastic technical speeches:

* [https://vimeo.com/9270320](https://vimeo.com/9270320) * [https://www.destroyallsoftware.com/talks/wat](https://www.destroyallsoftware.com/talks/wat) * [https://youtu.be/o_TH-Y78tt4](https://youtu.be/o_TH-Y78tt4) * [https://www.youtube.com/watch?v=csyL9EC0S0c](https://www.youtube.com/watch?v=csyL9EC0S0c) * [https://youtu.be/a-BOSpxYJ9M](https://youtu.be/a-BOSpxYJ9M) * [https://youtu.be/kb-m2fasdDY](https://youtu.be/kb-m2fasdDY)

</comment><comment><USER43> As I moved into management I started to give more and more talks/presentations. A few very tech talks at summits and conventions with our peers, most were briefings directed at upper management, and while the content are different they function the same really.

I start by figuring out what I want my audience to take a way from the talk. Then I break it up in keywords and then I build my presentation.

Once that is done I practice once or twice, by my self, talking to the computer while I rearrange, add or delete from the presentation to make it what I want it to be.

Once this is done I practice, going through the entire presentation until I'm able to give it on the fly if I was woken up at 4am. I don't practice it word for word though, but when you've talked about a subject enough times, you can do it again.

The practice but is really, really important. Especially if you're not used to giving speeches. At first I thought that if I just practiced in my head, I'd be fine, because I knew what I wanted to say. Hah, not so. The first time I gave a presentation I was a stuttering incoherent mess, because I hadn't practiced by saying the words out loud. I knew exactly what I wanted to say, I just couldn't.

Now, many years later, I don't have to practice as much because I've gotten better verbally. So yo can definitely be the type of person who doesn't need to practice out loud. But I had to do more than a thousand presentations to get to a point where I could comfortably skip practicing on short presentations and only doing it once or twice on long ones.

As for questions afterwards, take your time to think about your answer, and if you don't know the answer, then be honest and always, always be polite and affirmative. If you make people feel like they asked a good question, even when you think it wasn't, then they and everyone around them will like you better. This too gets better with practice, but it's obviously not something you can practice on your own.

Humor is typically a good thing, it relies a lot in timing and it sometimes falls flat. Just never do it at someone's expense.

</comment><comment><USER44> If your slide has writting on it, people will read your slide instead of listening to you. Keep the writing to a bare minimum and fill in the missing parts. Even better, use a picture that helps tell your story for that slide.

For each slide, think about what the audience take-away is. They should learn something from what you say for each slide.

Mingle and introduce yourself to a few people before your talk but don't tell them you are a speaker. Before you get on stage see if you can find them in the audience and pretend you are talking to them and not a huge audience. If you can't find some known faces, pick one from the first few rows. Helps with the nerves.

Until you get good at speaking, you need a lot of rehearsal for each talk. Present once in front of a willing friend and then after making corrections, get a few volunteers at work to be an audience. As many rehearsals as possible.

Slow down. Pause. People need a little time to digest each idea. Your material is new to them.

Like everything in life, the only way to become good is to make mistakes. With speaking you do that in front of a lot of people. It helps if you can laugh at yourself and be forgiving. The audience will often treat you the way you treat yourself.

<comment><USER45> The 'assertion-evidence' approach to creating slides focuses on for keeping text to a minimum and using pictures and other visual aids to support your message. They emphasized it in my engineering school, and I've been using it in workplace presentations for years.

[https://www.assertion-evidence.com/](https://www.assertion-evidence.com/)

</comment></comment><comment><USER46> My biggest suggestion is this:

1\. Don't read the slides to your audience. Generally speaking, the audience can read.

So what are slides for then? Well, if it's a text only slide, I treat them as being there to be _reminders of what I 'm supposed to talk about now_. And that's it. The content is what I say, not what's on the slide. So there doesn't actually need to be much on the slide at all. Just a couple of bullets to reflect the high points of the conversation. Now graphics are a different story.

There are exceptions, of course. I've been known to do a slide with a massive list of "things" in 10 point font, with like 30 items on it... but when I do that, it's to _make a point_ \- a point like "there are a fuck-ton of options for X" or whatever.

The other thing I try to do, is put links and pointers to other resources somewhere in the deck, so that sharing it with the audience actually provides some value. If you adopt the "very information sparse" slide format, then the slides don't really provide much value to the audience after the fact. Whether that's an issue or not is kinda up to you.

</comment><comment><USER47> Finish your slides _at least_ a few weeks before the talk and dedicate a time slot equivalent to the talk (ex: 1-hour => 1-hour, 30-min => 30-min) per week doing a dry run. This is particularly important to get the timing correct. If you're repeatedly short or long then adjust accordingly.

Version control your slides. This is particularly useful if you end up giving the same talk more than once as you can tweak things and improve it.

It's a tech talk, not a stand-up comedy routine. Light jokes and colorful anecdotes help with connecting to the content but the substance should stand on it's own.

Depending on your alcohol tolerance 1-2 drinks can be remarkably effective at smoothing out your delivery.

I find a small intro on the format of the presentation to be helpful at setting expectations. The talk descriptions are often very short and it's hard to gauge what's actually going to be covered with a lot of " _Deep dive into XYZ_ " barely getting your ankles wet with real code. It's appreciated (as an audience member) to know in advance what you'll be getting.

<comment><USER48> I could not disagree more with your first line. For one it's utter fantasy. For tech talks where you need to present results, sometimes results dont arrive until the morning of. Secondly, there should be a measure of proaction - gauge the audience and adjust the talk accordingly. In fact, I'd go the complete opposite, keep adjusting your slides until you're comfortable. But yes, do time yourself. Generally IMO a minute per slide is a good ballpark. This means your slide is not too empty or too full, and you can talk about the material in the slide without reading the slide out.

<comment><USER47> > I could not disagree more with your first line. For one it's utter fantasy.

The lead up from call for papers to actual conferences is usually 4-6+ months. Assuming you submit a talk without any content prepared yet and spend the first two months procrastinating, that leads 2-3 months for put together your outline and slides.

> For tech talks where you need to present results, sometimes results dont > arrive until the morning of.

That's a specific case and hardly the norm. Plus you likely know the direction of the results without know the final 7 decimal points. The latter you fill in as it comes.

> Secondly, there should be a measure of proaction - gauge the audience and > adjust the talk accordingly. In fact, I'd go the complete opposite, keep > adjusting your slides until you're comfortable. But yes, do time yourself.

Definitely play the audience but if you haven't practiced your content you have to spend more time coming up with phrasing rather than shifting over, or dedicating more time to, a section.

> Generally IMO a minute per slide is a good ballpark. This means your slide > is not too empty or too full, and you can talk about the material in the > slide without reading the slide out.

I vary widely from 20 seconds per slide for a quick succession of minor points to 3-4 minutes when there's a code sample to talk through.

This is also why practice is so important as you get a feeling for where you can spend more time if you have it and where you can cut out if you don't.

</comment></comment></comment><comment><USER49> In my experience, one of the most important things is to keep your audience in mind. I recently gave a talk about how docker works internally. I knew that a good chunk of the audience was aware of the difference between docker and a VM, so in the beginning, I explained these differences via a more or less fun story. People who already knew the content were not annoyed, the rest got the information they needed.

Another thing is, tech talks tend to be as dry as the Sahara desert. So try to make your talk interesting. Do not just focus on getting the information across, but make it fun to listen.

Practice your talk without slides. This has two benefits: You concentrate on the content, so your stuff by heart at the end. And you don't depend on the slides, in case something goes wrong.

Lastly, prepare for 4:3 - even if they say you get a 16:9 beamer, chances are it's not. And prepare for offline, your Laptop being broken and in case you are doing a live demo: Have a video of it as a backup.

These tips are all just from my experience and may not apply to you, but maybe it's helpful. :)

<comment><USER50> What was the fun story?

</comment></comment><comment><USER51> Do not assume everyone knows acronyms or initialisms that you use, particularly if the audience is unknown. Saying "test driven development" is more accessible to a wider audience than "TDD".

<comment><USER52> Also, if someone is hearing impaired, they might not know what TDT is.

</comment></comment><comment><USER53> If there is a Q&A section and it's being recorded... please please please repeat the question so your mic pics it up because the person asking it is miles away and it never makes it into the audio so the people watching at home later have to guess what the question is based off the answer you gave which can be tough sometimes. So just a "Ok, so the question is... blah blah blah - answer".

Also... nothing can quite prepare you for how shot your nerves can be. It definitely pays to run it through many times as you can with a timer so that you are at least confident in your pacing.

Other than that it's quite fun.

It can be pretty handy to you to include your twitter handle in the top right corner so you get some follows throughout the presentation from people who were interested. At the end link off to 'you can find the slides for this presentation here bit.ly/soloyolo' etc.

</comment><comment><USER54> Understand your audience.

It's SO easy to assume knowledge. When I talk about python, I now give a quick intro to the command prompt. I started out assuming everyone knew how to use the command prompt. A lot of times, you forget that the stuff you "just use" may be new to the listeners.

</comment><comment><USER55> who is your audience? where are they starting from? know this before going in.

get there very early and check that the tech is sorted.

have a short list of explicit goals - feel free to write them out.

practice at least once, for real, out loud. If no one will help, present the talk to a stuffed bear.

do not read your slides to the audience.

expect live demos to fail - have a practiced contingency plan.

no lewd illustrations and don't put people down - you are in a position of responsibility.

at the end, sum up.

</comment><comment><USER56> Former tech trainer and presenter here. In no particular order:

* start by telling everyone what you're going to tell them, then tell them, then tell them what you just told them;

* know your material well enough that when your computer stops working you can carry on seamlessly;

* rehearse in front of a mirror or record and watch yourself;

* if you're talking too quickly, take a quiet breath and make sure you pronounce the last letter of each word that you speak;

* switch your slide to black or white when you're making a very important point, and have them focus on you instead of the screen -- use `b` key for black and `w` key for white, works with most presentational software I've used;

* …and smile

</comment><comment><USER57> How do you prepare and how _long_ do you ought to spend preparing the talk? I'll quote `techtalk-pse`[1][2]:

[quote]

First, most important rule: Before you start drawing any slides at all, write your talk as a short essay.

This is the number one mistake that presenters make, and it is partly a tool fault, because PowerPoint, OpenOffice, even Tech Talk PSE, all open up on an initial blank slide, inviting you to write a title and some bullet points. If you start that way, you will end up using the program as a kind of clumsy outlining tool, and then reading that outline to your audience. That's boring and a waste of time for you and your audience. (It would be quicker for them just to download the talk and read it at home).

A good talk, with a sound essay behind it, well thought out diagrams and figures, and interesting demonstrations, takes many hours to prepare. How many hours? I would suggest thinking about how many hours of effort your audience are putting in. Even just 20 people sitting there for half an hour is 10 man- hours of attention, and that is a very small talk, and doesn't include all the extra time and hassle that it took to get them all in one place.

[/quote]

[1] [https://en.wikipedia.org/wiki/Tech_Talk_PSE](https://en.wikipedia.org/wiki/Tech_Talk_PSE)

[2] [http://git.annexia.org/?p=techtalk- pse.git;a=blob;f=techtalk...](http://git.annexia.org/?p=techtalk- pse.git;a=blob;f=techtalk-pse.pl;h=b49591;hb=HEAD#l869)

</comment><comment><USER58> The best advice I can give to you is that if you're giving a talk on something that you're not an expert on, then tell people you're not an expert.

I gave a talk a year ago about Continuous Delivery, despite being a bog- standard developer that has had to do it on a couple of occasions. I had some general rules that I could carry across from one company to another, so my talk was around these general paths to happiness, and discussing the tools I have used, alongside a generous Q&A.

The questions were all fairly straightforward, and a number of people came up to me at the end to share the same sentiments - they were developers that had been roped into doing sysadmin stuff, and that they found the talk and answers to be very useful.

I have a theory that people often go to talks not to learn something new from an expert on the subject, but for a structured developer chat around an approach on a subject that seems to work for someone in a given context. If they've attended, they're interested in the subject, so as long as what you say is on-subject and clear it's difficult to give a bad talk. From there, it's mostly around delivery, which comes with practice and preparation.

</comment><comment><USER59> The first few minutes are when the audience is most attentive, so don't waste it but jump right in with a motivating example or whatever is the most interesting thing about your talk. Then when you have them on the hook you can give them the outline and overview for the rest of the presentation as usual. I got this advice from a presentation given by Simon Peyton-Jones and have always tried to follow it since then.

</comment><comment><USER60> What do you do when the demo fails. I like to get all flustered and go down in flames but you might prefer to have a way of dealing with that eventuality.

</comment><comment> radford-neal Have something to say. Something that you WANT to say. If you don't have that, cancel the talk.

So you want to say something. Say it.

Don't start your 20 minute talk by spending two minutes going over an outline of it, saying that you'll first present the problem, then review past work, then blah, blah, blah. I HOPE that the thing you want to say isn't "I've spent a lot of time organizing my talk like this..."

Don't start your talk with a funny anecdote about the driver of the taxi you took from the airport. I hope that THAT isn't what you want to talk about either.

Do start by describing the problem you're solving (you are solving some sort of problem, I assume...?). But only to the point where the audience can grasp what you're trying to do. Review past work only if the focus of your work is something like "I fixed the problem that the XYZ algorithm unnecessarily recomputes A...". You can mention how past work relates to yours at the end of the talk. It will make more sense then.

Get as quickly as you can to WHAT YOU ACTUALLY ACCOMPLISHED. I hope that's what you want to talk about.

</comment><comment><USER61> The number one thing I love to see when I'm watching a tech talk that is focused on teaching or advertising a particular tech is the Bad Parts. Obviously you don't want to just bash the tech you're there for, but I've seen way too many demos that portray the technology as the One True Technology that will Solve All Your Problems and I usually approach tech talks from a place of skepticism.

Alice Goldfuss' recent talk on containers[1] is a really good example of what I'm talking about - she spends a good amount of time talking about what containers are, and why and when it would appropriate to use them, but she spends an equal or greater amount of time preparing the audience for what challenges they will encounter when implementing containers and talks about when you're probably better off without.

[1] [https://www.youtube.com/watch?v=sJx_emIiABk](https://www.youtube.com/watch?v=sJx_emIiABk)

</comment><comment><USER62> Never assume that your audience knows anything of real substance about your talk. You've spent many hours building up knowledge and context about the subject, and your audience is coming in cold. I've rarely been to a talk where the speaker "over explained" the material.

</comment><comment><USER63> Make the objective of your talk clear. If you're giving an introduction to some technology, it is helpful to also point people to resources to learn more. If you need to explain or 'sell' your topic, do so, but don't overdo it. Also, be honest. Everyone appreciates enthusiasm, but it's better if you don't come across as a fanboy.

If you're having an interactive part, be aware that it is hard to estimate the time this part will take. If you have a hard deadline, be ready to skip some parts (this is a good idea in general as things may always

It's probably best if you are so familiar with the topic that you don't really need slides in the first place. On the other hand, take care to connect with your audience and take their background into consideration.

</comment><comment><USER64> Stick to the topic, and don't go meta. Leave out things like "when I was preparing to submit this talk proposal" or "as I was creating the slides for this talk." Talk about the topic, don't talk about the talking.

Know the language and culture of your audience. If it's a mixture of people who don't speak English (or whatever language) as their first language, take care to avoid colourful metaphors that make sense to a native speaker but which confuse non-native speakers. I've confused people with expressions like "inside baseball" or reference to "Goldilocks values" (not too much, not too little). Good metaphors are valuable. Metaphors that depend on too much cultural context are unhelpful.

</comment><comment><USER65> [https://www.deconstructconf.com/blog/how-to-prepare-a- talk](https://www.deconstructconf.com/blog/how-to-prepare-a-talk) This is really good write up on similar topic by Gary Bernhardt.

</comment><comment><USER66> Something practical I haven't seen mentioned yet: unless you know the venue, assume the screen is far away from the audience (so the text needs to be large) and that it's hanging low (so most people can't see the bottom of the slides).

<comment><USER67> Black background with white text helps too.

<comment><USER19> That depends (a lot) on the displaying and viewing conditions; are your slides projected in a dimly-lit room, or are the lights on? Readability of your slides is affected by that.

Although slides often don't contain much information that needs to be read in full detail, I find code examples to be better readable in a dark font on a lighter background.

Sometimes the conference gives some advice regarding the slides (dark text on light backgrounds or vice versa), since they'll know / set the room lighting conditions.

</comment></comment></comment><comment><USER68> There is a lot of good content advice here. I'd like to add two technical points:

\- Plan for the worst-case scenario, e.g. your computer dying. All my presentations are available on GitHub Pages[0] (using RevealJS), so all I need is a random laptop.

\- Use a bright color theme on a beamer to improve readability (slides, console, editor/IDE). Dark schemes are nice, but they are inappropriate for most presentations. Bonus: when using HTML slides, you can design both a bright and dark theme and switch depending on the light conditions.

[0] [https://github.com/darekkay/presentations/](https://github.com/darekkay/presentations/)

</comment><comment><USER69> I'm a Toastmasters member, and one of the things I learned with presenting technical talks is that you should know your audience. If your audience understands the tech, then speak at a technical level, otherwise speak at a very high level

</comment><comment><USER70> \- Don't put too much on your slides.

\- Don't put too much on your slides.

\- Don't put too much on your slides

See if you can do without any bullet list. Now you are forced to talk from your experience in a natural form. You'll be fine.

More serious:

\- don't go into the trap of too much introduction and theory before getting to the actual matter. E.g. when doing a talk on GPU image processing don't spend 30 minutes on how a GPU works.

\- Know your audience experience with the matter if possible (see above)

\- If possible, do demos. If have demos, consider if it makes sense to run them _before_ the tech slides. They tend to make more sense after seeing a live demo.

\- If you have demos, rehearse them. Make sure you get the timing right.

\- leave room for questions.

</comment><comment><USER71> Introduce yourself.

Way too many times I'm sitting in the audience, the person at the front is exchanging smiles with the programme committee who all know each other, but I have no idea who they are and what drives their viewpoint.

</comment><comment><USER72> [https://www.hanselman.com/blog/11TopTipsForASuccessfulTechni...](https://www.hanselman.com/blog/11TopTipsForASuccessfulTechnicalPresentation.aspx)

</comment><comment><USER73> If you're showing code, use way less code than you initially want to.

</comment><comment><USER74> Chances are you're an expert in the field! Great! Rember not everyone in the audience is.

Keep in mind who you're talking to and what they'll bring home from your talk.

Will they use it on their job? Then it'll need operational details. It's just something cool you did? Make sure it's a good story with villains (problems) henchmen (bugs) and it stays relatable all the way to the victory. Is somerhing that pushes the envelope of what's known? Make sure to establish the state of the art and guide the audience through the wonder of the discovery process.

</comment><comment><USER75> Don't start with powerpoint. Get pen and paper. DRAW what you want to tell. If the result is good you can scan that drawing to make a slide.

This way I don't overspend time on tools, but on content.

Hope this helps

</comment><comment><USER76> Simple things that have helped me:

\- Right before the talk: get to the room well ahead of time and make sure there are no setup issues with the laptop, audio, projector, etc. I've seen a number of speakers fail to do this basic thing and it dampens their flow, confidence, etc. The audience might even get distracted and the whole show goes awry.

\- Prepare and practice the intro speech, don't wing it: if you have a good opening, you'll feel confident and the momentum will carry you through the rest of the talk.

</comment><comment><USER77> Don't do a Ubuntu update the day of the speech. I did then closed my laptop, headed to the venue to give a 30 minute workshop on best practices in resumes and the reasons for a LinkedIn Profile in front of 40 people, and bootloader was corrupted. Thankfully I had backup of folder (reveal.js presentation written with rmarkdown) on USB. I usually zip up and email a copy to the organizer, just in case.

</comment><comment><USER78> Casually give an informal version of the talk to some friends or colleagues to see if they "get it".

I find that talking it through a few times with someone will help you figure out which parts of your explanation are unclear and need rephrasing.

Also, don't take it too seriously - technical talks are already often dry - don't be afraid to insert some memes and jokes to keep the audience engaged!

</comment><comment><USER79> Don't try and cover too much ground in the time - it is generally quicker than you think. Have a strong story arc however so that any questions can be asked at the end during the presentation or afterwards.

You can always put slides and examples online and refer to them, especially if in another country where people might not keep up with your native language.

Smile a lot!

</comment><comment><USER80> Two things I haven't seen ITT yet:

1\. After you tell me what you're going to talk about, tell me why I should be listening to _you_. Why are you an authority on this topic? Unless you're famous, I don't know you.

2\. The talk should contain 50% or less of your knowledge on the topic. You want to keep some info "in your back pocket" to ad lib with.

<comment><USER46> _After you tell me what you 're going to talk about, tell me why I should be listening to _you_._

Interesting. I never do this, and probably never will. My viewpoint is that you've already made the decision to attend the talk, so me spending time reciting my bio is just redundant and a waste of time.

</comment></comment><comment><USER81> I frequently see speakers end their talk with "Any questions? No questions?? I was really perfectly clear? OK. Bye!" That fast.

It takes at least ten seconds for people to formulate a question well enough to ask it in front of everybody. Have some patience. Bonus points for having something low-key to fill the awkward silence.

</comment><comment><USER82> I write a weekly newsletter on this exact topic - you might find it useful :)

[http://blog.voxgig.com/2018/07/13/welcome-voxgig- newsletter-...](http://blog.voxgig.com/2018/07/13/welcome-voxgig-newsletter- event-speakers-july-13th-2018/)

</comment><comment><USER83> I had filed this one (1) away for next time I have to do a presentation. It sums up a list of bad titles for a presentation.

[1] [https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d...](https://gist.github.com/snare/7f0c4708bf4ea8133204c21e8ba64d23)

</comment><comment><USER84> in my experience I would consider the following:

\- Understand what are your takeaways for the audience. Remember it's about the content, keep in mind main areas/topics to cover.

\- who's your audience ?, there are a few conferences where going very technical (low level) matters, most of them want to focus on how X works, how to solve Y, etc.

\- "Start with why". Yeah, it should sound familiar, check this 5 minutes video: [https://www.youtube.com/watch?v=IPYeCltXpxw](https://www.youtube.com/watch?v=IPYeCltXpxw) .

\- Note that likely in the first 3-5 minutes the audience will have a > 90% focus on what are you talking about, make sure to take advantage of that time with a good "why" (see above) for engagement.

\- Share your presentation slides with a colleague and wait for "honest" feedback.

</comment><comment><USER85> Here's a blogpost I wrote on dos/donts of giving tech talks - [https://medium.com/@gauravgupta/make-a-powerful-point-the- ne...](https://medium.com/@gauravgupta/make-a-powerful-point-the-next-time- you-present-d77f60e92fec)

</comment><comment><USER86> No matter how small the room is, or how much you think you can project, use the microphone. I can't stand when people say, "I have a loud voice, I'm not gonna use the microphone." And then either scream for an hour, or fade in and out of intelligibility.

</comment><comment><USER87> \- What is your message? You do this talk for a reason, it must be extremely clear to you what it is, in a short sentence or two.

\- Storytelling. Humans engage in stories. Prepare yours.

\- Rehearse. Rehearse. Rehearse. And when you are done, rehearse again fixing everything that was not perfect.

</comment><comment><USER88> TLDR; Recognize impostor syndrome and include 'basics' even in presentations for highly skilled people.

I'm in the physical sciences and routinely give fairly math-heavy presentations.

It's easy to think that an audience of Phd's and professors know all prerequisites and just need the hard facts in a rapid succession.

On the contrary over time I found that my audience typically appreciates when I start from the very beginning (in my case meaning advanced undergraduate level or so), and working up to the actual problem setting.

Although my audience is very much expected to know that material they A) get primed for the topic and have a chance to feel good about 'I know this' and B) understand my view of the topic so that we have a common language.

With that I'm ready to frame the technical problem and explain my work.

The last time I did this I actually spent 10 out of 20 minutes on the first part, and the talk was very well received and generated an 'invited paper' request for a journal.

No one has ever complained that my talks are 'too basic'.

EDIT: Btw, the metric I use to measure success is amount of generated questions & engagements in and after the talk. If the moderator has to cut off Q&A for the next speaker you win. If people hunt you down to talk more you win.

</comment><comment><USER89> The why is much more important than the how. The job of the talk is to convince people to read your paper. Focus on motivating your work, overview how the approach was done and the results but the setting for the problem is much more important.

</comment><comment><USER90> Keep the needs of the audience in mind.

More: [http://www.davidralbrecht.com/notes/tags/engcomm.html](http://www.davidralbrecht.com/notes/tags/engcomm.html)

</comment><comment><USER91> Plan for any tech or other collateral to not work properly on the day and have contingencies to continue - even things such as having a printout of your presentation storyboard or bullet points to hand.

</comment><comment><USER92> I will sound like an @$$ but get to the point quickly so many times 1 hour talk could actually be condensed to like 5 minutes of actual information. I wish there was a service that actually did this :)

</comment><comment><USER93> Kelsey Hightower had some insightful tips in this recent podcast: [http://testandcode.com/43-bonus](http://testandcode.com/43-bonus)

</comment><comment><USER94> Have a look at [https://perl.plover.com/yak/presentation/](https://perl.plover.com/yak/presentation/)

</comment><comment><USER95> \- Rehearse in front of a friend.

\- Add as little text to your slides as you can

\- Accept that you will get nervous. We all do, being nervous is not a problem, the fear of it is.

\- Remember, the audience wants you to succeed

</comment><comment><USER96> Who are your audience? What is their level of knowledge? What do they want to know? What DON'T they want to know? Why should they care what you've got to say?

</comment><comment><USER97> I'll give you what I do. I assume that tech talk here means seminar and not class. For a class I do things differently. First, write down the goal of the talk. What should the audience know, be able to do, etc. after this talk? If it's more than three bullet points, it's time to start cutting. Remember, in a talk, everyone is at the mercy of your pacing. Any given audience member will probably space out for at least five minutes of an hour talk, and if you're at a conference or embedded in a workday, they're already overwhelmed with information.

Then sketch an outline of presenting that information, just a rough order of what to touch on. I find that I naturally outline so that each entry is about five minutes, but I don't know if that's just me or a common tendency.

Then I get a timer, stand up, and start talking to myself. I'll take an outline entry, and try to tell an imaginary audience about it. Typically I realize that I have some questions I need to answer for myself, or I run over five minutes. Think about how to drop stuff, look up what you need, note down what bits of verbiage came out that flowed well to reinforce them for yourself, and do it again. I often get frustrated after two or three times on one item, and go do another one, then come back to it and do it some more. During this whole process pretend the perfect slide to go with your text is up next to you so you can point.

After some cycles, this will converge. You will know what you want to say, and you will know what needs to be on the slides. Now set the timer for the full talk length and give the whole talk like this, still with pretend slides. You'll probably find places where you need transitional material, and it will probably run long despite the fact that the pieces add up to fit. Adjust. Do it again. This is also a good time to figure out and memorize the first couple sentences of each section, which will let you transition easily if you lose your place.

At this point you know your talk. Now go sketch your slides out on paper, and give your talk pointing to the paper. Once you think you have what you need figured out on paper, then go turn them into a PowerPoint, PDF, whatever.

Now practice it with the slides. Practice starting from a section using those memorized sentences. Memorize your sequence of outline items with those sentences attached.

Then do a run-through the day before. The day of, I spend five minutes thinking through my outline and section starting sentences, take a deep breath, and talk as inhumanly slow as you can. Even if you don't have stage fright (I don't), you will have adrenaline, and you need to slow down.

</comment><comment><USER98> You probably know more about the subject than the people you are speaking to. So, when appropriate, err on the side of giving more background info than less.

</comment><comment><USER99> 1\. Describe the problem you're trying to solve.

2\. Describe your approach to solving it.

In general, have something to say, know your stuff, and the rest will flow naturally.

</comment><comment><USER100> When practicing and figuring timing, I find it helps to do it out loud. I go way too fast if I don't properly vocalise it.

</comment><comment><USER101> I find code in slides a bit distracting. It's better to have code in a separate editor (which can be run too!).

</comment><comment><USER102> Proofread everything you plan to display, because spelling and grammar errors can negate your authority (hint ^^^).

</comment><comment><USER103> can keep in mind transitions between slides, whether working your way through the current slide as intended or digressing. these transitions can contain a purpose for arriving at the end of the current slide + relevance to the upcoming ones

</comment><comment><USER104> These are some things that I generally keep in mind whilst preparing or giving a talk. (These are just things I do, feel free to disagree.)

Preparing: 1) Give yourself enough time to write and practice the talk. If you can get ~1 month, that (for me atleast) is more than enough time.

2) Say the words out loud when practicing. You may use different words or slightly improvise during the talk, which is totally fine. Just let yourself hear some version of it a few times (out loud) before presenting. In my experience this helps to avoid stutters, and keeps you in your place.

3) Watch talks of people online that you enjoy or by people that inspire you. We all have our own "style" when it comes to public speaking. You will never be able to straight up copy someone. But watch and take mental notes as you do.

4) (If you are preparing slides), keep them simple! It is YOU who is presenting the talk. Not a wall with a projector. Treat your slides mostly as an accessory. They can help illustrate a point perhaps, or outline the key subjects. Short and simple.

Presenting: 1) If you can, make sure you have a bottle of water handy when you go up.

2) When I approach the stand, platform or stage, I like to do so with confidence. This really does depend on the setting. But for example, as I walk up, sometimes I'll take my jacket off. Or do something that otherwise makes me feel like I'm owning the space. This makes me feel much more comfortable and puts me off to a good start. Even if you're not a confident person, walk up as if you are or do something simply to make you feel more comfortable.

3) Don't be afraid to use the space you have been given. This goes both for actually walking around, and using your arms to assist your words. Hands out of pockets. Use them.

4) Pauses are a good thing! Whether it's just to take a sip of water, or just a pause for the sake of pausing. This both gives you a few moments to collect your thoughts and also a few moments for the audience to digest what you have just been saying.

5) Slowww it down. It's almost too easy sometimes to rush talks when it comes down to actually presenting one. Take your time. They came to see you! So make it worth their while.

6) This is slightly tricky in some cases, but try to calibrate yourself towards the audience. For example, in my case, I've found people seem to pay more attention if I've just said something slightly amusing. If you can get away with it, go for it! It's a hard one to explain, but the bottom line is, try to get the crowd on the same page. I'll perhaps think of a better way of explaining this one and reply to this comment.

</comment><comment><USER105> Ask yourself: "Who is my audience?" Everything else comes from that.

</comment><comment><USER106> If you get butterflies or a racing heart, take three deep breaths.

</comment><comment><USER107> As a tech conference audience member, one of my biggest pet peeves is people using roughly 70+ percent of their talk to introduce the background/rationale of their tool/library/use-case/workflow/whatnot without even showing precisely what the tool does or how to use it practically. Chances are, most people in the audience are in the room _because they are already on board with your rationale_.

A fake example: If you're giving a talk on your new Linux shell that 's way better than Bash, you don't need to spend the first two-thirds of your talk explaining what Bash is and what its weaknesses are. Your audience probably knows what Bash is and knows enough to be interested in an alternative. Don't bore them out of the room.

TL;DR: Show first, tell second.

</comment><comment><USER108> Proofread the title. Pay attention to articles...

</comment><comment><USER109> One thing that has always helped me is mugging the first few lines until you can get in your rhythm. Sometimes that glare of hundred eyes causes you to forgot about your talk.

</comment><comment><USER110> A technique that works really well for me is to focus hard on the fact that my job is to be merely a conduit for information, and any anxiety I might feel is just another factor that might impact my ability to convey that information. My feelings then become secondary because my whole focus is on the message. Sometimes I still get an adrenaline rush at the start, but this dissipates as I focus on the content. Other times I am completely relaxed throughout.</comment>


New Aphex Twin track remixes - <AUTHOR> https://aphextwin.warp.net/tracks <comment><USER2> I like techno, but I'm not afraid of it.

A hit is a hit, and this my friend, is not a hit.

</comment><comment><AUTHOR> I like the animated ship as track position indicator as you stream... :)</comment>


Tips to get your first contract on Upwork - <AUTHOR> https://remoteletter.com/post/first-contract-on-upwork <comment><USER2> My advice: don't waste your time on Upwork or similar platforms.

There's absolutely no way to compete with the infinite supply of so-called "developers" from third-world countries and everyone appears to be an "expert" with 10 years experience in every technology you can imagine. The rating system has been gamed to death so there's no way for a client to tell the good from the bad, and given that a lot of them are non-technical they will fail to spot the red flags and go with the lowest bidder.

There are also horror stories when the platform itself fails to mediate disagreements and steals a freelancer's hard-earned money. I am not sure if this is resolved but as of last year, EU-based VAT-registered freelancers were still unable to work on the platform and abide by the rules because their payment system is unable to handle VAT, so your option is to either eat the VAT yourself or take the payment off the platform and break the rules.

You will overall make more money (more consistently and with less stress) by taking a low-wage job like stacking shelves in supermarkets or doing food deliveries.

<comment><AUTHOR> This might not be suitable for someone from Europe or USA but for some one living in a 3rd workd country, I think it is more than okay to get paid around $30 per hour.</comment></comment>


Back to the Future, Time Travel, and the Secret History of the 1980s - <AUTHOR> https://medium.com/message/back-to-the-future-time-travel-and-the-secret-history-of-the-1980s-80bf3c6347cf <comment><USER2> I grew up in the 80's and saw the original Back to the Future in a theater. When I was a kid, I remember thinking 1955 was ancient history. It's pretty wild that young people today, like the high school students I teach, feel the same about 1985 as I felt about 1955.

I wonder if there's something different though? I knew little about the 50's when I was in high school. None of my peers were "into" the 50's, and nobody was listening to music from the 50's. But my current students still love 80's metal bands like Metallica and Slayer, and 80's hip hop like NWA and others. They like 80's movies, and will have quote battles about 80's movies.

Maybe 1985 doesn't feel as far away to them, or as irrelevant, as 1955 felt to me.

<comment><USER2> I wonder if the cultural shifts - the pivotal moments in history - were more significant between 1955-1985, than 1985-2015.

Between 1955-1985 we had the civil rights movement, the moon landing, the Vietnam War, and the final decades of the Cold War. Between 1985-2015 we've had the fall of the Soviet Union and the Berlin Wall, the Gulf Wars and Afghanistan, and 9/11\. I'm obviously missing some other significant events.

We also had technological shifts - 1955-1985 saw records -> tapes, but CDs and PCs were not quite massively adopted yet. 1985-2015 has seen CDs -> flash storage, mass adoption of PCs -> laptops -> smartphones, and social media apps. Much of the advances in technology have connected us geographically and temporally.

I feel like the significant events between 1955-1985 separated the youth of the 80's from the youth of the 50's, more than the significant events from 1985-2015 have. I also feel that many changes between 1985-2015 actually connected today's youth to people and events of the last 30 years.

<comment><USER3> > I wonder if the cultural shifts - the pivotal moments in history - were more > significant between 1955-1985, than 1985-2015.

That might be part of it, but I think a lot of it is just that the Baby Boomers are the worst generation in history, while today's younger folks are…just younger folks.

<comment><USER4> I think economically the Boomers were a disaster (cashing checks that future generations now must cover).

Socially and culturally however I think they achieved many great things we take for granted (birth control access, environmentalism, civil rights advances, multiculturalism, the sexual revolution, etc).

<comment><USER5> I think this idea that the Boomers were somehow special or more damaging that newer generations is BS.

</comment></comment></comment></comment></comment><comment><USER6> Only 10 years later we had cell phones and browsers.

> Let's stop checklisting and complaining and start opening things up and > bolting them together again.

Good luck with that. Electronics made in the 80's were a lot more friendly to open up and repurpose (to the individual part level) than what you buy today.

<comment><USER7> On the one side, you're right.

On the other, as a popular internet image says, you've got everything listed on a full-page Radio Shack - and more - in a package smaller than a walkman in your pocket nowadays, with the possibility to write any kind of software (or indeed attach any kind of accessory to) for it, which far exceeds anything anyone with an old radio and a soldering iron could ever do - and in a fraction of the time. And share that same thing instantly with a potential audience of tens of millions with the press of a button.

So maybe you can't open something up and bolt it together again - but you shouldn't marginalize what you can do instead either.

<comment><USER8> True but technology is becoming increasingly restrictive as time goes on. A kid today can't write software on a phone like you could with old computers. And just like hardware, software is growing in complexity and buried from the user.

<comment><USER9> > A kid today can't write software on a phone like you could with old > computers.

On Android, at least, to the extent that that's a problem, its a convenience- of-the-form-factor problem (with tablets even this isn't really a big problem, especially with keyboard cases), rather than a lack-of-support problem (iOS, out of the box, is somewhat more locked down, but even there I think there are some options.)

There are quite a lot of on-device programming environments, largely free-of- charge, in the Google Play Store.

</comment></comment></comment></comment><comment><USER10> I loved the trilogy when it came out, and then met Tom Wilson (who payed Biff) a number of times. He's really funny and has an amazing tenor voice. It was hard to put that voice with his character. Everyone always asks him to record a voicemail message "Hey Butthead".

<comment><USER11> Have you heard his standup/music bit where he sings about fans always asking him the same things?

On the off chance: [https://www.youtube.com/watch?v=iwY5o2fsG7Y](https://www.youtube.com/watch?v=iwY5o2fsG7Y)

<comment><USER10> Yes, he's actually pretty nice about it in person.

</comment></comment></comment><comment><USER12> Rather than respond to a lot of different comments, I'll just note (and these comments are US-centric):

1\. Because of the internet, recording technologies, etc., we have a much more accurate view of the relatively recent past than one had in the 1980s.

2\. From the 50s to the 80s there was a huge change in societal attitudes vs. authority, order, etc. Nothing as dramatic has happened since. Cynicism has changed in its specifics, been put aside occasionally, etc., but since the stock market crash of 1987 and Iran/Contra took some of the bloom off the Reagan rose, there hasn't been a huge societal consensus, so there in particular hasn't been a huge societal consensus that was later shattered.

3\. Sexual mores had a much bigger shift from the 50s to the 80s than from the 80s to the present; the 80s are when the view was adopted that sex was permissible but dangerous, and that's been the general societal attitude ever since.

4\. I agree that modern filmmaking techniques emerged in the 1970s. Hollywood then regressed to the more commercial action blockbusters, but eventually technology evolved to the point that the same or even greater quality of storytelling was possible on television. Buffy the Vampire Slayer was like a series of 1970s auteur movies of 22 * 47 minute duration. The same is true of Babylon 5, except that the dialogue (usually stolid at best, Londo & G'kar excepted) and special effects were more in the George Lucas vein. TV may have progressed even further since.

5\. The internet brought tremendous changes to day-to-day life, especially if you include the rest of computing (PCs, video games, mobile phones) as well. I don't have a good answer for why that alone doesn't make the 1980s feel more distant than they do.

6\. People never know many details of era before their own. This was brought home to me when my stepdaugher, who is a Middle East expert (e.g. relevant Master's degree from Harvard), couldn't get a Trivial Pursuit question whose correct answer was Gamal Abdel Nasser.

</comment><comment><USER13> I saw an interview once with the producers saying that 1955 was not that much in the past had changed. So for some of the things (like the gas station attendant scene and some of the cars) they had to go back into the 40s to make it look 'older'.

</comment><comment><USER14> Great Scott!!</comment>


The first augmented reality social network - <AUTHOR> Hi guys, we are working hard to create the first augmented reality social network. We have already spread all over the world but we still have a  few users. What is missing? Check it out http://walla.me <comment><USER2> I think it'd be cool if you guys pivoted to a sort of scavenger hunt game with your friends (or strangers) and/or king of the hill game where you can tag up places and somehow counteract/tag over others markings....maybe you can have a social platform surrounded by or based on top of a game platform. This would give people more of a reason to use the app because there's less of a barrier for entry. In a social network you would need a bunch of your friends to be on it for you to join so it ends with s situation that you're seeing where nobody really joins, but if it's based off of or works in conjunction with social games then you only need a handful of friends to get started - plus you can play/meet new people.

Some other ideas: scavenger hunts and treasure maps/hunts made by others, you can make the scavenger hunt list and treasure maps yourself and also include ones made by sponsors/advertisers that take you through/by certain shopping spots or stores ____enable use with quadcopter so people can draw /create their own virtual courses that they can physically fly through. The benefit of this is that if you hit a loop then you're not damaging your drone because it's a virtual obstacle - great for training ____restaurant /travel tips and suggestions. People can draw a positive review in green or a negative review in red. One can then swipe through these reviews on the storefront or display the ratio of positive vs negative reviews which will be done by tallying the number of messages left in green vs red. I think the traveling aspect will really set this apart from something like yelp because it can be applied to anything and the places don't need to be registered/listed like they are in yelp. ____directions to certain places indoors. For instance if you had a trade show, you can draw a publicly viewable path to their table that people can register to see. __ __a game similar to draw something __ __a free draw option so people can use this to draw and map out furniture in a new apartment or rearranging the furniture

There's many more ideas related to what you currently have. These are just off the top of my head, I'm sure if you got the team together you can think of many more/better options.

</comment><comment><USER3> Where does the social network aspect come in? Had you not mentioned it I had thought it was something more akin to snapchat with a location based aspect to it. Even so it looks like users can still look at the pictures directly? But I am not sure about that.

If it doesn't need the person to be at the location, it is just another picture sharing app. If it does require that, I can see why it would get old quite fast.

Looks novel at most, I doubt people crave a new "social network" anyway. The mere thought of it makes me annoyed tbh.

</comment><comment> grif-fin I think these maybe missing:

\- My friends don't use this app, so there is the chicken & egg problem that exists with all social networking services (can I see public drawings?)

\- Assuming chicken & egg problem did not exist or you have solved it, how often the friends I am in touch with would draw a message in a particular place and send it to me and how often do I remember to check their message when I pass by that place?

Wouldn't it attract more people if it would have been public so I could see any drawings, information about the building or poster images by anyone?

Pivoting towards a pure anonymous entertainment/game maybe necessary?

Overall it is a cool idea but would people use it without a big pivot? I doubt so or if they do I'm missing something here

</comment><comment><USER4> Saw a similar idea back in 2013. They had no success

[https://itunes.apple.com/us/app/thinkr/id655199132?mt=8](https://itunes.apple.com/us/app/thinkr/id655199132?mt=8)

</comment><comment><USER5> I put app a few months ago and then deleted it. For me, I just didn't feel like there was any incentive to create messagees or even view other's. It's awesome work though. I commend your team for putting it together. Social networks are hard.

</comment><comment><USER6> Since nobody I know currently uses this, what value is there to it which does not rely on network effects?

</comment><comment><USER7> Wasn't Ingress an augmented-reality social network? It's been around for years.</comment>


Ask HN: What's the best way to unit test a RESTFul API? - <AUTHOR> I wrote a RESTful web API for a side project of mine (https://wintermute.design), and I tested it using mocha and chai (the API is written in express JS). But recently I read different articles which advise against such practice and recommend using mocks instead. What's your opinion on this ? How would you go about testing  your own API if you had to write one today ? <comment><USER2> Mocha + Chai along with Sinon ([http://sinonjs.org/](http://sinonjs.org/)) for stubbing and mocking.</comment>


Computers in your clothes? A milestone for wearable electronics - <AUTHOR> https://news.osu.edu/news/2016/04/13/computers-in-your-clothes-a-milestone-for-wearable-electronics/ <comment><AUTHOR> Fabrication of Textile Antennas and Circuits With 0.1 mm Precision (IEEE Antennas and Wireless Propagation Letters)

[http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=tru...](http://ieeexplore.ieee.org/xpl/articleDetails.jsp?reload=true&arnumber=7110536)</comment>


A developer-first project management tool - <AUTHOR> Here's a very useful developer-first project management tool that makes your software development workflow faster.
The tool includes beautiful issue tracker, continuous integration and documentation. It is free forever for up to 5 users and a Web IDE will be added soon.
Give a try here - https://codegiant.io <comment><USER2> No pictures of what the tool looks like in the sales page?</comment>


Embeddable Bitcoin Miner for Websites - <AUTHOR> http://www.bitcoinplus.com/miner/embeddable

<comment><USER2> I'd show some stats on the website, like how much mined in previous 24hrs, how much the individual pc is contributing, other sites that run the widget.

Make the user feel appreciated.

Give them the option to turn it off, or throttle down. Check out the Wibiya toolbar and how that can be switched off. Build a network.

Also, consider making the mining as part of a captcha mechanism.

<comment><AUTHOR> I've made an option to add controls, which shows the current hashrate and a start/stop button. Right now it's up to the websites using it to enable that if they want to.

I like the captcha idea, I've actually been planning something like that. I've got some changes I need to make to my infrastructure before I can do that, but I'm hoping to do it (or let other people do it with the API I'm going to offer).

Thanks for the advice about making the user feel appreciated, I think that's quite important.

<comment><USER2> You've got to keep your eye out on how to access the full power of the client's GPU. I just saw how IE9 and FF4 offer GPU acceleration <http://www.youtube.com/watch?v=r7VLB4DcXhg>

Also, when the user is scrolling the page can you throttle down, so basically the idea is not detract from the user experience. On-demand throttling down somehow. Maybe when a tab is not visible.

<comment><AUTHOR> Yeah, I'd really like to use the GPU, it would be a huge speed boost.

Was it lagging when you were scrolling down? I try to play nice with the CPU and run it at low priority, so it shouldn't interfere. What OS/browser/java version combo has trouble?

<comment><USER2> I don't have Java installed and don't want to install it. I wonder if internet cafes and kiosks would be interested in something like this. You could create a url shortener that place their homepage in a frame or something.

<comment><AUTHOR> We really think alike - the captcha idea, and the URL shortener with a miner at the top were two of my first ideas for uses of an API.

I didn't think of marketing it to internet cafes/kiosks though.

</comment></comment></comment></comment></comment></comment><comment><USER3> Wow. I'd like a list of sites that use this, so that I know to never do business with them.

<comment><AUTHOR> Can I ask why?

The way I see it, websites with advertisements use your mind (by grabbing your attention). This only uses your computer. Which would you rather have a website try to take over?

<comment><USER4> You really think you'll get effective monetization out of a Bitcoin miner that's written in JavaScript and only run on people's short one-minute visits to a website?

Bitcoin mining is orders of magnitude more efficient on a GPU than on a CPU, and that's compared to the fastest C++ clients, not something running in a JavaScript interpreter. _Maybe_ a popular installable game that's played for hours at a time _and_ uses people's excess GPU to mine Bitcoin could be profitable. But this is just a waste of everyone's time.

<comment><AUTHOR> This one isn't javascript, it's based on my browser bitcoin miner[1] which is written in Java. It's about 2000 times faster than the javascript bitcoin miner that I know of.

It's around 30-40% slower than one of the optimized C CPU miners, and of course it's a a lot slower than a GPU miner, but it mines at a reasonable rate (and it starts up quickly)

As for effective monetization, this is something you can run in addition to regular ads if you wanted, since it doesn't take up any screen space.

[1] - <http://www.bitcoinplus.com/generate>

<comment><USER3> Oh good. So not only does it spike my CPU and kill my battery, I also get the resource overhead of the JVM. This is a reverse DDOS.

Sorry if I'm being too hostile, but I like the idea of bitcoin, and don't want to see it become associated with hijacking people's computers.

<comment><AUTHOR> No need to apologize for how you feel - some people love the idea (of supporting a website with their computer power), some people hate it.

As for the resource overhead of the JVM, it's infeasible to have a bitcoin miner that uses javascript - that was how I did it initially, as a proof of concept, but it was so slow I abandoned it.</comment></comment></comment></comment></comment></comment>


Ask HN: What service would you pay $10k/y for - <AUTHOR> <comment><USER2> one that made me $100k/y</comment>


Life Cycle of a Silver Bullet (2003) [pdf] - <AUTHOR> http://www.crosstalkonline.org/storage/issue-archives/2003/200307/200307-Sheard.pdf

<comment><USER2> Great read, for those in a rush the morals alone are worth a glance</comment>