Hideki Mori

Posted on Jul 20

I survived 24 years because I'm lazy

#ai #productivity #discuss #career

I've shipped code for 24 years. Same job, mostly the same stack, mostly alone.

People assume that takes discipline. It doesn't.

The truth is simpler and less flattering: I'm lazy.

Not Larry Wall's "automate the boring stuff" lazy. Regular lazy. I avoid hassle. I skip work I don't want to do. I work around things that feel like chores.

Twenty four years happened because I built around that. The first thing I built around was deadlines.

Don't set my deadlines

I don't want to accept deadlines from other people.

Not because I'm undisciplined. The opposite. Once I'm inside a problem, I stay there until it ships. Interrupting the flow costs me more energy than continuing. That part isn't the issue.

The issue is that nobody outside my head can predict when "done" is. They don't know what's easy for me and what's hard. They guess. Then they tell me their guess as if it were a fact.

It grinds on me. Every project where someone tried to schedule me, I ended up resenting the scheduler more than the work itself.

The answer is always: "I'll ship it when I can. And yes, I'm working flat out."

Most of the time, "when I can" is the next business day. There's not much point setting a deadline for that.

What "when I can" actually looks like is the rest of this article.

What a lazy survivor actually does

Here's the daily shape of it. Some of these will sound like discipline. They aren't. They're what laziness produces when you've been at it long enough.

I don't stop until it's done. This is where "lazy" gets confusing. When I'm in a problem, stopping is more work than continuing. I sleep and eat enough to not fall over. The work isn't the chore. Pulling myself out of it and back into it is the chore.
I write the spec by being my own user. Nobody knows what's easy to use and what's consistent better than the person stress-testing it. That's me.
The 3-line discipline. (See 010.) By the time the code is written, it's already been tested.
After release, I watch the logs. Access logs, batch logs, error logs — I keep them tailed. A weird line scrolls past and something catches. The alerts haven't fired. I already know.
I redeploy as many times a day as I need to. The first release barely matters. What matters is the 10, 15, 20 years of changes that come after. The earlier you ship, the longer that window is.
I throw real data at my own software, hard. Big data, malformed data, weird-shaped data. The only confidence I trust is the kind that survives that.
When an internal user overloads my system, I thank them. Live data is a gift. I have never had the opposite feeling about a real-world failure.
A bug found before anyone else sees it isn't a bug. It's just an edit.
If there's an update worth making, the next day is too late. GPT-5.5 ships → I verify it on my app today, ship it as a selectable option today. I don't want to be the one lagging behind.
Batch processing is what I love most. Shaving milliseconds. Cutting load. Watching batch logs scroll. Every part of it is a reward. I'm always hoping more batch jobs come in from users.

And one more — the most important one, the one 24 years actually paid for:

Discomfort means something is wrong. Always. When something feels off, I hunt it down and crush it. The hunch isn't mystical — it's 24 years of pattern recognition without a vocabulary, and it hasn't been wrong yet. The part of me that wants to look past it has always paid for it later.

Where being lazy actually hurts

Not all laziness is helpful. Some of it is just being a person who avoids reading.

I don't read manuals. My wife has a car with cruise control. I've driven it for years. I still don't know how to turn the cruise control on. Every time, I'm too lazy to figure it out, and I drive without it.

That instinct does real damage at work. I don't read API docs unless I have to. I don't read change logs carefully. I skim. I assume. I run code instead of finishing a manual.

English is the other one. I'm Japanese — my technical reading is fine, but the gap between "I can read this" and "I want to read this carefully" is wide, and laziness lives in that gap. Long English documentation is exactly the thing I will not voluntarily face.

For most of my 24 years, this cost me real time. I'd build something that worked, then discover three weeks later that the API I'd wrapped had a flag I'd missed because I never read past the example block.

The honest answer is that Claude reads for me now. I describe the problem, Claude reads the docs, Claude points me at the part I need to verify. It doesn't replace judgment. It removes the friction between me and information I was always going to avoid anyway.

I don't say that to praise AI. I say it because it's true for me, and it would be dishonest to write a piece about how I work in 2026 without saying it out loud.

The engine

If you re-read the list above, two things are doing the work. Both are unglamorous.

The first is the laziness. Each new component means ten years of maintenance I'll have to carry. Each new methodology means bugs I haven't learned yet. Each methodology argument is time not spent writing code. Each promised date is someone else's deadline I'll have to keep. I avoid all of it by default.

The second is profit. What I build has to make money. Not in some abstract sense — actual revenue from actual users. That part of me has no patience. If a service isn't paying for itself, something is wrong with it, and I want to know what. So I ship early, watch logs, redeploy whenever there's something to fix. Not out of discipline. Out of refusal to leave money on the table.

These two forces don't agree on much. Laziness says "don't bother." Profit says "if it makes money, bother." What's left after they negotiate is everything I actually do.

That's why "shipping continuously for 24 years" looks like discipline from the outside. It isn't. It's laziness pushed in a useful direction by the only thing that ever moved me — the need for the result to actually pay.

A CEO at one of my earlier companies once asked me: "That service running on your desktop — can you make it public right now?" I half-dismissed him at the time. Years later I understood he was the salesperson version of the same engine. That's a story for another time.

Other solos

There are other people doing what I do. Solo. Operating something they built years ago that's still running.

I assume — based on no evidence except how this kind of work shapes a person — that no two of us work the same way. Each of us has wrapped a different cocoon around a different temperament. What I do would be unworkable for them. What they do would be unworkable for me.

I respect that more than I can put into words. Solo developers who keep their own systems running for years are doing a job that doesn't show up in any career framework I've seen. Most of them never write about it because writing is also work.

Whatever way you do it — keep going. I see you.

What survived

People who watch me work sometimes call it persistence. Conviction. The shape of a long arc.

It isn't.

I survived because every alternative was more work than continuing. I stayed lazy. I got paid. Together, those two facts ran the clock for 24 years and counting.

What looks like a disciplined career from the outside has always been, on the inside, the path of least resistance — provided someone was paying me at the end of it.

The lazy way is the only way I know.

Built with Claude (Opus).

Earlier in this series:

DEV Community