The Philosopher Developer

Value over time

2026-04-03T00:00:00

Throughout my career the question of "quality vs. speed" has always been a topic of spirited debate. The premise is that these are competing values, with some people, teams, or companies focused more on quality while others focus more on speed. It is almost like there is an implied spectrum, with quality on one side and speed on the other, so that you could assign every individual or team a "quality vs. speed score" from 0 to 100 to define where they fall on the spectrum, describing their relative attention to building high-quality things and moving fast.

The wrong question

My view is that the "quality vs. speed" question is poorly formed because it has a false premise. If there really were a spectrum, and if either quality or speed were in fact "more important", then one end of the spectrum ought to be "better" than the other. So let's consider the two ends.

Someone on the "quality" end of the spectrum would optimize for value per change: for every deliverable they produce, it should provide the highest possible value. "Do the best possible version." "Anything worth doing is worth doing right." Etc. This approach is known as perfectionism.

The problem with perfectionism is that it does not include the crucial variable of time. It makes a big difference whether the "best possible version" takes 2 hours to make, or 2 weeks, or 2 years. It also neglects to consider the surrounding context: if I'm a professional chef, I might want the best possible cookware, but not care as much about my shoes. If I'm a professional athlete, the opposite could be true.

I believe that optimizing for value-per-change comes from what most of us experienced during school. In school, the number of challenges we are given is fixed, and the best possible outcome results from completing all of those challenges as well as possible. The real world is not like this: we are not all given the same assignments. The best outcome for you is often not to deliver the A+ version of everything someone else gives you to do; often, the best outcome requires far more proactiveness—delivering more than strictly what was asked—and a willingness to iterate.

Someone on the "speed" end of the spectrum would optimize for change over time. Do things as fast as possible, then move on to the next thing. You might also call this "quantity over quality".

In contrast to perfectionism, which leaves out the variable of time, the speed-over-everything mindset leaves out the variable of quality, or value. If you can deliver 100 new products in a year, but they're all basically worthless, is that truly better than delivering nothing?

So if we only cared about quality, then we would say that whether you complete 1 project in a year, or 5, or 20, it makes no difference: all that matters is the average quality of them.

Meanwhile, if we only cared about speed, then we would say that whether the projects you complete in a year are F- quality, or C+ quality, or A+ quality on average, that doesn't matter: what's important is simply the number of projects you complete.

If we plot what these two approaches would look like over time, we would see something like this:

The right question

Rather than value-per-change, or change-over-time, I believe the right thing to optimize for is value over time. It is not that quality matters more than speed, or that speed matters more than quality, in any objective sense. What we are ultimately striving to do is to use the finite time we have to provide the greatest value within that time.

Remember bivariate optimization in math? This is where, say, you have 100 ft of fence and you need to enclose the largest possible rectangular area. Doing this requires solving for two variables (in this case, length and width) to maximize their product (area) with the constraint that they must add up to 100 ft.

You could "optimize for length", making the enclosure 48 ft long and only 1 ft wide. Or you could "optimize for width" and make it 48 ft wide and only 1 ft long.

Both of these approaches are clearly wrong: we can see that it isn't true that "length is more important than width" or vice versa. The thing we want to optimize for—the area—is a function of both of those factors. They need to play together.

I believe quality vs. speed is a false dichotomy. It is like asking about "length vs. width", pitting two dimensions against each other when what we actually care about requires both. Reimaginging the same spectrum I shared earlier with the two ends relabeled, it suddenly looks very silly.

So why does it sometimes probably feel to my teams like I only care about speed (or maybe your local leadership team is the opposite, and they seem to only care about quality)? Well, one possible explanation is that I'm just wrong. But another possibility is that speed or quality actually can be "more important", not objectively, but relative to the current state of things.

Getting the car where it needs to go

Here's an analogy I've shared in the past: imagine you and your team are driving a car through open wilderness, towards some important destination.

Suppose you and your team members get in the car, check your instruments, validate you're headed the right way, then drive 10 ft. forward. You stop, check your instruments again, validate again, and drive another 10 ft. And so on.

In this scenario, your group is focusing too much on heading the right direction, and not enough on getting there faster. To them, as an advisor, I might say: "Stop getting out of the car so much and just GO."

Or suppose your team gets in the car, figures out what direction you want to go, and then just floors it, racing for hours without stopping.

In this scenario your group is too focused on moving fast. You could be veering wildly off course, even heading 180 degrees the wrong way. If I were advising them I would say: "Whoa there, you're going the wrong way. Pause and check your instruments. Stop and check every now and then."

If we have a destination, we need to know both: (a) are we heading the right way, and (b) how fast are we moving. If we just know we're heading the right way, but we're only moving 2mph, it's going to take us a long time to get there—possibly so long that the destination won't even be worth reaching by the time we get there. Meanwhile, if we're moving 100mph, but heading the completely wrong direction, that doesn't do us any good either.

Clearly the "right" way to drive the car involves a balance between paying attention to where you're going while also moving as fast as possible. In practice, most teams are often too focused on one or the other.

Why speed gets all the love

As I've written before, it is very common that different people need to hear different things.

If my teams feel like I'm always telling them to "move faster", it doesn't mean "speed is more important than quality"; it means I believe their balance is off and there's a better way to get to the destination.

A lot of intelligent, hard-working people prioritize quality over speed by default because they don't consider the time dimension. Again, I blame the wrong lessons learned during school for this mindset, as every student in a class is forced to the same schedule (all take a quiz or a test on the same day, assignments are due the same day for everyone) so that time is fixed and quality is the only variable. In an academic setting, there is generally no bonus for completing assignments early, or for completing 2x the assignments of your peers. Sadly, the people who most need to unlearn this lesson are the A students! They are the ones who "won" in school by focusing solely on quality (i.e. getting the best possible grade).

The other thing is that I know we all want to put our best foot forward, which sometimes means planning to put our work in customers' hands when it's mostly "done", i.e. let's say 90% done. Sometimes I ask if we can ship something sooner, not necessarily because I want the overall project timeline to be shortened, but because I believe the end result will be higher-quality if we start getting feedback from customers much earlier in the process, giving us more time to incorporate that feedback into our work.

Area under the curve

The visual I tend to have in my mind is like this: imagine the value you deliver as an area chart, with time as the x-axis and value delivered (cumulative) as the y-axis. Essentially what I believe we want to do is to maximize the area under the curve. When we think about it this way, the following statements are all pretty obvious:

Quality (delivering more value) is good.

Quantity (delivering more things) is also good.

Delivering value earlier is good.

These things are all good. At any given time, we should ask ourselves: what maximizes area under the curve?

There is no set formula here. You could be Harper Lee and create one incredible masterpiece, win the Pulitzer Prize, and have greater impact than most of us would have in 10 lifetimes. You could also hustle your whole life, build 100 companies, and ultimately fail to leave a mark.

What we all have in common is that our time is always limited—the time we work on a project, the time we're together as a team, the time we work for a company, the time we're here on this Earth—and in the end we want to make the most of it.

What are engineers for?

2024-03-05T00:00:00

I was once out with a team of software engineers who were talking about a challenging project, and one of them said, "It's our job to say what's impossible."

I couldn't stop myself from interrupting. I said wait a minute, that is not what our job is. I think I knew what he was really trying to say, but I saw the moment as an opportunity to challenge what I felt (and still feel) is a backwards view of what engineers are actually for.

At the time I think I said something like "The company we work for employs thousands of engineers. Do you think we need thousands of people to say what's impossible?"

So if that isn't what software engineers are for... what is?

To share my own personal answer to that question, I'll start by describing one of my favorite scenes from the movie Apollo 13.

The scene begins with some NASA staff members approaching Lead Flight Director Gene Kranz, played by Ed Harris, to inform him of a CO₂ filter problem on the lunar module. The CO₂ levels are at 8 and rising, they explain. If the levels go above 15 they will lead to impaired judgment, blackouts, and brain asphyxia for the astronauts on the Apollo 13 mission.

Kranz asks: "What about the scrubbers on the command module?" No luck: "They take square cartridges. The ones on the LEM are round."

Then, after a dramatic pause, the flight director delivers the inevitably quotable line: "Well, I suggest you gentlemen invent a way to put a square peg in a round hole... rapidly."

The film then cuts to a team of engineers entering a small room. "Okay people, listen up," says one of the lead engineers, as several boxes full of seemingly random items are emptied onto a table. "The people upstairs handed us this one, and we gotta come through. We gotta find a way to make this," he says—holding up a square cartridge—"fit into the hole for this"—holding a round cartridge—"using nothing but that"—gesturing to the pile of items on the table.

The next line we hear, muttered simply by one of the engineers as the camera gives us an overhead view of hands sorting the items on the table: "Okay, let's build a filter."

This scene beautifully captures what I personally love about engineering, and what I believe the job of engineers really is.

The job of an engineer is, given a goal and a set of constraints: figure it out. Figure out how to make it work, even when the real-world constraints make it seem hard. Especially then. The tougher the constraints, the seemingly more impossible the goal, the better.

Another way to think about it: if it's easy, if the solution is obvious, then what do you need engineers for?

Imagine the Apollo 13 scene were different: suppose the NASA staffers approached Kranz and told him about the CO₂ issue, and when he asked "What about the scrubbers on the command module?" they all just said, "Oh, right! Those will work. We're so dumb!" No need for engineers.

It's only because the solution was not obvious, due to the constraints—square pegs, round holes—that Kranz needed engineers at all.

Would you like to build a computer in the shape of a perfect cube with 90 degree angles? Maybe you want to provide live search results to 40,000 users concurrently every second? Need to land a 200-ft, 500-ton rocket on a small ship in the middle of the ocean after returning from space?

You're going to need some engineers!

To be clear, I'm not saying engineers can solve any problem no matter the constraints. I have certainly encountered problems I was unable to solve with the constraints I was given. But I try to never say that something is impossible. I might say: "We haven't managed to figure that out yet," or: "The only solution we've been able to find so far would be very expensive."

The aspiration should always be to remain unintimidated by seemingly hard problems, and to know we can figure it out eventually. "Impossible", as far as I'm concerned, should be treated like a dirty word.

I love engineering because I love figuring things out. Every engineering project is like a puzzle, with a unique goal and a unique set of constraints—the team, the systems, existing infrastructure, available time, company policy, dependencies on other teams, the list goes on. I feel so privileged to have a career in engineering, because the world needs puzzles to be solved, and I love solving puzzles.

The job of engineers is not to say what's impossible; it's the opposite. At our best, engineers take what seems impossible and figure out how to get it done.

When sophistication is required

2024-01-04T00:00:00

This is a post I originally authored over 5 years ago, while learning and writing about cryptocurrency. Since it wasn't published anywhere other than GitHub, I figured I would port it to my main blog.

The post has been very slightly modified to reflect my current views and make it a bit more general.

QR codes are interesting. They are a great example of almost maximum obfuscation: a visual representation of information that is easily readable by machines and incomprehensible to humans.

In chapter 2 of Mastering Bitcoin, the author provides a hypothetical example of a transaction wherein Alice purchases a cup of coffee from Bob's coffee shop by scanning a QR code. In the example, upon scanning the code, Alice is able to see a human-readable description of the transaction before confirming. But it got me thinking: if this type of exchange were to become truly commonplace, people might grow accustomed to scanning QR codes to perform transactions without even worrying about the encoded information.

We do this all the time, actually. When's the last time you read the full text of an EULA before checking the box saying you agreed to the terms? We have become quite comfortable with skipping over information that's opaque or overwhelming based on trust.

The thing is, I think part of the conceptual appeal of cryptocurrencies is that you're not supposed to need trust. You don't need to trust central banks because the ledger is decentralized. You don't need to trust individuals because transactions are cryptographically signed.

The more I read, though, the more this starts to feel like the same tune, just a different song. In practice, many participants in the crypto market are already trusting corporate entities like Coinbase. In theory you have total control of your money, if it's been delivered to an address for which you (and only you) have the private key. But I am skeptical that most people are doing it this way because most people do not even understand what a private key is or what it does.

In fact, there are already people in the cash world who have this same amount of control, because they hide piles of cash under their mattress. We tend think of these people as a bit paranoid. But it's true that no one can take their money without physically entering their house, just as it's true that no one could steal your Bitcoin without stealing or hacking whatever device has your private key on it.

The problem is that the system is complicated. You cannot reasonably expect the average person to understand how it all works, and so those who want to participate will seek assistance from those who do (or who claim to) understand it, in exchange for some amount of control. This creates opportunities for exploitation, as people will enter into agreements they don't understand.

This is pretty much the way I think capitalism itself has played out thus far: in theory, it's great and works to everyone's benefit, as long as consumers are sophisticated. But most consumers are not sophisticated, and so they are taken advantage of. I suspect that is a fundamental inevitability for any large-scale system. To make it work, some amount of technical sophistication is required; this forces less technically sophisticated participants to depend on trusted providers; and therefore you cannot fully decentralize and eliminate the role of trust (or the risk of manipulation or abuse).

The 100-mile chainsaw

2023-08-28T00:00:00

John was a lumberjack. Every day he would go to the forest, chop down trees, and haul them back to town to sell to anyone who needed lumber. Fortunately for John, everyone needed lumber, all the time, as the town had many flourishing businesses and the population was growing.

Because demand for lumber was always high, whenever John wanted to make a bit of extra money, he could push himself to work extra hard and cut down a few more trees to sell. While it was demanding work, he always felt incredibly gratified after such days. Not only was he rewarded for his effort; he knew he was also providing extra value to the people of the town, who could always put the lumber to good use.

One day, a traveling salesman came into town and showed John an incredible tool he had never seen before. The salesman called it a "chainsaw" and showed John that with very little effort, this tool could cut through logs in a fraction of the time it would take him with an axe. The chainsaw was awe-inspiring to John, who could plainly see that it would be more than worth the expensive price tag after only a short time given the number of trees he would be able to cut down.

Sure enough, the next day, John brought more than twice his usual daily haul of lumber into town. The people were astounded and overjoyed, and everyone congratulated John on his wise investment. John made more money than he had ever earned in a single day before, and went to bed that night knowing that his life had changed.

Weeks went by, and John continued to earn far more money than he ever had before. The people of the town built more and more with the lumber John supplied. Everyone was happy, but John started to wonder if he might be able to do even more. It was as if a switch had been flipped in his mind: seeing just how much of a difference the chainsaw had made, he soon began dreaming of other ways to achieve similarly transformative gains in the amount of lumber he could provide to the town.

After many late nights spent tinkering with the chainsaw he had bought, John finally came to understand the inner workings of the tool well enough to recreate it. But instead of creating a chainsaw with the same dimensions, John produced one that was 100 feet long. The night his work was finally completed, John went to bed as excited as a child on the night of Christmas Eve.

The next day John brought his 100-foot chainsaw into the forest eager to try it out for the first time. To his delight, in a matter of minutes, he was able to cut down not a single tree but dozens of trees nearly simultaneously. In a single sweeping gesture, John's new chainsaw ripped through trunk after trunk, scattering wooden splinters across the forest floor in a breathtaking display. Trees fell one after another causing the ground to shake and filling the air with a thunderous chorus of crashing branches and limbs.

When John finally returned to town with his haul of lumber at the end of the day, the townspeople were speechless. They had never seen so much lumber produced in a single day. It changed everyone's sense of what was possible. The business owners in the town updated their ambitions accordingly, planning for larger and larger construction projects to utilize the vastly increased supply of lumber now available to them.

Over a year passed, and John had become a very rich man. While he was incredibly proud of his work, once in a while he experienced a tinge of nostalgia. He remembered the thrill he experienced building his 100-foot chainsaw and using it for the first time.

Eventually John started having trouble sleeping. An obvious truth was lying just under the surface of his consciousness, waiting for him to acknowledge it. One night it forced itself into his awareness, hitting him rattling force: Why stop at 100 feet? Imagine how many trees you could cut in a day with a chainsaw a mile long.

It was an engineering challenge like nothing John or anyone had ever attempted. His neighbors helped him with the materials, and eventually with storage as he worked on creating a tool of such magnificent scale. Before long John was working on a chainsaw that stretched all the way through town. Transporting it to the forest was an ordeal, but he knew it would be worth it.

When the chainsaw first roared to life, John felt a rush of adrenaline like nothing he'd ever experienced. As he slowly lifted the chainsaw and began moving its blade through the forest, the sound of hundreds, thousands of trees being severed at the base and falling to the earth was almost deafening. The experience was overwhelming for John. For the first time, on that day, he cut down so many trees that he couldn't even see how many were falling. He wasn't sure how much lumber he could transport back to the town. He did his best to load up everything he found, but there seemed to be no end to it. When he finally returned home at the end of the day, he did so knowing that he was leaving some fallen trees behind.

The next day, John carried the chainsaw to a different part of the forest. Again, the metallic scream of the chainsaw ripping through an endless swath of foliage echoed far and wide. John returned to town again with every piece of lumber he could carry, knowing he wasn't able to collect it all.

After this carried on several more days, a stranger visited the town asking for the one who was tearing down parts of the forest with a howling blade. The people of the town sent the visitor to John, who greeted him and asked him why he had come. The man explained that he had been living in a secluded cabin in the woods, until John's fearsome weapon had appeared and destroyed his home.

John was deeply moved by the visitor's story. For a few days, he took time to reflect on his actions. He knew that the lumber he provided helped the people of the town. Was the value he provided to them enough to make up for the damage he had done to the visitor's house? He thought long and hard about it.

Eventually, the townspeople started visiting John and asking him to resume his work harvesting lumber from the forest. They needed it, they explained to him. Without it, the town could not continue to thrive.

John decided to hire some helpers. They would join him in the forest and spread out to survey areas for dwellings or anything of value that he shouldn't damage. Of course he couldn't hire enough people to be absolutely sure he wouldn't do any harm; but having the help soothed his conscience, and the business owners in the town were thrilled for him to get back to work providing their lumber.

This worked well for some time. Unfortunately every now and then John would still discover that he had accidentally destroyed someone's home or other property. But this was rare enough, and the value he provided to his town was so great, that he was able to continue sleeping at night knowing he was doing far more good than harm.

Years have passed. The needs of the town (now a city) have scaled tremendously, and with them so has John's output. Today he uses a chainsaw that is 100 miles long. He employs a considerable workforce responsible for surveying entire forests to help him decide where to clear trees for lumber production.

These days, it simply isn't possible for John to know how much damage he is doing. A 100-mile chainsaw can clear over 30,000 square miles of forest at a time. Even with the help of his team, a single person simply cannot assess the impact to such a large area. At this point John has become accustomed to learning that there are times he has accidentally destroyed entire villages. He still believes that the good he is doing by producing such vast amounts of lumber outweighs the unfortunate cost.

And if it weren't, how would he know? Why should he stop? What John knows is that the lumber he supplies is still being used by the city. And the visitors from the forest stopped making their pleas long ago.

What you need to hear

2023-07-29T00:00:00

A few years ago I wrote a piece called Advice vs. guidelines because I wanted to distinguish between times when I'm just trying to be helpful to someone given the state of the world, versus other times when I have an opinion about what the state of the world "should" be.

There is another distinction I often find myself making, which is not about the world as a whole but rather who we are in the world. That is, who I am, and who my audience is—whether the reader I have in mind for a piece of writing, the viewer for a video (I often record videos to share with my teams at work), or simply the person I'm speaking with in reality. The myth of the "general audience" is that a piece of communication may be suitable for everyone; but I find this is rarely the case. Even when I think what I'm saying is general, inevitably someone has a reaction to what I say that surprises me and shows me that what I have to say isn't as universal as I thought.

In truth, I am skeptical that there is any form of advice that would be valuable to all people. We all come from different backgrounds, face different challenges, and are the result of a unique combination of countless variables that collectively made us who and what we are.

This is an imperfect analogy, but it is a bit like every human has an internal set of metaphorical locks, and advice is like a key. Many keys fit locks that are common to many of us. Some keys only fit locks that are shared by a small few. There is no lock that everyone has, and therefore no key that works for everyone.

For example, in my career, I have advised many individuals with something along the lines of "It is easier to ask for forgiveness than permission"—a well-known adage, but certainly not a message I believe everyone needs to hear. Some people are bullies, or reckless, or have very poor judgment. A lot of these folks probably need to hear the opposite advice. But there are a lot of smart, capable people who usually know what needs to be done, but their deference to authority or their reliance on achieving consensus slows them (and their teams) down. These are the people who, in my opinion, often need to hear this advice.

Sometimes, what you need to hear is "Believe in yourself; you can do this!" But not everyone has a confidence problem. Some people have an arrogance problem. These people might need to hear "Get off your high horse for a minute and actually listen to what people are trying to tell you."

Sometimes, what you need to hear is "A penny saved is a penny earned". But not everyone is too short-sighted to plan for the future. Some people have a bigger problem living in the moment and enjoying life. These people might need to hear "Live today like it's your last."

Sometimes, what you need to hear is "The squeaky wheel gets the grease". But not everyone has a hard time speaking up, voicing their problems, seeking attention or asking for help. Some people are constantly complaining or declaring that the sky is falling. These people might need to hear the story of the boy who cried wolf.

I have to remind myself of this sometimes, not only when I give someone else advice but also when I hear advice that doesn't resonate for me. My knee-jerk reaction is often That sounds completely wrong! But then I realize: maybe it just isn't what I need to hear. It could be exactly what someone else needs to hear.

Let others hear what they need to hear, and keep your ears open for the keys that will unlock something in you.

On ice cubes and hot soup

2023-06-20T00:00:00

I was chatting with a colleague recently and we were sharing our experiences and perspectives working through recent organizational changes at our company—new leadership, new org structures, new ways of working. He said something like "Either we will change, or our new leaders will have to change."

I noted that both would surely change; the question was only a matter of degree on each side. The executives who had recently joined the company would inevitably find themselves adapting to the culture that existed before they arrived. And the rest of the company would likewise adapt to its new leadership. On this we agreed.

I don't believe that one-directional change is actually possible. You can't change a thing without changing yourself. In order to have an effect, you must also allow yourself to be affected.

The picture that always comes to mind for me is that of some ice cubes being dropped into a bowl of soup that's too hot. The purpose is to cool the soup down. We understand that in order for this to happen, the ice cubes have to melt.

In life, we often want to either drive or resist change. Sometimes we're the ice cubes, other times we're the soup.

It's natural for the soup to fear the ice cubes. They seem extreme. "If the rest of us came down to your temperature, this soup would be freezing cold!" But the ice cubes were not added to make the soup freezing cold, only to cool it down. By the time this has happened, an equilibrium has been reached.

Meanwhile, ice cubes often have their own ideas: "This soup should be cold! Gazpacho time!" But they can only influence the temperature of the soup so much. As they change the soup, they also start to melt into it.

I believe there are lessons to be learned on both sides of this interaction. When we see change coming from the outside, it isn't always as scary as it might seem. And when we're the ones bringing the change, we should remember that the degree of change we are able to bring will depend on the amount of change we can receive.

Plan for the best

2023-06-10T00:00:00

One Friday night recently, some friends of mine dropped off their daughter for an evening play date with three other girls. Their daughter hadn't met two of the other girls, so they hoped she would get along with them but figured most likely she would still want to come home before bedtime. When they returned later that evening, the girls had become fast friends and were already making plans for what they would do the next morning. But since the parents had assumed their daughter would want to go home, they hadn't brought a change of clothes, her toothbrush, or anything she would need for a sleepover; so they found themselves driving home with a deeply disappointed and frustrated child.

This story reminds me of something I have seen many times in the workplace. The members of a product team will chat often about an idea: a vision, a strategy, or just a cool feature they'd like to build. These discussions happen in bits and pieces over Slack, during meetings on Zoom, in social gatherings—but never "on paper". No one ever takes the time to really put the idea into writing or flesh out all the details, because "We'll never get time to work on that." And then one day, some SVP or other senior leader comes along and asks, "Have we ever thought about..." and the team has nothing to show. They assumed they would never get the time of day from any senior leadership, and they were unprepared when the moment came.

We've all heard the expression: Hope for the best, plan for the worst. It sounds so sensible. And of course, it comes from a sensible place. We should not simply hope that good things will happen and assume all of our dreams will come true. Bad things do happen, challenges do arise; and if we don't invest any effort in preparing for them, they can knock us down.

Here's another expression, from President Dwight D. Eisenhower:

Plans are nothing; planning is everything.

The existence of a plan is one thing. But it is really the act of planning that forces you to think through the details of what might happen and equips you to handle different scenarios. This simple act makes a huge difference in determining whether we are prepared to respond appropriately to different situations, to take advantage of new information and choose promising new paths when they emerge from the fog.

One of the most common mistakes I see people make is spending all of their effort planning for the worst, and only hoping for the best. When you only hope for something, you aren't thinking through the details. You aren't asking yourself, "What if I get it done in 2 days instead of 2 weeks?" or "What if they actually say yes?" And then when something like that happens, you have no plan, and the moment passes you by like a wave passing a surfer without their board.

By planning exclusively for the worst, we render ourselves unable to seize those opportunities that could lead to the best—and then the worst just happens by default.

I'm not saying we should not plan for the worst. None of us has complete control over our environment or the obstacles we will encounter. This is why we should spend a portion of our energy preparing for those obstacles so that we're ready to deal with them.

But sometimes the universe smiles upon you, and you find yourself on a surprisingly smooth path. To spend all of our energy planning for the worst leaves nothing left to actually make plans for when things might go better than expected: when solving a technical problem turns out to be easier than we thought, when we're able to complete our work ahead of schedule, when all of our dependencies actually fall into place (it can happen!), when our executive leaders love what we're doing and want to give us more funding or support.

My point here is simple. Let's be done with "Hope for the best, plan for the worst".

Plan for the best, and plan for the worst.

Adventures in AI

2023-04-09T00:00:00

Back in early 2018 I decided to start learning about cryptocurrency. I created a website, called "Adventures in Cryptocurrency" (no longer live), to document my experience learning about the subject. It didn't last very long: by the end of January I was already becoming skeptical at the ostensible aspirations of the crypto community to offer a decentralized alternative to traditional banking.

That was five years ago. As I write this, we are in the middle of another potentially transformative technological wave, as artificial intelligence dominates the media and seemingly a decent amount of public conversation (it has come up in real-world conversations for me with a wide variety of people, not just tech workers). Unlike cryptocurrency, though:

I am much more interested in artificial intelligence to begin with: I don't have to push myself to learn about AI.
In a similar vein, the average person has a strong intuition about how AI is likely to have a tremendous impact on the economy and society at large. (In contrast, my sense is that the majority of people were always scratching their heads over cryptocurrency.)
The discourse around AI today feels more grounded and less hype-driven to me than it ever was for crypto. Even those who are most bullish on the potential for AI to make the world a vastly better place still recognize major risks and worry about catastrophic outcomes.

So I'm starting over again, this time documenting my experience learning about artificial intelligence.

https://aiadventures.net/

I haven't yet decided on many of the details of this project. How often will I write, where will I distribute the content (other than directly via the website), how will I prioritize my time (mostly reading articles and papers? taking courses? building things?), will I explore other media besides writing, etc. are all up in the air as of right now.

What I'm sharing today is simply that I'm doing this, and it's what I expect to be focused on for a while.

If you're already following The Philosopher Developer and wondering whether this blog will remain active: at the moment, I do intend to continue publishing here. Certainly whenever I write about something not related to AI, it will be here. As for my AI-related content, my current plan is to write frequently on potentially narrow topics at aiadventures.net (e.g. summarizing a paper I read or a podcast interview I listened to) and probably to publish less frequent updates here, synthesizing the many thoughts I've had and things I've learned maybe every 2 weeks or so.

Time will tell whether this ends up like the crypto thing or it's the start of a much longer chapter.

The men on the beach

2023-01-29T00:00:00

Two traveling men meet on a vast, endless beach.

Both men are traveling with carts full of useful items that they've collected throughout their lifetimes.

The first man, Saul, has built up his collection by finding things beneath the sand. Every day, he digs countless holes. Most of the holes lead nowhere, but every now and then he finds something.

The second man, Sy, has a much larger and more impressive collection. Saul asks him how he has found so much. Sy shows Saul a magical device. It is shaped like a long, straight stick with a couple of concentric rings on one end. Sy holds the stick and moves the ringed end along the sand as he walks, gesturing for Saul to follow him. The two men walk together until eventually the stick makes a noise. Upon hearing the noise, Sy digs, and finds a shiny object.

Sy explains that once he discovered this stick and learned how to use it, it changed everything for him. He claims that the stick always works: when it makes the sound, and he digs, he never fails to find something. Saul is incredulous. Sy invites him to try it out for himself.

The two men walk together some more, this time with Saul holding the stick. Eventually it makes a sound again, and Saul digs. Sure enough, once again the stick has located something useful.

The men keep walking together for some time. After too many successes to count, Saul is fully convinced. The stick works.

By now the men have become friendly with each other. Sy reveals that he has a second magic stick. He offers it to Saul as a gift. Immensely grateful, Saul accepts. As the day ends, the two men go their separate ways.

Years have passed. Both men are much older. One day, they happen to meet again on the same beach.

Their collections have grown. Saul now has two carts connected together, while Sy's collection is so large, it fills a long train of almost twenty carts. While Sy is still carrying his magic stick, he is surprised to see that Saul seems to have his stashed away. He is even more surprised to learn that Saul has been digging holes without using the stick.

Sy asks Saul why he has gone back to digging random holes. Saul admits that the stick was very useful, and he still uses it sometimes. But he explains that over time, he started to suspect the stick wasn't able to find everything there was to find. He now has his collection divided into two carts: one holds everything he's found with the stick, while the other holds things he found just from digging, without the stick.

Sy is dismayed. Why would Saul not always use the magic stick? He starts looking through the items in Saul's second cart. Quickly, he finds items that he has in his own collection. He shows these to Saul, hoping to persuade his friend that there is nothing special about these things; the stick can find them, much faster than random digging.

Perhaps, Saul admits. But he points out that some of the items in his cart don't appear anywhere in Sy's collection, even though Sy's collection is much larger. Sy responds that this should not be surprising. By chance, over a lifetime, surely anyone would find some things that Sy hadn't found with the stick. But this is just pure luck. He insists that his stick would eventually find these things. Saul is not so sure.

After debating for some time, the friends realize they are not going to agree. The day is coming to an end. They shake hands once more, and part ways for a second time.

As he leaves his friend, Sy feels sadness knowing that Saul will spend the rest of his days wasting considerable time digging holes in the wrong places.

Saul meanwhile carries on with lingering doubt. Maybe Sy is right, and he is wasting his time. But he still has a feeling that there are things the magic stick cannot find. It saddens him to think that, as long as his friend Sy refuses to dig holes without using the magic stick, he might never find these things.

Leaky bucket, overflowing bucket

2022-06-22T00:00:00

Note: this post was published in 60 minutes.

I've used this analogy over the years with multiple people, both team members reporting to me as well as peers and friends. Since others have told me they found it helpful, I decided to write it down to share more broadly.

Early on in most of our careers, our responsibilities are limited. The people we work with don't depend on us for too much yet. But we may be capable of doing a lot, and many of us are eager to be given a chance to do more.

Let's call the ratio of capacity to responsibility the "C/R ratio". At this stage in our careers, C/R is greater than 1. This means that, for most of us, our capacity exceeds our responsibility: we are capable of doing more than is being asked of us.

For this reason, when we're still relatively new in our careers, failure to fulfill our responsibilities is typically a sign of a "leak". We have the capacity, but we still dropped the ball.

Fortunately, leaks can be patched. With a little mentorship, some better time management tools, or just simple practice, we can get better at managing the responsibilities assigned to us and become more reliable workers.

As we grow in our careers, both our capacity and our responsibilities increase. We can do more, and more is asked and expected of us. But often the rate at which responsibility increases exceeds the rate at which capacity increases, driving C/R down. Eventually, we may reach a point where C/R drops below 1, meaning suddenly our responsibility exceeds our capacity¹.

This represents a difficult moment for many people. You start developing that feeling of "dropping the ball" again. You associate this feeling with the presence of a leak, but you struggle to find ways to patch it. In fact, at this point to call the issue a "leak" is to misdiagnose the problem. It is no longer a leak that can be patched; it is an overflow.

At this stage, it becomes necessary to revisit your C/R ratio. If you want to get it back to 1², at a high level, you have two options:

Increase capacity (e.g. hire more people, ask for help, take a course)
Reduce responsibility (e.g. delegate, deprecate, deprioritize)

Either way, communication is vitally important. Unless you are communicating clearly to those around you that you are at capacity, that your bucket is full, they will continue to pour more responsibility into it and it will continue to overflow.

Ideally there would be an objective quantifiable measure of these things (capacity and responsibility) but there isn't, which means you cannot rely on a system or process³ coming to your rescue. Be self-aware, understand your priorities, and help anyone impacted by your C/R ratio understand what you're focused on and why.

Note that what I'm describing is different from the Peter Principle, which is about being promoted into a role that you are fundamentally ill-suited for. The scenario I describe here is not about achieving a level where you're incompetent (I'm sure this also happens, but I don't think I've experienced it yet), only one where the practical constraints of available time and energy prevent you from doing everything that is expected of you. ↩
It's worth acknowledging there are some readers for whom this may not feel like a problem that needs to be solved. It could be a feature, not a bug. There is a certain school of thought that it's better for everyone to have too much to do than too little. It isn't my personal view (I believe excess capacity is an important way for organizations to be resilient), but it's a view. ↩
At least none that I've encountered! ↩