Insight

Manual Coding Is Dead

Fri, 01 May 2026 00:00:00 GMT

Stop looking at the code. Close your editors; the models don’t need them.

I have seen a lot of “coding is dead” and “coding is alive and well” posts in the last few months, and I now think both categories are missing the point. The typical ‘dead’ argument goes something like “agents can now write the code, so software engineers are doomed”. The typical ‘alive’ argument says “software engineers do a lot of things, and agents don’t do all of those things, so we’re fine”. I’m honestly not sure if we’re doomed or fine, but I suspect it’s neither: things are changing dramatically, and trying to explain a divergent future in terms of today’s jobs (or the past 50 years of them) isn’t going to work very well.

I need a term for the old-school way of coding, the one where you open a text editor and type the code, one character at a time. I propose we call it manual coding. I’ll also include in this category variants such as “first read the code in the editor and then use a tool (agent or refactor button) to edit the code”. Basically, if you’re still opening an editor, you’re coding manually. And if you’re still reading the code that was produced, you’re reviewing manually.

I strongly believe that manual coding is dead. Looking at the code is more and more akin to looking at the assembly: a few people actually need to do it, but the vast majority of us do not. If you take away just one thing from this essay, let it be this: stop looking at the code. If you’re still doing it, you’re wasting your time, and you’re missing out on the biggest productivity multiplier since compilers were introduced. Close your editors; the models don’t need them.

I think I understand at least some of the resistance to letting go of the code. I spent my entire 20-year career as an IC because I liked the code. I did this for fun and professional pride. Few days felt as good as the ones spent entirely immersed in a hard problem, coming out on the other side with an elegant solution that you could proudly show your peers. It felt great when someone understood you, when they recognized the craft. Product people and business people may not have cared, but the coders did. You could look at 50 lines of code and say “this is beautiful”. So when I say “you have to let it go”, you say “but what of the beauty”? The beauty is for us, the old guard. You had to be there. The new generations will never see it.

The primary reason you have to stop manually coding is simple: the SOTA LLMs (Opus 4.7 and GPT 5.5 as of this writing) are now better than us. Modesty aside, I think I’m a great coder. I went to two ACM ICPC world finals, I built Bing’s crawler scheduler, Facebook’s audio calling, Snap’s push notifications backend and OpenAI’s connectors. I worked with some of the best engineers in the world and I held my own. And even with those credentials, I think the LLMs code better than me. They’re more knowledgeable, more creative, and more precise. Even if they took just as long as I took to type the code, you should probably still take their code over mine (for a sufficiently well-defined task). But on top of all that, they are orders of magnitude faster. They do in minutes what would take me a day, and in hours what would take me a week or more. And they charge a lot less than I did per hour.

If you take this advice and stop manually coding, you will soon find new challenges: writing good specs, verifying the agents’ work, designing good architectures, and designing good UIs. This partially explains the “alive and well” camp, because these skills matter today. Agents still need help sometimes, but they often do not need any help. Models got much better in the last few months and they’ll continue getting better. And a lot of people, myself included, have been spending time building harnesses to address these deficiencies at a higher level of abstraction. So I don’t think you should take it for granted that those other skills will retain value.

If you read this far, it may seem that I’m saying that software engineering is dead. My main disagreement with the doomers camp is that the software doesn’t just appear out of thin air. Someone must will it to exist, and keep poking at it until it has the right shape and is delivered to the right people. The general business prompt to an all-powerful agent (“make me some money”) is unsatisfying and undifferentiated, and humans will continue thriving by trying to shape the world to match their preferences and judgment. We just won’t be typing much in the process.

I hope to write more frequently about this subject. In my next post, I’ll write a case study based on Retirement Lab, a 200k LOC app that I built and shipped solo in two months with the immense help of Claude Max and Codex Pro subscriptions. If you’re not convinced by this first essay, perhaps a few examples and statistics will help.

Second Leter to Ben

Mon, 06 Nov 2023 00:00:00 GMT

Time carries me relentlessly
I caught some droplets off its vast stream
Held them in my agings hands
and made ink.

I refuse to let it go. 
We shall remember. 

1. Bonding

Your mother can see into mysteries invisible to me
I nod when her prophecies come true
Wondering about my blindness

I might have worried when she said
You and I were not bonding
But I knew things were fine
(fathers have their own powers, you see)

We did bond.
We became quite the pair, you and I
Countless steps back and forth
Holding you close to my chest

2. Right leg up

I hope to one day visit your home
To sit down and have a cup of coffee
I don’t know what we’ll talk about
(I suspect it won’t be trucks anymore)
But I’m confident your right leg will be up
Just like you always liked it

3. Mexerico

You’ve been fond of touching
Ever since you were born
Each face and toy and wall
Was something to be explored with curious fingers
Even today, three years later
You still tell me that you’re just seeing this or that
With your hands

4. Mirror

Some people tell me you look just like me
I tend to disagree, my hair and skin being darker
Except in the earliest of hours
when the world looks black and white
I look at you and see myself
A ripple from another place and time

5. Fearlessness and robots

You seem to have no fear
You’ll climb and jump and fight
sometimes too bravely for my own heart
Nothing frightens you
except for robots

Perhaps you know something we don’t.

6. Cooking and feeding

If I invite you to cook
You drop your favorite toy to join
We like the fire, the smells and tastes
And we like to share our joy

May your pantry ever be full
I’m sure your table will have many guests.

7. Dally

For years I was neither daddy nor papai
I was ‘dal-ly!’
That’s how you’d summon me
when you felt hungry, tired, proud or lonely
And even when I was tired
and everything else was quiet
I reminded myself that one day would be the last time
And I’d miss your voice

I do miss it
Never hesitate to call me
That’s what dallys are for

Breadth

Tue, 25 May 2021 00:00:00 GMT

In the spring of 2015, my manager in London told me he was impressed with my technical breadth. I joined his team after a hackamonth working on a code editor with Kent Beck, went on to work on some low level bluetooth routing, and eventually left that to work on the newsfeed and composer surfaces of the Facebook app, covering three quite distinct surfaces in a few months. That conversation was the first time when I really felt like a senior engineer. Senior not in the sense of “I achieved level 5”, but rather in the sense of “I feel like I know what I’m doing”. Having worked on a lot of apparently unrelated things, I finally achieved a sense of mastery. This post offers some introspection on that process.

(The other reason to write this one is that I really value symmetry, and thus a post about Depth keeps wanting its counterpart to exist)

I don’t necessarily recommend that you become a generalist — it probably takes longer to rise up in the ranks than it takes a similarly skilled specialist. Furthermore, generalists tend to eventually branch off of technical jobs and go into management or other less technical disciplines. But some people — like me — can’t help themselves, and will sooner or later get bored of encountering the same problems, or worse, knowing the solutions and slowing down on their learning curves. At that point, the natural thing to do is simply to seek something new and shiny again. So that’s element number one of being a generalist: you don’t want to specialize.

Now, how does anyone get good at anything if they don’t put in enough work? I don’t think they do. If I kept switching to completely different jobs (say farming, baking, running, painting) every 2 years I’d probably be mediocre at best at each of those jobs. The key realization for one to become a successful software generalist is that things are largely similar and applicable across different domains.

As obvious as it may sound, it turns out that it’s all just code. At a high level, it doesn’t really matter if the code is running on a desktop PC running Windows, or on an Android phone, or on a k8s container hosted on god-knows-which-cloud-provider. Code, as Turing would teach us, is all some arithmetic, branches, loops and state. And to make things even easier, modern system architectures are very similar to each other. Armed with that knowledge, one can always go ramp-up on a new problem space as long as they can patiently read and understand the code! I can’t emphasize enough how important it is to read the code. I’ve found and fixed a lot of issues over the years just because I’d be the only one to actually go read the code very carefully. A corollary here is that programming languages don’t matter all that much — as long as you learn what the computer is doing behind the scenes, you can always figure out how to work in a new language.

The other important property of software that helps generalists is that certain patterns are fractally applicable (i.e they help at a high level, but if you zoom in and look again you still want the same patterns to hold). An obvious such property is the minimization of dependencies (in particular circular ones). You want this to be true when designing a collection of services, but also when defining a collection of processes in your container, or a collection of classes in your process, or a collection of variables in your class. Another one is size, or partitioning. No matter which level you’re operating at, you never want something so big you can no longer reason about it (think a 1000 loc function, or a service with 1000 endpoints), and you also don’t want a collection of pieces so small that you lose track of what exists (think 1000 functions made of 1 line each, or 1000 tiny services).

I don’t intend to create an exhaustive list of all the behaviors that help across software domains, but some others include “testing” (how can I know something works), “fast iteration” (let’s build things in small chunks and ship them ASAP), “customer focus” (who are we building this for) and “business focus” (why are we building this). As you move through different projects in your career, these meta skills continue accruing and remain applicable to everything you touch. That’s what allows one to keep on improving when switching over to a new area — despite it being new, they’re not starting from scratch.

One final thought. While my intention was to create a counterpart to my depth post, I now realize that these two have a common thread: curiosity and its natural consequence, exploration. No matter whether you’re going deeper into something you’re familiar with or getting to learn something brand new, allow yourself to be curious! Don’t treat software as black boxes. When given a chance, open it up and see what’s inside!

Depth

Wed, 17 Mar 2021 00:00:00 GMT

In this piece I discuss the practice of going deep into a system through a few examples. I believe I do this more often and more thoroughly than the average engineer, giving me an edge when tackling problems and increasing my rate of technical learning.

Microsoft, 2006

Soon after joining Microsoft as an SDET (a software engineer that writes test automation, a misguided concept IMO but a story for another day) I was given the task to fix a test suite that had been severely damaged by the introduction of IPv6 to the Windows networking stack (including the component I was supposed to test, Microsoft’s DNS Server). The tests were written in a custom scripting language called HAPI and a very large amount of them were failing mysteriously. I think my job was to fix them, but also to write tests for other new features that were coming online.

Despite having spent nearly 2 years at that job, I never really understood how HAPI worked. I never made a custom build of the interpreter, I never even read its source code. In hindsight, it was pretty hopeless that I could fix the broken tests, because I didn’t understand what they were doing.

Looking back to that time, I feel I wasted much of those 2 years. Not so much for staying in the SDET position (which was a minor mistake), but primarily for failing to go deeper into it. I learned a few things here and there, but not enough.

Eventually I interviewed for a SDE position at Microsoft and accelerated my learning speed, and later joined Facebook and accelerated it even more.

Facebook, 2012

After Skype balked at a partnership to support voice calling on Facebook mobile, I had a chance to write it from scratch. I proposed to write a prototype based on WebRTC, then a somewhat nascent technology developed for desktop computers. I started porting WebRTC to mobile and with the help of two other engineers got it to work on Facebook’s mobile application. Thanks to open source and a lot of hard, focused work, our small team of 3 people accomplished what a company of thousands wouldn’t do for us. I couldn’t be more proud at the time of my performance review.

To my great surprise, despite a promotion and glowing commentary in other areas, my performance feedback said that I needed to go deeper into the system. Having handwritten some assembly to fix an endianness bug that would only manifest on ARM processors I was outraged at this feedback. Did they want me to go deeper than the actual CPU instructions? At that time I hadn’t yet learned to be cautious of my own bias against constructive feedback, so it didn’t immediately sink in.

Having shipped a v1, at the time we were focused on improving quality before rolling out more broadly. A lot of my time was spent aggregating logs and trying to build a model to understand which variables could predict bad calls. Despite some good ideas, this effort didn’t yield the breakthrough I wanted, and I had wasted a good quarter on this.

The one thing that probably saved my next review was an investigation that I did into connection establishment delays. We knew that sometimes it took too long to connect a call, so I set out to figure out what was taking time. For signaling (the metadata that controls a call, saying things like “I’m calling you” or “I accept”) we leveraged MQTT, a lightweight transport protocol that Facebook used for chat as well. I traced the code all the way down to the actual system call that opened a socket, and then got curious about how said socket was configured. I realized that we wanted to send bytes out as soon as possible (both for chats and calls), so I just reduced the TCP send buffer size. This was non-controversial enough that I simply committed a one line code change without wrapping it into an A/B test or anything like that. A month later someone chased me down because they were trying to understand how the latency for all chats had reduced by 10%. I explained, people were happy. Going deep paid off, and the previous performance feedback started to make sense. Nobody was saying I was incapable of doing this. They were saying I should do more of it!

Snap, 2016

There was a time the Snapchat app for Android got so bad that the head of engineering asked my team in Seattle to stop everything we were doing and to help alleviate the problem. This was way before the rewrite (aka Mushroom) and I think no one will disagree when I say that was a wild time for that app.

One of the many problems that plagued the app were the infamous ANRs. ANR is short for “application not responding”, which Android would show to users after the UI thread had been blocked for a long time, prompting them to terminate the offending application. When looking at the stack traces for our ANRs, the most common had to do with SharedPreferences.

SharedPreferences is Android’s built in mechanism for an app to save small bits of data, typically some trivial state or app configuration. By then, most of our developers were savvy enough to not update SharedPreferences on the UI thread, since blocking IO would easily lead to dropped frames and overall user sadness. But somehow we still had a lot of ANRs related to it. Having learned my lesson about going deep, this time I didn’t hesitate. I went beyond our app and started reading Android’s source code. That allowed me to understand that the implementation of SharedPreferences simply queued updates to be executed later on, that each update would completely rewrite the entire preferences file, and that the entire queue would be executed on the UI thread when certain system events occurred. With that knowledge I built a wrapper to avoid that access pattern, which killed one third of all Snapchat’s ANRs when shipped.

Snap, 2020

The other day I had a conversation with a more junior engineer in which he asked me how come I knew so much stuff. My first instinct was to say “well, I’ve been doing this for a long time”. But reflecting further I remembered this pattern of going deep. When facing a technical mystery, don’t just shrug and write it off. Try to figure out what is actually going on — there are many tools to do it (debuggers, source code, tracing tools, network monitors and so on). If you do a good job, there’s a fairly decent chance that you crack an important problem. And even if you don’t, you’ll come out of your investigation knowing a bit more. You’ll get better and learn something different each time you repeat this cycle, eventually allowing you to solve problems that few others can.

Snow

Wed, 03 Mar 2021 00:00:00 GMT

If I grow old enough to forget   
Or sad enough to despair 
Or mad enough to lose touch   
Be a good friend and remind me   
Of that winter time when my kids were young   
   
Help me recall the quiet white   
the clear taste of snowflakes   
the mesmerizing fractal dances   
the comforting smell of hot chocolate   
the pure essence of childhood   
the all encompassing love   
   
Find me those memories and I shall smile   
Remembering that I have known true happiness

1wloc

Wed, 20 Jan 2021 00:00:00 GMT

Joining Facebook in May of 2011 was quite a shock for me. I had come from 6 years at Microsoft, at a time a slow behemoth so big that it could probably ship software faster if it had less engineers. Facebook was not like that.

Every 2 weeks Facebook would pool its new hires into a Bootcamp class. Bootcamp was to last for 6 weeks, and it included everybody — new grads, veteran engineers and everyone in between. The program included a few talks, but primarily it was about tasks and team selection. Bootcampers were assigned random tasks from across the company so they could get a flavor of many teams and so that the company could get a flavor of them. Completing no tasks was not good.

I was given a laptop and told to sit at one of the many anonymous rows in an unfinished building. I happened to sit by some lively ex-interns — kids still. And while the kids were crushing it, completing several tasks a day, by the end of my first week I was still stuck on my first task, wondering if I’d be fired.

In comparison, my previous job had been easy. Projects were supposed to take long, with plenty of planning time. Now, my planning habits were looking very much out of place.

So I invented a trick that I still use when I need to start on a new project. Let’s call it ‘one wrong line of code’, or 1wloc for brevity.

I say ‘invented’ because I don’t remember anyone teaching me this. It’s entirely possible that it was mentioned to me and I forgot about it, and I’d bet that this idea arose independently several times; maybe it’s even a thing somewhere. But I don’t think I’ve heard of it before it occurred to me.

This is applicable when many things are still unknown. I don’t know how to structure the software (functions or classes or something else), I don’t know where to put it (file names, folder names, projects) and I don’t know where to start. Over time all these mysteries clear, but they can be paralyzing at the beginning.

1wloc goes like this: just open a code editor and type a single, wrong line of code. If it’s an existing project I’ll try to place it in a spot I know how to run, and if it’s a brand new one it will be in a new file that contains only main(). It doesn’t matter that the code doesn’t run, that it doesn’t compile and that it doesn’t even make a lot of sense. As soon as I have a single line of code in front of me, I can leave the abstract planning behind and start fixing it. Putting all the other concerns aside and focusing on just that, I’ll go on to type a second line, and a third, and slowly things will begin to take shape. When there’s enough lines they will move into a function, and then into a class, and then into a file, and we’ll be in business.

The key for this to work is detachment. There’s almost no chance that this first line survives. Very likely it will be entirely replaced by something better as the project starts to take shape. The point is not to produce an enduring work of art, but rather to get your thoughts flowing. What you need at this stage is not the final code; you need momentum to start exploring and figure out where to go next.

Hopefully it goes without saying that never having a plan also won’t work. If you turn 1wloc into nwloc you get nonsense. I find that this technique is a great way to break analysis paralysis, but it needs other companion behaviors (such as planning and iteration) to be successful.

As to Facebook’s bootcamp, I wasn’t fired. I adapted and eventually got the hang of it, going on to have a moderately successful stint at the company. The pressure during those years was formative, and I learned then much of what makes me a good software engineer now. I hope to share a few more of my learnings in future posts. I haven’t fully planned this series yet, but one has to start somewhere. Call it 1wloc for posts if you will.

First Letter to Ben

Sat, 02 Jan 2021 00:00:00 GMT

Everyone will remember this as a dark time
But not me

History books will talk about viruses, murders, fires, lies
But not love, naturally
scholars can’t comprehend this mystery

What I remember most vividly from this year
Is a grey day by the end of summer
When your mother and I lay spooning on a hospital bed
Waiting for you

We arrived early
As one does for very important appointments
The morning went by peacefully
And sometime in the afternoon the outside world dimmed
as the spotlight was cast on you
We teared up and held hands tightly when it was time
I don’t know whether you or mom were in a hurry
but you came out fast
Push, breathe, push and there you were
Screaming for air
Full of precious life

We left by the following night
listening to our music while driving
The trees on empty roads watching over us
as the family pieces fell into place

Everyone will remember this as a dark time
But not me, I can’t
For you filled our hearts with light
May it shine forevermore

Second Letter to Ian

Sun, 09 Jun 2019 00:00:00 GMT

I start with an apology:
I’m sorry I didn’t write earlier
I took a while because I was afraid
that my words wouldn’t be good enough
to capture these miracles I’ve seen.
That is obvious now; they never will.

(Some friends used to say
in red lettered posters
that ‘done is better than perfect’
and they were right)

I write to tell you about the lessons I’ve taken
on the subject of time.

First, that the future does not exist,
yet you’ll imagine many futures,
like I do now,
thinking of future you.

Second, that there’s only now,
all that happens is at the present moment,
and you should be mindful of it - all else is waste.

Third, that memories are but a shadow of the present,
yet you’ll cherish some forever,
because they’re all that’s left
of a perfect past.

Fourth, that human time is not made of seconds
but rather of moments. 
In that sense you enlarged my existence
a thousand fold.

I collected some of our moments here
While your memory isn’t ready
and while mine hasn’t faded
These will go one day too
But for now we fight the fleetingness
with beauty.

I. Disarray and first bottle

Dry lips in the morning
Sore breasts which you wouldn’t take
A nurse that didn’t know the urgency of life
A cupboard impatiently opened
Pots and pans on the floor
A hastily opened box full of nutrition
Your first bottle
Relieved breaths

II. Drive

Never have I felt such clarity of purpose
as when doing things for you.
I drove to three cities because you needed me to
and no traffic or rain could bother me
Nothing would stop or distract me from my mission
to provide.

III. First Light

I remember watching the very first light appear
breaking one of our many sleepless nights
turning the dark sky grey
as the world turned, revealing itself
I held you in my arms then,
as I did many times before and after,
and understood everything.

IV. Warmth

I miss the time when you perennially wanted to be held
I’d walk around rooms everywhere,
In this continent or another
Sometimes I’d sing, or count in silence
And you were always so warm

V. Old new clothes

One day you wouldn’t fit
any single one of your clothes
When did you grow?
Were we not looking?
Your mother and I packed
everything, carefully, in a box
And hugged each other as the tears flowed

VI. Banana pure

Your first solid meal was banana pure
That must be quite common
A baby eating their first pure
But like many times since we met
I couldn’t really tell you why I teared up
It’s something about life
Rushing in, thunderously

VII. Past, present and future

I opened a door
And for a brief moment stepped out of time
My father was carrying me
I was carrying you
You were carrying a baby
May this cycle be repeated a thousand times.

VIII. Remote control, red balloon

You were always eager to explore
We encouraged you, of course,
But you struggled to do more
Like that day when you got
the remote control in one hand
and a red balloon in the other
and places to go
I asked you ‘what now’
And off you went
Walking by yourself

First Letter to Ian

Tue, 21 Nov 2017 00:00:00 GMT

On the night you came into this world
Your mother and I listened together
Hand in hand
To all our love songs
The water broke as the second one played
And we kept on listening
I felt infinite love for her
And let a tear or two surface and drop
(Unlike what others may say,
Men do and should cry)

We rested for a bit
There was lightning
We never see lightning in this part of the world
I wondered what kind of omen that was
Decided it was a good one
And went back to waiting

I will never forget your mother's face while she pushed you
The fiercest, bravest expression you'll ever see
All the fury and energy and power of every woman that ever walked this earth
A warrior you could not face
The primal forces of nature combined
No words will do it justice
It takes a lot to bring one of us into life

We saw your black hair first
Then you were out, eyes wide open
A blur of medical people surrounded us
But your mother and I saw just you
We cried the happiest tears
And held you a long time

A different room, a little rest
The early hours snowed the first winter snow
Wasn't it supposed to be fall?
I hope you like this world
It's weird and messy and full of beauty

Welcome now
There's much for you to learn
Know this, remember it always:
You've been loved from the start
Endlessly