The easiest way to be disappointed is to expect others to act contrary to their self-interest. So really, we shouldn’t be disappointed to hear that Zuckerberg is enthusiastic about finding a way to appease Chinese censorship.
Facebook has already gobbled up an incredible 1.8 billion people and auctioned off their eyeballs and privacy with astounding economic success. If Zuckerberg can lock up another 1.4 billion Chinese, Facebook could feed the growth beast for at least several quarters!
It’s better for Facebook to be a part of enabling conversation, even if it’s not yet the full conversation.
Calling bowing to Chinese’s suppression of dissidents a “conversation” makes about as much sense as defending Thiel’s board seat as “diversity”.
But as I said, we shouldn’t be surprised. Of course Zuckerberg is going to spin an opportunity to double his user base as something that’s good for the world. That’s the thing about the new class of tech lords. Unlike the robber barons of old, they so desperately need to cast their greed and growth as a direct blessing to the world.
It reminded me of the Sinclair quote about a man and his paycheck. Repurposed for the age:
It’s difficult to get an entrepreneur to understand something, when their valuation depends on them not understanding it.
It seems painfully obvious that if Facebook arms the Chinese government with tools to suppress and hunt dissent, the slogan of “making the world more open and connected” is definitively a sham. But maybe this is just Facebook growing up and succumbing to the same market pressures as everyone else. Google dropped “Don’t Be Evil” a while back too.
It’s hard to have a backbone when it has to carry the weight of billions of dollars. At the very least it seems that several Facebook employees decided that their conscience was worth more and quit over having to work on this. Kudos to them.
A few years ago, Microsoft launched a Office 365 campaign with the slogan of #GetItDone. The basic premise was fitting more work into more places of your life. Well, not so much just fitting as shoving, cramming, and crunching it into every damn nook and cranny of your existence.
Like, why shouldn’t you check up on that Excel spreadsheet with the latest TPS numbers from the bathroom? Or take that conference call from your kid’s soccer game? Or fake presence with your spouse reviewing Word revisions while watch a show “together”?
Seriously. I’m not making these scenarios up. Microsoft’s campaign included all of them, complete with stats to alleviate the guilt of living such a shackled life. See, everyone is doing it! And Microsoft 365 makes it easier!!
Anyway, that was then. I kinda thought Microsoft would have wised up since. In 2013, you could at least excuse the company somewhat since the dancing buffoon was still in charge. But in 2016? No. No, you cannot excuse that any more.
Oh yeah, that’s just Microsoft putting a chipper fucking jingle to an ideal of work that’s literally presented as “14 hour days, 7 days a week, for decades”. Say what now? In what alternate universe is that an ideal you want to endorse?
Maybe that’s what the new Surface is all about. Perfect for sweatshops like Marvel to churn out yet another superhero rehash. Just so everyone else who’s working death shift after death shift for decades can escape the hell that is their life in make-believe fantasy. Swell.
But hey, THIS IS THE FUTURE OF WORK, right? The Surface Pro 4 is just here to enable the inevitable transition to this glorious paradise of productivity. Your life: 14 hours a day, 7 days a week, running Microsoft gear. Wouldn’t you want this too? Isn’t this aspirational? No. It’s death.
Sleep is good. Sleep works. Fuck companies and products that endorse skimping or skipping it as some kind of superpower. Fuck the Surface Pro 4’s marketing team. I seriously hope that this is just Microsoft temporarily slipping up, not a trend worthy of retracting forgiveness for.
We run on 6-week budgets for most major product work at Basecamp. It’s not that everything has to done in that time, but the self-imposed constraint makes us try. It’s not a deadline, mind you, but a budget. Deadlines are just excuses for death marches (fixed scope, fixed time). Screw deadlines.
Budgets, on the other hand, instruct us to keep quality high but scope variable. When making decisions on how to fit within budget, we decide to write less software. Fewer features, fewer settings, fewer wouldn’t-it-be-cool-if’s.
Nothing brings clarity to the discussion like “well, there’s only 3 weeks left: We can either do A and B, but not C. Or just C. Which would you rather?”. It moves the debates out of the we-really-ought-to realm. That’s the realm free of compromise and trade-offs. That’s the realm of bloated, late software.
This might make it sound easy to ship great software on time, but of course it’s not. Because like any good constraint, it hurts when its working. We have to kill our darlings all the time. Features, settings, considerations that we really think are important have to be cut constantly. When something you believe to be important doesn’t make it, it hurts.
But it’s also the right thing to do. We’ve proven that time and time again. Things we thought were terribly important in the heat of the argument frequently turns out not to matter at all. And above all, the discipline and the habit of shipping software every six weeks (or thereabouts) is worth some real sacrifice.
We’ve run other intervals in the past, and we sometimes do when circumstances warrant. Our standard used to be two months, but we’d still go a week or two over budget with that schedule. And it’s not clear that the software we shipped was appreciably better. Now we only run on 8-week cycles over the Summer when we work four days a week instead of five.
Shipping software on a budget rather than on a deadline or When It’s Done is a key component to how we’ve written and released so much with such a small team for so long. It’s probably been the most helpful general concept we’ve adopted from agile development. It doesn’t even require a big process, a backlog, or a stand-up meeting. But it will occasionally hurt. That’s when you know it’s working.
Great comedians bomb on new material all the time. That hilarious HBO special wasn’t just random, clever observations from the last month, but the product of years and years of filtered and practiced work. Thousands of hours and ideas boiled down into perfect timing to a continuous laugh fest. To get there, lots of not-funny shit had to be flushed.
The same goes for anyone trading in ideas. REWORK, the book about business that I cowrote with Jason Fried, has now sold roughly half a million copies. It’s less than half the length of a normal business book, but it still took about a decade to write. Thousands of blog posts made candidacy for inclusion, less than a hundred made the cut, and all of them were further refined and polished.
Being funny or insightful is as much a function of labor as it is ability. Much more so, actually. But that’s not how it looks from the outside. Most people just see the highlight reel and extrapolate that every idea coming out of that person must be a perfect pearl.
I remember sitting at a standup club in Copenhagen many years back. The comedian on stage was a veteran trying out some new material. Two bits bombed in a row, and some heckler followed up immediately with a taunt: “Say something funny!”. I’ve never seen a veteran decompose so quickly, so uncomfortably. He went on to spend the next 10 minutes trying to pin down the heckler.
But I get it. The pressure to be funny on command can crush even the strongest comedian. I get emails or meet people in person all the time who expect that I’ll have the perfect insightful answer or solution to their specific problem or domain. I’m sorry, I don’t.
This is part of why I’ve never personally been so eager to meet my intellectual heroes. All the best ideas from all the best people are already readily available in books, blogs, tweets, and talks. Whatever insight these people could provide for my particular situation would likely just be a watered-down version of some of that. Why bother with that? Take the pure goods and cut it yourself.
Most brilliant people aren’t brilliant most of the time.
That’s both a disappointment and a liberation. Disappointing when you hear someone you thought was a perfectly brilliant bulb being a bit dim about something. Liberating when you think that you too could be brilliant despite also being a bit dim much of the day.
Products, like people, sparkle best when the seed of a good idea has had the tender love and care over many years. We’ve been nurturing Basecamp for more than 13 years now. That’s basically an eternity in software. I’d love for you to take a look: It’s the saner, organized way to manage projects and communicate company-wide.
The company seems to be finding its groove again. Seems being the operative word. Lots of cool stuff that’s actually shipping, but whether it’ll make a dent in the world remains to be seen. Yet at least there’s some promise and optimism back. The ghosts of “cutting off the air supply” and IE6 have finally been vanquished.
Besides, the company just isn’t scary any more. Or tone-setting. Or, in many areas of past glory, even relevant. And perversely enough, that’s exactly what is setting it free to try harder, try again, and make an impression with a crowd that’s no longer dispositioned to reject the effort because Microsoft is the big bad wolf.
There’s no more wolf any more. It’s more like a puppy. Or a Golden Retriever at best. Nobody is afraid of Microsoft. So since they can’t rule the roost through fear, they’re trying the long route of — let’s not get ahead of ourselves and kid about LOVE — intrigue. And frankly some hope.
The two titans of integrated hardware and software are Apple and Google. And they’ve divided the spoils of the world just a little too neatly between them. It’s bizarre, but I actually want to see a resurgent, strong Microsoft. If for nothing else, to take the smug confidence of both titans down a peg.
I’m hoping real hard that either the Surface or the Hololens or SOMETHING out of Redmond is an honest-to-god big hit with the general public (outside of gaming). Not another cool demo or R&D plaything. But something that ships and in quantity.
I’ll be honest and say I held a grudge. For a long time. And that axe wasn’t getting buried until that hopping, jumping, dancing buffoon was out the door. But now that he is, and Gates is busy spending his loot curing the planet, do you know what? I can forgive.
Yes, I know they’ve been pining for it, so here it is: Microsoft, I forgive you. And I’m actually excited for the work you’re doing. ✌️
Would you believe that we actually have a Windows app for Basecamp 3? Yes, hell indeed did freeze over and Ballmer started flying.
We’ve been naughty at Basecamp. Since before the launch of version 3, almost a year ago, we’ve had an internal API for chatbots. This allowed us to pipe in GitHub commits and control our operations infrastructure from Campfire. It was a quick, hackish version, but it was enough to make it work — well, work for us.
Finally it’s time to atone and bring chatbots to everyone! You get chatbot, you get a chatbot, YOU GET A CHATBOT!!! Actually, you get the invitation to build a chatbot, I should say. Because we’re just publishing the API. You still have to make, bring, or adopt your own bot. But it’s really silly-easy-peasy.
There are two types of chatbots in Basecamp 3:
These are bots that people can talk to and get a response from. If you register a chatbot with the name of Tally, you can do !tally image donkey in any Campfire on the account, and the command URL registered for Tally will receive a JSON payload that has a key of command containing “image donkey”. Tally can then simply return a text/html 200 OK response to that POST, and the result will immediately be piped into Campfire.
If the command requires longer processing, you can grab the command_url from the payload, and send the response later (it’d be kind if you give some feedback, like “Processing command for shits and giggles” while you’re computing that donkey image, though!).
People can even start ping sessions with these bots:
These are bots that just send information to Campfire on their own without user interaction. They’re a great fit for things like continuous integration, statistical information, nagios alerts, and so on. These reporting bots do not have a command URL. When you add a reporting bot, you’ll be able to see a special tokenized URL that you can use to post to the Campfire as that bot. Each Campfire has their own URL.
Here’s Nagios reporting some hoopla and giving options to resolve:
Of course, an interactive chatbot can also act as a reporting chatbot and send information unprovoked.
But you can also manage the chatbots through the web UI. Here’s how:
The GitHub special!
Basecamp 3 ships with one, special built-in chatbot for GitHub. This bot makes it super easy to start piping in commits and other events from GitHub. Without creating your own code and operating your own bot.
You configure it on a per-Basecamp basis by clicking the GitHub link at the bottom of the Chatbots configuration screen, which takes you to this setup guide:
That’s it. Although I strongly encourage you to mind the chatbot noise. Don’t pipe a million reporting bots into a room that everyone is expected to pay attention to all the time. It’s just too much and it’ll make you sweat.
At Basecamp, we’ve actually set up entirely separate Basecamps for the robots most of the time. It’s very easy for chatbots to otherwise completely drown out humans in a busy room. And then skynet has pretty much won already, right? JOIN THE RESISTANCE!
The easiest thing in the world is to blame others when things go wrong. Analyzing every misstep, pointing out every flaw. There’s value to such analysis, but it’s incomplete. To round the circle, you have to do the harder work: Figure out how this is actually your fault.
This is obviously most pertinent if you’re responsible for others. “The buck stops here” has been a popular phrase for half a century because its a concept that needs reminding. It’s too easy otherwise for those at the top to lay blame upon those at the bottom. (Just look at the current Wells Fargo fraud!).
But it’s not just bosses who need a lesson in introspection. Everyone could do well to take one. If you’re part of a team or a process and something went wrong, of course it’s also your fault. You could have looked harder. You could have raised your doubts. You could have double checked.
There’s a system in place that caused this to happen, and you’re part of that system. Shit never happens in a vacuum. The vast majority of it is a predictable consequence of the way things are. Even if it was “just somebody’s fault”, others put or kept that person there.
The goal is to change the system, and to change the system, you have to change its parts. Have the courage to start with yourself. Absorb as much blame and responsibility you can for what happened, and hopefully some of that introspection will rub off on the other parts of the system. But even if it doesn’t, you’ve still done your bit to improve matters.
It’s your fault. Say it.
We’ve made many mistakes at Basecamp. Technical mistakes, people mistakes, product mistakes. I’ve always learnt the most from those when I assume I had the power to fix the system. Even if I didn’t know of it (I clearly should have!), even if I didn’t foresee it (I clearly could have!). Everything is at least partly my fault, a lot of it is probably mostly my fault, and some of it is obviously just my fault. I’d like to think that accepting all this is part reason why we’re still here.
The pace of progress have embarrassed many predictions of the future, but this specific example is still astounding. Three years ago is not that long!! In that time we went from “off by an order of magnitude” to “faster than most laptops”.
What’s even more important than the benchmarks, though, is how the consequences of this incredible leap of performance alters not only what’s possible on a phone, but what the common strategy should be.
That gap is gone. So I suppose that means the iPhone 7 is now officially certified for Serious Work™ 😜.
Using the mobile web as the core of our native apps was a gamble at that time. The institutional scar from Facebook abandoning HTML5 for pure native in 2012 was still fresh in the memory of most working at the intersection of the web and native. And to be fair, there were indeed some tradeoffs. Things clearly weren’t as fast as native, they were just fast enough.
That was an order of magnitude in performance ago! Now the performance of this strategy is not just fast enough to be passable, it’s more than plenty fast enough to be awesome. Or rather, a non-issue.
Granted, the performance of the iPhone 7 is a future that’s not yet widely distributed. Android in particular has a lot of catching up to do, but even at much less performance, they too are clearly within the habitable zone of performance. That place where other things just matter far more.
Now I’m not saying going hybrid carries no tradeoffs. There are still some interactions that occasionally feel less than native, and thus still lack that last tiny bit of polish. And there are clearly still applications, like high-end 3D games, that need every ounce of performance they can get. But with the performance afforded us today, the spectrum of applications that can be knock-it-out-of-the-park awesome using a hybrid web/native combination is very large indeed. And much, much larger than it was in 2013 when we forged ahead.
The productivity advantages of developing a multi-platform service using the hybrid approach are simply astounding. There’s simply no way we could have built Basecamp 3 in 18 months to cover the web for desktops, web for mobile, native iOS, native Android, and email without a hybrid and majestic monolith. Not without ballooning our development teams dramatically, anyway. That’s five platforms covering some 200+ separate screens of functionality.
This feels similar in many ways to the situation I outlined in Ruby has been fast enough for 13 years. When performance improves, it’s not just that the things we already do get faster. It’s that we can do new things, in new ways. Ways that would have seemed impossibly slow before. Ways that make people who had to do the hard work of fitting a full computer demo into 4Kb cry, but that none the less lifts the productivity of the masses.
It also reminds me of an anecdote from John Carmack, the legendary programmer of Doom and Quake. He talked about how when he was working on a new game, he had to program not for the performance of today, but for the performance of three years in the future, when his game would be finished. If he programmed for today, it would look dated when it launched. Doom and Quake always looked amazing because of this.
Think of that when starting a new app today. Are you programming for the state of the world as it looked in 2013? Or 2016? Or 2018? Program to where the performance puck is going to be, not where it’s been.
If you want to checkout how a hybrid app can feel, Basecamp 3 has some great examples in the iOS app and Android app. Both are sitting pretty with a 4.5/5.0 rating from hundreds and hundreds of ratings.
We recently launched a full API for Basecamp 3. That’s great for when you want to programmatically retrieve or post content. But what if you just want your program to be told when there’s something changes? Well, that required polling at regular intervals. Bah!
With our newly launched webhooks, you can instead have Basecamp call your program when things you care about change. Let’s say you want to resend all messages in the company-wide basecamp onto a mailing list. Just register a webhook about the “message” content type, and Basecamp will call a URL of your choice with all the details about the new message.
This new feature also allows integrators like Zapier to make more efficient, faster links between other apps. So even if you don’t write your own programs, you stand to benefit.
How to setup a new webhook
You can programmatically register new webhooks through the webhooks API. That’s great when you have a full Basecamp 3 integration that is already authenticated with OAuth. Then you can just add the webhooks you need automatically.
Truly learning a lesson is deeper than simply knowing the lesson. It’s possible to know a whole lot more than you’re capable of acting on with regularity. And it’s the act, not the mere knowing, that makes the difference.
When it comes to physical lessons, we instinctually know this. I know the steps it takes to do a kickflip ollie on a skateboard, but I still haven’t practiced nearly enough to pull it off. I wouldn’t expect to be able to do this without spending hours and hours of repetition.
Take the simple example of “I shouldn’t infer intention from action”. I know and believe this, but I still fail to practice it frequently.
Let’s say someone criticizes my work. I might infer that they’re just doing this to needle me needlessly because I criticized their work a few weeks back. That this really isn’t about the work, but it’s about retribution for an earlier skirmish.
That might be true. It is one of the possibilities. But it’s probably not that likely. It’s probably more likely that there’s simply a mistake in my work and the person spotted it. Unrelated to whatever discussion we had about their work weeks back.
But we humans love to jump to conclusions and validate our insecurities. That’s why we need lessons and coping mechanisms to do better. And that’s why it’s not just enough to know them, but to practice and be reminded all the time.
A strategy I’ve successfully used to remind myself in moments of need is to look for emotional smoke. If I’m getting upset about someone pointing out an error in my work, and it’s not because they’re being a dick about it, then that’s smoke. If you tune your emotional smoke detector to go off when your mood changes or your temperament flares, you give yourself a pause to contemplate which lesson you should be practicing.
The instinctual autopilot is great when the sky is blue and there’s no turbulence, but as soon as the clouds gather and the ride gets rocky, it’s time to grab the wheel with intent. So that’s what I try to do. Be mindful of emotional disturbances, hit pause when I spot them, and go through my current curriculum to find the lesson that clearly still needs attention.
The most important lessons are so because they’re hard. They’re the ones that take the most work to internalize, lest we forget in the moment and take action without their input. They are the ones we need to hear over and over again.