Brian Acton does not sound like the happy, fulfilled guy the stereotype of billionairedom would have you believe. He sounds like someone racked with regret, guilt, and torment over his decision to sell the most promising rebel base to the empire and then realizing that the empire would do what the empire does.
It’s so easy to dismiss such anguish with gifs of a man crying himself to sleep on a bed of money. But that’s as shallow as it is glib. Yes, Zuckerberg made Acton unfathomably rich. He also made him unfathomably small and impotent.
They say becoming a billionaire isn’t about the money, it’s about the power. If so, clearly this was a deal gone wrong. Acton became a billionaire by giving up all his power and handing it to Zuckerberg.
Who wouldn’t regret that? And yet, who wouldn’t be tempted by Facebook’s billions? Temptation is natural, it’s human. And so too is the rationalization that it was “an offer too good to refuse”, which seeks to absolve the taker of all guilt (and agency). And so too is the depths of despair when you deep down know you made a mistake.
That’s probably what makes the Forbes interview so painful to read. Acton is trying to make sense of his regret. Facebook is clearly on a path to turn what may well have been his life’s work into everything he built it not to be. And yet he has to rationalize his decision with utterly inauthentic excuses like how they’re “just being good business people, not bad people”. It’s like watching an early session of therapy play out awkwardly on a lit theater stage in front of an audience. You can’t help but cringe.
And in that cringe lies the appeal of Acton’s story. The utterly human temptation towards unfathomable wealth with the equally human suspicion that purpose is so much more than 10-digit bank balance.
The bastion of hope that was WhatsApp is gone. The “no ads, no games, no gimmicks” ethos will complete its transition into “all ads, all deceit, all extraction” soon enough. There’s a twenty-billion dollar hole in Facebook’s balance sheet that needs filling (with interest).
But rather than mourn that loss, we’d do well to use it to energize a new generation of entrepreneurs to avoid the trap that Acton fell into. To power the formation of a thousand new WhatsApps, intent on avoiding the faith of the fallen one.
We need to rewrite the cultural incentives around selling out. Acton predicament as the prototypical tragedy rather than victory. Replace envy with pity. Inspiration with rejection.
Let’s make it cool to turn down twenty billion dollars.
Basecamp is hiring a data analyst to help us make better decisions in all areas of the business. This includes everything from running A/B tests with statistical rigor to forecasting revenue for the year to tracing performance problems to analyzing usage patterns.
We’re looking for an experienced candidate who’s done similar work elsewhere (as you’ll be the only one at Basecamp with this specialty). But nobody hits the ground running. You won’t be able to answer every question immediately or know how all the systems work on day one — and we don’t expect you to.
We want strong, diverse teams built from different backgrounds, experiences and identities. We’re ready for the ongoing work that goes into building an inclusive, supportive place for you to do the best work of your career. That starts with working no more than 40 hours a week on a regular basis and getting 8+ hours of sleep a night. Our workplace and our benefits are designed to support a sustainable, healthy relationship with your work. (We literally just wrote a book on the topic!)
Today, our team works from 32 different cities spread across 6 countries. You can work from anywhere in the world, so long as you can design a normal working day with 4 hours or more overlap with Chicago time (CST/UTC-6). Nomads welcome.
About the job
Data informs almost everything we do at Basecamp, but we’re not a “data-driven organization” in the sense that data dictates decisions. Data is there to clear the head, but ultimately we drive the company with our heart.
This means the job isn’t about maximizing revenue or minimizing costs. Yes, we want to make money and we don’t want to be wasteful, but we also want to be kind, considerate, fair, flexible, and calm. You won’t be looking for ways to squeeze the last sour drop out of the lemon at Basecamp.
But you will help us make sense of the data. Establish the facts. Put a price on the choices we make. Help us understand the business, our software, and its customers.
Here are some examples of projects you might work on:
Analyzing the performance of a new marketing page. Track the cohort that signed up with this variation. Keep us patient for a statistically significant result. Compute the value of the change.
Identify when a brute-force login attack started, quarantine the IP addresses involved, work with technical operations to bolster our defenses, and write up the forensics report at the end.
Analyze our purchase records to locate transactions within states that are starting to collect sales tax on software like ours, work with our accounting company to document that sourcing method, and help evaluate whether we should buy or build a sales-tax engine.
Help product strategy analyze usage data to figure out whether a certain feature is working as intended, and if it is, who it’s important to.
Illuminate how we’re spending money on cloud computing today, and estimate how much we’ll be spending next year, given our growth patterns.
Answer the question: Has Basecamp 3 gotten slower in the last 6 months? Compare aggregate performance data to find the high-level trends, then help us pinpoint data tipping points or code regressions.
Answering these questions usually means formulating and running queries against our big data infrastructure. But it also means just doing the basic math, and ensuring we’re being statistically rigorous. You should be able to do both the technical and statistical work to answer questions like the ones in the examples above.
That’s a lot of different areas of responsibility! So you probably won’t be an expert in all of them, and that’s fine. A solid fundamental approach to analysis will pave the way.
And you’ll have plenty of help! Basecamp has a Security, Infrastructure, and Performance (SIP) group that’s responsible for managing the data pipeline, storage, and analytical interfaces. And a Operations (Ops) group that’s responsible for running our servers, network, and cloud services. It’s a plus if you’re able to help evolve these systems, but by no means a requirement.
In broad strokes, Managers of One thrive at Basecamp. We’re committed generalists, eager learners, conscientious workers, and curators of what’s essential. We’re quick to trust. We see things through. We’re kind to each other, look up to each other, and support each other. We achieve together. We are colleagues, here to do our best work.
You’ll probably have a degree that has exposed you to the rigor of the analytical work. Social scientists welcome. If you don’t have a degree in Theoretical Statistics, that’s not a showstopper — and it’s not what we’re looking for, anyway! We care about what you can do and how you do it, not about how you got there.
While we currently have an office in Chicago, you should be comfortable working remotely — most of the company does! This means that the bulk of our work is written, whether that be in the form of long reports or short chats. We value good writers.
We also value people who can take a stand yet commit even when they disagree. We subject ideas to rigorous debate, but all remember that we’re here for the same purpose: to do good work together. Charging the trust battery is part of the work.
About our pay & benefits
Our pay is within the top 10% of the industry, for the matched role and experience, based on San Francisco rates. This comes to a range at hiring of between $115,000 and $141,000, depending on your seniority. No matter where you live. Plus, with two years under your belt, you’ll participate in our profit-growth sharing program.
Our benefits at Basecamp are all about helping you lead a healthy life away from work. While we have a lovely office in Chicago, it’s not where you’ll find foosball tables constantly spinning, paid lunches, or any of the other trappings that companies use to lure employees into staying ever longer at work.
Work can wait. Our benefits include 4-day Summer Weeks, a yearly paid vacation, a one-month sabbatical every three years, and allowances for CSA, fitness, massage, and continuing education. We have top-shelf health insurance and a retirement plan with a generous match. See the full list.
How to apply
Please send an application tailored to this position that speaks to us. Introduce yourself as a colleague. Show us that future. As we said, we value great writers, so please do take your time with the application. Forget that generic resume. There’s no prize for being the first to submit!
We’d like to hear about how you’d approach some of the example projects outlined in the description about the job. Imagine you’re doing the work and walk us through your thinking.
All that being said, don’t send in a copy of War & Peace. We hire rarely at Basecamp, so when we do, there’s usually hundreds of applicants. Be kind to the people doing application triage and keep your cover letter to fewer than 800 words and the thoughts on project approaches below the same ceiling.
Go for it!
We are accepting applications for this position until Friday, October 12. We’ll let you know that we’ve received your application. After that, you probably shouldn’t expect to hear back from us until after the application deadline has passed. We want to give everyone a fair chance to apply and be evaluated.
As mentioned in the introduction, we’re eager to assemble a more diverse team. In fact, we’re not afraid of putting extra weight on candidates from underrepresented groups at Basecamp.
We can’t wait to hear from you!
(And again, imposters: We are too. Take heart. Step up.)
Managers used to be the object of envy for their leisurely workday. Maybe it included showing up half an hour later than the norm. Maybe it was that mid-day session of golf. Maybe it was skipping out early on a Friday.
In an age of back-breaking manual labor, it’s understandable how such disparity was cause for contempt. But for much of the economy, those days are over.
And yet it seems that far too many managers have internalized a deep sense of guilt from that era, so they desperately try to convince themselves and others just how hard they’re working! How worthy they are of their perched position on the hierarchy. How important their constant gaze and vigilant action is for both their company and the economy as a whole.
Thus is the sign of insecurity. When you deep down know that your 24/7 efforts just aren’t as important — or even desired! — as you’d like to believe, the quickest way to quell those nagging thoughts is to doubling down on the bravado. You don’t think I work? Oh, let me show you!!
Overcompensating like that may or may not be a conscious process. It’s probably easier when it’s not, but that doesn’t mean it’s easy in any psychological sense of the word. It’s hard work to dance with dissonance, cognitive or otherwise.
But to keep dancing like this, you need someone to provide the music, and the media has been all too willing for all too long. Fawning article after adoring hagiography. Look at this marvel of a monster manager! Up before anyone, to bed later than all! No vacation for 20 years! Bathroom breaks strategically picked to squeeze out 120-hour weeks! You should all be in awe of these super humans!
It’s time for the music to come to a halt. Stop lionizing toxic work habits as inspiration for new entrepreneurs and managers. Masochistic managers can continue their self-immolation for The Mission and The Company, but the rest of us and the media do not need to bang the tambourine while they do it. Because that shit already trickles down enough as it is. We don’t need to help it.
Instead we should look with pity on such a narrow existence. And frequently with the appropriate level of ridicule and scorn when the performative aspects of exhaustion get too over the top.
Let’s return to a time where being a harried mess of a human wasn’t the high managerial calling it is today. But let’s spread that luxury wider. Instead of turning everyone into the overworked peon of the early 20th century, we should be striving for everyone to be able to take off early on Friday for golf. Or enjoy that long lunch. Or pick when they come into the office.
Jason and I have have sought to become calm managers in a calm company for the better part of twenty years. It was our continued frustration with the endless exhaustion bravado that lead us to pen our latest book: It Doesn’t Have To Be Crazy At Work. It’s coming out October 2nd in the US.
Not because there aren’t people who actually enjoy working in an open office, there are. Quite a few, actually. But they’re in the distinct minority. The vast majority of people either dislike the open office or downright hate it. So how is that going to work, exactly?
By force, of course! Open offices are more appealing to people in management because they needn’t protect their own time and attention as much. Few managers have a schedule that allows, or even requires, long hours of uninterrupted time dedicated to a single creative pursuit.
And it’s these managers who are in charge of designing office layouts and signing leases. It’s also these managers who are responsible for booking photo shots of the FUN-FUN office, giving tours to investors, and fielding interviews with journalists. The open office is an excellent backdrop for all those activities.
What it isn’t, though, is conducive to better collaboration. A new study shows that the number one argument for the open office, increased collaboration, is bullshit. Converting traditional offices with walls and doors and separation into open-plan offices causes face-to-face interaction to plummet, not rise. People try to shield their attention (and sanity!) by retreating into headphone-clad cocoons, and instead rely on instant messaging or email to interact. D’oh!
My personal distaste for the open office goes back to the turn of the millennium when I worked at several tech companies with open-office layouts. It was a tyranny of interruption, distraction, and stress. The quality of my work suffered immensely, and so did my mental wellbeing. I feel quite comfortable stating that I would never have been able to create Ruby on Rails or any of my other software or creative achievements in such an environment.
One particular incident from those days stand out. We were already working from an open office, but at least I had a desk with a wall behind me, so there was a modicum of privacy and psychological safety. Then management decided that it would “look better” if we went to circular desks where several of us would be sitting with our backs to the hallway, so everyone walking past would be looking at our screen as they passed. It took a minor rebellion that lasted several weeks before management backed down from that horrendous idea.
Now, an open office is a continuum. The absolute worst is when you have dozens of people from all different departments in the same room. Sales, marketing, support, administration, programmers, designers, what have you. These departments have very different needs for quiet or concentration or use of phones or open conversation. Mixing them together is peak bad open office design.
Less bad — but still not great — is to again have dozens of people in the same room, but from largely the same functions or complimentary ones. Programmers, designers, writers together. The problem here is that even within the same domain, different people will have very different sensibilities about what’s a reasonable level of conversation or interruption. Remember, there’s a sizable minority of even creative people who enjoy the open office!
And probably least bad is small team rooms of fewer than ten people, preferably fewer than six. I’ve sat together with really small teams before and that’s been OK. Some people who don’t like the open office at all might even still enjoy this configuration.
None of this is new. There’s been an endlessstream of studies showing that the open-plan office is a source of stress, conflict, and turnover. And yet it’s still the default in tech. An almost unquestioned default. That’s a fucking travesty.
We’re squandering human health and potential on an epic scale by forcing the vast majority of people who dislike or hate the open office into that configuration. Their work deteriorates, their job satisfaction declines. And for what? Because a minority of people kinda like that configuration? Because it’ll look good in a few photos? Because it’ll impress strangers who visit the office? Get outta here.
The Basecamp office has a row of desks out in the open which we govern by Library Rules. We also have four private work rooms. Usually fewer than five people work from the office on any given day. The rest is remote. Want to learn more about how we try to keep it calm at Basecamp? Got a new book coming Oct 2, 2018 called It Doesn’t Have To Be Crazy At Work. Check it out.
I think I’ve cracked the obsession amongst much of the Silicon Valley set with compressing work life, sacrificing everything until the big exit, and running fast while breaking all the things: If you don’t plan to stick around, who cares how you leave the things behind?
This loot’n’leave strategy can justify much of what’s wrong with startup culture in the broad, below-the-titans cut (where reaching emperorhood brings its own justifications). Employees, customers, regulations, and, hell, even society at large, is much easier to screw over without regret if you don’t have to stick around for all that long. A few years of being the villain or the asshole is probably something a lot more people can imagine tolerating than if it was the condemnation of a whole career.
I can think of how the opposite dilemma frequently guides my decisions and opinions at Basecamp. If I’m going to be here for the next 10–20–30 years, what’s the right move that I won’t regret over the coming decades? How can we find ways to do right by more people, more of the time? How can we get to the root of what’s going wrong at our company or with our offering or with our technology? How can we fix them in such a way that we won’t have to worry about them all the time for the decades to come?
That perspective of permanence gives you a completely different outlook on your actions and your overall strategy. It’s like how most people end up treating a neighborhood they live in with a different kind of respect than one they’re just visiting. It’d be nice if everyone were just the best human they could be all the time, but it seems that most need some intrinsic incentive. Having to stick around is one such incentive.
How would things be different for you if you couldn’t just loot’n’leave?
Using SMS as a second security factor for signing into web applications is no longer recommended by security experts. Therefore we will be ending our homegrown SMS verification program on July 2nd, 2018, and switching to Google’s state-of-the-art Two-Factor Authentication (2FA) system.
Moving forward, if you want to secure your Basecamp account with 2FA, you’ll need to log into Basecamp using a Google Sign-In. You can use Google Sign-In with 2FA through their own authentication app, 1Password (we love those guys!), or the gold standard of a physical Yubikey.
How to switch to Google Sign-in with 2FA for Basecamp:
It’s never been more important to take serious precautions to guard your security online. Hacks are common, and failing to protect your online accounts with a second factor makes it so much easier to become a victim. We highly recommend switching to a Google Sign-In so you can take advantage of the protections 2FA provides.
Besides Basecamp, please take the time to get acquainted with two-factor authentication in general, and ensure that you have it turned on for as many services as you can. These days, almost everyone offers some way of adding a second factor. Read about doing it for iCloud, Dropbox, GitHub, Facebook, and Twitter.
Good security is like good backups. It’s a bit of a hassle to setup, but the regret you’ll feel if you don’t have it when you need it dwarfs that inconvenience. Don’t procrastinate.
It used to be a fundamental requirement that you learned an extensive amount of SQL before you were able to start working on database-backed applications. It was taken as self-evident that you needed to speak the native language of the database before you were qualified to use it. And better yet, you really ought to understand and care about your particular brand of database engine.
This is no longer so. That fact has snuck up upon us, but it’s none the less true — and that’s amazing.
Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).
The ORM was long derided by programmers as an unreliable, even harmful, aid of the lazy or the weak. Something Real Programmers shouldn’t expect to lean on, as it was likely to break down if not immediately, then certainly soon thereafter. And then you’d better know all your relational theory!
That’s the past.
Basecamp 3 has about 42,000 lines of code, and not a single fully formed SQL statement as part of application logic! It serves millions of people. It not only leans on the ORM abstraction, it hardly even thinks about it the vast majority of the time.
Do you know what else application programmers rarely need to think about any more either? Memory management and garbage collection. It used to be just as foundational to know your pointers, your destructors, your mallocs, and all the other conceptual overhead needed to deal with manually managing memory. Now it isn’t.
Our abstraction of SQL isn’t quite yet to the point of our abstraction of memory management, and certain frameworks and environments are further ahead than others, but it’s getting closer. The first version of Basecamp had a bunch of #find_by_sql calls, the latest have none. That’s progress.
It’s not that knowledge of SQL isn’t nice to have. It’s good to know a lot of things. Just like it’s helpful to have a strong conceptual model of how computers deal with memory management. It’s just that you no longer need to know these things to start making applications, and that’s a wonderful thing.
SQL, like memory management, is a concept you can unpack when you need to. Further down the line of your career. Then after you learn it, you can compress it back down again and spend more of your mental capacity on other things most of the time. I used to write SQL statements every day. Now maybe I do so once a month? Less? And that’s against a major application that’s reached a scale that most beginner apps never will.
Some programmers will scoff at this notion instinctively. That it’s simply irresponsible for programmers to start writing code until they know these historical fundamentals. I suppose it’s natural to think that all the hard work you spent learning the basic concepts — that indeed were required when you got started — should still be taught to all on day one. This is one of the key pitfalls of experience. Falling in love with the trials and tribulations you had to suffer, rather than rejoicing in the fact that the next generation doesn’t have to endure them.
The relational database is a glorious invention, but for most programmers it doesn’t need to be more than an appliance. Sure, take the time to learn how the drying tumbler machine works, it may well save you a service call to a specialized technician one day. But it’s hardly a requirement for living with such a device and getting your clothes dry.
The relegation to “appliance status” isn’t a dig, but an honor. It means we’ve finally made the technology and the abstraction so good that many, if not most, programmers don’t even have to think about it on a daily basis.
It also means it’s become a commodity. At Basecamp we happen to use MySQL, but to be honest, it’s basically only for historical and operational reasons. We could switch to PostgreSQL tomorrow, and I wouldn’t really give a damn. We have nothing in the application that relies on a particular brand of the database appliance.
Building stuff with computers means building on top of abstractions. CPUs, 1s and 0s, assembler, C compilers, database drivers, memory management, and a million other concepts are required to make our applications work. But as we progress as an industry, fewer people need to know all of them, and thank heavens for that.
It takes hard work to improve the conceptual compression algorithms that alleviate application programmers from having to worry about the underpinnings most of the time, but it’s incredibly rewarding work. The more effectively we compress the concepts of yesterday, the lower the barriers to entry become. And we need low barriers if we are to get more people started making applications.
SQL is perhaps the brightest example of conceptual compression over the past decade or so, but application work is full of other examples. And we need such conceptual compression more than ever to starve off specialization, and to preserve the power of individual generalists to make complete applications.
We’re currently living through an explosion of conceptual expansion and experimentation on the client-side in the web application world. That’s really exciting! Lots of new ideas and approaches churning rapidly. But it’s also needlessly intimidating in many ways. We don’t all need to spend hours or days learning how to configure build pipelines. Some day our leaky abstractions will be good enough that the conceptual compression will relegate such tooling to appliance status as well. That will be a good day.
You can’t learn everything. You can’t hold every concept fully expanded in your head. And moreover, you shouldn’t. As we compress formerly fundamental concepts, we make room for new, grander abstractions. These are the leaps of progress it’ll take to continue to make us more efficient and ultimately more effective.
But I get that it’s hard to break habits. Like the stereotype of an old person complaining about the price of gas or a gallon of milk because their frame of reference is anchored in a time past. Broad-based progress sometimes need that generational churn to really happen (and that’s not about your physical age, rather the years of experience).
Don’t be a fogey. Don’t fight the conceptual compression. Help make it happen.
In 2014, Highrise was spun off as a separate (but wholly-owned) company from Basecamp. Last year it celebrated its tenth anniversary in business. And this year it’s moving back in with Basecamp.
In some ways, it’s like it never left. While Highrise operated as an independent company under Nathan Kontny as CEO, Basecamp’s technical operations team continued to run servers and systems. Our support team still has a lot of people who used to answer customers when Highrise was a direct part of our suite of products. And almost all the members of the original product team for Highrise are still with Basecamp.
In other ways, this is indeed a change. Nathan Kontny had built a team of seven to lead new development, and they made a lot of improvements over the years. We want to thank the team for all their work and wish them all the very best.
Spinning Highrise off into a separate company with a separate team and CEO was always a bit of an experiment. While that experiment had a bunch of highlights, we ultimate decided it was time to try something different on both the product and business side after a thorough review was conducted some time ago.
For customers of Highrise, we at Basecamp are committed to supporting the product until the end of the internet! Highrise is home to over 10,000 customers who’ve trusted their data and their business to us. We are grateful for the trust and will continue to operate Highrise to the same high standards as Basecamp.
In short, this transition back to the Basecamp team is going to be nearly invisible to Highrise customers. Highrise is returning to the team that originally built the software, and it’s being operated on the technical side by the same team that always did so.
We’ve also begun exploring a range of new directions for the product’s future. We’re not yet ready to share where this is going, but will do so as soon as there’s a final path set.
Thank you to all our Highrise customers whether you’ve been with us for 10 days or 10 years! ❤️
I mean, in the widest possible sense, you are. Your mere existence is bound to change some of it somewhat. But that’s not what the unironic use of the phrase — WE ARE CHANGING THE WORLD — is meant to convey in Silicon Valley. They’re actually serious.
And look, some of them do end up changing the world. The world is different now that, say, Twitter is here, and the president of the United States can threaten nuclear war from the comfort of his golden shitcan. Seriously, that is different!
But let’s just say that most companies that actually end up changing the world rarely set out with that as the explicit mission. Twitter started as a way of telling your drinking buddies by SMS which dive bar you were hanging out at. Facebook started as a way for Zuckerberg to lure “dumb fucks” into giving him their private information. Modest beginnings!
The odds are that whatever you’re doing is never going to amount to any of the global significance that either Twitter or Facebook has bestowed upon the world. And thank god for that! If everyone in Silicon Valley who proclaimed to be on a mission to change the world actually did, our collective regret would be far deeper.
I like to peek beneath the surface of such delusions of grandeur. What on earth would prompt someone hawking life insurance — LIFE INSURANCE! — to posture, and quite possibly believe, that they’re Changing The World™ (or, as here, Healing The World)? Such delusions seem farcical on their face. An Onion piece a little too on the nose. But there we are.
My pet theory is that it’s really an existential cry for help. If you’re going to toil your life away on a literal treadmill with meetings at 9pm every night, you’re going to need to tell yourself something different than “I do this such that I can save privileged joggers and kale eaters 10% on life insurance”. Because such a mission just doesn’t warrant the sacrifices proposed.
But the cognitive dissonance between “I sell life insurance” and “I believe I’m healing the world” is so loud that it invites intervention. Someone to slap you across the face, shake you violently, and yell “snap out of it, mate! Snap out of it!!!”. The absurdity of the juxtaposition is the subconsciousness wailing in distress.
Usually the script isn’t this unbelievable, though. But it still follows the same arc. The idea that work isn’t worth living unless it entails the prospect of upsetting the world order. That work can’t just be about making the existing world a bit better, a bit smoother, a bit cheaper, or a bit more joyful. It has to rearrange the cosmos to warrant our time.
Partly, I blame Steve Jobs for this. I know it isn’t kind to speak ill of the dead, but when he asked Scully to take over as CEO of Apple, it was with this grand pitch: “Do you really want to sell sugar water for the rest of your life?”. And as many larger-than-life characters of history, his words have echoed through time, but also ended up distorted after having bounced around enough to be heard by the next generation.
It’s not that “selling sugar water” is a noble quest, and Apple really has changed the world, so Jobs was right. It was more the idea that we all need to think about changing the world all the time, lest our life is bereft of meaning.
For the vast majority of people on earth, including the vast majority of people working in Silicon Valley, existence will not be justified through their work alone. There will be no monuments, no valedictorian speeches, no Harvard Business School case studies. This isn’t cause for despair but for celebration!
Carrying the weight of Changing The World on your shoulders is a tremendous burden. Look at the characters who actually managed it. Most of them weren’t exactly living envious lives outside the scope of their work. Why are you so keen to follow in their footsteps?
I think more people in Silicon Valley would be better served by embracing the mundane. Do you know what, life insurance is a perfectly honorable thing to be selling on its own merits. And if you found a way that makes that transaction a little better for some small subset of companies or consumers, hell, good on you. It doesn’t have to be anymore glamorous than that.
Well, except that you raised $82 million off the hook that you were Changing The World with Big Data, and not on the more earthly promise that you were going to be a bit better at insurance brokering.
I have no illusions that my time in this world is going to be remembered through the ages. When it’s over, I’ll be so fortunate as to have left an impression on my friends, my family, and a few colleagues in the industry. And those impressions will fade quickly, so they aren’t even worth elevating much.
Look. You can’t outrun existential angst. Even if you put actual fucking treadmills in the middle of your office. Eventually the delusions are going to crack, and the more you’re invested in them, the harder you will shatter. And for what reasonable purpose?
Set out to do good work. Set out to be fair in your dealings with customers, employees, and reality. Leave a lasting impressions on the people you touch, and worry less (or not at all!) about changing the world. Chances are you won’t, and if you do, it’s not going to be because you said you would.
*HealthIQ did change its career page last night after the Twitter mob came carrying pitchforks. I think they deserve kudos for that. Although it remains to be seen whether it’s just a matter of changing appearances or actually provoked a real conversation within the company around its values and practices. They still seem oddly focused on banning critical internal feedback (no devil’s advocate allowed!), which is probably how they ended up with that terrible career page in the first place. No way everyone at the company read that and thought AWESOME! SHIP IT!
I’ve begun a new YouTube series called On Writing Software Well where I explore the real Basecamp codebase in search of interesting programming topics. It’s less “here’s how to do it” and more “here’s what I was thinking when we made this choice or took this direction”. And it’s intimately grounded in real, production code that’s been used by millions of people.
It’s partly a reaction to the endless debates we tend involve ourselves in as software writers without looking at real code. When you debate without code, you’re likely to get sucked into illusions of disagreement. You argue from your experiences with codebase A, I argue from my experiences with codebase B, and we clash because A isn’t B. That’s just silly.
Yet somehow arguments grounded in production code are rare. Few people seem willing to lift the curtain on such codebases, which is a damn shame. Because that’s where the real wisdom is buried. That’s where people have been forced to make actual trade-offs between competing patterns and practices. It’s those trade-offs and the circumstances around them that are valuable.
Programming arguments based in example code is most often stylized and idealized. It’s Platonic shadows on the cave wall. So easy to dig in and defend a technique when you don’t actually have to worry about guarding the flanks, setting up camp, and getting your supply lines in order. You know, like in real life.
So that’s my mission: To take you into the trenches and have you fight by my side in the battle against complexity and in the search for beautiful code.
Yes, the code is all Ruby and Rails, but the principles should travel reasonably well. So even if you don’t do Ruby on Rails, I’d be surprised if there wasn’t something to in there to pique your interest and rattle your convinctions.