### Yos Riadyoptimize for learning

Work you didn’t sell is no better than the work you didn’t do.

The rest of us aren’t writing safety critical software, and as a result people aren’t willing to pay for that level of correctness.

So the result is that we write software with bugs in it, and we adopt a much cheaper software testing methodology: We ship it and see what happens. Inevitably some user will find a bug in our software. Probably many users will find many bugs in our software.

And this means that we’re turning our users into our QA department.

I think two of the most efficient ways to learn, to get information, are reading and talking to experts. So I spend quite a bit of time doing both of them.

In my own life, I found that whenever I wasn’t sure what to do next, I would go and learn a lot, read a lot, talk to experts. I don’t know how the human brain works but it’s almost magical: when you read enough or talk to enough experts, when you have enough inputs, new ideas start appearing. This seems to happen for a lot of people that I know.

When I think about what to do with my own life, what I want to work on, I look at two criteria. The first is whether it’s an opportunity to learn. Does the work on this project allow me to learn new and interesting and useful things? The second is the potential impact. The world has an infinite supply of interesting problems. The world also has an infinite supply of important problems. I would love for people to focus on the latter.

So one pattern of mistakes I’ve made in the past, hopefully much less now, is doing projects where you do step one, you do step two, you do step three, and then you realize that step four has been impossible all along. I talk about this specific example in the strategy innovation workshop I talked about. The lesson is to de-risk projects early.

People that count on willpower to do these things, it almost never works because willpower peters out. Instead I think people that are into creating habits – you know, studying every week, working hard every week – those are the most important. Those are the people most likely to succeed.

## Thinking

• Stackstorm’s DSL for describing how services talk to each other and their web-based graph editor is baller.
• Similar to Botsquad, there’s Bip.io and Dexter. Of course, the percursor to everyone in this space (including BotSquad) is Yahoo! Pipes.
• Thinking that one day I may be as prolific in open source as maxogden and substack gives me determination.
• Bitcoin Agents are fascinating. They’re essentially autonomous entities that survive by selling their services and buying their own server time.
• Software Engineer Skills Matrix
• One analogy I’ve found useful to explain how Artifical Neural Networks have an expensive pre-processing step and instantaneous classification time is muscle memory in sports.
• Turns out that WhatsApp uses Erlang at its core.
• AI assistants in the near future might look like homebrew but for general purpose, everyday tasks.
• Another ‘run functions on the cloud’ project is webtasks

## Listening

We tend to treat software projects like the release date is the end. We move on after that. But the release date is actually the beginning of the software’s life.

## Guitar

• When things calm down a bit, I plan to arrange some music for solo guitar.
• Arranged Once Upon a Time, the opening piece of Undertale.

#### 📬Get updates straight to your inbox!

Subscribe to my newsletter to make sure you don't miss anything.

Here's something you might be interested in...

Have you heard about the Serverless programming model? The Going Serverless book teaches you how to build scalable applications with the Serverless framework and AWS Lambda. You'll learn how to design, develop, test, deploy, and secure Serverless applications from planning to production.