carusooneliner

Interesting point but it's unnecessary and irrelevant to compare startup scaling to hunting animals. Why hunt? As though we hunt customers. And why animals? Who in their right mind would hunt any of these animals. Could use a better analogy to communicate the point. Startup scaling is an act of persuasion rather than condescension.

Assuming the startup has a product, your questions should center on impact and growth.

1. Impact: What problem are they solving for users? How are users using the product?

2. Growth: How quickly are they growing users, both free and paying? How are they acquiring users?

If the startup has a convincing answer for 1, they're working on something concrete. If they don't have convincing answer, probe deeper to find out if they have tangible plans for what they're going to create.

If they answer question 1 well, ask them 2. If they're growing users quickly (for instance, double digit % week over week), the startup is totally worth considering. If they're not growing quickly, ask them how they plan to grow. It's useful to know how they're acquiring users -- if they're spending money to get users, you should ask if it's scalable. If they're getting users without spending much money, great.

Growth can fix most problems in a startup -- it attracts users, investors and talent. If they aren't seeing growth, they should at least have a tangible impact with the users they have and plans for growth.

The 'you know' is a filler we use for traffic regulation. We use these fillers subconsciously to take micro breaks while speaking, to verbalize our thoughts and to indicate to the listener not to interrupt as we aren't done speaking yet.

Polish of delivery is just a nice to have feature, substance matters most of all.

I've attended public speaking courses, which tend to emphasize polish, but seeing some of the most effective speakers using fillers like 'ums' 'ahs' and 'you know' just goes to show polish doesn't matter all that much. Reality supersedes theory.

Nassim Taleb uses the Florence example to make the argument that Europe has more economic inequality compared to the US. He makes an interesting point that static measures of inequality like 'top 1% of population have xx% of the wealth' aren't that useful, a better indicator would be a dynamic measure that shows economic mobility, people going both up (new money) and down the ladder (bankruptcy). It looks like in Florence, families that climbed the ladder centuries ago never came down.

Taleb's essay on inequality: https://medium.com/incerto/inequality-and-skin-in-the-game-d...

Macro stats about install/uninstall rates of mobile apps are meaningless distractions when you're building a startup. Focus on what your audience needs and build that, whether it's a mobile app or a website.

I built a funny videos android app and website, android users discovered the app more easily and were more engaged with the app because they wanted to share videos from my app to whatsapp.

My more recent app is a web app because my audience are people doing work on their computer.

Audience guides the approach.

The best way to make your talk memorable is to focus on substance over style. Work hard on giving something new for the audience to chew on. Without interesting content the audience will tune out no matter how well you structure the talk.

Managers have to communicate both up and down while developers only need to communicate up. When I made the jump from a developer to a manager I had to learn how to properly communicate issues and risks to upper management. If there's an issue related to your team, you should be the first to escalate it. If management hears about your team's issues from a different source, you'll look bad. As manager, my number one job was staying on top of risks and issues, which meant getting up to date information from my reports and communicating the exact magnitude and priority of the risk/issue. If you develop a reputation as someone who can communicate and handle risks and issues well, that'll set you on good footing.

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.

Some explanation why it's so, courtesy this obituary of William Baumol: https://www.wsj.com/articles/baumol-diagnosed-the-disease-of... (paywall)

An excerpt from the article:

"Dr. Baumol’s insight in the 1960s was that costs inevitably rise fastest for things that are difficult to automate, including medical care, garbage collection and the live performance of a Mozart string quartet.

It came to him in the middle of the night.

“It was 4 in the morning,” he recalled in an oral history. “I suddenly woke up and said I know why those costs are going up! I got up, wrote down a few notes, and went to sleep again.” His theory became known as Baumol’s Cost Disease."

It was useful for us. What we got out of the 1-1s depended on our effort preparing for it -- how we communicated our value prop, how succinctly we described the problems we're having, etc.

My cofounder and I took this course last year. About the format of the course and efficacy:

- assigned mentor: we were assigned a former yc startup founder as mentor. the mentor had 30 minute 1-1s with us once a month and gave us useful advice on a wide range of matters.

- weekly homework: choose a single metric you'll measure through the duration of the course and report the metric and growth weekly. The metric could be DAUs, number of customers you've talked to, whatever. It's for you to figure the most important thing to focus on. We were running the startup in a bit of an ad hoc manner until startup school; weekly metric reporting helped focus our efforts in service of a single meaningful metric.

- group calls: we were lucky to be in a good peer group comprising about 30 startups of all kinds -- medical device to SaaS to consumer apps. There were weekly 1-2 hr calls chaired by the mentor. Before the meeting, the mentor sent out a questionnaire to fill out -- what's your product's value prop, what setbacks have you faced, etc. -- and startups would be randomly chosen to talk about their response to the questionnaire. Lot of time for Q&A. Our peer group is still in touch through a facebook group, where we occasionally share progress.

- Demo day: record a 2 minute video talking about our startup. This forced us come up with a concise statement to describe our startup and gave us a platform to showcase it.

If I had to summarize the benefit of startup school, it would be three things:

- quality mentorship

- diverse peer group

- forcing function for startup to hit goals

I'll venture to say it's probably one of the most valuable things an early stage startup could invest time on.

We've built a tool for this use case. It's called Outclip -- https://checkoutclip.com. You'll need to install the Outclip chrome extension (click on 'get chrome extension' on the above webpage) and after that it's a couple of clicks to start a screen recording. After you stop recording, within a few moments you'll have a link (e.g. https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K) you can share with others or use in a bug report. People can click the link to view the video.

We don't support gif creation, to do that you can download the video file (.mp4) from Outclip and use a service like https:///cloudconvert.com to convert to gif.

Some of my favorites organized by category:

Interviews on a broad bange of topics

  BBC: In Our Time

  Conversations with Tyler

  Hidden Forces

  Econtalk

  The Knowledge Project with Shane Parrish

Startups and Tech

  a16z

  Exponent

Finance and Economics

  Bloomberg Surveillance

  Bloomberg: Masters In Business

  Bloomberg: Odd Lots

General Topics

  ABC Big Ideas

  The Reith Lectures

Current Affairs

  BBC: The Briefing Room

Thinktanks

  Carnegie Council Audio Podcast

  World Class

Science Leakey Foundation: Origin Stories

  BBC: The Life Scientific

  BBC: The Curious Case of Rutherford and Fry

  ABC: All in the Mind

Bitcoin/Ethereum

  Epicenter

Indie

  Future thinkers

I'm really into taking notes -- both written and typed. The tactile part of taking notes helps me register things better and the notes themselves greatly help with recall. For written notes, I use Peter Pauper notebooks (https://www.peterpauper.com/) and Staedtler pens (https://www.staedtler.com/intl/en/products/products-for-colo...). I'm a sucker for good stationery. For typed notes, I use Google Keep on my phone and the Notes app on my Mac.

Lately I've been using screen recording to create video notes. I developed an app called Outclip (https://checkoutclip.com) with my buddy. Although the app is meant for a different purpose (bug reporting) I use it to screen record as I'm doing things (like configuring an AWS service for instance) in case I have to repeat the steps later.

Heavy note taker here. If I'm on my Mac, I use the Notes app. My favorite things about the app are real time sync between the desktop and phone app, easy checklists, text format options and the ability to inline embed images.

When I'm on my phone I use Google Keep. What I love about it are the colored background, tile view and checklists. I wish Keep allowed inline embedding of images.

Thanks for your words of encouragement! Very interesting to hear that you've come across an internal tool that did something similar.

1) Education of a Value Investor by Guy Spier

Autobiography of a guy who won an auction to have lunch with Warren Buffett for $600k and ended up becoming a successful, contrarian value investor. Fun read for contrarians out there.

2) Napoleon's Buttons by Penny Le Couteur, Jay Burreson

A look at world culture and historical events through the lens of chemistry.

3) Becoming Leonardo: An Exploded View of the Life of Leonardo da Vinci by Mike Lankford

A quirky and entertaining biography of Da Vinci.

Some more details on the landing page will be helpful. The features could use more explanation.

Curious, what's a use case for emailing an app?

Hi HN!

Tao (@taot) and I have built a tool that allows users to create screen recordings (via a chrome extension) for bug reports. I've been in the software industry more than a decade and a significant part of it has been dealing with bug reports -- writing reports and fixing bugs. Over time I've learnt that good bug reports are tedious to create, they require great detail on the steps to reproduce. In the last couple years through some projects I picked up building video tools and figured that screen recording might help alleviate that longstanding painpoint of mine -- creating good bug reports in the fastest way possible.

Having talked to users, we found that a lot of people are already using various offline screen recording tools like Quicktime, but they still require users to find a platform to upload the video to and lack collaboration features. Outclip aims to streamline the entire bug reporting process - from creation to submission, while allowing users to collaborate with each other. Hope you give it a try and find it useful. We look forward to your comments and feedback for improvement.

There's various kinds of documentation of differing granularity. Typically the high level documentation (coarse grained if you will) about architecture, requirements, etc. stays good over time but finer grain documentation (the kind I mentioned in my earlier comment -- data structures, order of function invocation, etc.) gets stale quickly because source code is constantly changing -- it gets refactored, plenty of bug fixes are put in, etc.

Reverse engineering is probably a loaded word, but in general digging in to understand the codebase helps you work more efficiently and avoid introducing bugs to the extent possible.

More broadly, reverse engineering a codebase is a critical software activity. If you can't reverse engineer a codebase you can't debug it or add to it. Working with an existing code base is pretty much a given, unless you're developer #1 on a startup. Your success as a software developer hinges on how well you can work with an existing codebase.

One less celebrated but very valuable approach to grasp a codebase is the way you document what you've learnt. While you can learn about a codebase through exploratory debugging (mentioned by someone on a separate comment) you have to persist that knowledge on "paper" in some way. My favorite ways to do that:

  - class diagrams (for static stuff like data structures, class relationships, etc.)

  - sequence diagrams (for dynamic stuff like which functions call which and data passed between them)

With good documentation for your own learning purposes, it'll become easier to start working on a codebase and especially when you context switch, it'll help you return to a codebase more easily.

Good to know, thank you.

It's going to change and get less hefty, we're looking into code splitting.

Haven't tested, I intend to make it possible. Thank you.

Agreed! We're working on prerendering some pages -- https://ssr.vuejs.org/#why-ssr .

Our site does't work with js disabled. Serious question: is it common for folks to disable js?

vue is used only for the web app. No js frameworks used in the chrome app.

I can vouch for the author's points on the good parts of vue.js.

We've built our single page application (SPA) web app with vue.js and are very pleased with the results -- https://checkoutclip.com. We were able overcome most of the stumbling blocks by looking up https://vuejs.org/v2/guide/, https://github.com/vuejs/vue/issues and https://forum.vuejs.org.

For server side rendered (SSR) pages, we're using nuxt.js, which is working out great as well. E.g. SSR page: https://video.checkoutclip.com/-LDQ5TtL_yywYCgUNb6K

I would recommend vue.js for anyone building their first SPA even if they don't have prior experience building one...it's easy to pick up.

The ones hitting my inbox:

* The Art of Data Science: https://tinyletter.com/art-of-data-science

* Week in Ethereum: http://www.weekinethereum.com/

* Benedict Evans: https://www.ben-evans.com/newsletter/

* Matt Levine's Money Stuff

I like this point in particular -- "Don't stress out too much about how valuable the things you're going deep on are." The general stance of people is to stick to the practical stuff -- knowledge or skills that you can use right away. But, it's important to have a long view and given enough time the impractical could turn into something practical. Serendipity is underrated, and in my experience the impractical stuff is what enables serendipity.