Hacker Newsnew | past | comments | ask | show | jobs | submit | bphogan's commentslogin

I haven't met too many people who share this condition. Nice to meet you.


Same! Excluding members of my family, over the years I've only met a few people online who share it.


Where? Even thick ones are super expensive here. Over $250 a lens. I'd gladly pay $75 more for a significantly thinner lens. Point me in the right direction please.


Hey, author here. Thanks so much for the kind words! I love Hugo, and I wanted to give people a real-world tour of how to build something concrete with it.


I think you're missing my point. I have tons of MIT code out there, including a node.js project used by lots of companies. I don't care about people using my code for money because I open sourced it under a permissive license. So I'm not really objecting to that.

But what's bothering me about this is that it's not a small company doing this. It's a company that's got crazy amounts of cash, who has been trying to trade on a "we're nice now and we love open source" image in the last few years, now taking all the open source code and balling it up in a closed-source app they will charge us for.

I'd be fine if I got to use it for free, extend it to whatever editing platform I like through its open API, and it was a part of an open project.

But right now it looks like they'll charge, and that bugs me.


Hi HN. Didn't really expect to see this tweet make it here of all places. But that's cool.


Hi! I work on the "Write for DOnations" program at DigitalOcean and I want to thank you for your kind words. Your comment put a huge smile on our faces when we saw it. Glad to hear we were able to help you along your journey-that's what we're here to do.


in office or not, managers and teams should be monitoring contributions

Your version control system and ticketing system should be able to identify things like this.

If not, then nobody's minding the store, and that's why things aren't working. Not cos people are working remotely.


One thing that always gets lost is this:

Some humans do not think on their feet. They often need time to digest thoughts and new ideas. If you start observing this behavior, you will notice that an impromptu brain-storming session often results in a couple of people talking and many others observing.

It ends up being highly productive to the people talking, and very frustrating to those who are observing.

If you don't see this trend, your hiring practices may be optimized for finding only one type of person - extroverted people who can say things quickly.

Consider that you may be missing out on some very good ideas from people who aren't comfortable with quick context switches and immediate requests for feedback on ideas.


I saw them at least 3 times in the early 1980s in Wisconsin, but never since. I had an uncle who was very much into stargazing, so we'd often go out in the middle of the night to see meteor showers or the northern lights.


Sure, a live coding talk without preparation is gonna get people to check out. But honestly, if you throw up 45 minutes of slides you're gonna put an audience to sleep too.

According to audience feedback I've collected, my talks where I do a lot of live coding are engaging and fun. But that's cos I practice, and I put effort into the talk.

The key to a good presentation is to polish it and engage the audience. It's part teaching and part performance, and if you don't do both of those well, you'll lose people. Ask the audience questions to get them involved at key places. Practice so you know the timing of things.

If you just show slides or just live code, you're probably better off recording a youtube video, tweeting it out, and spend conferences enjoying the hallway track. :)


I just finished my first talk. I had not prepared half the slides necessary the day of, nor practiced anything but the intro. I thought it would take 45 minutes but I went over to 1hr30mins. Only 10 mins of that went into livecoding, which I rehearsed a dozen times.

I had one part where I intended to livecode a hello world app for threeJS. The whole code was printed in my hand, so I read it through and typed it out. 3 minutes later, it didn't compile and I could tell my audience was getting bored, so I bailed and showed the end result.

At the end of it, I was told it was one of the better talks given at my local meetups and it was more like 3 talks in one. So that was a huge compliment. I didn't catch anyone falling asleep or leaving either, so that's a good sign. I kept it engaging by asking a question every 10-15minutes to test if my audience knew anything about the topic, at the 20% 40% 60% 80% and 100% points of the talk. I tried to tailor analogies based off things my audience would know, or the responses I got during q/a.

This past weekend I went to a google cloud conference and watched a dozen presentations. Some were good and informative, others way too slow-paced and/or hard to read on screen. Quality varied greatly. None of the presenters asked questions during talk. I feel like there was a missed oppurtunity here

I personally think the 80/20 rule applies here - 80% slides, 20% livecoding + asking questions to the audience. It's boring listening to one person talk the entire time, no matter how engaging they might be. The best presenters takes feedback from the audience straight into code. Those are always fun.

As a side note, the livecoding should really happen somewhere halfway during the presentation. Ideally, everything should be recorded on video anyhow as a backup.

I think it's also important to know your environment as well. I have a natural tendency to want to walk around if possible while presenting, because standing still is boring for the audience. Sometimes, the projector is incredibly hard to read due to poor lightning as well. So it's important to consider what color your slides are going to be. Font sizes, transitions, content per slide, opacity for highlighted code sections, etc should also be considered. Pure black backgrounds aren't that great, personally a linear-gradient darkgrey is more inviting. Important transition points should use a different slide color.

Lastly, bringing tools with you the day of talk. Laser pointer, extension pole, pointing to the slides, your phone + notes linked to slides.com, hardware for recording, tripod, lapel mic, camera, backup chargers, a mouse, downloaded slide assets for offline viewing, ready to show-code on vscode, memorized shortcut keys and/or extensions to show what keys are pressed, printed notes, etc. There's a surprisingly huge checklist of items you should have available as a presenter, at least if you treat it seriously.

I wrote a post about my first talk and things I wish I did right. https://vincentntang.com/things-wish-knew-first-tech-talk/


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: