This week I am in St. Louis, visiting . As usual, we’ve been yelling at code together and streaming it (, ).
Oh oh oh before I get into the rest of this email, I just wanna say I’ve been working super hard on getting my new chatbots video ready for sale. It has a proper name now: Let’s Build a Chatbot in Ruby!
And I made a cover graphic!
And you can ! I’d love to get some more beta customers to give me feedback on it 😁
OK, shameless self-promotion out of the way…
Once I was employee #1 in a funded, incubated startup. The investor/advisors made sure that the founders had all their ducks in a row. Accounting! Payroll! Legal! Branding! Lean startup coaching! Office space! Networking!
And, of course, hiring staff, i.e., me. Which was nice for me, but probably a bit premature in retrospect.
It all seemed to keep the founders quite busy, right up to when the startup folded. I’m not going to claim that all this legitimacy theater was the cause of the company’s failure; ultimately it was a matter of insufficient product value. But I submit that the distractions didn’t help.
Since then, I’ve observed this same phenomenon from the middle distance, via friends and colleagues, at a lot of funded startups. I believe it is possible to give a startup just enough money to waste all of its’ time.
Having money leads to spending money, and spending money costs time. Spending other people’s money costs even more time. You have to perform due diligence to reassure yourself that you’re spending the money well, and the more money, the more time it costs.
Here’s the important bit: a lot of legitimacy theater is about managing risk. E.g. what if by failing to do a full legal review, we omit a line in a contract, and fail to give ourselves the option of suing an incompetent contractor?
But this omits consideration of the opportunity risk: what are we risking by dithering and expending cycles on dotting Is and crossing Ts? What if in the meantime, that contractor decides to move forward with a different opportunity?
My theory: if you look at the early history of of successfully bootstrapped (non–funded) companies, I suspect you’d find a lot of fudged procedures in the beginning. They made handshake deals instead of running everything through legal. They sorted the books out after the fact.
There’s the Way Things Are Done, and then there’s the way they actually happen.
This week I’ve been making a concerted effort to write some Actual Code (see those videos above), which means turning my travel machine into an Actual Coding Workstation.
For reasons I might go into in another newsletter, I’m committed to developing on Windows systems these days. Over the past year I’ve done enough Rails and Node development with native Windows to decide, once and for all, that it’s a non-starter. By “native”, I mean: using Node or Ruby interpreters + libraries compiled for Windows.
(These days it’s not so much a Microsoft/Windows problem as an ecosystem problem: any nontrivial Ruby or Node project has hundreds or thousands of third-party dependencies (packages, tools, etc.) and every five minutes some open-source developer out there introduces a Windows regression into the latest version of a gem or package. Not out of malice, mind you, but just because they don’t have access (or time) to test on a Windows box. Much of the time it’s not a simple regression, but an interaction between packages/tools that results in an error.)
So. Fully-native development is out. But! After a fair amount of time exercising it, I can happily say that Windows Subsystem for Linux (WSL) is fucking amazing and a real game-changer. We can now install Ubuntu, Arch, Fedora, etc. directly from the Windows Store, and in my experience it Just Works.
No recompiling, no container boot times, no massive memory usage, no SSHing, no setting up filesystem mappings, no port mapping. Just pop open a WSL terminal, install needed packages straight from distro repos, and code away, using a combination of native and Linux tools. There are some I/O efficiency issues when working with thousands of files (cough NPM cough), but the recently-announced promises to address this.
This week I took things a step further and installed so I could play with the new support, and it’s super cool. It transparently runs editor extensions on the remote side. Whether “remote” means over SSH, via Docker, or local WSL instance. This means that, for instance, a code-linting extension will automatically run using the target development environment, instead of behaving subtly differently because it’s running on the “client” side.
What I’m grateful for this week: I feel like I basically covered that above: WSL. Also, frequent flyer points that take me to see the people I love.
What meetup I’m going to this week: none, while I’m in St. Louis. But I can report that I had a nice time meeting folks and learning about WebPack at last week’s KnoxJS!
Let’s see how I did:
✔ Livestream with Jess, since I’ll be in St. Louis. Done! See above.
✔ Pre-sell and get started marketing the chatbots video. !
❌ Book a Rubber Duck Session or two. Nope. I had one potential session that I had to cancel because I got sick 😭
❌ Pick a first business metric to track and figure out how to track it. Nope.
❌ Book summer camp(s) for the kids Ugh, nope.
Book summer camps for the kids.
Start on getting 2018 non-biz numbers to my accountant
Write an anxiety-inducing email
Finalize Let’s Make a Chatbot in Ruby as a product, and prepare for launch.
That’s it for now. See you next week!