The requirements go in. Out comes a timeline, a cost estimate, and a series of milestones. This is comforting. The buyer knows what they will receive. The team knows what it must build. Everyone can track whether the project is on schedule.
The requirements may be incredibly well stipulated. The estimate may be honest. The team may execute perfectly. None of that proves that X solves Y.
Consider a clinic with too many missed appointments. That is problem Y. The clinic owner decides that the solution is a mobile app. That is X.
The requirements include accounts, patient profiles, appointment calendars, push notifications, rescheduling, payments, analytics, and integrations. Three teams provide estimates. The best proposal promises the app in six months for $100K, with milestones for design, backend development, beta testing, and release.
6 months later, the app may work perfectly. Patients may still not install it. X was delivered. Y was not solved.
Now put Musk’s five steps inside the function.
Why does the clinic need an app?
It does not. It needs fewer missed appointments. The app is only a hypothesis about how to achieve that.
The first step is to challenge the assumption that X is required to solve Y.
Delete everything that is not required to test the hypothesis.
There is no need for an app, an account, a profile, a custom calendar, a payment integration, or an app store release. None of these things is necessary to learn whether reminders and easier rescheduling reduce missed appointments.
Export tomorrow’s appointments. Have the receptionist send each patient a WhatsApp message:
You have an appointment tomorrow at 2 PM. Reply 1 to confirm or 2 to reschedule.
That is enough to test the important part of the idea. Patients receive a reminder. They can confirm. They can reschedule.
Run the test tomorrow. Try it with the next 100 appointments. Measure confirmations, rescheduling, and no-shows.
Within a week, the clinic has evidence. If the message works, test a better version. If it does not, test another hypothesis.
Perhaps patients lack transportation. Perhaps they forget why the appointment matters. Perhaps appointments are booked too far in advance. Perhaps a small deposit would work better.
The clinic is now learning about Y instead of blindly constructing X.
Only automate after finding something that works.
If the messages reduce missed appointments, connect the scheduling system to WhatsApp. Send reminders automatically. Process confirmations. Offer available times when someone reschedules. Escalate non-responses to a human.
The clinic may never need an app. If it eventually does, it will build one based on evidence rather than imagination.
This is the difference between building X and solving Y.
“We have $100K and 6 months to build this app” is a commitment to X.
“We have $100K and 6 months to reduce missed appointments” is a commitment to Y.
As a decision leader, your job is not to guarantee that X gets built. Your job is to solve Y within the available budget and time.
The milestones should therefore describe evidence, not construction. We verified why appointments are missed. We tested reminders manually. We measured the effect. We rejected one hypothesis. We found an intervention that works. We made it repeatable. We automated it.
X should remain disposable for as long as possible. Y is the commitment.
The old function promises certainty about X. The new function creates evidence about Y.
So please, stop asking, “How long will it take?” Start asking, “What is the fastest, cheapest thing we can do next to discover what actually solves Y?”.
This is how you keep your agency in a world where AI distorts every timeline:
Math is the base, not the summit. Above problem-solving on paper sits a harder, more abstract problem: making something other people actually want. That pulls many other skills such as sales, distribution, marketing, and taste. So every day, alongside eating well, moving, and doing math, my kids also try to make things people want. And making something almost always means creating something.
We tend to file creating under art: singing, dancing, playing the piano, or painting. But playing a piece of Mozart exactly as your teacher instructed is not creating. It may teach technique, and technique matters, but technique is the base, not the summit. Art begins where the instructions end.
Here in Singapore, a lot of what gets called art education is precisely that: doing what the teacher says. Play this piece. Paint this picture. Copy this object. A child can become very good at following instructions without ever deciding what should exist. That is the opposite of creating.
Creating means making choices when nobody knows the right answer. You decide what to make, how to make it, and when it is done. You try and fail. You get frustrated. Maybe nobody believes in you. Maybe you are the only person who likes what you are making. You keep going anyway. Eventually, perhaps, you make something other people want. It is great if that thing is useful like a hammer, but usefulness comes in many forms.
My eldest, Pascale, has had the most years of this. Her art has grown from drawing to stickers, air-dry clay, polymer clay, masks and costumes, sewing, embroidery, face painting, photography, and YouTube Shorts. It did not follow a curriculum. One thing led to another. Each new thing required a new skill, a new material, or a new way to reach people.
Now she is making money at it. She already earns more than an entry level wage in some countries. That is not a side detail. She is not being paid for following instructions. She is being paid because people want what she makes.
She started with eating and sleeping well, moved through math and harder math, and arrived at making something people want. That progression is how my homeschooling is fundamentally different from the government curriculum. The goal is not just to follow instructions well. It is to decide what should exist, make it, and find out whether other people want it.
There is a problem above even that: governance. If you only ever make what people want, you slide quickly toward vices, sugar, cigarettes, gambling, the things that hijack our wiring. So as you mature, you also have to think about how what you make gets consumed.
A lot of people, and a lot of large companies, stop at “if it is legal, I will do it.” At the scale of a Google, ByteDance, or a Meta it becomes nearly impossible to resist those market forces. It is easy to criticize them for how their products farm attention and addiction, including in children, and easy to note that the age limits barely hold.
And that was fine in our household, because when I introduced my kids to these platforms, I also taught them about addiction. That is the thread running through all of it, back to nutrition. Sleep, food, exercise, math, screens, they are the same tension: we are wired to want something, we overshoot, and it turns on us. We crave sugar, so we eat too much and get sick. The right thing almost always takes effort, so we avoid it. That gap between what we are pulled toward and what is good for us is the central human problem, and it is the same problem whether you are an individual or a society. It comes down to self-control, incentives, mechanism design, and role modeling.
Here is a real one. Pascale has eczema, and has had it her whole life. It affects her, and it affects millions of people. But pharmaceutical R&D budgets follow profit, not need. The most research money flows toward whatever will sell, which is how our system works, and we do not have a much better one. Maybe there is a cheap cure for eczema sitting right there, something that would cost a hundred dollars and wipe out the industry of creams and lotions built around managing it forever. If so, there is no economic incentive to find it. My hope is that AI and cheaper research start to open up problems exactly like that, the ones with no product to sell at the end, maybe an RNA approach, maybe something simpler, that could actually help.
That is the arc I am trying to build, one kid at a time: a well-run body, regulated emotions, a mind trained on abstraction, the ability to make something people want, and the judgment to care how it gets used. None of it requires a special gift. It requires starting early, going slow, and not quitting.
Everyone can learn to ride a bike.
]]>I challenge them with abstract thinking in its purest form. We call that math, but we usually confuse math with its notation. The syntax and the algorithms are only one aspect of “math”, the way language is only one aspect of a culture. You cannot reduce Japanese culture to the Japanese language, and you cannot reduce math to its symbols. Math is really the exercise of reasoning itself, the workout for the part of the mind that solves problems.
The trouble is that math is difficult to teach well, particularly in a classroom that must move many students at one pace. You have to go slow. Like REALLY SLOW. So slow that it’s uncomfortable to most impatient adults.
Classrooms do go slow. They just never go slow at the speed of the individual learner. For a given topic, child’s right pace is another child’s crawl. The result is one-size-fits-none: too slow for most of the class most of the time, then too fast in the exact moment when it is your turn to miss a concept. If you never miss a concept in class, it is because you went slow somewhere else, maybe at home, where someone let an idea sink in. There is always a moment where understanding has to land, and that moment is slow. Slow is smooth, and smooth is fast. We forget that we once learned “after nine comes ten” slowly, the same way we later learned a differential equation slowly.
We do not give kids room for that slow moment. It takes an educator, or an educator plus an AI, willing to sit at one child’s pace.
That is what made Khan Academy powerful: you could press pause on a good teacher and take your time. Grant Sanderson’s channel 3Blue1Brown goes further, building visualizations that let a hard idea, a Riemann zeta function or how a neural network works, actually sink in while you pause and rewatch. Go slow, but keep challenging. If you stop challenging yourself, you stop building the muscle.
We do math seven days a week. Five days never made sense to me. The weekend off is a leftover from when families needed a day to rest from physical farm labor and a day for the Sabbath. We do not have that constraint anymore. A little every day beats a lot once in a while, the way Kumon runs twenty minutes a day with no exceptions.
Think about how Olympians train. Not Monday to Friday. Seven days a week, rarely at one hundred percent, usually around eighty, because the total accumulated hours are what matter and going all-out daily just gets you injured.
Same idea for the mind.
Two things, mostly.
First, Art of Problem Solving, an American math curriculum. It is not expensive and we simply follow the textbooks: thirty minutes, an hour, sometimes two, seven days a week. I am sure China, Russia, and others have excellent programs too. This is the one I know.
Second, Code Submission Evaluation System, a sequence of programming problems. These are more abstract and harder than the pure-math ones. A tough Art of Problem Solving question might take thirty minutes. A hard CSES problem can take six or seven hours, sometimes spread across days. The description might be forty words. The solution requires discovering a great deal.
We always start on pen and paper, working numerical examples by hand. That is the whole point: structure a problem, iterate toward a solution, and let the examples push you from guessing toward a hypothesis, then from a hypothesis toward an algorithm, then toward pseudocode, and only then toward C++, Python, or Rust. We use Claude Code and AI throughout, but as a tool, not a crutch. If it solves the problem for you, you lose the discovery. You do not hand a calculator to a one-year-old learning five plus five. But you do, eventually, teach them to use the calculator.
Math teaches them to solve problems someone else chose. The next step is choosing what should exist.
Next: Part 3
]]>I think it’s not too dissimilar to meeting someone who has learned how to ride a bike. Once you can do it, you forget how it feels to not be able to ride a bike. And riding it gives you freedom: you can cover long distances, you can go where you want, and you can move under your own power. A good business gives you leverage over your finances and your time.
I think most of us can learn how to ride a bike and most of us can learn how to build a business. Most people underestimate the pain and most people quit too soon. So it’s better to start to learn to handle pain and develop tenacity early on.
With my children, I started teaching entrepreneurial skills before age 10. I do not need all 3 of them to run companies. I want all 3 to know how to create value without waiting for permission.
This 3-part series is about how I’m teaching my children to think, create, and choose problems worth solving.
I homeschool around a simple hierarchy. First, build a healthy and self-regulating body. Then train the mind to solve abstract problems. Then learn to make things other people want. Finally, learn to judge what is worth making and how it will affect the people who use it.
This is not a research review. It is a description of what has worked in practice with my children.
Learning begins before birth, when experience starts to leave a lasting trace. Maternal nutrients help build our bodies, while flavors from our mothers’ diets become some of our first sensory memories through amniotic fluid and, later, breast milk.
In early childhood our first emotions get nurtured by whoever is caring for us. Quickly, we learn to control our emotions, to communicate through touch, and to lay the foundations of language. By five, most of that base is in place.
Then spoken language matures and we start to think more abstractly: basic math, reading, stories. Somewhere in here we also begin making choices, consciously or not, about how much effort we will spend, how hard we will push, and whether we treat our environment as something that happens to us or something we can harness like the wind.
That is roughly when primary school begins, and school does a decent, standardized job at the earliest stages. But by primary two or three, the fastest students are already far ahead and the slowest are already left behind. This is where the wonderful government-standardized system falls on its face. And it does not really recover until people hit the job market or try to start a business.
By the time you reach university or trade school, you have spent more than a decade on school benches. Think about the average age of becoming a plumber, an electrician, an HVAC technician, a drilling engineer, a computer scientist.
Many people spend more than a decade in school before they are trusted to solve useful problems independently. That is a shame. It could be the mid-teens. It could be dramatically accelerated.
Before a child can learn anything hard, the animal underneath has to be well. I mean the body and its basic regulatory systems: sleep, food, movement, emotional control. My kids do jiu-jitsu and ballet, they ride bikes, they swim. They sleep in the dark, in silence, through the night. They rarely get sick, they digest well, they have energy all day, and they get along with people. Because that base is handled, they can spend their attention on higher-level learning.
That foundation is worth more than it sounds. Most adults I know do not have it. Many never fix their diet, sleep, or stress until a heart attack or a cancer diagnosis finally makes them listen. My kids eat broccoli without complaint, they like salmon and chicken, and they understand why a balanced plate matters. We are still litigating whether a tomato is a vegetable or a fruit. We have at least settled the avocado. Getting these basics early is important.
I also teach them to be contrarian. When a lot of people believe something, that is a reason to look harder, not a reason to fall in line. I want them curious on purpose and skeptical of social proof. That is rarer than it should be, at any age.
That is the first layer: a body capable of sustained attention, emotions that can be regulated, and a willingness to question the default.
Next: Part 2
]]>We write emails so the reader can understand the point in seconds, decide quickly, and forward the message without extra explanation.
The first sentence should say the ask, decision, risk, or update.
Do not warm up. Do not build suspense. Do not tell a story.
If something is wrong, say it early.
Do not hide the problem behind context or politeness.
Every sentence should earn its place.
Delete filler, repetition, and softening language.
Say exactly what you mean.
Do not use sarcasm, hints, irony, or coded language.
Do not make the reader guess.
Use names, numbers, dates, and facts.
Bad: There were some delays.
Good: Vendor X missed the March 12 deadline. Launch now moves to March 19 unless we reduce scope.
An email should mainly do one thing: ask, decide, update, escalate, or confirm.
If you have three unrelated topics, send three emails.
Say who needs to do what by when.
If you want a decision, say the deadline.
If you want feedback, say what kind of feedback.
Facts are what happened.
Judgment is what you think it means.
Recommendation is what you think we should do.
Keep those distinct.
If something is uncertain, say that clearly. Do not present a guess as a fact.
The email should still make sense if someone forwards it to another person with no extra context.
That means the topic, names, dates, and decision should all be clear inside the email itself.
It is fine to use AI to draft or review an email.
But edit it until it sounds specific and human.
If a sentence could be pasted into any company, it is too generic.
Avoid phrases like: I hope this email finds you well I wanted to reach out Please be informed Kindly Just circling back Revert to me
Use normal words instead.
Aim for an email that can be read on one screen.
If it must be longer, put the punchline first and then add short sections underneath.
Be respectful, but do not hide the truth.
Direct is better than vague.
Clear is better than polite but useless.
Reply on the same thread only if the topic is still the same.
If the topic changes, start a new email with a new subject line.
CC only people who need to act or know.
The subject line should help the reader triage the email fast.
Good: Action needed today: approve revised offer Decision needed: pricing for Client X Update: contract signed with Acme Risk: launch delayed by one week
Weak: Quick question Following up Hi Update
Subject: [Action, Decision, Update, Risk]: [topic]
[First sentence: the ask or punchline.]
[Two to five lines of facts, with names, numbers, and dates.]
[Recommendation or next step.]
[Owner and deadline.]
Subject: Vendor situation
Hi John, hope you are well. I wanted to reach out regarding the vendor situation. As you know, we have been discussing timelines internally and there have been a few complications on their side, so I thought I would share some context before getting your thoughts. Please let me know what you think.
Subject: Decision needed: vendor delay on onboarding
Vendor X missed the March 12 deadline. If we keep the current scope, onboarding moves to March 19.
My recommendation is to remove feature Y and keep the March 15 launch.
Please reply by 3 pm today so we can confirm with the client.
Subject: Issues with campaign performance
Just wanted to flag that there may possibly be some issues with the campaign performance and we may need to revisit the targeting.
Subject: Risk: campaign under target this week
The campaign is 18 percent below target after four days.
Likely cause is narrow audience targeting.
Recommendation: expand targeting today and review performance again tomorrow at 2 pm.
Do not use email for long back and forth, unresolved debate, or high emotion.
Use a call or chat when speed matters more than record keeping.
Then send a short email summary with the decision.
A good email does not try to sound smart, warm, or impressive.
It makes the reader understand the point fast.
]]>It can feel intimidating when you are surrounded by people who have 10, 15, 20 or even 30 years of experience. Some of them have probably spent nights inside data centers fixing outages. Some have canceled vacations to handle incidents. Some have led big deployments and messy turnarounds. They have battle scars.
But here is what actually matters.
The hardest thing to find is not experience. It is someone who gets things done.
Most people do not like to work that hard. Most people are not reliable. Most people do not respond fast. Most people do not close loops. Most people do not keep learning. If you simply behave differently, you already stand out.
Experience gives pattern recognition. It helps people see risks earlier. That is valuable. But execution creates trust. When you respond quickly, prepare properly, follow through, and take ownership, people relax when you are on something. They stop asking how many years you have. They care that things move forward.
Also remember this. None of them had tools like ChatGPT 10 or 15 years ago. A lot of what we are building now, AI, automation, new infra patterns, is new to almost everyone. The playing field is flatter than it looks. You can compress learning cycles massively today if you are disciplined. You can research faster, simulate scenarios, draft solutions, and prepare sharper questions.
So do not be intimidated by tenure.
Focus on what you can control:
If you do that consistently, your value will be obvious. Experience earns respect over time. Execution earns respect immediately.
]]>One axis is agreement versus disagreement. The other axis is effort versus no effort.
Bottom left is the most common and mostly useless feedback. You agree and you suggest something that is missing. “This is good. Did you think about adding X?”
This kind of feedback feels helpful, but it usually is not. Ideas are cheap. You are pushing work back onto someone who has already done the work and probably already thought about that idea and decided not to include it. Sometimes it is fine, but most of the time it adds little value.
A step up is when you agree and you do the work. “This is good. Here is a sentence you can add.” Or a concrete image, sketch, calculation, or paragraph.
This is good feedback. You put in effort. You made the feedback actionable. You saved them time. If you are faster or better at a specific skill, design, math, writing, this can be genuinely helpful.
Another form of good feedback is when you disagree, but you do not do the work. “I think this part is wrong.” “I see a hole in this argument.” “I disagree with this assumption.”
This still has value. Disagreeing thoughtfully is harder than agreeing. If you are right, you are pointing out something important they may not have considered. You have not fixed it, but you have surfaced a real issue.
Great feedback is when you disagree and you do the work.
You point out what is wrong and you propose a better version. You rewrite the paragraph. You fix the logic. You sketch an alternative design. You show how you would approach the problem.
That is great feedback.
This framework applies to everything: Presentations. Writing. Code. Design. Math proofs. Data analysis. Product specs. Business strategy. Pricing models. Sales scripts. Marketing copy. Hiring decisions. UX flows. Architecture diagrams. Operating procedures. Checklists. Recipes. Photography composition. Sound mixing. Choreography. Yoga poses. Ballet movements. Weightlifting form. Climbing routes. Jiu jitsu positions. Parenting. Negotiation. Thinking.
]]>He is right. There is a lot of tacit knowledge in operating a ship that never shows up in documentation. A skilled crew member still knows how to do things much better than AI can today.
Safety has the same dynamic. Many are moving away from BBS toward human performance. BBS is measuring near misses with an accounting lens. Human performance is changing the process instead of blaming the individual. It is about improving the system itself.
But something bigger is coming that most industries have not absorbed yet. Wearables.
We already see them in consumer life: rings that track sleep, watches that track runs, bikes connected to the internet. And now the Ray-Ban Meta glasses. This may be the first form factor that can replace the phone as the primary device we use.
You do not understand it until you put them on. These glasses feel like the BlackBerry moment. Not the iPhone yet, but the first credible step toward it.
Gen 1 felt gimmicky so I skipped it. Gen 2 is different. Eight hours of battery. A case that extends it. Pictures that are good. Recordings that are good. It has replaced my iPhone as my primary camera. I now take more pictures with my glasses than with my phone.
It is also replacing my AirPods. AirPods slip. The glasses do not. They are more comfortable. The audio is not as clear because the speakers sit further from my ears and people with big heads might feel the frame is small. But I still prefer using the glasses.
Talking on the phone is not the biggest shift. The glasses are becoming one of my primary interfaces to LLMs. For almost two years ChatGPT has been my main LLM because it has my memories and I can access it everywhere. But the glasses are even more convenient because they are on my face. I say hey Meta and I begin a conversation. Those conversations get stored. It is a real threat to ChatGPT.
I still prefer ChatGPT because GPT 5.1 is stronger and the speech capability is the best. Meta is better than Siri and better than Gemini but OpenAI leads in speech and conversation. ChatGPT real time can search the internet better than Grok or Gemini. Gemini still relies on older data. Everyone will eventually catch up. The point is I do not want to pick up my phone anymore. I want to talk to my glasses.
Two examples show the impact. When I ride my bike with my kids and talk to my parents on WhatsApp I used to keep the camera off because my phone was in my pocket. Now I turn the camera on through the glasses and they see what I see. They see my kids riding. A maintenance worker in the field could do the same thing.
At the airport I held my plane ticket up to my eyes and asked my glasses what my gate was. It struggled at first but after two or three tries it figured it out. It recognized the ticket did OCR and returned the gate number. A small example but a real wearable doing real time computer vision tasks.
Most processing is still done on the phone. The glasses do minimal processing and store pictures. The phone connects to the internet for full LLM power.
Ships all over the world are connected via Starlink. Underground mines have WiFi. 5G is everywhere. Wearables are everywhere. We will see massive changes bigger than we expect. Even difficult tasks where workers are blamed for mistakes will shift. Workers will adopt these technologies because they make them safer and more efficient. The incentives change and the big brother fear becomes smaller.
Companies that understand this without spending hundreds of millions and damaging their balance sheet will be ready. They can become more than a shipping company with ships and crews. They can become a company with ships and crews and a platform that differentiates them and supports organic and inorganic growth.
]]>As agentic AI automates many tasks in traditional expert roles like doctor, engineer, analyst, or architect, we’ll all move toward the same core function: learning how to question what the machine says.
AI gives us the prevailing view among experts. It is trained on large public and licensed datasets. It is the record of known results. But new knowledge does not come from agreement. It comes from doubt.
Our role now is to look at what the machine outputs and ask, how could this be wrong? To run experiments, to test boundaries, to consider cases that contradict the default answer. To create hypotheses, try to disprove them, and identify boundary conditions where the model fails.
That’s what science really is, testing claims against evidence. In this next phase, everyone becomes a scientist. Not by degree, but by method.
Are you a (data) scientist?
In the past week alone, I’ve reviewed more than a hundred resumes from people who call themselves data scientists. Maybe that’s where we’re all heading. Soon, most jobs will involve scientific work. You’ll be a medical data scientist, a legal data scientist, a construction data scientist, and so on.
Do you believe in science? Or do you believe something to be true because someone reputable said that it is true?
If you do, then you are not a scientist. Because believing in science is itself unscientific. Scientists don’t believe, they doubt. The scientific method is not about proving what you already think is true, it’s about trying to disprove it.
That’s what the so-called “null hypothesis” means, though the name is misleading. It sounds like it means “no hypothesis,” but what it really means is this: when you hold a belief, your job is to challenge it, not defend it. You don’t collect data to prove yourself right, you collect data to see if you might be wrong.
A better term for the null hypothesis might be the doubt hypothesis, or even the humility hypothesis. Because real science is an act of humility.
It’s the same principle behind Hanlon’s Razor, don’t attribute to malice what can be explained by stupidity. When we stop assuming intent and start looking for evidence, we act scientifically.
So the next time you catch yourself holding a strong opinion (especially one reinforced by ChatGPT!), ask: am I trying to prove this, or am I trying to disprove it?
The answer will tell you whether you are just another believer, or a true scientist.
]]>What is technical debt? It’s when the codebase of a software project starts to become difficult to maintain, for example due to:
The code still works, but the concepts embedded in variable names, data models, and APIs no longer align with what the product does.
But with AI-augmented coding, there’s a deeper, subtler burden but much more serious burden: AI theory debt.
When you prompt an AI like lovable or Claude Code, it feels like magic. You get 90 percent of a working feature in minutes. Its breathtaking.
But you never built a theory of that code. You don’t really know why it works, where its vulnerabilities lie, or how small changes cascade. You hold the result, not the insight.
Later, when you try to tweak one small thing, you end up in a cascade of failures: moving a pixel shifts layout, tweaking a state variable breaks logic elsewhere, refactoring one function ruins dependencies. You realize too late the AI was smart at generating but dumb at preserving coherence.
That’s theory debt. Or AI theory debt. Or AI debt. Or comprehension debt. Call it what you want.
Because you never internalized the code’s theory, you now pay for reverse engineering, debugging, and walking blind paths.
That Hacker News post I linked above connects to Peter Naur’s 1985 Programming as Theory Building. Naur argues that the real product of programming is not the code or documentation. => It’s the theory in the programmer’s head: how the system maps to the real world, why each design decision was made, how modifications should evolve.
If you lose or skip that theory, you degrade your capacity to change the system intelligently. Over time, the system devolves into patchwork, because you’re modifying without shared insight.
So unlike technical debt where you knowingly accept imperfections, theory debt is debt incurred by ignorance. It’s a debt you don’t see! Not until it forces you to rebuild, or abandon what you built.
How to manage theory debt:
Theory debt is insidious because it’s invisible until you suffer. It’s the debt of missing understanding. Don’t just borrow working code. Borrow the insight too.
💚💚
]]>