Huge thanks to Duo Security for hosting this talk and making it publicly available.
Everything related to work, aka, The Job.
Just been super busy lately. Flew to Austin for an on-site with my compatriots at Demand and attended AustinJS (my first) and met a bunch of interesting people. Good times.
Also, Chris & John over at Lost Art Press just flipped the switch on their new store, which I helped out with a bit. Definitely check it out! It’s built on Shopify, which is a pretty interesting platform. A bit limiting, but less so than any of the other hosted eComm solutions I’ve looked at.
Interactive Exploration of a Dynamical System from Bret Victor on Vimeo.
A user interface for exploring systems of differential equations. Every variable is shown as a plot; every parameter has a knob that can be adjusted in realtime. This ubiquitous visualization and in-context-manipulation helps the user develop a sense for how the parameters of the system influence its behavior.
Part of the Kill Math project: http://worrydream.com/KillMath
By Bret Victor: http://worrydream.com
Paul, who I seem to be linking to a lot lately, just put up a great piece on lessons learned in the trenches of startups over the past few years. I’ve been thinking about this a fair bit myself lately, so here’s my take.
Paul mentions this too, but it’s worth reinforcing. New things come along very very quickly in tech and you must be able to quickly learn enough about them to understand if they could be beneficial. Sometimes things come along that can severely reduce your cycle time while developing, things like Firebug, Dojo’s Dijit widget system, any server-side system that doesn’t require recompiles, remote editing, Skype, screen-sharing. Cutting your cycle time means you can either get more done total, or you can get enough done in a sane amount of time.
When you’re running the show, it can be very hard to keep learning and it’s easy to burn out. Everyone is coming to you for advice, everyone wants direction. It’s overwhelming. Everyone needs a decision and they need it now, so most of the time you’re going to fall back on what you know. You’ll stop learning and you’ll get burnt out.
I like to take a page from pro cyclists. When you’re riding a draft line, one person rarely leads the whole time, riders in the group takes turns up front. One guy will blow himself out keeping the train running for a bit, then fall back and take a rest, while the next person takes his place. You can do this in tech too. To me, making decisions is the most exhausting part of being in a startup. If you can, take turns making them. Let someone figure out direction and then let the rest of the team take it and run. Implementation is easy, deciding is hard.
Getting this to work requires a flat team and small egos, so this can be tricky to pull off. The team as a whole has to responsible for the direction and the product.
There’s a severe temptation to work all the time when you’re in a startup. Don’t do it. If you’re working 80 hours a week, I can pretty much guarantee that at least 40 of those hours are waste. Software requires intense concentration and no one can keep that up for that long without a break. That said, when you’re working, work. When you’re not working, don’t be at work. I believe (and have seen, over and over again) that a well-rested motivated person can get more done in 30 hours a week than a tired, unmotivated, burned-out person can get done in 80. Or 800.