John Backus Said Laziness Drove His Work. The Result Was FORTRAN.

John Backus once explained one of the most important inventions in programming with an unexpectedly simple motive:

“Much of my work has come from being lazy. I didn’t like writing programs, so I started work on a system to make them easier to write.”

That system became FORTRAN.

Before FORTRAN, programming a scientific computer could feel like hand-to-hand combat with the machine.

Programmers wrote long sequences of low-level instructions, managed hardware details manually and spent enormous amounts of time debugging code that only worked on a particular machine.

Backus looked at all that effort and asked a dangerous question.

Why should humans keep doing work the computer could do for them?

He got into IBM almost by accident

Backus did not grow up following a perfect path toward computer science.

He left one university after poor attendance. He tried medical school and dropped out. Eventually he earned a master’s degree in mathematics at Columbia.

In 1950, he wandered into IBM’s headquarters in New York, where the room-sized Selective Sequence Electronic Calculator was on display.

He mentioned his interest in mathematics.

An IBM employee gave him a set of math problems.

Backus solved them.

IBM hired him as a programmer even though, by his own later account, he barely knew what programming was.

Programming was expensive because humans were doing machine work

Early programming required people to think constantly about the computer’s hardware.

Instructions were extremely low-level.

Programs had to be tailored to specific machines.

Programmers could spend huge amounts of time translating mathematical intent into the tiny operations a processor understood.

IBM later described a problem that might require as many as a thousand manually written instructions being expressible in only 47 statements in FORTRAN.

The difference was not that FORTRAN made mathematics simpler.

It let the programmer say more directly what mathematics they wanted performed.

The compiler handled much of the tedious translation.

The obvious objection was: the generated code will be slow

This was a serious objection.

In the 1950s, computer time was enormously expensive.

Expert programmers took pride in crafting efficient machine code by hand.

Many believed a compiler could never produce code good enough to justify the convenience of a higher-level language.

So the FORTRAN team could not merely make programming easier.

They had to make the resulting programs fast.

That is why the compiler became such a remarkable part of the project.

Backus’s team built optimization techniques that produced machine code competitive with carefully hand-written programs.

The language succeeded because convenience did not require surrendering performance.

Productivity exploded when the abstraction became trustworthy

Once programmers trusted the compiler, the economics changed.

Scientists and engineers could express formulas in a form much closer to their own mathematical notation.

Programs took less time to write.

Debugging became less dominated by bookkeeping errors in low-level instructions.

Code could be moved across machines that had compatible FORTRAN compilers.

Programming stopped being a tiny priesthood of people who knew every detail of a particular computer.

More domain experts could program directly.

That is what a powerful abstraction does.

It does not merely save keystrokes.

It changes who is allowed to participate.

“Laziness” in engineering can be a form of ambition

Backus’s quote is funny because laziness sounds like the opposite of achievement.

But there are two kinds of laziness.

One avoids necessary work.

The other refuses unnecessary work.

The second kind can be extraordinarily productive.

Why type the same boilerplate again?

Why manually reconcile data the system can reconcile?

Why memorize an operational ritual that can be encoded?

Why force every new engineer to rediscover the same hidden rule?

Why make humans translate intentions into machine details when a tool can preserve the intention directly?

Automation often begins with irritation.

The best tools remove an entire category of thought

A mediocre tool makes an old task slightly faster.

A transformative tool makes part of the old task unnecessary.

FORTRAN did not simply provide a nicer syntax for machine code.

It moved responsibility from the programmer to the compiler.

The programmer could think more about the problem.

The compiler could think more about the machine.

That division of labor is everywhere in modern computing.

Garbage collectors manage memory humans once managed manually.

Database engines choose query plans.

Cloud platforms allocate machines.

Modern compilers reorder instructions.

AI tools now generate code and transformations that once required repetitive hand work.

Each layer raises the same question Backus asked:

Which detail still requires human attention, and which detail are we preserving only because the old tool made us?

Backus never stopped challenging the abstraction

Even after FORTRAN became one of the most influential programming languages ever created, Backus did not treat it as the final answer.

He later criticized the limits of conventional programming styles and explored functional programming — another attempt to let programmers describe problems at a higher level instead of specifying every low-level step.

He also helped develop the notation now known as Backus-Naur Form for describing the grammar of programming languages.

The pattern continued.

Make the machine handle more of the machinery.

Let the human think at a more useful level.

The real productivity question is not “how do we work harder?”

Teams often respond to overload by increasing effort.

More hours.

More people.

More checklists.

More process.

Sometimes the better question is whether the work should exist at all.

Backus disliked writing programs in the form computers demanded.

He did not become more disciplined at low-level programming.

He helped change the level at which programming happened.

What work are you trying to get faster at that would be more valuable to eliminate entirely?

Explore

Stay connected