Flash back to my first few years at Google: the road to success was clear. I’m handed a project, build it real nice-like, and collect warm belly rubs from the senior engineers.

Eventually I reached the esteemed level of senior engineer and I became responsible both for executing a vision and finding a good one in the first place.

All of a sudden, building hard things wasn’t enough. Hard things only counted when they made an impact.

At least for me, “finding what’s worth building” has proven a much stickier problem than the actual building itself. The majority of my career in the last 7 years – at Google, and eventually at startups – has hinged on that problem.

I’d be lying if I said that transition has been smooth.

Thankfully for everyone reading, I just watched an astonishingly excellent video from an indie video game developer named Jonas Tyroller about just this subject. In that video, he clearly lays out many of the truths I myself have had to learn through blood, sweat, and coffee. Watching that video felt as if he personally reached through the screen, caressed my cheek, and whispered “you’re a total idiot” to me-from-seven-years-ago.

Jonas is an independent game developer who’s been making games and releasing videos for 11 years. That means there’s full documentation of his journey going from making games that look like this:

To games that look like this:

Importantly for us, he’s not just talented at making games but also incredibly thoughtful about the way in which those games are made. (Note to the reader: these two facts are probably related.)

Fundamentally, his lesson is this: game development requires a good search algorithm. For the less computationally-minded, a search algorithm is just a plan you can follow to find the best option given your limited point of view. Looking for the deepest point in a lake? Want to find the best path from your house to the grocery store? Need to find the best fishing spot in town? These are all searches, and a search algorithm gives you a set of steps to find the best – or at least a very good – answer.

The key tension in search algorithms is that you’re weighing time spent exploring options versus time spent actually doing the damn thing: after all, any time spent scouting fishing spots is time spent not fishing.

Jonas has devoted an enormous amount of effort to “searching for fun games” and offers some genuinely terrific insights that are applicable both to his own domain of making games and my personal domain of “finding useful things to build”.

Go wide first, then narrow

Start by entering an “exploration phase” where you’re trying lots of very different ideas by building really crummy prototypes that test just a single thing. In this phase, your primary goal is to test very different hypotheses and gather samples about which seem most promising.

He uses the analogy of “finding the deepest spot in the lake” – if you only ever test one small area of the lake, why should you have any conviction you’re in the right spot? Instead, you want to make big jumps between your samples. Your early prototypes should be very different from each other.

Only once you’ve sampled lots of different ideas should you start to reduce the size of your jumps and start moving into real work on a single project.

Don’t get stuck at a local maximum

Local maxima are an inherent challenge in any search algorithm. What’s a local maximum? Imagine that you’re fishing in a nice pond, but there’s a river absolutely teeming with salmon just over the hill: you’re at a *local *maximum because anywhere you look from your current perspective is worse, but there’s a global maximum that’s far better out of your immediate field of vision.

The key suggestion that Jonas makes to avoid local maxima is to look for and frequently take opportunities to inexpensively make big jumps in your search, even after you’ve “chosen your pond”. As a concrete example from the “building companies” world, it may turn out that the chat interface you’ve built for your video game may be a much better business than the video game itself: this is more or less the story of Slack. It certainly took resources for the team to explore this route, but they weren’t starting from scratch and the exploration of applying their existing infrastructure to a new domain paid off. They had reached a local peak with their video game, but a much larger peak was just out of sight.

Make exploration cheap

You have two goals when exploring: be fast, and be sorta accurate. Speed is more important than accuracy.

The key to prototyping quickly is to only prototype one thing at a time. Prototypes must be built with the intention of being thrown away. The point that Jonas makes is that if you’re prototyping art (in my world, design/branding) and gameplay (functionality) at the same time, you’re not prototyping at all: you’re just building the stupid thing. That’s far too slow. Instead, prototype each axis independently.

The goal of making prototypes cheap isn’t to “reduce time spent exploring” – instead, cheaper prototypes allow you to explore many more potential futures, improving your search.

Lastly, keep a list of things that you’d like to explore. When there’s downtime and you have extra staffing, get a teammate to explore one of those ideas.

Spend more time exploring and less time iterating on bad ideas

The ultimate message is that people often spend far too much attention iterating on the little things and far too little on finding the bigger truths.

Prototype; learn; evaluate; repeat. That’s how you can find the best plot to build your castle.

(You can find a link to Jonas’s original video here.)

“I want to get in better shape, but the idea of getting up an hour earlier for the rest of my life sounds terrible.”

“I know I need to talk to my customers, but I don’t want to spend the rest of my life writing cold emails."

In your head, you can viscerally understand the sacrifices of doing the right thing. In contrast, the long-term results seem vague, theoretical, and distant. How do you muster the motivation to get started?

One useful mental trick I’ve found in this situation is something I call the ACE technique. There are three simple steps:

• Advice: imagine you’re giving advice to someone else in your position. What are the concrete next steps you’d recommend they take?
• Commit: identify how long each day you feel comfortable taking your own advice. I usually find 30 minutes or an hour is good. Some activities also have a natural “increment” that you can use as your commitment, like “I will send one cold email to a potential customer every day.”
• Exit ramp: give yourself an exit ramp by identifying a date when you’ll reevaluate your commitment. This date needs to be soon enough where the commitment feels like a sacrifice but doable. “I’ll get up early to exercise for two weeks: if I want to stop after that, it’s okay.” Put this date on your calendar so you don’t miss it.

If you’re anything like me, you’ll find it significantly easier to take the right next steps because you’re not committing to that decision forever.

This technique takes advantage of the fact that the idea of doing something is often scarier than the reality. By the time you reach your exit ramp, you often find yourself saying things like “I can’t do this forever, but I can do it for another two weeks.” Once you’ve stacked a few of those commitments together, you’ve started to build a habit so the activity requires less motivation to sustain.

If you reach your exit ramp and want to give up: that’s okay! A genuine willingness to reassess or postpone work towards your goal is what makes this technique work. Put another date on the calendar to reevaluate if you can fit the goal into your life.

There are times in life when it’s genuinely impossible to take steps towards long-term goals: you just had a baby, or your parents are sick and you need to take care of them, or you’re moving, or you’re wrapping up your thesis. During those times, take solace in the fact that you have a date on the calendar when you can reassess what feels right. When the time is right, this technique can help you take the right first steps.

The concern about whether Rails can scale sort of makes sense at Google scale. From the announcement of a new Google product to the announcement of its cancellation six months later, this theoretical Google product can bask in the big G’s brand halo and benefit from the hordes of bloggers eager to share about all things Google. That drives traffic to the product and it would sure be nice if it didn’t collapse under the weight of interested passerby. Maybe it’s true: Rails may not be a good fit for Google scale traffic.

Yes, Shopify and GitHub and Twitter all made Rails work at massive scales. However, each ran into their own scaling issues that required skilled engineers to solve. There’s no question that a web server running Rails won’t match the peak throughput of one running similar code written in Go or Rust.

With all that being said, I was surprised when I left Google to find that the common wisdom among Google engineers also extended to engineers at early-stage startups operating with vastly different needs. Unlike at Google, speed of implementation and the ability to focus on the needs of the business were both far more important than the ability to scale for hypergrowth at a moment’s notice.

I think “shiny new thing” syndrome is at least partially to blame: Rails is out of favor and people want to try something new.

However, I think people often start down this path without thinking through what lies ahead. With that in mind, I’ve assembled my own list of annoying questions:

The questions

1. What ORM are you planning to use to interact with your database?
2. What method of data exchange (e.g. REST, GraphQL) are you using to communicate between your frontend and backend?
3. If you’re planning to use GraphQL, how do you plan to address the N+1 query problem?
4. What library are you planning to use to translate your ORM records into your data exchange layer? How well maintained is that library?
5. How are you planning to store files in production?
6. How are you planning to store files locally during development?
7. How are you planning to send emails in production?
8. How are you planning to test email sends locally during development?
9. How are you planning to run jobs that need to happen at a specific time (e.g. a monthly billing job)?
10. How are you planning to run background jobs that need to happen off of the main web server thread?
11. What payment processor are you planning to use?
12. Do you need a library to integrate with that payment processor?
13. How do you plan to mock that payment processor for local testing and continuous integration?
14. How are you planning to handle authentication in production?
15. If you plan to use a third-party authentication provider in production (e.g. Auth0), are you planning to use that same authentication provider locally and in CI?
16. What are you planning to handle authorization (i.e. determining who can do what within your app and enforcing that)?
17. How will database schema migrations happen when schema changes occur?
18. How will data migrations happen when schema changes occur?
19. When your new code is deployed to a new environment (staging, production), how will you run those migrations automatically?
20. How do you check whether records in the database conform to business-logic constraints that can’t be modeled as database constraints?
21. How do you insert seed data for testing changes locally?
22. How do you write code for one-off tasks that need to be manually executed?
23. How do you validate new records being saved to your database?
24. How the heck are you planning to test all of this?
25. What hosting providers are you planning on using?

I don’t know about you, but I don’t want to think about most of that stuff. However, all of those questions merit technologically sound answers and I greatly appreciate that someone else has devoted years to answering them. These are not the exciting parts to me about a startup.

When you choose Rails as the backbone of your stack, you’re joining a community that has good answers to 80% of these problems. Stuff pretty much just works. When something does go wrong - and it will - you have the enormous benefit that someone has probably already succinctly described and solved your problem on the internet, only a Google search away.

In my experience, when you assemble your own tech stack – including at Google scale – the vast majority of your time gets sucked up by this 80% that you barely even have to think about with Rails. Despite this, the developer ergonomics of this self-assembled stack rarely match those offered by Rails. At least Google has the ability to throw teamfulls of handsomely paid engineers at the problem. You don’t.

Furthermore, instead of keeping a single dependency up to date, you’re committing to keep 15 different dependencies up to date and hope that the maintainer of each cares enough about your particular stack to bother testing on it. If they didn’t and something goes wrong, you’re in no man’s land. It can be frustratingly difficult to tell which piece isn’t playing along well with which other piece and “this other person has experienced this before but they’re using foo and we’re using bar, and does that matter?”

Look - I get the appeal of assembling your own stack. I’m not some Ruby zealot: I sort of hate it as a language. I think it’s bizarre and unintuitive and easy to make mistakes in. I wish it were statically typed and I wish I were able to use the same language on both the backend and frontend. But striking out on my own feels like trying to build a lawnmower from Legos instead of buying a Honda: possible, but not recommended.

So if you feel yourself drawn by the siren’s call of assembling your own stack, reread that list above and be honest with yourself about whether you can assemble the pieces together into something that’s as coherent as Rails is off the shelf. Maybe you should just use Rails.

Three days later, our designer sent me a Slack message: “Your dialog is missing a heading. Mind fixing that?”

This is a (true and totally representative) example of one of the sneakiest problems I see slow teams down. A mistake that should have taken me one minute to fix at the source will now probably take 30 minutes to fix by the time that I stash my current work, create a clean workspace, remember and reopen the relevant files, make the changes, send them out for code review, get approval, wait for tests to finish, and submit the changes. Worse yet, the same pattern plays out on a larger stage with weeks of wasted effort on solving the wrong problems entirely.

Toyota gained a pristine reputation for value and reliability in the 1980s by fixing this exact problem on the automotive assembly line. A key tenet of their manufacturing process is that mistakes are significantly faster to fix when you catch them early. Want to make it take two hours to tighten a bolt? Slap an engine and a hood on top of it. Want to churn out high-quality cars quickly? Figure out how to catch your mistake closer to its source.

For software, here are some relevant questions to chew on:

While coding (stop mistakes from reaching code review):

• Do engineers and product designers regularly meet before implementation to make sure the scope is clear?
• Do you have precommit hooks installed to help engineers remember any “quick but easy to forget” things to do before pushing their branch (e.g. formatting, linting, schema file generation)?
• Are coding conventions enforced through linter rules instead of code review?
• Do engineers regularly ask designers to their desk for quick, informal checks when they’re unsure about a particular design choice? (Sharing a local instance via ngrok is a good-but-not-perfect replacement for this.)

While reviewing code (stop mistakes from reaching QA):

• Do you have comprehensive integration tests that cover most of your app’s behaviors?
• Are your integration tests reliable?
• Do your integration tests need to pass in order for a branch to be merged?
• Are designers able to participate in the review process via review environments?
• Are common “don’t-forget-tos” enforced via integration tests (e.g. updating schema files, formatting code)?

While prioritizing features (stop mistakes from reaching coding):

• Has this feature been explicitly prioritized above other, still-unimplemented features?
• Is there a clear system to convey prioritization to engineers?
• Did engineers get to participate in scoping the issue?

By catching mistakes earlier, you can restore your focus to where it belongs: getting that perfect sip of Frappuccino.

It would probably be pretty valuable – it might allow you to buy a blanket to sleep under or a warm meal to keep you full for the night.

Imagine instead that you have $10 million in liquid assets and I hand you a $20 bill: how valuable is that same bill now?

Probably… not at all. That money likely doesn’t allow you to do anything that you couldn’t have done before.

This difference illustrates the fact that even though $20 may have the same absolute value in two different people’s pockets, it has a diminished marginal utility in the richer person’s pocket. “Marginal utility” just means “how much additional happiness can this dollar purchase?”

This same dynamic has interesting consequences for the incentives of investors and founders.

When interests align

One common reason that people start businesses is that they want to make money. Would-be founders can and certainly should have other reasons that they want to start a business, but I don’t think that Jeff Bezos or Mark Zuckerburg would have put in as much effort as they did without the potential of making a buck. Unfortunately, these businesses need a lot of money until they can turn a corner and start making a lot of money.

Thankfully, other groups want to make money too. Pension funds, endowments, and high net worth individuals already possess fistfulls of cash and sometimes have a fiduciary responsibility to grow that into entire armfulls of cash. They recognize that it’s lucrative to buy shares of new businesses being founded by promising teams. These entities give their money to venture capital firms and become “limited partners” of the venture capital fund. The VCs then seek out promising companies to invest in.

Importantly, the economics of venture capital rely on what’s known as the power law distribution. These funds are searching for whales: the single best investment in a VC’s portfolio is likely to outperform the rest of their portfolio combined.

Incentive-wise, if a VC doesn’t believe that an investment might be that single best result, they’re obligated not to make the investment.

Founders need money to start businesses: VCs need to invest that money to earn returns for their limited partners. This is the symbiotic relationship that makes the whole ecosystem spin.

When interests diverge

Let’s turn the table back around and look at things from the founder’s perspective.

If a founder is ultimately able to sell their business for $100k, that’s significantly better than selling it for $10k. $1 million is significantly better than $100k. $10 million is better than $1 million. $100 million may be better than $10 million… but it’s certainly not 10 times better. I’m skeptical that $1 billion buys you any happiness that $100 million can’t – and heck, it may buy you some problems.

Somewhere between $1 million and $100 million, there starts to be a very steep drop-off in terms of “what can I actually do with this money in order to make my life better?” In other words, the marginal utility of the money starts to quickly diminish. Somewhere in that range is a number where you don’t have to work again, you can pay off your mortgage, you can send your kids to whatever school you want, you can live in a big enough house in whatever neighborhood you want, and you can pursue future goals without concern for money.

Therein lies the tension: for the founder, selling a business for $5 million is a life-changing win. For venture capitalists, a promising portfolio company selling for $5 million is like lighting a lottery ticket on fire. This fact shapes both the types of businesses that VCs fund and the paths they encourage those businesses to take once funded.

To founders who spend money, that money has diminishing marginal utility. To investors who view money as a rate of return on an Excel sheet, money has no diminishing marginal utility.

Thinking about expected utility

Venture capitalists should treat companies in terms of expected value: “if I invest this dollar in this company, what can I expect it to turn into 5-10 years from now?”

Because of the diminishing marginal utility of money, founders should probably treat the opportunity cost of starting a company differently. “If I work hard for 12-18 months to get this company off the ground, how much happiness/utility can I expect that work to bring me in the future?” Whatever the distribution of possible outcomes is, their choices should factor in that having $100 million in the bank provides about as much utility as having $10 million in the bank.

The good news is that if you understand the fundamentals of customer research, idea validation, sales, and marketing, there’s a pretty good chance that you can find some software that should exist and build it if you can rope in a similarly capable friend or two. There are reasonable $5-10 million business-to-business software ideas laying around in plain sight that have a ~20% chance of success. Many of these ideas can either be discarded or bumped up to a ~50% chance of success with less than 40 hours of work of well-executed customer conversations (see: The Mom Test). Furthermore, many of these businesses can be easily sold once they’re off the ground.

This type of business is what the software bootstrapping world is all about: find an unglamorous but meaningful B2B SaaS idea that’s been overlooked and turn that idea into something great.

However, herein lies the rub: investors care about the expected value of the investment. Founders probably care about the expected utility of their efforts. Founders would probably prefer “real possibility of a life-changing outcome” over “infinitesimal chance of becoming the next Bill Gates”.

The gap

For bootstrapped businesses, there’s an undeniable and painful gap between “I have an idea that my initial conversations indicate could work” and “I have a functioning business”. Even if you have the necessary tools to get the business off the ground, it’ll likely be at least 12-18 months before that business is going to provide meaningful income.

I think this gap is one of the reasons that companies are often pushed towards the venture capital track: a small amount of startup capital is incredibly helpful to get off the ground, but once you’ve gotten on the investor-backed rocket it’s hard to eject.

In going down this route, the incentives of the business shift permanently towards “becoming huge”. You’ll be pressured to take on subsequent investment, attack larger-but-lower-likelihood-of-success problems and markets, and hire (and therefore manage) more. Because you’ll likely be pressured to hire more and move faster, chances are that you won’t have time to find the “right” employees that have an owner’s mindset about the business. Lower ownership employees lead to more time micromanaging and less time for strategic thinking.

Speaking from experience, “growing quickly” – particularly with lower ownership employees - skips right past the fun part of growing a business. You immediately have to spend more time thinking about “getting the right systems in place” rather than the probably-more-interesting questions like “where can I find more customers?”

Sprinkled on top is the fact that your company’s incentives inevitably shift towards pleasing investors over pleasing customers. How can I best share updates with my investors? What types of metrics are other companies sharing in their pitch decks these days? What investors should I try to bring in for my next round of funding? When should I raise, and what terms are fair? These are all hard questions that responsible venture-backed founders must think about that don’t have a damn thing to do with solving the core problems that provide value for customers.

That 12-18 month chasm of bootstrapped businesses is hard, but on the other side lies a company in which your attention can rest mostly on the inherent problems of the domain rather than the problems stemming from rapid artificial growth before product/market fit.

Speaking from experience: it’s incredibly hard to keep team morale and focus high in that time before a business finds its legs. On the off chance that you manage to hire a strong engineering team to build an MVP quickly, what do you do with them when you realize that your focus needs to shift outward towards talking with customers to better understand the domain? How do you keep them focused on the customer when the only “customers” are theoretical? I can’t say if “idle hands are the devil’s plaything”, but in my experience they’re certainly the plaything of company self-doubt – particularly by individuals who want to churn out steady, high-quality work. You can’t build or market or sell a product that you’re still trying to understand yourself. Navigating the time before product/market fit requires a kind of mental marathon that few people can or want to run.

In summary: I think venture capital is likely the only way to build a certain kind of massive business. However, there are lots of other types of businesses out there that require a lot lower risk tolerance, have a higher “expected utility” in terms of the money generated (if not absolute expected dollar returns, due to the power law distribution of returns), and frankly require a whole lot less bullshit.

The key to building these businesses is that you need to be more creative in how to bridge that pre-revenue gap: can you work nights and weekends? Can you raise funding based on early customer conversations from angel investors or friends and put sufficiently clear expectations on your future goals? Can you self-fund? These are worthwhile questions to ponder: venture capital certainly isn’t free capital and you should understand the cost before you accept it.

This ubiquity exists almost regardless of the context in which you’re building:

• New companies have to convince external customers they’re worth talking to, close the sale, hire new employees, and raise funds from investors
• A new internal team has to find new internal clients for their product, justify capital investment from executives, and request resources from other teams
• Builders looking for a new role have to move interviews along at a reasonable pace and negotiate their compensation

What I’ve learned the hard way is that the default speed of most negotiations is somewhere between “glacier” and “tectonic plate”. If you’re trying to get things done, this is a problem. The situation is also jarring in contrast with the years of education in which most professionals are trained, where natural deadlines are built into everything by way of semesters, exams, projects, and quizzes.

To prevent negotiations from yawning into infinity, you have to find real ways to introduce some urgency into the equation.

One technique that I’ve used to great effect in the past is something I like to call “FRESH urgency”. FRESH stands for Firm, Reasonable, External, Specific, and Hopeful.

Take the following email as an example:

Hi Joe,

Just wanted to follow up: I’m nearing the end of a few different interview slates and I’d hate to miss out on what might be a mutually great fit just because the timelines don’t work out.

Do you have any time tomorrow to talk about next steps?

Sarah

I’d like to highlight a few things about this email:

• It’s firm. It’s not overly apologetic: it’s just transparent and communicative.
• It’s reasonable. The suggested timeline is reasonable given the lightweight request. The heavier the request, the more notice is required.
• It cites an external factor as the reason for the urgency. By shifting responsibility to a pesky external factor as the reason for the urgency, it casts the sender in a much better light.
• It’s specific. The other party knows exactly what the sender is requesting.
• It’s hopeful and it focuses on the benefit to the other person. The message makes it clear that the sender is just trying to reach a mutually beneficial conclusion: they’re not just sending the email for themself.

There’s a very real question of “does the external factor have to be true?”. I try to stay mostly on the side of “yes”, but fully admit that the line is blurry.

There’s an adjacent question of “can the external factor exist for the sole reason of creating urgency”?” and here I say absolutely “yes”. Go ahead: schedule a caterer just to tell a customer that you need their response on attending by a specific date. Make up a business trip just so that you can say “I actually happen to be in San Francisco next week - want to meet up then?”. (Okay, that one’s a little bit of a white lie, but it passes muster for me.)

I had a conversation with a startup CTO this week who told me a (potentially apocryphal) story of the startup Zenefits. Supposedly when they were onboarding their first customers, they added an onboarding fee for their service for the express purpose of telling customers that they had an onboarding opening next week and could waive the fee if the sales lead was willing to take over that onboarding slot.

Often the person on the other end of the negotiation needs to be able to justify to others why your thing takes priority. By giving a reason to point at, you’re helping both sides get the deal over the finish line.

The most prominent lesson I took away was “nothing is real until the ink is dry”: the cash offer for the acquisition was withdrawn about three weeks after it was verbally made. Overnight, we went from adjusting spreadsheet numbers in search of an equitable split to discussing our favorite flavors of ramen.

My second biggest lesson was that I should never, ever work at or invest in a startup where I don’t trust the executives –  even if others urge that doing so might make me fistfuls of cash. There are too many opportunities for bad execs to burn just about anyone that touches their startup.

Thankfully, this wasn’t a concern this time around: I trust Curtis Wiklund (the founder of Channels) immensely and he repeatedly proved worthy of that trust. However, it seems worth sharing some ways I learned that you can be burned as an employee during an acquisition.

Acquisitions are typically announced in the press with headlines like “Dropbox sells for $50 billion”. The reality is more complicated.

For illustrative purposes, let’s consider a fictional HotStartup that raised $5M. Let’s say that this money was raised by selling 20% of the company in a single round of financing, placing the post-money valuation of the company at $25M.

Those cash investors are almost always given preferred shares in the company. This is in contrast with the common shares given to employees in the form of stock options.

Those preferred shares also come with a term known as a liquidation preference. This is a multiplier (usually somewhere from 1-2x) that specifies the return that preferred shareholders are entitled to receive before common shareholders receive any money. This is critical: in the event of an acquisition, investors’ cash is valued above employees’ work.

Preferred shareholders also reserve the right to convert their preferred stock to common stock, forgoing their liquidation preference. You can expect them to do so if it’s beneficial to them. If an investor invested $1M at a 1x liquidation preference and received 10% of the company, then they’ll keep their preferred shares with the liquidation preference unless the exit is for more than $10M, at which point they’ll convert their preferred stock to common and instead take 10% of the acquisition amount.

Particularly for small acquisitions, liquidation preferences play an outsized role in determining how much money flows through to common shareholders and therefore how much employees (the common shareholders) get paid. Compare the following two outcomes for our hypothetical acquisition with different liquidation preferences:

In the first example, a CEO with 50% of common shares rides away in a Ferrari. In the second, they ride away on their rusty Huffy bike.

Astute readers will notice that while a liquidation preference is meant to reduce risk for investors, it can also skew incentives in a way that hurts those same investors. In the above scenario where common shareholders receive no money from the acquisition, why on Earth would the executives from the company pursue that acquisition? The startup is sitting on an asset potentially worth millions of dollars with literally no incentive to sell that asset. Acquisitions require tons of work and stress: furthermore, they often require the executive team from HotStartup to work at the likely-not-very-entrepeneurial AcquiringCo for a year or more after the acquisition (via lock-up agreements).

The executives at HotStartup have two main ways to resolve this incentive misalignment:

• They can renegotiate the liquidation preference so that more of the acquisition proceeds flow through to common shareholders, of which they presumably own lots
• They can request a management pool be allocated to key executives responsible for the acquisition. This is basically a bonus pool paid out to the executives before any preferred or common shareholders are compensated for their stock.

Any agreement needs to be approved by the board (or investors if no board exists), but the board is often faced with a “take it or leave it” offer. This is particularly true at low exit prices where the company might otherwise just shut down.

Management pools may seem borderline ethical at first glance, but they can make a lot of sense. Much of our acquisition’s value hinged on the tech transfer, which in turn depended heavily on me as CTO. Because of this, I’d be required to sign a lock-up agreement. However, I didn’t hold nearly enough common shares to have the acquisition outweigh my “next best alternative” (going to work at another company). A management pool could help bring those two in line so that an acquisition was as beneficial to me as it was to the other stakeholders.

The last lever available in the offer is the team’s compensation package at AcquiringCo after the acquisition. An acquirer could save money by making a lowball offer for HotStartup with an overly-generous salary for the CEO once he’s at AcquiringCo. This is effectively bribing the decision maker to reduce the payout to the other stakeholders. In this situation, the burden is on the CEO to negotiate for a larger acquisition price for all shareholders, even knowing that it may mean less total compensation for themself.

To be clear: management pools, generous executive compensation packages, and renegotiation of liquidation preferences can all be useful tools in structuring acquisitions. The goal is to reach an overall package where everyone feels that the acquisition is worth the opportunity cost.

However, particularly in “middling outcome acquisitions”, there’s often not enough pie to go around for everyone to get fat. Because executives wield most of the decision-making power in these negotiations, they’ll have every opportunity to push the acquisition in extreme directions that benefit themselves and hurt employees.

Specifically, they can:

• Negotiate with the board for an outsized management pool instead of a lower liquidation preference knowing that the management pool impacts their compensation disproportionately (hurting employees)
• Negotiate with AcquiringCo for a lower acquisition price in exchange for a higher compensation package post-acquisition (hurting both investors and employees)

In these acquisitions, liquidation preferences play an outsized role. Because of this, it’s worth asking about the liquidation preferences for current investors when joining a startup. Furthermore, it’s critical when joining a startup that you have faith in the leadership team: upon an exit, they’ll have every opportunity to burn you.

If you’re interested in learning more, I’d heartily recommend reading The Holloway Guide to Equity Compensation. The Long-Term Stock Exchange also has an excellent article on liquidation preferences. I read most of the former when I first joined Channels and what I learned proved invaluable over the past few months.

In my opinion, this is because most people confuse “marketing” with “marketing done poorly”. The word “marketing” brings to mind a flood of Facebook invites to their high school acquaintance’s essential oils party.

In contrast, I’ve come to think of marketing a little like grease on a machine: if you can see it oozing out, you’re probably using it wrong.

To reset, let’s flip the narrative a bit: as an engineer, your job is to build something that others can benefit from. Along the way, you probably learn things that others can benefit from. Unfortunately, approximately 100% of the population doesn’t know about all the cool things you’ve done and learned at the end of your work day.

Regardless of how amazing that creation or lesson is, in many cases it doesn’t matter unless you can convince other people that it matters. Marketing is just the process of finding the people that would find your work useful and convincing them of its usefulness.

Consider: the Instagram cofounders could have created the exact same app and it would have faded into irrelevance had they not had a real strategy to convince people to try it.

Marketing is frankly an uphill battle. People are bombarded with junk every day and their brain is hardwired to filter out 99.9% of it. Because of that, marketing requires a deep empathy for your audience and understanding how you fit into their lives rather than the other way around.

Do you find lots of advertising annoying? Do you get pissed off when people spam self-promotional links on LinkedIn or Reddit? That’s great! That means that you’re highly sensitive to bad marketing.

In my experience, this is where most engineers’ relationship with marketing ends. “Ugh,” they say. “Marketers are the worst.” Instead of digging deeper, they speak of their work only in hushed tones to their coworkers and expect it to speak for itself, despite its lack of lips.

This is a mistake: people need to know your thing exists to find it useful. Instead of giving up, start paying closer attention to what things have wormed their way into your brain that you consider useful and how you became aware of those things. Through doing so, you can build a catalog of “brain hacks to get people to care about what you’re doing”. That catalog? That’s your catalog of marketing techniques.

Did you listen to a presentation at a conference on all the ways someone attempted to solve a particular problem before they got it right, and what they learned? They were marketing.

Did you get an email from someone asking if you could discuss a particular problem you’re facing that they’re trying to solve? They were marketing.

Did someone reply to a forum post you made with a detailed answer and a link to an even more detailed answer offsite? They were marketing.

All of these people were marketing because doing so greatly amplifies the reach - and therefore impact - of their work.

I see that skeptical look on your face. “But Charlie!”, you say. “I work on the internals of a product that already has customers! People benefit from the work that I do without me having to market it!”

That may be true, but then marketing becomes critical in other ways. Almost by definition, this type of work can easily go unnoticed by others in your organization. The more visible your work is to others by default, the less you have to work at marketing. But that implies a converse: the less visible your work is to others by default, the more important it is for you to market that work.

If you work on the guts of something, then you should probably be marketing the bejeezus out of your work internally. Then everyone will realize that you deserve that promotion instead of Jim Bob, who watches three hours of YouTube at his desk every day but boy is his feature visible in the product.

Still convinced marketing is fluff? In that case, I’ll pose this question: do you think that Stack Overflow became a success because it was such a great product? Don’t get me wrong: it was a good product, and it got a lot right over the alternatives at the time. However, it’s also no coincidence that the two founders of Stack Overflow were two of the most popular software bloggers at the time making a product for programmers. They both had incredible marketing channels for the target audience of their startup. There was incredible founder/market fit.

Furthermore, how do you find Stack Overflow answers most of the time? If you’re like me, the answer is “It’s one of the first few results on Google”. Stack Overflow is excellent at SEO and helping people find the answer to a problem they’re actively trying to solve. In fact, some of their core community policies exist explicitly to improve SEO marketing: they encourage duplicate questions with different wordings because it covers a wider array of phrases that someone might use to search for an answer.

So how do you market effectively?

I find the following questions to be really helpful when putting together a marketing strategy:

1. Who are you trying to make aware of your work?
2. Where do those people gather?
3. What are the norms about acceptable ways to communicate in that gathering place?
4. What do you want them to know about your work?
5. What is your target audience trying to achieve? Why should they care?
6. How can you demonstrate value immediately?
7. Where’s the overlap?

To risk pandering to my fellow engineers: you know that part of Star Wars where Luke is flying his X-wing through the trench on the Death Star? That’s like marketing: there are a million ways for it to go wrong and success is when your message just sneaks in that 2 meter wide exhaust port. One meter off to the left or right and people’s marketing alarms sound and they think “Ugh! I hate marketers.”

These may seem like really basic questions to ask, and they are! But almost all people still get them wrong. Here are a few examples of marketing gone awry in various ways.

Someone might launch their new health startup targeted at doctors on ProductHunt, despite no doctor ever having visited ProductHunt in the history of ever. This is a mistake as old as time: confusing where you hang out with where your target audience hangs out. Remember: who are you trying to make aware of you, and where do those people gather?

Someone might post their new startup launch newsletter on the /r/startups subreddit with a title of “Check out my new newsletter, Launched With Laura!” You’re getting closer now: you’re at least in the same neighborhood as your target audience. Unfortunately, while your newsletter may rock, your marketing skills still need improving: people want to open threads that bring them value, not threads that bring you subscribers. Remember: what are the norms about acceptable ways to communicate in that gathering place? How can you demonstrate value immediately?

Now suppose that Launched With Laura is a newsletter about the history of successful software-as-a-service launches and someone asks a question on the /r/startups subreddit about “How do I launch this product I’ve built?”. You could respond with a comment to this thread saying:

It sounds like you would really enjoy my newsletter, Launched With Laura! Subscribe here.

This is approaching good marketing: you’ve nailed lots of things and may very well get some new subscribers out of your reply, but in my experience you won’t get many. You’re asking someone who lacks proof of your genius to fill out a form – a tough sell. But you’re getting much, much closer!

Instead, suppose that you reply with the following:

Based on my own experience, the best way to develop a launch strategy is to learn from the successes (and failures) of other companies. For example, I know that ExampleX shared a similar target customer with you and found a lot of success by cold emailing the Chief Revenue Officers of hospital systems and including a forecast of the expected integration ROI.

I actually did a case study on ExampleX’s launch a few weeks ago on my newsletter, Launched With Laura: you can get access to that (and 50+ others) if you subscribe here.

Boom! That’s marketing. (Specifically, this “provide-utility-without-clicking-link” technique is often called “zero click marketing”.) You identified your target audience, what they’re trying to achieve, what value you can offer, and how you can show that value immediately. That’s extremely targeted and I would frankly be shocked if you didn’t get a subscriber out of that – your marketing efforts made it through the Death Star exhaust port.

“Bah”, you think, “replying to a single person is so unambitious! Why bother?”

Well, it’s important to consider that there are far more lurkers reading threads than there are people asking questions. For these public one-on-one interactions, the audience is almost always bigger than it seems and you often get bonus authenticity points with others for caring enough to respond thoughtfully to a 1:1 question.

There’s some “marketing technique spectrum” that exists with one side containing a huge audience with wildly differing interests (think: the Superbowl) and the other side containing tiny audiences with very similar and predictable interests (think: Laura’s Reddit thread). I find that engineers almost always err too far on the side of large audiences. Unwittingly, they choose a 0% conversion rate of a large audience over a 30% conversion rate of a much smaller audience. My advice is the same as the inimitable Paul Graham: “do things that don’t scale” and hold off on trying to do outreach to big audiences until you’ve first nailed your messaging at the tiniest of scales, like a single comment thread. You might be surprised at how much can learn from and grow your audience.

For the sake of your mental wellbeing and marketing stamina, my parting wisdom is to track and celebrate the small wins when it comes to marketing. I think that we’re all so used to seeing the staggering numbers associated with late-stage exponential growth that we’re conditioned to believe that anything less than massive, instantaneous success is a failure. I push hard in the opposite direction: I’ve set up Zapier to send me a text message every time my blog gets a new subscriber and it genuinely thrills me. Whatever a “sale” means for your thing - a new subscriber, a new demo request, a view of your presentation - I’d encourage you to find creative ways to amplify the feeling of that win.

Good luck out there Red 5: give ‘em hell.

• No one’s ever intimidated by you because your next embarrassment is right around the corner
• By starting out mediocre at so many things, you notice similarities in how to improve – at least up until somewhere in the middle of the bell curve

One striking similarity is how many skills have a saying among the experts akin to “the key to drawing well is learning to see well.” I’ve heard variations of this phrase used for chess, cooking, and programming.

The root of these sayings is that humans are just awful at debugging why things really go wrong. Unfortunately, this ability is absolutely crucial to improving at things. In my experience, the most pernicious bias at play is the tendency to immediately blame failures on the most proximal (closest) cause of a problem rather than searching harder for the most important cause. For example, a chess player may blame a blunder on a careless tactical mistake when in reality their poor opening led them into a situation in which some mistake was inevitable. I’ve written about my own experience with this phenomenon in Rocket League and Root Cause Misattribution.

To get better at debugging failures, you need to develop a better understanding of what’s happening under the scenes, thereby separating the inputs of the activity from the outputs - a win or a loss, a good painting or a bad one. Without this understanding, your only validation that you performed well is success, which is a regrettably noisy and lagging indicator. It’s entirely possible to play a good game of chess that you lose. It’s also possible to play a bad game of chess that you win. Success is an even worse measure for endeavors like engineering, where a result may arrive only after months, years, or decades of work. To improve rapidly, you need to consciously seek out shorter feedback cycles.

Across domains, I’ve found that experts almost always find these shorter feedback cycles by breaking the larger skill down into “minigames” with clearer objectives. This is what I call “vision”: being able to peek under the surface of an activity to recognize the minigames being played and when each is applicable. Improving your vision allows you to identify which minigame your ultimate failure can be attributed to and focus your improvement efforts.

A decent start to a list of “minigames” for an amateur sketcher might be:

• Do I have the right shapes for the items in the scene?
• Are these items positioned correctly relative to another?
• Are the items’ relative sizes correct?

In my experience, “reaching the next level” in a skill usually means adding one or two new minigames to your arsenal while making only modest improvements in minigames that you’re already aware of. In contrast, I find that most people think that the path to improvement lies solely in building upon minigames they know. This difference can lead to significant frustration because “what got you here won’t get you there”.

I regularly see junior software engineers make this mistake: after landing their first “real” job, they’ll seek to reach the next level by trying to learn how to solve trivial Leetcode problems faster. They’d almost always be better served by “going deep” and closing some foundational gap they see between themselves and the more effective senior engineers. The number of those gaps may seem daunting, but the gains compound. Leetcode may have gotten you the job, but it almost certainly won’t help you make more of an impact in your role.

In my opinion, identifying which minigames you should be focusing on at which skill level is the most important value a good coach can provide. Whenever you fail, you almost certainly could have done something better along some axis that you already know about: you could have worked another hour per day or been more (or less) responsive to email. You could have played a better chess opening or seen some tactic. You’re human. Furthermore, if you were failing, chances are you were under some amount of pressure that caused you to make tradeoffs.

A good coach or mentor can provide the superior vision to help you find the ultimate cause of your failure rather than just the most proximal one. Furthermore, that coach can help you identify which minigame you need to improve at and find good resources to do so.

When seeking out a good coach, it’s not sufficient to find someone that’s an expert at the activity. In the chess world, Magnus Carlsen may be the world chess champion but he seems like he’d be a pretty miserable chess coach: he’s notoriously unenthused about explaining his reasoning to others. John Bartholomew, on the other hand, is a very-good-but-not-great chess streamer who’s gifted at explaining how he makes decisions each step along the way. Given the choice between each player as a coach, I’d choose John every time.

Recently, many of the best “coaches” I’ve found are actually content creators: listening to them is like eavesdropping on a conversation between people far, far smarter than I am. The Acquired podcast has taught me more about “big tech strategy” and venture capital than working in big tech ever did. Rob Walling’s Startups Like the Rest of Us has proven similarly useful for learning how to launch bootstrapped businesses. John Bartholomew was a wonderful chess coach even though I just watched his YouTube channel. This is a huge benefit to the information age: you can get access to some of the best coaches in the world without changing out of your sweatpants.

Given the number of successful professionals that credit a mentor they actually talk to for their success, I wish I had better advice about how to find one. I’ve struggled with this myself, but I suspect the right person would be invaluable. Until that time, I’ll just remain thankful that we live in the age of YouTube and podcasts.

Early on, we identified the “main page” of our application that most prospective customers would care about when they saw our product. However, there were also the hundred other features and screens that were begrudgingly necessary but no one would think twice about: ways for users to change their email address and password, workflows for customers to create new posts on that main page, workflows to edit existing posts, notification systems to alert subscribers of new posts. We put in the time to build the main thing well, and then we spent at least as much time building the small annoying things.

We use a tool called FullStory that allows us to see how users interact with our site. Every time we sent the demo to a customer, they looked at the “main page” for about 20 seconds. Then they closed the demo. They’d shoot back an email along the lines of, “This looks great! Let’s meet next Tuesday to talk more.”

During later conversations with those prospective customers, we’d discover that they were making the entire purchase decision based on the sliver of the product they saw. They just assumed that the rest existed and was built to the same quality bar.

The lesson was stark: customers will extrapolate from the quality of what they can see.

If you build a big crappy product, people will assume you’re capable of building a bigger crappy product. If you build a small excellent product, they’ll assume you’re capable of building a bigger excellent product and may want to join you on the ride. People are constantly bombarded with new things trying to enter their lives: something needs to be remarkably good to warrant a try. The way to move fast but still pass that filter is to build something remarkably good and remarkably small.

There’s a reason that people can’t wait for the next Pixar movie, but mostly ignore 95% of other movies that come out: Pixar’s output volume is low, but their work is remarkable and consistently worth paying attention to. Similarly, when building a product, you should ask yourself: “What can I cut so that I can make the important parts remarkably good?”

In that spirit, it’s critical to identify:

• Who makes the decision about whether to use this product?
• What parts will they be looking at when making that decision?
• How can I avoid building as much of the other stuff as possible?

Startups need to move quickly to find customers and prioritization is the single most important part to moving quickly.

A few nuggets to help with this prioritization:

• Build an FAQ page with entries for how to do all of the things you didn’t build. For each entry, just say “Reach out to support@example.com for help doing this.” It’s important that you be responsive to that inbox, but the emails you receive there can help inform you which of the features you skipped should be built first.
• Early customers are surprisingly accepting of the limitations of an early product that’s great at one particular thing. See: “Instagram only lets you post square pictures.”
• When possible, use high-quality off-the-shelf solutions that require only small amounts of customization. For your homepage, you can use a good-looking Webflow template, strip out what you don’t need, and ship something that looks good in half a day.
• Avoid cargo-culting things that “real companies do” but don’t affect whether customers will purchase your product. Your company doesn’t need a website unless potential customers will actually look it up. Your website doesn’t need a team page unless potential customers care who the team is.

It’s not an exaggeration to say I could have saved literally years of effort by building less before selling. If you can use prioritization to spend less time building and more time finding and talking to customers, you’ll put your company in a much better position to succeed.

Distribution is just company-speak for “how do you get new customers?”.

The ideal and most common answer to this question is “people love it so much that they talk about it”, but founders often give little thought as to why people are talking about the company or eager to try it. Unfortunately, most products that people use - even great ones - don’t prompt them to gush about the experience to their friends.

An interesting and frustrating trait shared by good distribution strategies is that they’re highly tailored to the products themselves. For example, let’s look at distribution strategies for three very viral consumer companies:

• Facebook relied on Mark Zuckerberg’s access to house mailing lists at Harvard and students’ curiosity about what other students were up to. The most common “use” of early Facebook was to check other people’s relationship statuses, which has obvious utility on a college campus
• Instagram made it easier to take good pictures on bad phone cameras by applying a filter. Although your filtered photo was uploaded to Instagram, one of the main draws at launch was the ability to share an (Instagram-marked) image to other social media sites like Twitter and Facebook - where your friends actually were. People on those networks would wonder “what’s that mark on the image” and become Instagram-curious
• Discord knew it was entering an already-crowded voice chat space with Teamspeak. However, the team recognized that they could leverage new technology (WebRTC) to make a browser-based voice chat client (whereas Teamspeak required a download) and bet big on that low onboarding cost. They then used Reddit to target players of specific games and make Discord popular among players of those games, knowing that it would spread due to its multiplayer nature

When the distribution strategy is poorly tailored to the product, the result is often that the user feels spammed (see: Clubhouse spamming you with notifications to invite your friends). When the distribution strategy is well tailored to the product, it almost feels like a feature (see: Gmail slowly allowing early customers to invite friends while in private beta).

If you’re not already subscribed, subscribing to the First 1000 newsletter is a great way to build a personal playbook of successful early distribution strategies. In short, the newsletter describes how each company it profiles acquired its first 1000 customers. This is useful because the likelihood that a given distribution strategy will work for any startup is low, but the likelihood that some already-used distribution strategy will work for a startup is much higher.

Sometimes, a good distribution strategy relies on adding a missing cofounder or equity partner to your team. This can particularly be the case if your product will rely on “big sales” that require significant trust or if your product exists in a market where there are natural “hubs”. As an example, recruiting a few well-known food bloggers as equity/distribution partners for your new meal planning app could make a substantial difference.

To be clear, I’m not saying a good distribution strategy is an excuse for a poor product. Even if you get your product into people’s hands, a poor product creates too strong of a headwind for meaningful growth. However, I do think that a good distribution strategy should be put on the same pedestal as high product quality and that most inexperienced founders put far too much early effort into product and not enough on distribution.

Similarly, I think that your distribution strategy should be developed and tested alongside your product, not after it. A few useful questions to ask yourself when developing this strategy are:

• How are you going to get your first 5-10 customers?
• How are you going to grow from 5-10 customers to 50-60 customers?
• Are there any other successful companies that share your target customer? How did they grow?
• How are new customers finding out about your product?
• Once you’ve saturated a single market (geography, vertical, etc.), how do you gain a foothold in a new market?
• How can you gather more information about your distribution strategy before you need to use it?

(These numbers are for consumer applications: for B2B applications, you might want to cut them by 5x given the generally-larger customer lifetime value.)

Each of those answers - especially the early ones - should have simple, realistic answers. If any of them seem incredibly daunting, chances are that you have a tough slog ahead. In that case, “can I sell this thing” is probably a bigger existential risk to your company than “can I build this thing”. You should spend more time brainstorming and testing different distribution strategies before sinking significant time and money into building a product.

I realize that probably sounds condescending, but I actually don’t mean it to be at all.

Toddlers are humans showing the first inklings of social behavior. However, unlike adults, they have no shame in showing you how they truly feel, usually by yelling at you or throwing stuff. This tightens the feedback loop when you’re trying to figure out how they tick.

One such insight I gained from my toddler: a few years ago when I was first named a tech lead at Google, I wasn’t given much training. However, I knew that I was supposed to let the engineers on my team choose the projects they worked on. The rationale here seemed sound: people are going to be more effective working on projects they’re personally interested in.

So I gave clarity on an overarching goal for our team and let the other engineers choose projects that brought us closer to that goal, providing input when asked.

To put it succinctly, chaos ensued. The new engineers on the team lacked the necessary context required to choose good projects and our team fell short of its goals.

Furthermore, even they were frustrated: they lacked the context to pick right-size projects and would instead end up with too-difficult ones. This led to a lack of incremental wins and ultimately burnout.

In response, I swung the pendulum the other way: “this is what you’ll be working on”, I proclaimed. The result was equally uninspiring: the engineers ended up working on projects that they didn’t feel interested or invested in.

This was frustrating to me: I tried both approaches and neither worked well. What else could I do?

Now that I’m a parent, I can see my mistake clearly. My toddler responds… poorly to commands. He has little sense of what needs to get done in a day, yet has a desperate need to feel control over that day. Complicating matters, if he detects even a whiff of a command he’ll push hard in the opposite direction. Newton’s third law in action.

Here’s the parenting trick: present two or three options that you’d be equally happy with them choosing and let them decide. A few examples you’ll hear often at my house:

• Do you want to eat grapes or strawberries for lunch?
• Do you want to go upstairs to get changed now or in a minute?
• Do you want to go to the park with the broken slide or the park with the bumblebee?

Using this same principle, engineering managers can let the engineers with the necessary context mostly dictate the set of projects for the team. Then, when a junior engineer needs more work, you give them a few right-size options, some pros and cons of each, and let them decide between those options. 

They end up with right-ish difficulty projects that provide meaningful opportunities for growth, but maintain that important sense of ownership over their work.

Now as these junior engineers grow, it’s critical to allow them to propose projects of their own. Doing so builds useful skills in scoping, planning, and technical communication. However, relying on this “illusion of choice” for a while gives them an opportunity to build context and confidence.

Since then, the landscape has inverted and the common wisdom is that “ideas are worthless and execution is everything”. This is, of course, complete malarky: Elon wouldn’t be Elon if he had chosen to build an iPhone app that reminds you to feed your dog.

The obvious truth is that a good startup idea is a necessary but not sufficient ingredient for success in the startup journey. A poorly thought-out idea is like starting a trip without a route: there’s a chance that you’ll be happy about where you end up, but you’re also not doing yourself any favors.

Coming up with a good startup idea is a three step process. You need to find a problem, find a way in which technology can help solve that problem, and then analyze your solution to see if you can build a good business around it. When it invariably turns out that your idea sucks, there’s a fourth step where you soak that idea with gasoline and light it on fire.

Find a problem. Find a solution. Analyze the business. That’s all that it takes. Now, you just have to do this over, and over, and over again until you stumble across a few ideas that make you wonder, “Huh – could that actually work?"

Creating startups and shaping the future is an inherently creative process. It turns out that discarding promising raw material until you find something interesting is very common among creative endeavors. Ken Burns, the famous American documentarian, uses a beautiful phrase to describe the importance of unused ideas: “honoring the negative space of creation”. In his words, “It takes 40 gallons of sap to make one gallon of maple syrup.” He was alluding to the fact that every second of used footage in his documentaries corresponds to 40 seconds of promising but unused footage.

For startups, this might mean that you can expect to come up with 40 startup ideas to find one that’s promising. Actually, you’re not Ken Burns. Let’s make it 80.

Of the skills that you need to find a good startup idea, the best one to learn first is probably the one that you use last in the process: analysis. After all, it doesn’t make much sense to set out on an elephant hunt if you don’t even know what an elephant looks like. So without further ado:

What makes a good business?

Entire volumes have been written about this: I’m not going to rewrite them poorly here.

Wait – actually I am. Here’s my short, short version of what makes a good software business:

1. Is there a real, pressing problem?
2. Does your business solve the problem in a significantly better way than the alternatives?
3. Do you have a realistic plan to grow your business?
4. Is the total addressable market large enough?
5. Once your business starts to succeed, is there something that will prevent competitors from just copying you?

If the answer to any of those is “no”, it’s probably not a good idea.¹

Bear in mind that the above list certainly isn’t comprehensive. Theranos answered “yes” to all of these, but failed because the thing couldn’t actually be built. WeWork answered “yes” to all of these, but failed because there weren’t real economies of scale. If your idea answers “yes” to all of those questions but requires a billion dollars to get off the ground with no intermediate validation that might be used to secure funding, you have – you guessed it – a bad idea.

My advice to help develop your sense of what makes a good startup:

• Listen to the Acquired podcast. In each episode, they dig into how a company was built and then assess the company’s prospects going forward. This podcast has been immensely helpful for me in evaluating the prospects of growth and late stage startups.
• Read The Lean Startup by Eric Ries. While it’s fiercely debated whether this book’s frugal prescription is actually realistic nowadays, I still think that it’s a great tool to get you into a mindset of scrappily evaluating startup ideas.
• Read Paul Graham’s essays on his website. (I recommend Do Things That Don’t Scale as a first read.) Paul Graham was a founder of the YCombinator accelerator and has mentored many successful startups in their early stages.
• Read Andrew Chen’s book The Cold Start Problem. Andrew Chen took his experience on the growth team at Uber and as a VC at Andreesen Horowitz and wrote a wonderful primer on how to kickstart marketplace businesses.
• Read Andrew Chen’s blog, which is similarly insightful.²
• Read Hamilton Helmer’s 7 Powers, which is an incredibly useful framework for assessing whether companies are likely to eventually get their profits competed away.

At some point while doing these things, you might realize that you have the vocabulary to describe exactly why your roommate’s app idea is so terrible. That’s probably a good sign.

Equipped with your new superpowers of analysis, you can move on to understanding:

How does software solve problems?

Your goal here should be to develop some sort of Swiss Army knife of “how does software provide value in the world”. A few examples:

• Software can aid with discovery (Airbnb, Google, Uber): Take an activity that people are doing or would like to do and help find other people that want to participate in that activity.
• Software can be a trusted 3rd party (Airbnb, Wise, Uber, Kickstarter): By acting as the trusted broker between two other parties, you can facilitate exchanges that might otherwise be too risky to take place.
• Software can provide something faster or cheaper than non-tech-enabled competitors (Gusto, Vouch)
• Software can centralize a hard process that lots of companies are already doing poorly on their own (Plaid, Stripe, Vanta): Lots of companies can pool resources through yours to do something hard well instead of each company competing in a silos to see who can do that thing least poorly.

The same resources I listed in the previous section should go a long way towards helping you develop a sense of how software solves problems. The key here is that, as you hear smart people dissect different businesses, you should start to notice patterns in how those businesses provide and capture value. The more concisely you can use words to describe those patterns, the more effective your brain will be at using those patterns to solve new problems.³

If you know how software provides value, then you just have to:

Find a problem

There are obviously no hard rules about “how to find interesting problems”, but a few things that I’ve found very helpful in the past are:

• Reading a book about an unfamiliar field
• Reading books that take place in different worlds (science fiction / fantasy)
• Become deeply integrated into a technology/culture “wave”
• Traveling to new places
• Going to a conference for an unfamiliar field (I haven’t done this myself, but have heard it recommended by others)

Looking at these, there’s a clear pattern: innovation is almost always the result of applying techniques from one domain to solve problems in another. It’s a little more like “domain arbitrage” than it is coming up with something new: you’re just assembling familiar components in unfamiliar ways.

There are pitfalls to this approach, though. Trying to solve a problem in a field you’re not yet familiar with is also a recipe for falling prey to the Dunning-Kruger effect, where you’re overconfident in your ability to solve a problem precisely because you know so little.⁴ Because of this, it’s important to approach any problem you stumble upon with a great sense of humility and an earnest desire to learn. Only after you’re knowledgeable about the problem should you feel vaguely qualified to build a solution.

Tons of startup ideas revolve around using technology to solve problems that have existing but maybe suboptimal software solutions. In my opinion, this is one of the toughest ways to build a business.

To illustrate why this might be hard, imagine that you sell shovels in a frontier town. Because you’re the only seller in the market, you just have to let people know you exist in order for your business to take off. If you sell shovels in Farmville, USA between the Tractor Supply and the Home Depot, your shovels are going to have to be God’s gift to digging in order to attract customers. Even then you may find yourself in a hole that’s hard to escape.

It’s also entirely possible to build a successful new product ignoring all of this advice: as an example, I don’t think there was any particular reason why Webflow couldn’t have been built 5 years earlier. However, this approach is certainly harder. Vlad Magdalin, the founder of Webflow, had to found the company three times and work for over 10 years to crack the formula for no code website building. Heck, just look at the Hey.com and Superhuman teams trying to break into the email space with (what I believe) are two really interesting products. In both cases, it took talented teams years of building before they had something with even the minimum expected feature set to put in front of customers. And it’s not yet clear whether those teams will ultimately succeed.

A good startup idea can act as a strong tailwind to your startup, amplifying all of fundraising, hiring, and selling that will be necessary to grow. If you’re going to put years of your life into making your startup idea a reality, why not do so with the wind at your back?

In both cases, you start with a problem and Frankenstein together various components using rules of thumb until you have something that looks like a solution.

Because the crafts look so similar, you’d be forgiven if you thought the business models behind building software and houses were similar. They couldn’t be more different.

When you’re building a house, you have a pretty good idea of how many people that house will impact. The market has already demonstrated that they’ll pay for a roof and a walk-in shower and a state of the art heated toilet seat. If you erect a sturdy 4 bedroom, 2 ½ bathroom house with these amenities in a desirable neighborhood, you can rest easy knowing that you’ll be able to sell it.

This is not how software works.

The main problem here is that houses and software have wildly different marginal costs. If I build a house and my neighbor really likes it and wants to live in a house that’s exactly the same, it will cost them almost as much to build as it cost me. Sure, they might be able to save a few thousand dollars on architectural fees, but they’ll still need wood, wires, and boatloads of time from skilled plumbers, electricians, and carpenters to assemble those raw materials into something resembling a house. Marginal cost is just the cost to produce one more unit of something - in this case, one more house.

Contrast this with software, which lives in the realm of often-near-zero marginal costs. I can’t make a living building Zoom for someone because Zoom already did that. The marginal cost to Zoom of onboarding a new customer is almost zero, whereas the fixed cost to me of recreating Zoom is astronomical.

Building houses is a great business because those high marginal costs for each new house are paid to you. The work you do correlates pretty linearly with the value you provide, providing you with a steady stream of income and feedback that the thing that you’re doing is actually useful. The trade-off is that it’s hard to gain much leverage in your work, with leverage meaning something like “how much impact can I have for every hour I work”. Whether you work on a small project with a small impact with a small team or a big project with a big impact with a big team, the amount of impact per person might vary by 1x or 1.5x or even 10x, but the physical nature of the work makes it hard to stretch the impact much beyond that.

Software is a great business because, if you can build something that’s useful and provides $10/month of value to someone, it’ll probably cost you a lot less than $10/month to provide that value to a second person. Multiply that by 1,000 and you’re getting paid to do a full time job, even if you only work 5 hours per week. Multiply that by 10,000 and you can retire in a few years. It’s an extremely high leverage business.

This makes software a weird anomaly. Paging back through history, there have been very few opportunities for near-zero marginal cost goods. Probably the closest parallel to present day software in history is publishing companies, where additional prints are cheap compared to the cost of creating the content in the first place.

Unfortunately, there are three significant downsides to software’s low marginal cost structure:

First is that software takes a lot of time to write up-front. By the time you’ve signed up your first customer at $10/month, there’s a good chance you’ve spent 100s or 1000s of hours writing that software. Low volume software is not a good business to be in.

The second downside of the “high-leverage” software model is that unless you aggressively seek out feedback, you’ll probably realize that your software sucks only after you’ve built it and can’t find a customer. The digital nature of software makes it extremely easy to ignore pesky distractions like customers right up until the moment you need their money to buy that expensive Icelandic yogurt you love.

The third downside is that, unless you can differentiate your product from what already exists, it’s going to be hard to find a foothold in the market. Given how many software products already exist, that’s a high hurdle to clear.

The distribution of “value created by people building new houses” is probably some sort of a normal distribution that’s anchored in the cold-hard reality of the physical world:

There’s almost no one in this distribution creating zero value, but there’s also almost no one creating hugely lopsided value.

Compare this with “value created by people building new software”:

Here, you have the vast majority of people building new software creating no value, some people creating a modest amount of value, and a few people creating tons of value. This is what’s known as a power law distribution: a very small number of outliers account for the vast majority of the impact.

If you’re building software - particularly new software that hasn’t already found a market -this underscores the importance of being good at what you do: if you’re just average (or more precisely, just median), you’re creating zero value.

This is also why this blog focuses on how to build successful software: for each few percentile you move to the right on that curve of outcomes, the value you’re creating increases exponentially. To achieve this, you need to not only build high quality software but also understand adjacent ideas like identifying promising distribution channels, soliciting and incorporating customer feedback, and building defensible moats around your business.

These are the things that can transform a “software engineer” into “someone who can solve problems using software”. The latter is a heck of a lot more fun.

To be very, very clear, there’s a lot not to like about blockchains: it’s estimated that Bitcoin - the most popular blockchain - uses about half a percent of the world’s energy: the same as the country of Finland. If you’re in the camp of “this thing is fairly useless”, then the horrific externalities of Bitcoin mining clearly outweigh the minuscule benefits.

For the past few months, I’ve been trying to suppress my own quickly-formed negative opinions about blockchains. For the next three minutes, I’d ask you to do the same: fear not, you can pick your opinions back up at the bottom of the post.

You can basically think of blockchains as “a distributed database on a bunch of people’s computers”. To answer “are blockchains harmful to the environment”, let’s look at how much energy each blockchain uses to save something new to that database - commonly known as a transaction.

The Crypto Carbon Ratings Institute found that Bitcoin used a staggering 17.2 megawatt hours of energy to perform a single transaction. That is… alarming.

However, that number is highly blockchain-specific. Ethereum, the second most popular blockchain, uses about 1000x less energy per transaction with a still-much-too-large 37.6 killowatt hours of energy per transaction. That equates closely with an amount of energy that the EPA says equates to a gallon of gasoline (33.7 kWh). Ethereum is also working hard to migrate to a new technology that’s about 2,000x more energy efficient.

Solana, a newer blockchain that’s growing quickly in popularity, uses 10,000x less energy per transaction than Ethereum - only .17 Wh per transaction. That equates to about half a Google search (0.3 Wh) or leaving an LED light bulb on for one minute. In a year, Solana uses about as much energy as 1000 U.S. households. That’s still something, but it’s squarely in the realm of “we accept that useful and ethical things can use this much energy”.

The important takeaway from these numbers is that high energy use may be an inherent part of some blockchain implementations - like Bitcoin - but it’s not an inherent part of the underlying idea of blockchains. The two can be separated. The details matter tremendously here: there’s a 100,000,000x difference (8 orders of magnitude) between the energy requirements for a Bitcoin transaction and a Solana transaction.

To say “blockchains use too much energy” is a little like saying “Amazon employees have amassed too much wealth”: are you talking about Jeff Bezos or Joe the warehouse picker? The imagined relative wealth disparity between those two ($179B vs. $1,769) is the same as the difference in energy consumption between Bitcoin and Solana transactions. The details are paramount.

Bitcoin’s energy usage is a big problem, especially because cryptocurrencies are self-perpetuating in nature: the current Bitcoin miners and token holders have an enormous incentive to maintain the status quo. If there’s a way to reduce Bitcoin’s environmental impact, it’s certainly above my paygrade.

But as someone evaluating whether Solana, for example, might be useful to solve real problems in the world, Bitcoin’s energy costs are irrelevant. The two come may come from the same ancestor, but they’re worlds apart.

With that being said, I agree that just because blockchains aren’t bad doesn’t make them necessarily good.

The reason I’m interested in blockchains is that they’ve created a scenario where enormous pools of resources have been amassed to do something (consume computational resources and therefore energy) that normally costs money. The Bitcoin community has poured millions and millions of dollars into finding more efficient ways to do that thing. And they’ve done so not out of the goodness of their hearts, but because they’re incentivized to.

If you care about the climate and this doesn’t pique your interest, it should: if it were possible to tweak the incentive structure of a blockchain such that the thing that people are aligned to do is “capture carbon” instead of “use energy”, then you would have effectively created an economy around carbon capture that doesn’t rely on governments to enact carbon taxes. (Regardless of whether you think governments enacting carbon taxes is the right thing, I expect that we can at least all agree that it’s an enormous hurdle worth avoiding if the end result is the same.)

In my opinion, some of our society’s biggest problems come down to situations where an individual’s incentives are misaligned with the greater good: providing affordable health care and better education, combating climate change, and building more affordable housing represent different flavors of this same problem.

I won’t tell you that “blockchains are the solution to all of these problems” because I frankly don’t know if they are. However, blockchains do have incentive-aligning traits that make them an interesting tool worth learning about.

My big ask: if you find yourself in a conversation where the other person bemoans the environmental impact of blockchains, cryptocurrency, or NFTs, tell them it’s a little more nuanced and point them my way.

That destination is just that, though: a destination. There are a whole slew of hurdles that stand in the way of that company and its dazzling future. If you’re evaluating the merit of investing your time or money in a company, it’s often useful to ask yourself “What things do I need to believe in order for this investment (of time or money) to not make me look like a big fat idiot in the future?”

Take Google, for example. When they were grad students at Stanford, Larry Page and Sergey Brin codeveloped the PageRank algorithm to better rank search results on the internet, eventually dropping out to found Google. In order to believe that PageRank could form the basis of a successful company, you had to believe:

1. The algorithm generated meaningfully better search results than the existing search engines could
2. The algorithm could actually be implemented and run at “web scale”. (Admittedly a lot smaller in 1998 than today.)
3. The algorithm wouldn’t just be copied by the existing search engines behemoths like Yahoo or Alta Vista. (Thankfully, a patent on the algorithm helped out here.)
4. More and more people would use Google because it was a better search engine
5. That better search engine could be successfully monetized and turned into a good business
6. The money generated from successful monetization and the data generated from increased usage of the search engine could then be used to produce a meaningfully better search engine, feeding back into step 5 categories:

If you’re starting a company, there’s a good chance that you need to get buy-in from both potential hires and potential investors. Coming up with an accurate list of “beliefs” or “hypotheses” to be tested is a great first step towards getting that buy-in: it at least shows others that you’re realistic about the challenges you face.

If you have some pedigree, a cofounder, a decent tech-enabled business idea, a vague notion of how to bring that idea to fruition, and the knowhow to pitch that idea, then your company is probably worth on the order of a couple hundred thousand dollars these days. Congratulations!

However, maybe more importantly, you now have some very concrete steps to increase that valuation. The reason that your company is worth what it is instead of the gazillion dollars that it would be worth if all those hypotheses were true is that the company’s value is discounted to account for the key risks you face.

To increase your valuation, you just have to take the easiest hypothesis to test and prove it. Going back to the Google example, if Larry and Sergey indexed a single “segment” of the web like stanford.edu, they have the opportunity to reduce the risk for two of the hypotheses:

• They proved they have the know-how to build a version of Google that runs at sub-web scale
• They can do some very basic testing where they ask 20 people which search results they prefer for a Stanford-related query, Google or Alta Vista?

This certainly doesn’t guarantee the success of their company, but it’s likely enough to drive up their valuation significantly - say, from $200,000 to $1 million.

With that higher valuation, they can seek outside investment in their company, selling 20% of the company to raise $200,000.

With those funds, they could:

1. Acquire additional hardware, prove that the algorithm can work at web scale, and release a beta version of the search engine
2. Hire a patent attorney to help them file for a patent on their algorithm

… and now the company is really off and running. They’ve greatly reduced or eliminated many of the early-stage existential risks to the company (hypotheses 1-3) and are in a great position to test their growth strategy (hypothesis 4).

They’ve also provided enough signal to unlock a new tier of investors and early-stage employees by demonstrating that the company has a real shot at success: it wouldn’t be stretch to say that nowadays such a company might be able to raise $10 million in funding. The later hypotheses are obvious harder to test, but thankfully the company has more human and capital resources at its disposal to test them. It can now sell the same portion of the company that it sold before (20%) but for much more money ($2 million instead of $200,000).

With that capital, they can hire someone with better knowledge of how advertisers allocate their resources and build an effective advertising business to help them monetize searches. They can also hire someone knowledgeable about growing startups to help identify obstacles that are hindering growth.

In the end, this method of company building looks a little like this:

One of the reasons that this framework is effective is that there’s often a gaping chasm between “What’s the next easiest hypothesis to test?” and “What should I do next that makes this company look more like a real company?”. Early-stage investors tend to care a lot more about the former than the latter: “making a company look real” by renting an office and paying for health insurance is easy given sufficient resources, but you’ll inevitably run aground if you try to scale a company built on flawed underpinnings.

Another reason that this framework is effective is that investors always want to know “Why is this money going to help you succeed?”. This plan ensures you have a clear answer: “file for a patent”, “buy hardware to bring our prototype from Stanford-scale to web-scale”, etc.

By systematically identifying the hypotheses that underpin your company, proving those hypotheses, and leveraging the resources unlocked from that newly reduced risk profile, you should hopefully be able to build that 5 star resort on the moon while not looking like a big fat idiot. Happy launch day!

Shepherd: “I’m sick and tired of always having to be the one that brings the cows in from pasture. I wish I could get someone else to do that.”

Friend: “Maybe you could call and ask Anna and Joe’s daughter if she’s willing to help out a few times per week.”

Shepherd: “No no, I want to solve this problem for others too. Let’s build a mobile marketplace that matches up shepherds with people willing to help them take care of their animals.”

Friend: “I don’t know, seems a little overcomplicated to me. Can’t you just pin up a job posting at the tavern asking if anyone’s willing to help bring the cows in, then call around and ask a few other shepherds if they’re willing to help chip in if the new hire brings their cows in too?”

Shepherd: “No no no, I want to fix this for everyone. I want to start something. We’ll get flooded with requests from other people and won’t be able to keep up unless we automate this thing.”

… and so on.

By the end of this, the shepherd has spent a year hiring a team to build out a slick mobile application that matches up shepherds with people that will help them… and there are 10 shepherds who know about it, but 80% of them don’t use it because it doesn’t really match what they need. The shepherd has only talked to 2 of those people, and he’s not really sure why it doesn’t match their needs, but it sure is frustrating.

I would say this describes about… 99% of the new products or features that I write. I’m the shepherd here.

My new rule of thumb is that, until proven otherwise, I assume that all code for new products will get executed many, many fewer times than can possibly justify automating the task.

My pitch to the shepherd here: text a few of your friends, find people that want help, find someone who’s willing to help. Get out a pen and paper and figure out how to split the helper’s schedule. Text out the schedules to your friends. Rinse and repeat, get feedback on why your schedules are rotten, fix them. If you start to feel like sending a particular type of text is really repetitive and a giant waste of your time, then maybe it’s time to automate it.

Zipping back to the present, I genuinely believe that experienced engineers from big tech companies make worse technical decisions in early-stage products than people who have no idea what the heck they’re doing. We have so many preconceived notions of what counts as “real engineering” because it’s required to scale successful services (fancy databases, backends running in the cloud) that we completely forget that 99% of new services aren’t successful. For new things, you should be spending more time figuring out how to not build things (e.g. faking automated services through manual work) than you spend actually building them. Only automate processes when the manual part gets painful.

In my experience, the real villain in this story is “friction” - basically, however much harder something is to use because you didn’t do it the “real” way. In the above story, it’d be easy to convince yourself that the reason that shepherds/helpers aren’t signing up is because there’s no website to do it at, or there’s too much delay in receiving their schedule because it’s not automated, or any other way that a multi-billion dollar marketplace might be better than you texting some friends.

However, I almost always find that:

• Especially among early adopters, friction is less of a deterrent than you probably think it is
• Friction is more of a deterrent when you’re not talking directly to prospective customers, which you probably should be at the start
• While friction can be a deterrent, it can be mitigated by being upfront with customers about the early state of your product and making up for a poor quality product with customer service that’s drastically better than what they’d receive elsewhere
• Friction can be greatly reduced through manual work (e.g. responsive texting / emailing)

The problem is that, in rare cases, friction actually is a deterrent that prevents you from meaningfully testing your product. But that’s the exception, not the rule.

The seminal article on this whole space is Paul Graham’s Do Things that Don’t Scale - if you build new things and haven’t read it, it’s definitely worth a read. However, I read that article when it came out and still made all the mistakes that it warns against. Repeatedly. Builder beware.

One basic lesson that he’s taught me is to never reach out twice with the same value proposition.

To illustrate what I mean, imagine you receive this email from an interior decorator you’ve considered working with:

Dear Jenny,

I was reaching back out to you to ask if you’d had any further chance to consider working together. I have lots of happy clients and would love to work with you to craft your perfect home.

Thanks,
George

That’s a very polite email! Thanks George.

Unfortunately, that email probably doesn’t meaningfully alter your chances of hiring him beyond “if I just forgot, maybe I’ll follow up now”.

Furthermore, you’ll probably tolerate one or two of those emails before you wish George would shut it and go away.

That’s fine, but George can do better. Now, how would you feel if you received this email instead?

Dear Jenny,

Loved chatting with you the other day!

I’m reaching back out because an upholstery brand that I think you’d really love (Hickory Chair) is having their biggest sale of the year right now. I’d be happy to stop by to see if any of their items might help solve that pesky living room seating issue you mentioned.

As an example, here’s a piece I thought you might like:

Thanks,
George

Now I don’t know about you, but I’m much more likely to reach out to schedule a meeting after that second email. It’s polite, recognizes that George listened during the last meeting, and offers a meaningfully different value proposition than he put forth in your initial meeting.

Assuming that George’s barometer of what appeals to you is correct, he can probably reach out with many more of those emails before you get annoyed. They’re thoughtful and likely take him more effort to craft than it takes you to read them: it’s a little like having a free personal content curator working just for you.

It takes real effort to find that new value proposition. Often, it requires some combination of passive effort (keeping your eyes open for something that matters to that person) and active effort (passing along that new value proposition when you find it). However, it’s that very effort that demonstrates to the recipient that you care and makes the pitch much more effective.

When Mark Zuckerburg started Facebook, he was a student at Harvard that made a social website for other students at Harvard. Only after reaching a critical mass of Harvard students did he expand the site to other elite universities, where the site benefitted from the halo effect of already having succeeded at one of the most prestigious universities in the world.

The restaurant reservation startup Tock (recently acquired by Squarespace) was cofounded by Nick Kokonas, the co-owner of probably the most prestigious restaurant group in Chicago. He was able to bootstrap the platform with his own restaurants and benefit from the halo effect of those restaurants as he recruited others onto the platform.

What do each of these stories have in common?

In each of these, the founder of the startup pushed an unfair advantage to gain market insight and distribution for their startup. If you or I were to try and compete with that founder given an equally good product and market insight, we almost certainly would have failed because we lacked the key advantage that they leveraged.

Some unfair advantages are obvious (owning the most prestigious restaurant in Chicago) while others are less so (being a former sorority sister). However, it’s critical to have a good fit between the product you’re trying to bring to market and the advantages you have. Otherwise, you’ll be on equal footing with your competitors and your chance of succeeding falls dramatically.

People often discount their own unfair advantages because they just feel like uninteresting characteristics or pieces of backstory. However, it’s this very fact that makes these advantages so powerful: they’re such an innate part of “who you are” that it’d take another person years or decades to try to mimic those advantages.

Furthermore, people often further discount those unfair advantages that seem unrelated to entrepreneurship and startups. I’d posit those “unrelated” advantages are the most important ones to leverage because it’s less likely that another startup founder has already moved into the space. It takes an incredible level of technical prowess and market insight to start a successful API-only software product in 2022 because the overlap between entrepreneurs and software engineers is massive. On the other hand, if you’re a stay at home mom that has unique insight into challenges that other stay at home moms might face, there’s probably a lot more problem space left to explore.

Too often, startup founders try to compete on equal footing instead of moving to areas where they have the high ground. Identifying those areas and integrating them into your startup’s story can dramatically improve your ability to gain traction as a company.

• Your boss tells you to write a service or feature that does X
• You work really hard and make something that does X well
• Your work makes the world better and you’re rewarded for it

This was stupid. This is not at all how software engineering works.

“Obviously useful”, grand slam projects like this are rare enough that most of them have already been finished. If your boss was so sure that this project was one of them, it probably would have been done long ago.

Software engineering, unlike food service, law, nursing, or dry cleaning is not a service industry. In each of these industries, the utility your work provides to the world has some rough correlation to the effort you expend. A great nurse or lawyer will certainly have a much higher coefficient for how much utility they create per unit of their time. However, the two are usually still correlated and there’s a cap as to how much utility they can provide with their time.

Contrastingly, software is a product-driven business: you can work really hard on a product, but if no one uses it, then - pardon the French - you’ve wasted a shit load of your time.

To exacerbate this, software has a high upfront cost to write but often has almost no marginal cost to add a customer. This means that, unless you’re careful, there will be huge sunk costs by the time you realize something isn’t useful.

The obvious upside to this model is that if you can actually write software that’s useful, it can provide a terrific amount of utility to the world.

My advice to my younger self: you may be handed projects, but the project specifications will be wrong in 50 ways that no one knows yet. This is not your boss’s fault: the hard part of software isn’t writing the code, it’s figuring out what the software should do in the first place. Knowing how to write the code is just table stakes for the real job.

As soon as you acquire those basic engineering skills, start focusing on understanding how to validate your product ideas, work closely with customers to refine them, and get buy in from others to work on them. This is a completely different and frankly much more valuable and difficult skillset than software engineering. Find and study the experts in the field like Paul Graham, YC Startup School, Eric Ries, and Peter Thiel. The whole field is as much black magic as it is engineering, but there are still very real principles to be learned.

Past a certain point, these skills are as useful at a large company as they are at a startup. You can receive a few promotions at a large company just by doing the right engineer-y things that look right, but at some point you’ll be expected to create something that matters and no one really cares how hard you worked on it if it doesn’t provide utility.

In one of his early YouTube videos, Ludwig took on a seemingly pretty easy challenge: start a new, anonymous YouTube channel and get 1000 views on a video.

However, anyone that’s ever created anything online knows just how difficult this challenge is. The vast majority of blog posts, videos, and songs online sit quietly, with a few people at most ever seeing them.

Ludwig ultimately succeeded in his challenge: the video he created centered around another popular Twitch streamer, MrBeast, and how he employed the “random person bursting through the front door” trope from 90s sitcoms to keep his Twitch channel interesting – think Kramer in Seinfeld or the roommates from Friends rudely bursting through the front door of their neighbor’s apartments.

After Ludwig created the video this, he posted it into MrBeast’s Twitch chat, trying to get MrBeast to open the video on-stream, which would then cause his followers to view the video too. To increase the likelihood of this happening, Ludwig:

• Posted the video at a time when MrBeast was transitioning between topics
• “Boosted” the post in the chat by attaching a $50 “tip” to the post, which ensured that the comment wouldn’t be drowned out by other “free” posts to the chat
• Ensured that the thumbnail and title of the video were chosen specifically to appeal to MrBeast’s vanity

All of this succeeded: MrBeast opened the video on-stream and his viewers followed. Ludwig’s video ultimately received over 11,000 views and yielded 150 new subscribers to his channel, putting him solidly in the camp of “having more subscribers than 99% of other YouTubers”.

I think this story is interesting because it illustrates the problem with what many people intuitively want to believe: build something great and people will come. As inspiring as Field of Dreams was, it was frankly full of crap on this account. If you build something great and you work your butt off to get people to come, then you have a real shot at making something new.

Thankfully, I’ve learned a few rules over the past few years at a startup about how to build your own distribution: I’ll share them in the next post.

Having worked for years on Google Chrome, which is a globally distributed team, let me just say: I sure hope we’re going back to the office. I also hope that the office looks a little bit different for most people.

I’ll be the first to admit that an office-only culture is problematic. Even when I worked on office-first teams at Google, I was always afforded the flexibility to work from home for appointments or frankly if I just didn’t want to put on pants for the day.

It’s also not in anyone’s best interest to commute an hour and a half to work each way, like I’ve had some friends do in the valley. Offices force you to be located in a particular location which may put stress on your budget or lifestyle. (See: the children per family in San Francisco or New York.)

However, even the fiercest distributed team advocates agree that an office provides some benefits that are difficult to replicate on a distributed team. I want to dig into some of those benefits.

It’s easier to initiate outside of work experiences

In my time at Google, I found that having experiences with coworkers from outside of a work settings would significantly strengthen the relationship with those coworkers.

At Google Chicago, we had a yearly two day team ski trip. I found that I was always more thankful for who I worked with after that ski trip than before. If a conflict arose with those coworkers, I found myself naturally more willing to “assume positive intent”.

While it’s certainly possible to boot up Among Us during work or schedule Zoom lunches between random teammates, the set of remote bonding activities is significantly more limited than the set of in-person bonding activities. Furthermore, the spontaneous and critically important break-outs (small conversations) that happen at team off-sites or conferences are near impossible to replicate over any remote tool I’ve used.

One question that I’ve used in planning my own team bonding activities is “how different is this context from what we usually do together?”, with the belief that something completely different gives you a better opportunity to see different facets of your coworkers. There’s not much hope for the answer to that question on remote teams: the activity will probably include the same glowing rectangle you spend the rest of your day looking at.

Zapier, a great distributed company, famously has quarterly offsites for its teams where everyone meets in person to replicate this effect. However, I highly suspect that most big companies won’t make any such effort to do this. Even if they do, once budgets get stressed, it seems likely this will be the first “perk” to go: its benefits are hard to quantify and it certainly seems frivolous to the short-sighted.

It encourages the spontaneous collision of people and ideas

Steve Jobs famously proposed a Pixar headquarters with all restrooms located in the central lobby in order to force people together and encourage chance encounters.

While working from home certainly increases the amount of control that people have over their day, it does so at the cost of essentially all of these chance encounters.

Despite my best efforts at scheduling random meetings, all of the most authentic connections I’ve made since transitioning into the Ann Arbor startup world stem from the coworking spaces that I was in for two months pre-pandemic. The quality of connections in the year since have been significantly lower: Zoom calls with strangers always feel transactional, whereas running into someone at a lunch table doesn’t.

It gets you out of the house

When I lived in Chicago, I tracked my steps and found myself regularly getting 10-15,000 steps per day without any effort on my part. Walking was a key part of any transportation strategy, which made me healthier and happier.

I later moved home to the much less walkable Detroit and found that my default step count plummeted to 4-6,000 steps per day.

My point here is that while there will always be exceptions, healthy defaults are incredibly important in shifting human behavior.

Getting out of the house and into a setting with other human beings builds a heck of a lot more socialization into your day than sitting at home in your office. While it’s certainly possible that some people working from home will choose to socialize more, I predict that the majority of people will socialize less as they have fewer opportunities to meet and talk with people built into their days.

Integrated beats segregated, every time

I suspect that some of the above problems with remote work will have much better mitigation strategies five years from now than they do now. However, it’s likely that combating these problems will require a whole suite of tools that, at best, provide a vague approximation of the benefits of a great office.

As we all know, it’s certainly possible to build a mediocre office-only culture. And, in my opinion, it’s better for a mediocre culture to be remote than in an office: at least you can work in your pajamas.

However, I would argue it’s much harder to build a great distributed culture than it is to build a great one that includes an office. It requires incredible amounts of work to mitigate the problems inherent to remote teams and I suspect that almost all companies will fail to put in the effort.

Lastly, I think it’s going to be near impossible for employees to win back the “concession” of an office from a company once it chooses to go remote. Doing so feels a little bit like your kids asking for a really fancy backyard treehouse: sure it’d be neat, but we just don’t have the money for that sort of thing.

Personally, I hope to always be on a team where in-person interaction comprises a significant chunk of work.

Today is one of those days for me, so I thought I’d jot down some strategies I’ve developed over the years to deal with these sorts of days.

Make a list of what you want to get done

First on that list should be “Make a list”. Check it off when you’re done making your list.

Your goal for the day should be to go out and collect checkboxes for that list. Given that what you want to do is lay on your couch and watch a movie, every checkbox that you collect is a victory.

If one of these tasks has ambiguity such that you aren’t forced to think through the exact steps involved, it needs to be removed and replaced with multiple, more specific tasks. For example, “Get life insurance” doesn’t count as a task if you don’t know what insurance company to call or the exact policy you want to set up. “Ask on Facebook for references for reputable life insurance providers”, “Call Mom and Dad about how to choose a life insurance policy”, and “Call Auto Owners Insurance at 234-567-8910 to start life insurance policy” is a much better set of tasks.

For more about this strategy, see my previous post: The Pomodoro Technique in practice.

Set a timer and a modest goal

Pick one of the easier tasks on your list, set a timer for 5 or 10 minutes, and focus only on getting the task done. Yes, I know the Pomodoro Technique usually calls for 25 minute blocks, but we’re not mentally ready for that.

If you get it done, regardless of whether the timer has gone off, cross off the item and reward yourself with time spent doing something you enjoy or are satisfied by. Go for a walk around the block, or make your bed, or go eat a banana.

When choosing rewards, it’s critical that you pick one with an intrinsic end. If you check Facebook or Reddit, or start reading a book, or play a video game, there will be a huge temptation to continue doing that thing right past the point you intended stopping at.

In my opinion, it’s also important that the thing not be too much fun. I find that the more I enjoy the “break” activity, the less I want to get back to work.

Lastly, I find that it really helps if the reward involves me getting out of my work chair. I don’t sit back down in the chair until I have a clear plan for what I’m going to do: I pick a next task, pick a duration to focus on it for, and then sit back down.

If you feel able, increase the length of timer you set a little each time you sit back down. However, if you don’t feel able, that’s okay: in the long run, it’s much more important that you get back into the groove of setting goals, reaching them, and rewarding yourself than it is how quickly you ramp up.

“Livestream” your work

Another trick that I sometimes use to get work done is to “livestream” what I’m doing. I’ll start up Loom and explain every step of what I’m doing as if I have an audience listening.

This probably seems (and looks) strange, but I find that I get many of the same benefits from this that I might get from teaching a subject: by explaining my actions like I’m teaching someone else, I hold myself more accountable to staying focused.

(Fun fact: this is also the primary reason that I write a blog. Forcing myself to write about a subject helps me develop clearer thoughts around it.)

Be proud of yourself

What you do on the hardest days is what distinguishes you as a professional from the amateurs. Take some time to be proud of yourself: this is an incredibly tough challenge and you deserve serious kudos.

Tock is really interesting to me because it’s the first startup that I’ve felt go all the way from founding to exit. The CTO, Brian Fitzpatrick (“Fitz”), and the original director of engineering, Robin Anil, both worked at Google Chicago at the same time that I was there. Fitz was the site lead for a time and Robin was a staff software engineer on my ad forecasting team while I was more junior. I knew Robin a lot better than I knew Fitz, but I know both well enough to know that they were superstars: Robin was an amazing engineer, and Fitz was an amazing engineering manager and networker.

From my understanding, Tock was conceived as a parternship between Fitz and Nick Kokonas to polish and productionize the reservation system that Kokonas had built internally for his 3 Michelin star restaurant Alinea.

Tock’s core product insight was that restaurant reservations were broken. Reservations were free to make for potential visitors but carried a very real opportunity cost for restaurants, who might turn away walk-ins or real reservations in favor of an earlier-made reservation who never intended to show up.

Tock solved this problem by making diners prepay at least a portion of the bill up-front: the diners then had something to lose by not showing up, and the restaurants got paid regardless. In short, it aligned the interests of the restaurants and the diners and, in doing so, made the restaurant ecosystem healthier.

This company is a great example of a common startup playbook: you find someone thoughtful who has deep insight into a specific vertical (restaurants), give them superpowers through technology (by partnering with a former Google site lead), and see what happens.

There’s a saying that goes something like “Most innovation happens from mapping concepts from one domain onto another domain”, and I think that certainly applies to Tock.

How can we reproduce this kind of innovation?

The tricky thing about this form of innovation is that it doesn’t happen by default. Restauranteurs mostly associate with their employees and other restauranteurs. Engineers at Google mostly associate with other engineers from Google.

It seems like the ideal thing to do here is to take a whole bunch of really smart people doing interesting things in their respective fields, put them in a giant lottery ball tumbler, spin it around a few times and see what ideas and relationships pop out.

Interestingly, this is exactly what Fitz has been doing for years with ORD Camp.

I’ll cherry-pick the camp’s description from their website:

ORD Camp is a two day, invitation-only, gathering of – 350 hand picked attendees. It’s a time to collect together the best minds in the midwest and beyond, to spark new ideas and spread old ideas. People from many different fields, many different walks of life, get together and share, teach, and learn about uniquely interesting topics

Sound familiar?

Interestingly, the one problem with ORD Camp’s invite-only nature is that it doesn’t generate a heck of a lot of value for you unless you’re invited. However, by founding ORD Camp, Fitz basically made sure he was invited and was a central node in this network that would hopefully produce a lot of cross-pollination between fields. Pretty genius in my opinion.

Every year, ORD Camp would seek out volunteers from Google Chicago to help out with the conference. It’s a major regret of mine that I was too busy hitting the local bars on Friday night to take the time to volunteer and see how the camp worked up close: I heard amazing things about the conference from the people who did help out.

With that being said, I think Fitz’s ORD Camp playbook is a good one for anyone trying to innovate: become a central node in a network of people doing really interesting things by being the person that brings them together.

Now I’m terrible at Rocket League. When I first started playing, I was automatically placed into the competitive tier somewhere between “toddler” and “arthritic senior”.

However, I do somewhat diligently try to get better. Recently, I’ve found that my biggest problem is that I just can’t make the sort of finesse plays that my opponents can. The shots that I needed to make were just a little bit harder than what I was capable of making reliably. I’d miss often, get scored on, and lose about as many games as I won.

I did some of the drills that the game offers in order to improve these skills, but the learning curve is steep and I found progress to be glacial.

Before cozying into my recliner on Thursday to start playing, I happened across a video called The Rotation Mistakes of Every Rank in Rocket League. My main takeaway from the video was that many people at my skill level (gold) just try to chase the ball around like a bunch of overzealous schoolkids rather than giving their teammates some space. This puts them too close to the ball to play well and removes their ability to defend their goal

In the next few games, I tried to stay further away from the ball and noticed an immediate improvement in what I was able to contribute. Instead of having to make finesse plays in tight spaces crowded with teammates and opponents, I had plenty of time and space to make easy shots because no one was near me.

What I had initially read as “get better at making tricky plays” was actually “position yourself better so that you don’t have to make tricky plays”.

A Rocket League fable

My main point here is that root cause misattribution is really easy. What can feel like dead obvious problems - being tight on money, or dinner taking too long to make at home, or having too much of your time occupied by code reviews - can all be second order effects of more distant problems.

Often, it’s tempting to think that the only way to address a problem is by fixing its most proximal manifestation - in the Rocket League case, I figured that I needed to just get better at making tough shots.

However, it’s often easier to make a small amount of progress on a more distant problem than significant progress on a proximal one. The reason that an effective coach can be great is that someone with more distance and experience than you can watch you work and look for these deeper problems.

It can definitely be worth the time to put yourself in reverse, get some distance, and see if you’re missing something important on the field.

Time between wins is just the amount of time in between someone successfully wrapping up one piece of work and wrapping up the next piece of work.

This metric is important because, in my opinion, one of the strongest contributors to burnout is when the relationship becomes murky between the effort you put in and the results you get out.

The burnout cycle

The burnout cycle that I’ve experienced myself and seen happen to other engineers is as follows:

1. An engineer takes ownership of a complex project and is excited about the challenge
2. Because the project is complex, the number of tasks required to finish starts to grow quickly
3. As the number of tasks grows, the total amount of work done remains high but the average pace per “branch” of the project decreases because the engineer is spread thin. At this point though, the engineer is still feeling good about the project, if a little overwhelmed.
4. As the pace slows on each branch, they remain open for longer and longer. The engineer starts to lose the feeling that their effort brings them meaningfully closer to their ultimate goal. This is a dangerous place to be.
5. Days start to slip away. What happened to today? This week? How does it take three days to reply to a relatively simple comment on a code review? “What’s wrong with me?” The engineer starts to feel bad about their work and they dread showing up to work, feeding into a negative feedback loop.

How can this be avoided?

As a manager, you’re the lifeguard on duty looking out for this anti-pattern.

This is where time between wins is important. Time between wins is a simple metric to tell you “has this person had any success we were able to celebrate recently?”.

What’s a healthy amount of time between wins?

In my opinion, somewhere between a couple of hours and a couple of days. Less than that and it’s unlikely that the task is large enough to feel meaningful. Greater than that and, in my experience, that relationship starts to feel fuzzy between effort and success.

How can a manager help decrease time between wins?

As a manager, you certainly can’t just hit the “easy win” button when someone’s time between wins starts to exceed your target threshold. You often lack the context to help the project along meaningfully and doing so would likely be construed as micromanaging, anyhow. So what can you do?

Ensure tasks are properly scoped

The most meaningful way that you can help is to make sure that tasks are well-scoped. Task scoping is mostly arbitrary, anyhow: you could have a task on your list of “Rewrite front-end in TypeScript” and it’s certainly a well-defined task, but if it takes three months it’s certainly too large to not be broken up further.

You should help your teammate break down any task that’s likely to take longer than a couple of days into smaller tasks. For my team, that generally means smaller GitHub issues. In each of those issues, you can say something like “Blocked by X” and then basically make the larger issue a list linking out to many smaller issues.

Ask that the owner delegate

Another empowering way to help decrease time between wins is to essentially make the issue owner a temporary team lead themselves. Are there any well-defined pieces that don’t require too much context ramp-up that can be handed off? If so, ask if you can take them yourself or delegate them to a teammate, accelerating the progress on the overall issue.

In my experience, it requires more prodding than you might expect to get someone to hand off subtasks. Doing so can feel like admitting weakness or failure. As a manager, you need to convince them that it’s neither and that delegation is a demonstration of leadership.

Pair program

Decreasing time between wins is, in my opinion, one of the great benefits of pair programming (in addition to knowledge sharing).

Paired tasks often take more than half the time they would have take if tackled alone, so from a “pure efficiency” perspective, pairing rarely seems worthwhile. However, you get to celebrate the win with someone else, making it sweeter. Furthermore, the win is shared by multiple people. In other words, you’re multiplying the emotional reward for the work, increasing morale.

A healthy, energized attitude towards work

Keeping time between wins low is a great way to help the people on your team enjoy a health, energized attitude towards their work. If they put in a full day worth of hard work on a worthwhile problem, it’s your job to make sure they know that work is valued and fits into a larger effort.

I find him interesting for two reasons:

1. He reasons from first principles about how to effectively build companies
2. He’s built a wildly successful technology company in a secondary market (i.e. not Silicon Valley)

As someone that’s also trying to build a successful technology company in a secondary market (Ann Arbor), I’m definitely interested in what Lutke has to say.

One such piece of advice that he offers could be paraphrased as:

When hiring in secondary markets, choose employees with the assumption that you’ll work together for at least 10 years.

That means that hiring based on the candidate’s growth potential is much more important than in primary markets.

This advice resonates with how I see people in Michigan view their jobs: generally, when they choose a job, they pick a job that they could see themselves working at for 5-10 years.

This contrasts sharply with Silicon Valley. If the average tenure at a company is two years, you can sure spend 5 hours each week mentoring Jill on how to better manage her team but gee whiz, by the time that actually starts to pay dividends she’s moved on to the company next door.

I do think that his “hire for growth” advice - while not wrong - is at least insufficient to be useful. What does it mean to hire for growth? Does this mean not to hire senior engineers?

In this post, I’d like to carry forward Lutke’s first principles reasoning in order to determine how you should hire differently in secondary markets.

What does “hiring for growth” mean?

I like to think of what a candidate offers looks something like a layered cake: from bottom to top, the layers are:

• Foundational character traits
• Foundational technical skills
• Professional technical skills
• Professional social skills

The lower the layer in the cake, the harder it is to change that aspect of the person.

Starting with the bottom:

Foundational character traits include how well someone can teach others, whether they can write well, whether they try to avoid the same mistake multiple times, and how eager they are to learn new things.

These traits take years to take shape and are often the direct result of someone’s upbringing and education. There’s a good chance that if you hire someone with a gap in one of these skills, you’re stuck with it.

Foundational technical skills are the skills that someone needs before they can even really start grappling with the real skills that make them good at their job. For software engineers, you’re probably looking at someone that can program well in at least one or two languages, understands what a unit test is and how to write it, knows the basics of databases and networking, etc.

These skills are certainly teachable (as demonstrated by many-a CS curriculum). However, they’re wide-spanning enough that it likely takes years to learn them in a comprehensive way that ensures good coverage.

For example, when working on a project, it’s hard to justify stopping in the middle to take a few weeks and go learn SQL. If you make a hire without foundational technical skills, you’ll find that you’re often faced with two choices when you encounter one of these gaps:

1. Halt whatever you’re working on and develop a plan to fill that knowledge gap
2. Do “just enough to get by” but never really fill the knowledge gap

The first makes it hard to put this person on any sort of time sensitive project, while the latter never really addresses the problem.

That’s why I think that foundational technical skills are a must-have, even when hiring for junior positions.

Professional technical skills

These are the skills that get “layered on top of” the foundational technical skills in order to really make someone effective at their job.

For software engineers, I consider these skills the ones that basically no CS undergraduate will have learned in school. These are things like how to effectively monitor code running in production, design an API, or scale a service as it gets more usage.

These skills are often learned through a combination of actually facing the problem and having someone else around that’s faced it before and can help you learn how to solve it.

Additionally, the problems themselves are often ones that are hard to replicate in the classroom. For example:

• The solutions to these problems cost significant money (how to implement monitoring and APM services)
• The problems only exist due to the volume of traffic that a service is receiving (how to effectively use a load balancer)
• The problems only exist due to many engineers collaborating on a project (how to ensure consistent code styles and distribute knowledge of best practices)

Junior engineers cannot be expected to have these skills.

Furthermore, because these skills are a result of facing the problem before and not all engineers specialize in all things, not all senior engineers should be expected to have these skills. However, senior engineers should be expected to have depth in a few of these areas and - if you’re hiring well - at least one of those areas hopefully addresses a pain point that your team currently has.

Hiring this way allows senior engineers to be the mentor necessary to effectively bring junior engineers and other senior engineers “up to their level” in their respective area of expertise.

Professional social skills

These skills are layered on top of even the professional technical skills and are the ones that allow someone to coordinate a group of people to work together and grow as a team.

I don’t have much insight to offer here: I’m still learning.

Back to Lutke’s advice

In secondary markets, hire for growth potential.

I’d like to offer a corollary to this:

In secondary markets, hire people who are both great teachers and avid learners.

Why great teachers?

Being an effective teacher requires a high level of empathy with the audience along with communication skills that are very, very hard to teach. That’s why I stuck it in the “foundational character traits” bucket above. It’s very likely that if you hire a bad teacher, they’ll remain a bad teacher.

The problem with this becomes apparent when you see what happens when you hire a bad teacher at each level:

• If you hire a senior engineer that’s a bad teacher, they’re unable to mentor the rest of the team in their domains of expertise. This means that you get minimal leverage on their skillset
• If you hire a junior engineer that’s a bad teacher, you’re investing years of training into someone from whom you’ll ultimately get minimal leverage from their skillset

In computer science terms, hiring good teachers yields superlinear returns because you benefit from both the work they do and the increased level of productivity they help others reach.

Hiring bad teachers yields a linear return because you benefit only from the work they do.

Why avid learners?

Along with teaching, there’s one other foundational trait that’s critical when hiring in secondary markets: the person has to be an avid and effective learner. A strong growth mindset is critical.

If you think of someone’s growth as a straight line, their attitude towards learning and their ability to effectively learn greatly influence the slope of that line. Finding effective learners is much more important when the time that the person will be spending with you is significant. In high-turnover primary markets, the skill change during the minimal time the employee spends with you is likely to be small regardless of their ability to learn, so you should hire them primarily based on their current abilities. This isn’t true when hiring in secondary markets.

Summary

• Carefully choose what foundational character traits you care about and figure out how to identify them in interviews.
• In secondary markets, seek out great teachers and avid learners
• Choose your foundational technical skills and figure out how to identify them in interviews.
• Senior engineers should have depth in multiple areas, at least one of which will broaden the team’s overall expertise.

P.S. The startup I work at - Channels.org - is looking to hire a senior software engineer! You can find out more and apply here.

Across most activities, we see the same cycle play out as people learn:

Let’s quickly zoom in on each step.

Do

This one’s pretty obvious: you do the thing that you’re trying to get good at. If you’re like me, you probably start out doing something poorly, but hey, ya got out there kiddo and I’m proud of you.

It’s important while “doing” to find some way to record a transcript of what really happened - a video recording, audio recording, or whatever other format you need to get a ground truth account of what really transpired here. We’ll use this to…

Analyze

This is where I - and many people - fall off the bandwagon.

In this phase, we look back at our “ground truth” with two goals in mind:

1. To compare how we performed against some standards that we’ve set for ourselves and see how the two compare. (We’ll get to that in a second. For now, let’s assume you have no standards)
2. To look for big problems in our “doing” where, even if we met our existing standards perfectly, we’d still have performed poorly. We’ll use those to revise and build our standards in the next step.

What we’re really looking for here is eureka moments where we see that problems we run into - that can feel unavoidable at the time - are often the result of earlier fixable mistakes.

Standardize

In this step, we take what we learned from our analysis and encode it into some sort of realistic ruleset that we can hold ourselves against in the future.

“Realistic” means that there can’t be a bajillion items on this list: at most you should be adding one or two items from each analysis section. Better still is if you can revise an existing rule to be more accurate.

Practice

The goal with practice is to narrow down the “doing” stage as much as possible to focus on getting “reps” in a particular area.

Practice is pretty draining, so I find it really helpful to set a visual timer (I like the Time Timer) for no more than 30 minutes and focus only on what I’m practicing for that time period. After that, I’ll walk away and do something else. If I try to practice for much longer than that, I find that I lose focus and start to fall into my old ruts again. It’s much more important to practice regularly but avoid these ruts than it is to practice for a long time.

… and do again.

With your new standards and skills in hand, it’s time to get back to doing.

This time around, try to approach the “doing” while holding your standards in half of your brain while performing the activity with the other half.

What you’re shooting for here is “marginally better than the last time I did this thing”. No trip through this loop yields significant results, but each leads to a little improvement that compounds over time.

Out-of-band learning

Outside of this loop, it’s sometimes necessary to do some out-of-band learning. This is when you read a book, talk to a coach, take a class, or watch a video.

I usually put too much hope in out-of-band learning. Frankly, if I’m not already doing the things I know I need to be doing, then there’s not a ton of sense in going off and learning new things that I should be doing. And yet.

The main goal of out-of-band learning is to help you improve your analysis skills. If you find yourself frequently unable to diagnose problems in why things went poorly in “doing”, it may be time to hit the books.

One of the hardest things about out-of-band learning is finding the right resources. A book aimed at advanced chess players will be worse-than-useless for beginners: it’ll be discouraging and focus on fine details that won’t really help beginners.

Similarly, I find coaches can sometimes be overly prescriptive or theoretical for my taste.

High quality out-of-band learning resources though can help give you ideas for what and how to practice as well as what themes to look for during analysis.

I don’t have much guidance for how to find good resources - “you’ll know them when you see them”.

The most helpful resource I used while improving at chess was John Bartholomew’s YouTube channel. John has a clear love for the game of chess, has a sense of humor about his mistakes, and is great at identifying unifying themes that span games and are applicable for players of a given level. You can get an idea of his style here.

Yikes! That’s a lot of work.

The main problem with becoming good at something is that it’s hard. That’s why most people just reach a passable competence in most domains and stop progressing.

However, this cycle is significantly more effective than the “do-do-do” cycle that most people use once they reach a basic level of competence.

In the next post, I’ll talk about some techniques that can be useful in sustaining this improvement for the long haul.

In that time, my rating improved from about 1100 (the ~50th percentile of players on chess.com) to about 1400 (the ~75th percentile of players on chess.com). While neither is a particularly impressive rating, I’m proud of the improvement and consider a 25 percentile improvement significant.

This post is the first in a short series where I’m going to explore what I learned in this time: not about chess, but about what expertise is and how to gain it.

Today, I’ll lay the groundwork for this series by answering two questions: what is expertise, and what makes someone an expert?

I hope this series is useful for anyone that wants to be better at something than they are or has found that their improvement in a domain has stagnated.

What is expertise?

My definition of expertise draws heavily from the “Learning How to Learn” online course: expertise is a set of mental models that allow you to effectively perform a task.

You can think of a mental model as just a way of “compressing incoming information” when looking at problems. By compressing the information, your brain can “summarize” what it’s seeing and act on that summarized version of the information instead of the “raw data”. Later, you can use that extra brainpower to apply additional layers of mental models, further increasing your efficacy at the task.

For example, rather than remembering the speed limit on every single stretch of road, most people (in Michigan) know:

• If you’re on a highway with a median, the speed limit is probably 70
• If you’re on a highway without a median, the speed limit is probably 55
• If you’re on a regular thoroughfare, the speed limit is probably 45
• If you’re in a neighborhood, the speed limit is 25

In math, mental models tell you how to answer “What is (x² - 1) times (y³ + 7)?”. To the unfamiliar, the problem might look intimidating. Anyone that’s taken algebra will immediately recognize that we’re just multiplying two polynomials together and the problem can be solved using FOIL.

In both cases, mental models allow you to identify the pattern associated with the incoming information (“I’m on a highway without a median”, “I’m multiplying two polynomials”) which then map to problem solving techniques associated with this pattern (“the speed limit is 55”, “I need to use FOIL”).

What makes someone an expert?

Experts have a set of mental models that allow them to be unusually effective at a given task.

As an example, the follow set of mental models might correspond to each chess rating:

• 600: You know how the pieces move
• 800: All of the above, plus you recognize some common openings and have learned the first few moves of very common openings
• 1000: All of the above, plus you know of and have practiced a few basic tactics (pinning, forking)
• 1200: All of the above, plus you have a basic understanding of how to protect your king and what pawn structures you should try to avoid (backwards pawns)
• 1400: All of the above, but your opening knowledge is deeper (generally can make it 7-8 moves into a game without getting lost)

It’s not that players that have a rating of 1400 are any smarter than players with a rating of 600. They’ve just built more effective mental models that allow them to better approximate how to perform the task “perfectly”.

How do I become an expert?

While I don’t pretend to have all of the answers, the time I spent improving at chess taught me some useful lessons. Competitive games are great for understanding the “meta” of how to gain expertise because there are lots of people striving to do so and discussing their strategies. Unlike in many other domains in “real” life (e.g. driving), competitive games usually give clear feedback about who’s better at the task.

I’ll share more about what I learned in this series: if you want to follow along, feel free to subscribe below.

When I first jumped into this role, I assumed our team moving fast would cause us to feel like we were moving fast. I also assumed that this was so dumbfoundingly obvious that it felt idiotic to even say it out loud. After a great week, we’d look back on the great work we did and feel encouraged by our speed.

However, over time I came to recognize that this wasn’t actually true in two important ways.

Velocity isn’t felt equally

On teams, it can be really hard to keep a pulse on what work is being done, especially if you’re an individual contributor who’s heads-down working on your own features. This is greatly exacerbated in remote teams like most have been forced to become due to COVID.

Our company’s founder Curtis and I soon found that how we felt about a team member’s contributions for a given week were less tied to those contributions than they were to how close we were to those contributions. Had we reviewed the code, or had someone else? Was the work easily visible in the frontend?

Velocity isn’t felt equally by all team members. Just because you feel like the team is moving fast doesn’t mean that everyone else does.

Perception of velocity affects future velocity

The second thing I noticed was that the team seemed more focused and productive after I sent out an email clearly summarizing what we’d done in the previous week, even if I hadn’t felt like the previous week wasn’t a particularly productive one.

Sharing the highlights from the previous week immediately made people feel like we were moving faster: after all, a huge corpus of work just became visible. Once people felt like the rest of the team was moving faster, they felt increased pressure to be a good teammate and contribute more themselves. It feels great to be a valued member of a highly productive team; it feels crappy to be the only contributing member of an unproductive team.

Perhaps even more importantly, people felt like their contributions were noticed and appreciated. It should be no surprise that people do better work when they know that work will be recognized.

Be the team crier

You know the town criers that you can imagine hollering news in a medieval city square? As a team lead, you need to play a role sort of like that by regularly distilling and sharing your team’s accomplishments.

For my team, this means sending out weekly or biweekly email updates calling out the great work that team members have done. As an added bonus, being the author of this email acts as a powerful lever about which tasks are highlighted. I can be sure to explicitly call out grungy but important work that might otherwise go unnoticed.

Writing all of this down feels almost silly because it’s obvious that doing this is good. However, it’s one of those obviously important things that’s easy to forget about.

Note to self: be the team crier.

However, we’ve since added a few more full-time developers and now have a team of around 5 ½ working on our product. We noticed as we added more developers that miscommunication became more frequent and people no longer knew what each other were working on.

We’ve tried a number of things to fix these problems and I thought it would be useful to quickly document what each was and how it worked.

Two week sprints

Date: April 13

The first thing that we put in place was two week sprints with a kick-off meeting on Monday. A sprint is just a period of time over which you commit to finishing a set of tasks. At the kick-off meeting, we discuss how much work we think each task planned for the sprint will be and then take turns claiming work that we’d like to do.

The following Wednesday, we gather again to show off what we accomplished. We also talk about what went well during the sprint and what we can do better in future sprints.

As the CTO, my primary responsibility is to take people’s feedback about what we can do better seriously. Taking the feedback seriously - especially when it’s inconvenient to do so - encourages people to give feedback in the future, creating a virtuous cycle.

Status Hero

Date: April 16

In order to better understand what each other are doing, we added Status Hero to our Slack. Status Hero asks people at the end of each day what they accomplished and how they’re feeling.

Ultimately, we ended up ditching Status Hero in favor of frequently updating Slack statuses: more on that later.

Zenhub

Date: April 17

Soon after installing sprints, we found that using Github project boards to manage them was getting unwieldy. Github lacks first class support for Story Points. Additionally, we felt that we needed a better understanding of how much work we had left until launch.

Zenhub acts as a Github project management tool, integrating into Github through a Chrome extension that adds UI elements to it. These UI elements include “Release”, “Epic”, and “Story point” fields on each issue.

Overall, we’ve found Zenhub really helpful in organizing our work, although sometimes its burndown charts are less than useful due to scope changes for a given release or milestone.

CrushingIt

Date: May 29

Even with all of the previous tools, we found it difficult to keep track of whether we were actually hitting the goals we set for ourselves each sprint. We were certainly getting lots done each sprint, but a lot of it was “scope creep” that we added after the sprint’s start.

Additionally, we felt that Zenhub’s board was demoralizing because it buried the things that you got done and showed you only what you had left to do.

To solve this, we created “CrushingIt” bot. CrushingIt is basically a Google Sheet that’s hooked up to our Slack through Google App Script. At the start of each sprint, we add the tasks that we’ve committed to finishing and, every time that someone marks one of their tasks as done, CrushingIt announces the completion to Slack and gives an overview of what’s left.

We’ve found this has three great side-effects:

• People have a better idea of what others are working on
• It creates a public occasion to celebrate the completion of a task
• Because the task list doesn’t include scope creep tasks, we have a much better sense of when we finish the tasks we commit to each sprint

Overall, the CrushingIt bot has been a tremendous success in improving our team’s productivity.

Slack statuses

Date: June 17

Eventually, we decided that Status Hero was more burden than help and we ditched it. To fill the gap that it left, we’re trying to update our Slack statuses more often - sort of like the old AOL Instant Messenger away messages - to keep teammates up to date on what we’re working on.

So far, it’s working pretty well, although the jury’s still out as to whether people will continue to be so diligent in updating these messages. Strangely enough, I think the fun of picking an emoji for your current work is a big plus and may help this stick.

Future

We still have lots of work left to do in the future. I fully expect that what works now for 5 ½ people won’t work well for 10, 20, or 100 people.

Probably the biggest three pain points that I feel are:

• We don’t have a clear enough accounting of how much work is left until important business milestones
• We need better processes to ensure clean hand-offs between product/design and engineers
• We need a way to quickly and thoroughly give story point estimates for issues. Doing it at the sprint kick-off takes too long and there’s too much pressure to “move on to the next task”

With that being said, I’m optimistic that we can find ways to tackle these problems too!

Sometimes after writing code for an hour, I’d step away only to realize that I hadn’t accomplished anything meaningful since I sat down.

Other times, I’d quickly check the news while my code compiled. When I remembered to go back to work, I’d find that the compilation finished ten minutes ago.

In short, I wasn’t focused enough.

A friend recommended I try out the Pomodoro Technique. Its prescription is simple: devote 100% of your focus to a clear task for a fixed amount of time, then take a break. Its name - the Pomodoro Technique - refers to the tomato-shaped kitchen timer the creator used to track his focus time as a student. (Pomodoro means tomato in Italian.)

Over the last ten years, I’ve implemented and dropped so many productivity habits that Erin (somewhat ironically) calls me a self-help junkie. Through that, the Pomodoro Technique has remained at the center of my productivity workflow. Above all, it’s effective at squeezing out the nebulous, unproductive middle ground that can unobtrusively slide between work and leisure.

If you’ve never heard of the technique before, perhaps this post can sway you to try it. Whether you’re a wee cherry tomato or an experienced beefsteak (is this metaphor working?), I hope this post helps you make the most of the Pomodoro Technique.

So what is the actual Pomodoro Technique?

Okay, I may have oversimplified above. The actual Pomodoro Technique is as follows:

1. Choose a task to work on
2. Start a timer for 25 minutes
3. Devote 100% of your focus to completing the task. If you get distracted, jot down whatever distracted you for later and get back to work.
4. When the timer rings, take a 5 minute break. Add a tally mark on a piece of paper to indicate that you’ve completed one “pomodoro” (one block).
5. After every fourth block, take a longer 25 minute break.

As with all techniques, though, the devil is in the details. Here’s what I’ve found.

A crisp task definition is critical

A “crisp task” is one that:

• Is accomplishable within a single block
• Makes it excruciatingly clear what the action associated with the task is. Not crisp: “Decide on my future profession”. Crisp: “Come up with a list of five potential professions with 1-2 sentence descriptions of why each might be a good fit for me”

I’ve found that time spent upfront clarifying the task pays outsized dividends when you get to work. I’ve also found it’s much easier to decide on a crisp task before you sit down at your desk.

Different tasks call for different block lengths

I usually work in either 25 minute or 50 minute blocks. The key decider of the block length is this question: “How likely am I to be going down a stupid path at the end of this amount of time, even if I’m 100% focused?” The more likely I am to be doing something stupid, the shorter the block needs to be. Otherwise, I’ll get tired and lose the mindfulness required to make good decisions.

For tasks like debugging a program, I often find I’ve gone down a stupid path at the end of even 25 minutes. This stands in contrast to writing, when I’m generally still humming along a good path at the end of 50 minutes. Writing in 25 minute chunks feels too choppy.

If you fail to complete the task within a block, strongly consider breaking the task down further

These situations usually fall into a few categories:

• Type 1: I just need a minute or two more to finish the task. In this case, I’ll finish it before my break.
• Type 2: The task was a little bit harder than I thought and I need another 10 or 20 minutes to finish it. In this case, I’ll take my break now and work on the task for another block.
• Type 3: The task was much harder or more ambiguous than I thought. In this case, I find it’s incredibly important to break the task apart into something that’s less ambiguous and accomplishable in a single block.

For me, there’s a huge temptation to say that a type 3 task is actually a type 2. To counteract this, I try to err on the side of breaking tasks apart: a too-small task is motivating, whereas a too-large task is daunting and can lead to procrastination.

Before starting your break, set a timer for when it will end

Otherwise, it can be too easy for a five minute break to stretch into a 15 (30, 45, …) minute break.

I like going for walks. Walks make Charlie happy.

Try it out!

There are still aspects of this technique I haven’t nailed down: how should awkward chunks of time between appointments be handled? Should blocks be shorter at the beginning of the day when getting started is most daunting? If you’re blocked on a task because someone isn’t responding, how long should you wait before switching tasks? These are all questions that still stump me.

It’s certainly not a complete or perfect system, but it’s the best one I’ve found so far.

All of this transformed our stairs from looking like this:

to looking like this:

However, we never replaced the railing. After watching a few too many guests nervously butt-scoot down the stairs, we decided it was time to do so.

I wussed out on installing the banister myself and instead hired Macomb Stairs & Millwork to do it. Within a month, they were able to fit us in. It took them about two hours and a lunch break to install the banister. Impressive.

Erin and I are thrilled with how it came out.

Unfortunately, Macomb Stair doesn’t paint or stain banisters. We want to stain the handrail to match the floor but paint the newels (the thick vertical posts) white to match our trim. This would require two different contractors (a painter and a wood finisher) and would likely be close to as expensive as the banister itself. Because of this, I’m going to tackle it myself.

I started by going to Woodcraft in Canton, where the clerk recommended using a gel stain on the handrail. The benefit of using a gel stain over a traditional stain is that gel stains are actually just colored varnishes that sit on top of the wood, whereas traditional stains soak into the wood. Poplar, which our bannister is made of, is notorious for accepting stain poorly, resulting in a splotchy look. Because gel stain just sits on top, though, it allows you to achieve a much more consistent color over woods that usually stain poorly.

The clerk recommended using the General Finishes Georgian Cherry gel stain. This stain matches the darker parts of our floor very well - too well, in fact. Our refinished treads are a little oranger than our floors and, because of that, the Georgian Cherry gel stain matches the old floors but doesn’t quite match the new treads.

Here’s a sample board that I stained with the Georgian Cherry stain with a backdrop of our stair treads. The left side of the board received one coat of gel stain and the right side two.

You can also see that there’s a lot of variation in color on the side with one coat. I suspect that’s because I was a little stingy with the pre-stain wood conditioner that’s supposed to make the wood less porous, giving a more even finish.

To better match the color of the wood, I also picked up some mahogany gel stain which is a little oranger. I read online that you can mix gel stain colors and I tried a few different ratios of Georgian Cherry to Mahogany to find which matches best.

However, none of them looked right.

Refusing to accept defeat, I went to Home Depot and picked up two new gel stains: Minwax Cherrywood and Minwax Mahogany. I created a new poplar sample piece where I used the Minwax Cherrywood for most of the first coats and tried various other stains for the second coat.

This gave me this sample piece:

It’s a little hard to see here, but there are five different sections with different stain combinations. From farthest to closest, they are:

1. Minwax Cherrywood for both coats
2. Minwax Cherrywood first coat, General Finishes Georgian Cherry second coat
3. Minwax Cherrywood first coat, Minwax Mahogany second coat
4. Minwax Cherrywood first coat, General Finishes Mahogany second coat
5. Minwax Mahogany for both coats

I think either 3) or 4) are close enough matches, but I ultimately chose 3) as the closest match because I thought the light cherry undertones peeked through a little more with the Minwax Mahogany than the General Finishes mahogany, which matched the stair treads slightly better.

So I finally have my color! Time to move forward with doing some real work. In the next installment, I’ll prep and stain the railing.

Here’s what our condo looks like, all the way from when we originally bought it until Friday night:

It was also looking likely that it would stay this way for a while. My Uncle Mike, who’s installing the second bedroom for us, was busy this weekend. I was busy for the next two weekends, and he was busy for the subsequent two. This meant that we wouldn’t get the second bedroom roughed in until late October. (For those like me that have no idea what “roughed in” means, it’s when the floor joists, plywood floor sheets, and wall studs are installed.)

This past week, I was worried about this. Most of the remaining projects, like the electrical work, installing drywall, painting, and installing trim on the second floor can only be done after the second bedroom is roughed in. To further complicate things, some of those jobs require coordination with contractors, which nudges the difficulty of their scheduling into “hellish” territory.

Take the electrical work, for example: we need an electrician to work on our condo twice before we’re finished. The first time he visits, the second bedroom needs to be roughed in but without drywall so that he can route the power through the studs without having to cut open and then patch drywall, which would be more time consuming and therefore expensive. The second time he visits, all drywall needs to be up but not painted so that he can do his finish work: cutting holes and placing the canisters for recessed lights, adding the switch covers, and so on. In total, he estimated this would take about a day and a half.

At the estimate, the electrician told me to call him when he could come out for his first visit. If I called him in late October, and it took a week for him to come in, and then we put up drywall, you can begin to see how vanishingly unlikely it was that we could hit our target move in date of early November.

So, you can imagine my relief when Uncle Mike texted me on Friday asking “What time in the morning”. I worried that if I acknowledged that I thought he was busy this weekend, he might agree that indeed doing anything sounded better than working on Saturday and instead decide to go to the park with his dog. So instead, I just replied “Is 9 too early? I’m not picky”, and we settled on that.

On Friday night, my Dad graciously helped me prepare for Uncle Mike coming on Saturday by ripping out the upstairs trim. One thing I’ve learned so far is that, if you’re relying on a skilled tradesperson with a tight schedule to help you out, try to do as much of the menial work beforehand as possible. It ain’t glorious - boring cleaning and running around may not feel like real work - but much of it would take the skilled tradesperson as long as it’d take you, and their time is a heck of a lot more valuable.

So thankfully, Uncle Mike was able to start working shortly after he arrived yesterday morning and boy did he get a lot done. While I acted as an extra set of hands - holding the tape measure somewhere, moving materials, tearing out drywall that he cut, cleaning, keeping him well fed and hydrated - he roughed in the entire second bedroom. This includes a closet with a “step” in it, an idea I stole from our neighbors across the hall, giving a bigger closet and providing sufficient clearance while walking down the stairs. The amount of work that he got done in a grueling, 10.5 hour day was truly impressive, and Erin and I are incredibly appreciative of his work.

He also showed me how to cut trim with his miter saw and install it. I think I got the gist of it, but have no doubt that I’m going to run into some trouble based on his many sentences that started with “Obviously” or “You can see here” when in fact the point he was making didn’t seem obvious and in fact I couldn’t really see there. I asked lots of questions when they seemed important, but also realized that a lifetime’s worth of experience installing trim couldn’t be summarized in 45 minutes to a nincompoop who had never used a saw before. I figure that I’ll have to make some mistakes for myself before I can truly appreciate the more nuanced points, but I’m at least now confident that I can use the miter saw without losing fingers. I even managed to install the new casing on a door and a half and can already feel myself moving faster.

Lastly, my Dad stopped by to help even more. I’m going to try to paint our cabinets (more on that later), so he sanded down the doors of the cabinets we’re going to replace in order to give me a few to practice on. He also ripped up the hardwood floor covering half of our second bedroom and knocked out half of of a wall between the second bedroom and the stairwell, which will allow us to more easily install the new drywall.

Here are a few pictures from the day:

All in all, we made a ton of progress, and I’m relieved that we’re able to call the electrician now to schedule a first visit. In the meanwhile, there are a lot of projects that I can make progress on - learning to use the paint sprayer, painting the cabinets and windows, priming the first floor walls, installing the first floor trim- that thankfully don’t rely on the second bedroom being installed.

One of our must-haves in our home was two bedrooms: in the short-term, we can use that second bedroom as a guest bedroom and office. In the long-term, we can turn it into a nursery for baby Andrews.

However, the home that we ultimately purchased was a spacious one bedroom, two floor loft. The reason for this is that the affordable options in the neighborhood were sparse and that I noticed in the walkthrough that this condo could be trivially converted into a two bedroom. Erin’s Uncle Mike, a lifelong carpenter, confirmed this in the second walkthrough and offered his help in the project. We now know that the reason for the easy conversion is that the condo was in fact originally a two bedroom before it was renovated by an architect into a hip loft. Well, we’re not hip, and what’s done be undone. Looking back, though, I do question my judgment in using the word “trivially” to describe any project as seemingly large as adding a second bedroom, even with the help of an experienced carpenter.

In addition to the structural changes, Erin and I wanted to make a number of updates that would make the condo better fit our style - somewhere between Erin’s traditional tastes and my contemporary ones. It’s plenty livable now, but we’re excited to have a home that we can make changes to, and many of these changes are a heck of a lot easier to make while we’re still living with her parents than after we move in.

So fast forward a month to now. I’ve done deep research on various topics - I know more about natural countertops than I frankly care to - and made some early decisions. We’ve also begun actual work on the condo in earnest, although that first hammer swing that took the condo from livable to “under construction” was admittedly gut-wrenching.

The short list of things we’ve actually accomplished:

• Chosen and met with a decorator, who’s helped us form a list of what we’d like to update before moving in

• Selected new trim (baseboards, crow mouldings, and door casings) to install

• Purchased that new trim and schlepped it to the condo

• Ripped out the old quarter-rounds and baseboards

• Received a paint estimate and booked a painter for late October / early November

• Chosen an electrician and received an estimate on how much the wiring will cost for the second bedroom change

• Bought some tools, like a professional paint sprayer (which I’ll likely sell when I’m done), a random orbit sander, and a detail sander

• Borrowed some other tools that I’ll need, like a miter saw, air compressor, and nail guns

• Purchased the joists, 2x4s, plywood, drywall, etc. that’s required to convert the condo from a loft to a two bedroom

• Schlepped those materials to the condo (thanks to the enormous help of my friends Andrew and Dan)

• Built out a floor for the second bedroom (and by “built”, I mean “watched Uncle Mike build”). Ladder holding counts as work, folks.

• Stripped the wall between the staircase and the upstairs down to its original studs, removing 4 inches or so of wall

• Wrote a short post about what I accomplished so far

This list pales in comparison to what we still have to do, though. To list a few of the biggies:

• Add studs for the wall and closet to the second bedroom

• Install the drywall in the second bedroom (and the newly-created ceiling in the first floor)

• Mud and sand that drywall

• Refinish the stairs

• Decide with our decorator on paint colors

• Install all of the new trim

• Paint all of the new trim

• Order new, taller cabinet uppers

• Paint all of the new and old cabinets

• Paint all of the walls

• Possibly move the washer/dryer from the walk-in closet of the master bedroom to the upstairs hallway, which will require moving a wall

• Choose a new countertop for part of our kitchen

• Rip out the old backsplash and install a new one

Suffice to say, we have a long way to go.

So why start blogging about the experience now, part-way through the process? Honestly, the reason is purely a selfish one: in the few past home improvement projects I’ve done, I have a tendency to move too fast or too slow after the initial novelty of the project wears off. However, when I write something down for a broader audience, I trick my brain and end up holding myself to a higher standard. I hope that by publishing what I learn, I’ll push myself to move as quickly as possible and as slowly as necessary to do the job right.

In a future post, I’ll probably post some pictures of the place as well as some progress photos of the work I’ve done. I’ll save that for episode two, though.

Hi Eric,

I’m incredibly concerned about the $2.9B MDOT plans you wrote about in Retaining walls, extra lane could be in works for I-94.

MDOT’s reason for widening the highway resonates well with common sense: if traffic is expected to grow, and the road is currently two lanes wide, then surely widening it to three lanes should help?

However, this ignores a well-known, subtle truth that many traffic engineers ignore known as “induced demand”. At its core, induced demand says that congestion effectively remains constant because, if you increase a road’s throughput, people will drive more and ultimately make the road as congested as it was before.

The Texas Transportation Institute summarized the phenomenon well in this study:

Metro areas that invested heavily in road capacity expansion fared no better in easing congestion than metro areas that did not. Trends in congestion show that areas that exhibited greater growth in lane capacity spent roughly $22 billion more on road construction that those that didn’t, yet ended up with slightly higher congestion costs per person, wasted fuel, and travel delay.

Because of induced demand, planners in Great Britain are no longer allowed to justify new highways on the basis of reduced congestion. Confusingly, in Michigan they still are.

I’m not suggesting that we let I-94 languish: if the road is in disrepair, then by all means it should be refinished. Perhaps it’s necessary to redesign some of the (treacherous) entrance ramps for the freeway. But before we embark on a 17 year project that costs enough money to kickstart a real light rail system for Detroit, we should strongly consider evidence that suggests that the current plan won’t have the desired effect.

I originally did this by pushing my feature branch to the project’s public Git repo from one computer and fetching that branch from the other computer.

# On my desktop, after making commits...
git push origin my_feature_branch

# Later, on my laptop...
git fetch origin
git checkout -b my_feature_branch origin/my_feature_branch

This is problematic, though, if the project you’re working on doesn’t like your ugly work-in-progress branches polluting its public repo.

The solution is to do this same push-fetch dance with a fork of the main repo instead of the main repo itself.

At a high level, here are the steps:

1. Create the fork. In Github, you go to the project’s page and click the “fork” button.
2. Add the fork as a remote repo on your desktop’s repo.
3. Add the fork as a remote repo on your laptop’s repo.

In practice, it looks like this:

# 1) Create the fork.

# 2) Add the fork as a remote repo on your desktop's repo.
#    Inside the my-repo project on your desktop...
git remote add fork <your_fork_url>

# 3) Add the fork as a remote repo on your laptop's repo.
#    Inside the my-repo project on your laptop...
git remote add fork <your_fork_url>

Replace <your_fork_url> with the SSH clone URL found on your fork’s Github project page.

Now you can do things like:

# In my-repo on your desktop...
git checkout -b add_readme
echo "This project loves Git!" >> README.md
git commit -am "Adds to the README."

git push fork add_readme

# In my-repo on your laptop...
git fetch fork
git checkout -b add_readme fork/add_readme
cat README.md
# ...
# This project loves Git!

You can do the same thing in the opposite direction, too.

Pretty nifty!

Be proactive.

Accept control of your life and focus on the things that you can control (your “circle of influence”) rather than the things that affect you (your “circle of concern”). Make and keep commitments to yourself and others; by doing so, you grow your circle of influence and build sense of personal honor that helps you to keep commitments even when you don’t feel like it.

Begin with the end in mind.

For all important projects, clearly define what success looks like and keep that definition at the center of your work. Life is your most important project: it’s critical that you do define what success in your life means. Imagine how you want others to describe you at your funeral and write a constitution describing the characteristics that would merit such a description. Memorize and strictly adhere to that constitution. Spend time each day to review it and visualize the minutiae of life under it. Following these steps will ensure that you aren’t making progress towards the wrong goal.

Put first things first.

Now that you’ve clarified your principles and values, effective self-management around them is the primary determinant of whether you’ll reach your goals. A key component of this is to distinguish importance from urgency. Ineffective self-managers often fail to prioritize non-urgent but important tasks and decline urgent but unimportant tasks.

A good strategy to focus on what’s important each week is:

• Determine the roles that you need to fulfill for the week.
• Determine when you’ll fulfill each of those roles.
• As things come up, rearrange your schedule around those roles.
• Follow your schedule.

Delegation is also key to accomplishing these goals, but effective delegation requires growing stewards rather than drafting gofers.

Think win/win.

In every negotiation involving another party, seek a solution that’s mutually beneficial. Try not to view problems as having binary solutions or being zero-sum; often times, there are less obvious paths that are ultimately more agreeable. Finding these paths requires a clear understanding of what each party wants. If no such mutually beneficial solution can be found, walk away.

Remember that public victory does not mean success over other people; it means moving towards a mutually beneficial results.

Seek first to understand, then to be understood.

Sincerely aim to fully understand the viewpoint of the person that you’re communicating with. Listen empathetically. Their concerns are valid - figure out why. A great way to do this is to rephrase content and reflect emotion. It sounds like:

“Dad, I’ve had it! School is for the birds!” “Ah, you’re feeling really frustrated about school.”

When doing this, let the other person speak. Don’t just look for an opportunity to respond. Avoid giving advice unless asked. Instead, try to help the other person to find their own solutions. If the other person is in a position where advice would be useful, they’ll ask. Lastly, if you find yourself in a conversation in which you’ve violated these rules, apologize and ask to restart.

Presentations are a great opportunity to use these skills: allow the person you’re trying to influence to fully explain their viewpoint, and then rephrase it back to them, confirming that you understand where they’re coming from. They’ll be much more likely to accept whatever solution you propose if they know that you understand and respect their concerns. Accept that this means you’ll be influenceable; this is key to being influential. Logic is surprisingly unimportant in influencing others.

Synergize.

Seek out moments of synergy, when things take a turn for the unexpected and fantastic. These experiences often begin with someone extreme honesty, authenticity, and courage and end with immense creativity and a close brush with chaos. Empathy is key to creating these situations; you have to allow someone else’s world view to influence your own. This creates a new and potent idea cocktail. And when trying to create synergy, “Seek not to imitate the masters, rather seek what they sought.”: look for new synergistic experiences rather than trying to recreate past ones. Find others that have different viewpoints and try to understand how they see the world. And, when trying to communicate these people, don’t be defensive or even just respectful: be empathetic.

Sharpen the saw.

Constantly focus on improving the primary areas of life:

• Physical: Eat healthily. Exercise regularly and sustainably. Find ways to manage stress.
• Social/emotional: Live your life in service of others. Practice empathy. Synergize. Rely on instrinsic rather than extrinsic motivation.
• Mental: Allocate time to learn new things. Read good literature. Write frequently to practice crystallizing your thoughts. Live deliberately through planning. Grow your mental discipline.

By continuously learning, committing to worthwhile things, and meeting those commitments, you get caught in an incredibly beneficial upward spiral.

I’m probably a little over-enthusiastic about these types of self-help books. I read How to Win Friends and Influence People by Dale Carnegie and talked about it obnoxiously to my friends, but found as I tried to apply its lessons that I need to basically reread the book continuously to remember all of its many lessons. That’s the biggest reason I like 7 Habits: my memory’s terrible, and this way I don’t have to remember as much.

The second habit in the book is “Begin with the end in mind”. Essentially, Covey suggests that you begin all important projects by clearly defining in writing what success looks like. Then, as you work on the project, you should frequently review the success criteria and make sure that you’re on track.

Given that life is essentially one big project, he suggests having such criteria for your life. When you die, how do you want your life to have been lived? What are some principles you should live by in order to live such a life?

He encourages readers to actually write these things down as a sort of personal constitution, review that consitution regularly, and curate it over time.

Here’s what my first attempt looks like (with some points unabashedly borrowed from Rolfe Kerr’s personal creed in the book):

• Succeed at home first.
• Seek and merit divine help.
• Never compromise with honesty.
• Seek to earn the trust of yourself and others.
• Know and meet your obligations.
• Listen twice as much as you speak.
• Defend those who are absent.
• Care for what belongs to you. Care for what belongs to others as if it were your own.
• Be stubbornly positive.
• Develop one new proficiency each year.
• Focus on one task at a time.
• Start with small wins to build momentum.
• Hustle while you wait.
• Ask for help when necessary. Don’t shy away when it’s offered.
• Be generous with your time and money. Don’t squander either.
• Keep self-praise to yourself.
• Be the first to criticize yourself and the last to criticize others.

What makes org mode great is that whenever you find yourself issuing a command reguarly that takes a few too many keystrokes, you can write a tiny bit of Elisp to turn that command into a single shortcut. This luxury doesn’t exist with non-digital implementations of GTD (it’s tough to write Elisp to open a file drawer, put something into the waiting category, and close the file drawer, although Perl may get the job done).

The somewhat nasty thing about org mode, though, is that it’s a little tough to get set up on your phone. There are a couple ways to do so, but I’ve found the easiest to be through MobileOrg and Dropbox.

MobileOrg is a fairly simple editor for org files on your phone. It has a drop-in connection for Dropbox, so if you store your org files there, you can access them from multiple computers and your phone.

Here are the basic steps in getting this combination set up, assuming that you already have org-mode set up on your computer:

• Sign up for a Dropbox account.

• Download the Dropbox app for your computer. This app makes your Dropbox file system accessible as a normal folder on your computer. You’ll want to do this on each computer that you’ll be editing org mode files on.

• Create a folder in your Dropbox folder that will store your org files. I use $HOME/Dropbox/org.

• Create a folder in your Dropbox folder that will store your org files that have been exported for the mobile app. I use $HOME/Dropbox/mobileorg.

• In your .emacs file, add the following line to let Emacs know where you want to export your mobile org files to:

    (setq org-mobile-directory "~/Dropbox/mobileorg")
    

• Set your org-agenda-files variable to the folder where you’re storing your org files. You’ll know it’s set correctly when you can run org-iswitchb to switch between your different org mode files. You can set it by adding the following line to your .emacs file:

    (setq org-agenda-files (list "~/Dropbox/org/projects"))
    

• Create a sample org mode file to test that everything’s hooked up correctly at ~/Dropbox/org/projects/test.org. It should read something like:

    * TODO This task should show up. 
    

• After you’ve done this, export your new file by running org-mobile-push. This basically wraps up all of your changes to org files and packages them to be sent to your mobile device.

• Download the mobile org app on your device. When it asks where to look for your og mode files, choose Dropbox and authenticate with your Dropbox account. When asked what folder to use in your Dropbox file system, choose mobileorg.

• You should see your sample task on your phone!

One somewhat nasty thing about this system is that you have to run org-mobile-push every time that you want to export your computer’s changes to your mobile device, and org-mobile-pull every time that you want to import changes made on your mobile device to your computer. I’m still looking for a better system than manually doing this, but for now, I still prefer this to using a less flexible task manager.

Now pardon me - I have to get some things done.

You know you’re one of only a few people in the world who is in a position to do that, right? Anyone else would (rightfully!) get torn to shreds on HN by tptacek or yourself. And I say “rightfully” because it is very likely that other people would screw up some central aspect to the security of any new product that claims security.

It’s not just that, though. Anyone else with your knowledge but no standing would be scorched for saying what you just said. “Throw away the one thing that has proven to be secure and write our own protocol” doesn’t go hand in hand with “serious cryptographers trust what this person is saying.”

The truth is probably that either you do this or nobody will.

You should. The world would be better for it.

I love this comment because it’s such an earnest plea to stop kicking the can down the road. Too often, no one else ever gets around to the task. No one else is more qualified than you are, right now. So stop complaining or get to work.

For those who want to read more, here’s a link to the full Hacker News post.

/shrug

Chances are if you had to fight hard to get this far, most other people turned around a while ago. And if that’s the case, you’ll look really good if you whack a few easy to spot nails with your shiny new hammer that no one else has any idea how to use.

Practically, this could mean a few things:

• If you just figured out a swamp of your codebase, clean up the unit tests for it (if they exist and are nasty) or write some new ones (if they don’t).
• If you had to learn how to do some performance profiling to speed up your code path, try profiling some other really important code paths in your project. There’s a good chance that if you had to try really hard to write performant code, some dolt messed it up elsewhere.

It may not be worth following the white rabbit for days, but a few hours? Almost certainly.

Check it out!

I really like python so far. It’s quick and dirty and great. The problem though, is that some of the expressiveness that makes it great costs speed. Loads of it. The problem I was working on necessitated working with fairly large data sets, and my program that needed to run in less than two seconds was instead taking 15-20s.

I tried profiling my program with cProfile, and it told me that everything was slow.

So I did what any programmer worth squat does: I looked online for an answer. The interwebs seemed to suggest that writing efficient python requires learning numpy, a python library that provides efficient ways to work with numbers and matrices. Despite my resistance to learning a new library, I decided that it was worth a try.

In an effort to do as little work as possible, I decided to start by converting only a small portion of my program to use numpy. Here’s the portion of my program that reads the input, sans numpy:

def main():
    while True:
        m, n = map(int, raw_input().split())

        if m == n == 0:
            break

        live_cells_count = int(raw_input())

        live_cells_unpaired = []
        while len(live_cells_unpaired) < (live_cells_count * 2):
            live_cells_unpaired.extend(map(int, raw_input().split()))

        live_cells = [live_cells_unpaired[i:i+2] for i in range(0, len(live_cells_unpaired), 2)]
        generations = int(raw_input())

        # In form grid[ring][cell]
        grid = [[([i, j] in live_cells) for j in range(n)] for i in range(m)]

And here’s the same portion with numpy:

def main():
    while True:
        m, n = map(int, raw_input().split())

        if m == n == 0:
            break

        live_cells_count = int(raw_input())
        live_cells_unpaired = []
        while len(live_cells_unpaired) < (live_cells_count * 2):
            live_cells_unpaired.extend(map(int, raw_input().split()))

        live_cells = [live_cells_unpaired[i:i+2] for i in range(0, len(live_cells_unpaired), 2)]
        grid = np.zeros((m, n), bool)

        for live_cell in live_cells:
            grid[live_cell[0], live_cell[1]] = True

        generations = int(raw_input())

They look almost identical. The difference? Without numpy, the input takes some 8 seconds to read in. With numpy, it takes .2s.

Sold.

Why this is the best part is probably obvious. Why it can be the worst, though, stems from the fact that it can lead to some serious self-esteem issues. It’s hard not ask yourself “Am I ever going to be as good as these people?”.

One thing that I’ve found helpful is to remind myself: even smart people are just people. They can only type so many words per minute and have so many ideas. Most of their ideas are probably bad, just like mine.

Given this, there should be some path that I can take that will get me to their skill level. Finding that path seems like a daunting task, though.

To avoid being frozen by indecision, I’ve started to employ what I call the greedy strategy of self improvement. The steps are simple:

1. Pick the thing that you feel is holding you back the most right now.
2. Dedicate a couple months to remedying this deficiency.
3. Repeat steps 1. and 2. without regressing on already-addressed deficiencies.

I call this the greedy strategy because it’s what’s known in computer science as a greedy algorithm, where you take the action that seems optimal at each step along the way.

Here’s how it’s been going for me:

• Leading up to July 2014, I’d wasted several months building beautiful systems to answer questions that I realized only in retrospect were flawed ones. So from July until September, I focused on getting answers quickly and avoiding premature perfectionism.
• After this, I realized that people couldn’t rely on me because I wasn’t organized. I then spent October through December on organization and becoming more considerate about how I spent my time.
• Now that I’ve got my tasks under control, I’ve found that I’m able to juggle distinct projects better, so I’m spending January through March on increasing the number of parallel projects I’m able to effectively handle.

My most recent undertaking has helped demonstrate the beauty of the greedy strategy: six months ago, I didn’t know I needed to increase my parallelism. The problem only became obvious once I had the tools I needed to address it. With the greedy strategy, I don’t need to be smart enough to craft a master plan: I just need be aware enough to recognize what needs improvement now.

Remember when we made insert-random-spaceballs-quote an interactive function so that we could bind it to a key? Declaring that a function is interactive is a little bit like signing a contract - you’re expected to play nice with certain features of Emacs if it makes sense for your function to do so. Specifically in our case, it makes perfect sense for our function to accept what’s known as a prefix argument.

A prefix argument can be passed to a function by pressing C-u, entering a number, and then calling the function. Functions that accept prefixes promise to do something sensible with the number that’s passed to them.

As an easy example, let’s take a look at the function previous-line, usually bound to C-p. Calling it once with C-p moves back to the previous line. Using C-u 10 C-p to pass it a prefix argument of 10 moves back 10 lines instead.

Following this logic, it makes sense for insert-random-spaceballs-quote to insert ten random spaceballs quotes when called with a prefix argument of 10.

How do we do get our function to accept a prefix, you ask? It’s pretty darn easy. Rather than calling (interactive) in that function, we just call (interactive "p"). Then we mark our function as accepting that argument.

Like this:

(defun insert-random-spaceballs-quote (arg)
  (interactive "p")
  ...

That argument is set to nil when no prefix argument is passed to the function; otherwise, it’s set to the prefix argument. This means that we want to execute insert-random-spaceballs-quote arg times if arg is set; otherwise we execute it once. Something like this:

(defun insert-random-spaceballs-quote (arg)
  (interactive "p")
  (dotimes (num (or arg 1))
    (insert (get-random-element spaceballs-lines) "\n")))

Now we can rest peacefully knowing that the interactive contract was fulfilled.

Eager to bring this idea to fruition, I’ve decided to teach myself the basics of writing a major mode. Specifically, I’ll be creating a mode that inserts a random Spaceballs quote every time the user hits ENTER.

I wrote the skeleton for this new mode based on this Sample Mode tutorial. It looks something like this:

;; ~/.emacs.d/playground/spaceballs-mode.el

(defvar spaceballs-mode-hook nil
  "Hooks to be run when entering spaceballs-mode.")
(defvar spaceballs-mode-map
  (let ((map (make-keymap))) map)
  "Keymap for spaceballs-mode")

(define-derived-mode
  ;; Name of the mode
  spaceballs-mode
  ;; Name of the mode that we're derived from
  fundamental-mode
  ;; How we appear in the mode line
  "spaceballs"
  "Major mode for generating random Spaceballs quotes.")

(provide 'spaceballs-mode)

The only part that’s not self-explanatory is spaceballs-mode-hook. This variable gives users a place to add their own hooks. These hooks allow a user to tell Emacs to perform certain actions (e.g. enable flycheck-mode) when spaceballs-mode is loaded.

Check that you’re able to load up our mode by going to a new buffer (C-x b *spaceballs*) and loading up our mode with M-x load-library spaceballs-mode. Emacs should allow you to enter this mode, although it’s not too exciting at the moment.

So now we’ve done the easy stuff: let’s move on to the more interesting parts. Adding the keybinding to insert the quote seems like a good next step. We can do this by using define-key in conjunction with our existing map variable which stores our mode’s keymap. That looks like this:

(defvar spaceballs-mode-map
  (let ((map (make-keymap)))
    (define-key map (kbd "RET") '(lambda ()
                                   (interactive)
                                   (insert "Spaceballs quote goes here.\n")))
    map)
  "Keymap for spaceballs-mode")

There are two parts that might be confusing here:

• insert just inserts whatever argument you pass it into the active buffer.
• More interestingly, interactive tells Emacs to make the function available to the user. You can’t map things to keys unless they’re marked as interactive.

Reload the mode with M-x unload-feature spaceballs-mode followed by M-x load-library spaceballs-mode. You’ll have to reenable the mode within *spaceballs* as well. Once you do this, though, you should find that mashing ENTER results in something like this:

Great! We’re getting closer. Now we just have to work on the actual random quote part. We can start by creating a text file containing the quote list at ~/.emacs.d/playground/spaceballs-quotes.txt:

That's all we needed, a Drewish princess.
What? You went over my helmet?
They've gone to plaid.
We ain't found shit.
That's amazing. I've got the same combination on my luggage.
You have the ring, and I see your Schwartz is as big as mine.
That's what I ordered. Change my order to the soup.

We can load that text file as a list of lines using the same technique that we used to read the list of animals in [Friendly Veterinarian]({% post_url 2014-10-08-the-friendly-veterinarian-2 >}}). To do so, add this at the top of spaceballs-mode.el:

(defun get-lines-from-file (file-path)
  "Returns the lines of the file at file-path as a list."
  (with-temp-buffer
    (insert-file-contents file-path)
    (split-string (buffer-string) "\n" t)))

(defvar spaceballs-lines
  (get-lines-from-file "~/.emacs.d/playground/spaceballs-quotes.txt"))

After reevaluating our mode with M-x eval-buffer, test that spaceball-lines was populated correctly by inspecting its value (M-: spaceballs-lines).

Now that we have this list, we can create a new function that gets a random element from it:

(defun get-random-element (lst)
  "Returns a random element of a list."
  (elt lst (random (length lst))))

This function:

• Generates a random number between 0 and the length of lst
• Accesses the element of lst at the index of that random number

Not bad at all. With our newly-minted get-random-element function, we can now create a function that inserts a random Spaceballs quote.

(defun insert-random-spaceballs-quote ()
  (interactive)
  (insert (get-random-element spaceballs-lines) "\n"))

As a review, here’s what our whole file looks like:

;; ~/.emacs.d/playground/spaceballs-mode.el

(defun get-lines-from-file (file-path)
  "Returns the lines of the file at file-path as a list."
  (with-temp-buffer
    (insert-file-contents file-path)
    (split-string (buffer-string) "\n" t)))

(defun get-random-element (lst)
  "Returns a random element of a list."
  (elt lst (random (length lst))))

(defvar spaceballs-mode-hook nil
  "Hooks to be run when entering spaceballs-mode.")
(defvar spaceballs-mode-map
  (let ((map (make-keymap)))
    (define-key map (kbd "RET") 'insert-random-spaceballs-quote)
    map)
  "Keymap for spaceballs-mode")
(defvar spaceballs-lines
  (get-lines-from-file "~/.emacs.d/playground/spaceballs-quotes.txt"))

(defun insert-random-spaceballs-quote ()
  (interactive)
  (insert (get-random-element spaceballs-lines) "\n"))

(define-derived-mode spaceballs-mode fundamental-mode "spaceballs"
  "Major mode for generating random Spaceballs quotes.")

(provide 'spaceballs-mode)

That should be it! Reload the mode and your *spaceballs* buffer and make sure that everything’s working alright. You should be seeing something like this when you hit ENTER:

Congratulations! Together, we’ve made the greatest contribution to the Emacs community since M-x butterfly. We can each now say, “Look upon my works, ye Mighty, and despair!". Or… something.

You’re probably already familiar with what this looks like in practice. You know how in Microsoft Word and Google Docs, when you spell a word wrong, there’s a little red squiggly underneath the word? Think of flycheck as a customizable way to make those squigglies.

Today, I wanted to learn how to make an incredibly simple syntax checker. Well, really I started yesterday, but this “incredibly simple” checker actually took me two days to build because I’m an idiot. Typical.

This syntax checker will… (prepare yourself)… mark an error on any line with the letter ‘q’. Let’s get started.

First, get a copy of flycheck. You can do this using package.el, which is included in Emacs 24. M-x package-install <ENTER> flycheck should do the trick. If flycheck isn’t an available package, make sure that you have the correct repositories set up. Once you’ve done that, make sure that you require flycheck in your .emacs file by adding the following:

(require 'flycheck)

Now that that’s taken care of, let’s figure out how a checker works in flycheck. Whenever I don’t have any clue what I’m doing (usually), I look for the simplest example that I can find. Luckily, flycheck is open source and has lots of checkers already defined, so we can just take a look at the main flycheck file in the github respository. yaml-jsyaml looks like a simple enough checker:

(flycheck-define-checker yaml-jsyaml
  "A YAML syntax checker using JS-YAML.

See URL `https://github.com/nodeca/js-yaml'."
  :command ("js-yaml" source)
  :error-patterns
  ((error line-start
          "JS-YAML: " (message) " at line " line ", column " column ":"
          line-end))
  :modes yaml-mode)

Let’s take this line by line:

(flycheck-define-checker yaml-jsyaml

This looks like it’s just a macro that creates the checker.

  :command ("js-yaml" source)

This looks like it’s telling flycheck the command to run to generate the list of errors. I’m assuming that js-yaml accepts a filename as its input, so source is probably just the name of the file being checked.

:error-patterns
  ((error line-start
          "JS-YAML: " (message) " at line " line ", column " column ":"
          line-end))

This looks like it’s telling flycheck what a line of output text looks like. It looks like the error text is in the form:

JS-YAML: This is an error message at line 43, column 2:

And lastly:

:modes yaml-mode)

Looks like it’s just telling flycheck what modes this checker is available in.

Great! Equipped with our new-found inkling of what to do, let’s try and write our own checker. This looks like a good framework:

;; ~/.emacs.d/playground/flycheck-error-on-q.el

(flycheck-define-checker error-on-q
  "A syntax checker that errors on any line with a q."

  :command ("TODO: Write the command")
  :error-patterns
  ;; Example error: 43:This line is bad
  ((error line-start line ":" (message) line-end))
  :modes text-mode)

(provide 'flycheck-error-on-q)

So now we just need to use our command-line-fu to write a one-liner that finds instances of the letter Q. To the terminal!

First, it’s probably a decent idea to think of a file that has some Q’s in it. In my case, I know that my Emacs initialization file has lots of them - it uses package.el’s require function a lot.

grep is good at finding things and, with a bit of fooling around, I found that:

grep --color=never -n -i "q" $FILENAME

finds the line with Q’s in them. This command makes sure:

• --color=never: We don’t colorize the output of grep. This ensures that we don’t insert any control characters into our output that might mess up the error parsing in our checker.
• -n: We print the line number so that our checker knows which line to mark as erroneous.
• -i: We accept both upper and lower case q’s

Running this on my .emacs file with grep --color=never -n -i "q" ~/.emacs, I get

2:;; Required here because this is what allows requiring of other packages.
3:(require 'package)
4:(setq package-archives '(("gnu" . "http://elpa.gnu.org/packages/")
...
292:(require 'flycheck-error-on-q)
293:(add-to-list 'flycheck-checkers 'error-on-q)

Looks like a good start. Notice, though, that our checker expects a message after the colon, while grep just prints the matching string. We can fix this with a bit of awk:

grep --color=never -n -i "q" $FILENAME | awk -F ":" '{print $1":Ick! Q! I hate that letter!"}'

Now, instead of 2:;; Required here because this is what allows requiring of other packages., we get 2:Ick! Q! I hate that letter!.

Unfortunately, after trying, I realized that we can’t just put this incantation as our flycheck :command for two reasons:

• Flycheck expects the return value of the command that’s run to be 1 if an error exists and 0 if it does not. For our command, it’ll always return 0 because awk is always successful.
• Flycheck automatically quotes all parameters after the first one, so it’d automatically quote awk as well as the pipe that follows it. We don’t want these evaluated as strings - we want them evaluated as regular old operations.

Fortunately, all of these problems can be avoided by writing a thin wrapper of a bash script around our existing command. This bash script looks something like:

#!/bin/bash
# ~/.emacs.d/playground/error-on-q

# Capture the first argument and put it into $FILE
FILE=$1

# Capture the output of grep and put it into $MATCHES
# Parameters:
# --color=never  Don't colorize the output - we want plain text
# -n             Print the line number of the match
# -i             We don't care about the case of the letter
# "q"            Our search string - the letter 'q'
# $FILE          The file to search
MATCHES=$(grep --color=never -i -n "q" $FILE)

# Capture the output status of grep so we know if we found any q's
GREP_EXIT_STATUS=$?

if [ $GREP_EXIT_STATUS -eq 0 ]; then
  # Print output in the form file:line_no:Ick! Q! I hate that letter!
  echo "$MATCHES" | awk -F ":" '{print $1":Ick! Q! I hate that letter!"}'

  # If we found a 'q', return 1 to indicate there was a problem
  # with the file
  exit 1;
else
  # Otherwise, return 0
  exit 0;
fi

It’s long, but if you look at what it’s actually doing, it’s pretty simple. It’s running the commands that we already talked about with one modification: it’s capturing the exit value of grep and inverting it. That is, if grep returns 0, it returns 1, and vice versa. This is because we have an error when we find a Q, whereas grep returns 1 unless a match is found. grep’s error is our success.

I put this file at ~/.emacs.d/playground/error-on-q and made sure it was executable with chmod 755 ~/.emacs.d/playground/error-on-q.

Now, we can use this script in our :command in our checker:

;; ~/.emacs.d/playground/flycheck-error-on-q.el

(flycheck-define-checker error-on-q
  "A syntax checker that always says that line 1 has an error."

  :command ("~/.emacs.d/playground/error-on-q" source)
  :error-patterns
  ((error line-start line ":" (message) line-end))
  :modes text-mode)

(provide 'flycheck-error-on-q)

If we reevaluate the buffer and go back to our text buffer, we should see something like:

Success!

I found this animal list on github which looks like a good list to use as an autocompletion source. We can download this file to our plugin directory with a curl one-liner:

curl -0 https://raw.githubusercontent.com/hzlzh/Domain-Name-List/master/Animal-words.txt \
  > ~/.emacs.d/playground/animals.txt

Perfect! Now we just have to parse the file when we call our autocomplete function. Googling for elisp read from file gives us an answer on how to do that.

;; ~/.emacs.d/playground/friendly-veterinarian.el
;; (defun query-favorite-animal...
;; (defun query-favorite-animal-autocomplete...

(defun get-lines-from-file (file-path)
  "Returns the lines of the file at file-path."
  ;; Insert the contents of the file into a temporary buffer
  (with-temp-buffer
    (insert-file-contents file-path)
    ;; Split the contents of the current buffer on the new line
    (split-string (buffer-string) "\n" t)))
    
(provide 'friendly-veterinarian)

It’d be nice to have an easy way of making sure this code works without having to use the rest of the plugin. Enter iELM (inferior Emacs Lisp Mode). iELM is what’s known in the lisp world as a REPL, which stands for Read Evaluate Print Loop. It’s essentially a program that reads a line of code that you write, evaluates it, and gives you back the result. This is exactly what we need - some way to test that get-lines-from-file works.

To do this, load up iELM with M-x ielm and evaluate the code in friendly-veterinarian.el using M-x eval-buffer. Evaluating the code makes that code available to be executed in the REPL. Once you’ve done this, execute this line in the iELM REPL:

ELISP > (get-lines-from-file "~/.emacs.d/playground/animals.txt")
("Aardvark" "Albatross" "Alligator" ... "Zebra")

Wunderbar! We can now swap out our puny autocomplete list that we were using in query-favorite-animal-autocomplete with the much more complete list from our text file.

;; ~/.emacs.d/playground/friendly-veterinarian.el
;; (defun query-favorite-animal...

(defun query-favorite-animal-autocomplete (name)
  "Queries the user for their favorite animal with autocomplete."
  (interactive
   (list
    (completing-read "sEnter the name of your favorite animals: "
                     (get-lines-from-file "~/.emacs.d/playground/animals.txt"))))
  (message "Your favorite animal is: %s. I guess those are alright." name))

;; (defun get-lines-from-file...
(provide 'friendly-veterinarian)

After reevaluating our buffer and calling our function with M-x query-favorite-animal-autocomplete, we’re greeted with something like this:

Now we have a friendly and smart veterinarian.

Or… so I’ve been told. I say all this never having actually developed an emacs package. I’m changing that today. And I’ve limited the scope of my first plugin to reflect the fact that my attention span is limited to about 30 seconds.

I think this plugin we’re making has real potential to take off: I call it the friendly veterinarian. It asks you the name of your favorite animal and prints a message based on your response.

I started off by using the command line to create a directory where I could store these types of projects:

mkdir ~/.emacs.d/playground

Now we can go ahead and create the actual package.

;; ~/.emacs.d/playground/friendly-veterinarian.el

;; Found by googling for "ask for user input emacs"
(defun query-favorite-animal (name)
  "Queries the user for their favorite animal."
  (interactive "sEnter the name of your favorite animal: ")
  (message "Your favorite animal is: %s. I guess those are alright." name))

;; This allows people to use (require 'friendly-veterinarian) in their .emacs
(provide 'friendly-veterinarian)

After evaluating the buffer (another way of saying loading the code) with M-x eval-buffer, we can now call our function with M-x query-favorite-animal and get asked what our favorite animal is.

Alright - I think I can do a little better than that today. What about if we gave ourselves some neat options for autcomplete?

The first result of googling for “interactive function autocomplete emacs” lets us know that we can pass a different parameter to interactive to give ourselves some autocomplete options. Great!

Using our new-found knowledge, we can add a bit to the file:

;; ~/.emacs.d/playground/friendly-veterinarian.el
;; (defun query-favorite-animal...

(defun query-favorite-animal-autocomplete (name)
  "Queries the user for their favorite animal with autocomplete."
  (interactive
   (list
    (completing-read "sEnter the name of your favorite animals: "
                     '("cat" "dog" "giraffe"))))
  (message "Your favorite animal is: %s. I guess those are alright." name))

(provide 'friendly-veterinarian)

Now we can reload our package by revaluating the buffer (remember M-x eval-buffer?) and call our function with M-x query-favorite-animal-autocomplete. Looks good!

Very humble goal: accomplished.