Programming Is Mostly Thinking (2014)
Great article! I've posted it in other comments before, but it's worth repeating:
The best explanation I've seen is in the book "The Secret Life of Programs" by Jonathan E. Steinhart. I'll quote that paragraph verbatim:
---
Computer programming is a two-step process:
1. Understand the universe.
2. Explain it to a three-year-old.
What does this mean? Well, you can't write computer programs to do things that you yourself don't understand. For example, you can't write a spellchecker if you don't know the rules for spelling, and you can't write a good action video game if you don't know physics. So, the first step in becoming a good computer programmer is to learn as much as you can about everything else. Solutions to problems often come from unexpected places, so don't ignore something just because it doesn't seem immediately relevant.
The second step of the process requires explaining what you know to a machine that has a very rigid view of the world, like young children do. This rigidity in children is really obvious when they're about three years old. Let's say you're trying to get out the door. You ask your child, "Where are your shoes?" The response: "There." She did answer your question. The problem is, she doesn't understand that you're really asking her to put her shoes on so that you both can go somewhere. Flexibility and the ability to make inferences are skills that children learn as they grow up. But computers are like Peter Pan: they never grow up.
I'm confident enough to tout this number as effectively true, though I should mention that no company I work with has so far been willing to delete a whole day's work to prove or disprove this experiment yet.
The effect of this was that I'd occasionally come in the next morning to find that my previous day's work had been deleted. Before I eventually installed an illicit copy of SVN, I got very good at recreating the previous day's work. Rarely took more than an hour, including testing all the edge cases.
This is a good article to send to non-programmers. Just as programmers need domain knowledge, those who are trying to get something out of programmers need to understand a bit about it.
I think I recognise that tiny diffs that I might commit can be the ones that take hours to create because of the debugging or design or learning involved. It's all so easy to be unimpressed by the quantity of output and having something explained to you is quite different from bashing your head against a brick wall for hours trying to work it out yourself.
This is why domain knowledge is key. I work in finance, I've sat on trading desks looking at various exchanges, writing code to implement this or that strategy.
You can't think about what the computer should do if you don't know what the business should do.
From this perspective, it might make sense to train coders a bit like how we train translators. For example, I have a friend who is a translator. She speaks a bunch of languages, it's very impressive. She knows the grammar, idioms, and so on of a wide number of languages, and can pick up new ones like how you or I can pick up a new coding language.
But she also spent a significant amount of time learning about the pharmaceutical industry. Stuff about how that business works, what kinds of things they do, different things that interface with translation. So now she works translating medical documents.
Lawyers and accountants are another profession where you have a language gap. What I mean is, when you become a professional, you learn the language of your profession, and you learn how to talk in terms of the law, or accounting, or software. What I've always found is that the good professionals are the ones who can give you answers not in terms of their professional language, but in terms of business.
Particularly with lawyers, the ones who are less good will tell you every possible outcome, in legalese, leaving you to make a decision about which button to press. The good lawyers will say "yes, there's a bunch of minor things that could happen, but in practice every client in your positions does X, because they all have this business goal".
---
As for his thought experiment, I recall a case from my first trading job. We had a trader who'd created a VBA module in Excel. It did some process for looking through stocks for targets to trade. No version control, just saved file on disk.
Our new recruit lands on the desk, and one day within a couple of weeks, he somehow deletes the whole VBA module and saves it. All gone, no backup, and IT can't do anything either.
Our trader colleague goes red. He calms down, but what can you do? You should have backups, and what are you doing with VBA anyway?
He sits down and types out the whole thing, as if he were a terminal screen from the 80s printing each character after the next.
Boom, done.
This is laid out pretty early on by Bjourne in his PPP book[0],
> We do not assume that you — our reader — want to become a professional programmer and spend the rest of your working life writing code. Even the best programmers — especially the best programmers — spend most of their time not writing code. Understanding problems takes serious time and often requires significant intellectual effort. That intellectual challenge is what many programmers refer to when they say that programming is interesting.
Picked up the new edition[1] as it was on the front page recently[2].
[0]: https://www.stroustrup.com/PPP2e_Ch01.pdf
“Programming is mostly thinking” is one of these things we tell ourselves like it is some deep truth but it’s the most unproductive of observations.
Programming is thinking in the same exact way all knowledge work is thinking:
- Design in all it’s forms is mostly thinking
- Accounting is mostly thinking
- Management in general is mostly thinking
The meaningful difference is not the thinking, it’s what are you thinking about.
Your manager needs to “debug” people-problems, so they need lots of time with people (i.e. meetings).
You are debugging computer problems, so you need lots of time with your computer.
There’s an obvious tension there and none of the extremes work, you (and your manager) need to find a way to balance both of your workloads to minimize stepping on each others toes, just like with any other coworker.
> how can you experiment with learning on-the-job to create systems where the thinking is optimized?
Best optimization is less interruptions as reasearch shows their devastating effect on programming:
- 10-15 min to resume work after an interruption
- A programmer is likely to get just one uninterrupted 2-hour session in a day
- Worst time to interrupt: during edits, searches & comprehension
I've been wondering if there's a way to track interruptions to showcase this.
Good programming is sometimes mostly thinking, because "no plan survives first contact with the enemy." Pragmatic programming is a judicious combination of planning and putting code to IDE, with the balance adapting to the use case.
That’s an iteration of Peter Naur’s « Programming as Theory Building » that has been pivotal in my understanding of what programming really is about.
Programming is not about producing programs per se, it is about forming certain insights about affairs of the world, and eventually outputing code that is nothing more than a mere representation of the theory you have built.
Off topic. I'm not a developer but I do write code at work, on which some important internal processes depend. I get the impression that most people don't see what I do as work, engaged as they are in "busy" work. So I'm glad when I read things like this that my struggles are those of a real developer.
Developers need to learn how to think algorithmically. I still spend most of my time writing pseudocode and making diagrams (before with pen and paper, now with my iPad). It's the programmers' version of the Abraham Lincoln's quote "Give me six hours to chop down a tree and I will spend the first four sharpening the axe."
Various programming paradigms (modular programming, object-oriented, functional, test-driven etc) have developed to reduce precisely this cognitive load. The idea being that it is easier to reason and solve problems that are broken down into smaller pieces.
But its an incomplete revolution. If you look at the UML diagram of a fully developed application its a mess of interlocked pieces.
Things get particularly hard to reason about when you add concurrency.
One could hypothesize that programming languages that "help thinking" are more productive / popular but not sure how one would test it.
One of the things I find interesting about the limited general intelligence of language models (about which I tend to be pretty deflationary) is that my own thought processes during programming are almost entirely non-verbal. I would find it to be incredibly constraining to have to express all my intermediate thoughts in the form of text. It is one of the things that makes me think we need a leap or two before AGI.
Most software developer jobs are not really programming jobs. By that I mean the amount of code written is fairly insignificant to the amount of "other" work which is mainly integration/assembly/glue work, or testing/verification work.
There definitely are some jobs and some occasions where writing code is the dominant task, but in general the trend I've seen over the past 20 years I've been working has been more and more to "make these two things fit together properly" and "why aren't these two things fitting together properly?"
So in part I think we do a disservice to people entering this industry when we emphasize the "coding" or "programming" aspects in education and training. Programming language skills are great, but very important is systems design and integration skills.
Writers get a bit dualistic on this topic. It's not "sitting in a hammock and dreaming up the the entire project" vs. "hacking it out in a few sprints with no plan". You can hack on code in the morning, sit in a hammock that afternoon, and deliver production code the next day. It's not either-or. It's a positive feedback loop between thinking and doing that improves both.
In the 2020s, we still have software engineering managers that think of LOC as a success metric.
“How long would it take you to type the 6 hours work of diff?” is a great question to force the cognitively lazy software manager to figure out how naive that is.
Nowadays I feel great when my PRs have more lines removed than added. And I really question if the added code was worth the added value if it’s the opposite.
Author listed a handful of the thinking aspects that take up the 11/12 non-motion work.. but left out naming things! The amount of time in conversation about naming, or even renaming the things I've already named.. there's even a name for it in the extreme, bikeshedding. Even sometimes I'll be fixated on how to phrase the comments for a function or even reformat things for line lengths to fit.
Programming is mostly communicating.
I would absolutely agree, for any interesting programming problem. Certainly, the kind of programming I enjoy requires lots of thought and planning.
That said, don't underestimate how much boilerplate code is produced. Yet another webshop, yet another forum, yet another customization of that ERP or CRM system. Crank it out, fast and cheap.
Maybe that's the difference between "coding" and "programming"?
Agree and disagree. Certain programming domains and problems are mostly thinking. Bug fixing is often debugging, reading and comprehension rather than thinking. Shitting out CRUD interfaces after you've done it a few times is not really thinking.
Other posters have it right I think. Fluency with the requisite domains greatly reduces the thinking time of programming.
It is an iterative process, unless “to code” is narrowly defined as “entering instructions” with a keyboard. Writing influences design and vice versa.
A good analogy that works for me is writing long form content. You need clear thought process and some idea of what you want to say, before you start writing. But then thinking also gets refined as you write. This stretches further: a English lit major who specialises as a writer (journalist?) writing about a topic with notes from a collection experts and a scientist writing a paper are two different activities. Most professional programming is of the former variety admitting templates / standardisation. The latter case requires a lot more thinking work on the material before it gets written down.
I tend to spend a lot of time in REPL or throwaway unit tests, tinkering out solutions. It helps me think to try things out in practice, sometimes visualising with a diagramming language or canvas. Elixir is especially nice in this regard, the language is well designed for quick prototypes but also has industrial grade inspection and monitoring readily available.
Walks, hikes and strolls are also a good techniques for figuring things out, famously preferred by philosophers like Kierkegaard and Nietzsche.
Sometimes I've brought it up with non-technical bosses how development is actually done, didn't work, they just dug in about monitoring and control and whatnot. Working remote is the way to go, if one can't find good management to sell to.
"Weeks of coding can save you hours of planning." - Unknown.
> If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work?
The diff will help, but it'll be an order of magnitude faster to do it the second time, diff provided or not.
For the same reason.
At my previous job, I calculated that over the last year I worked there, I wrote 80 lines of non-test, production code. 80. About one line per 3-4 days of work. I think I could have retyped all the code I wrote that year in less than an hour.
The rest of the time? Spent in two daily stand up meetings [1], each at least 40 minutes long (and just shy of half of them lasted longer than three hours).
I should also say the code base was C, C++ and Lua, and had nothing to do with the web.
[1] Because my new manager hated the one daily standup with other teams, so he insisted on just our team having one.
I liked "Code is just the residue of the work"
Who hasn't accidentally thrown away a days worth of work with the wrong rm or git command? It is indeed significantly quicker to recreate a piece of work and usually the code quality improves for me.
Famuosly described as the tale of the two programmers - the one who spends their time thinking will provide exponentially better work, though because good work look obvious they will often not receive credit.
Eg. https://realmensch.org/2017/08/25/the-parable-of-the-two-pro...
Funnily enough this happened to me.
Earlier in my career I had a very intense, productive working day and then blundered a rebase command, deleting all my data.
Rewriting took only about 20 minutes.
However, like an idiot, I deleted it again, in the exact same way!
This time I had the muscle memory for which files to open and where to edit, and the whole diff took about 5 minutes to re-add.
On the way out to the car park it really made me pause to wonder what on earth I had been doing all day.
This is also relevant in the context of using LLMs to help you code.
The way I see it, programming is about “20% syntax and 80% wisdom”. At least as it stands today.
LLMs are good (perhaps even great) for the 20% that is syntax related but much less useful for the 80% that is wisdom related.
I can certainly see how those ratios might change over time as LLMs (or their progeny) get more and more capable. But for now, that ratio feels about right.
Programming is mostly thinking just like many other knowledge related jobs, it's nothing special. This analogy can be used for most design related jobs, not just software.
If I had my client report deleted today, I could rewrite that report in nearly half the time the next day because I remember the way in which I structured the report, the sentences that flowed that didn't and the way I conveyed the findings in a neutral way.
No different to designing a physical product. You might see the outcome, but you don't see the numerous design iterations and compromises that came along the way which speak to the design that came out the end.
Furthermore, there are going to be programmers that can write more code with less thought, because they might have many years of pre-thought knowledge and understanding that allows them to execute faster.
This article sounds like it was written for a manager that doesn't see the value in the work performed, or simply doesn't understand design related work.
This is why I just don't care about my keyboard, mouse, monitor etc beyond a baseline of minimum comfort.
Typing at an extra 15 wpm won't make a lick of difference in how quickly I produce a product, nor will how often my fingers leave the keyboard or how often I look at the screen. Once I've ingested the problem space and parameters, it all happens in my head.
I’ve faced this viscerally with copilot. I picked it up to type for me after a sport injury. Last week, though, I had an experience; I was falling ill and “not all there.” None of the AI tools were of any help. Copilot is like a magical thought finisher, but if I don’t have the thought in the first place, everything stops.
In my experience quite a lot of programming is thinking, though quite a lot is also communication, if you work in a team
Typing out comments on PRs, reproducing issues, modifying existing code to test hypotheses, discussing engineering options with colleagues, finding edge cases, helping QA other tickets, and so on. I guess this is all "thinking," too, but it often involves a keyboard, typing, and other people
A lower but still significant portion is "overhead." Switching branches, syncing branches, rebasing changes, fixing merge conflicts, setting up feature flags, fixing CI workflows, and so on
Depending on the size of the team, my gut feel for time consumption is:
Communication > Thinking > Writing Code > Overhead
Programming is mostly planning.
When you work for companies that take programming seriously (e.g., banks, governments, automotive, medical equipment, etc.), a huge development cycle occurs before a single line of code is written.
Here are some key development phases (not all companies use all of them):
1. high level definition, use cases, dependencies; traceability to customer needs; previous correction (aka failures!) alignment
2. key algorithms, state machines, flow charts (especially when modeling fail-safety in medical devices)
3. API, error handling, unit test plan, functional test plan, performance test plan
4. Alignment with compliance rules; attack modeling; environmental catastrophe and state actor planning (my experience with banks)
After all of this is reviewed and signed-off, THEN you start writing code.
This is what code development looks like when there are people's, business's, and government's lives/money/security on the line.
So. Much. Planning.
Somehow the post seemed to miss the amount of time I seem to spend on "busy work" in coding. Not meetings and that sort of thing, but just boring, repetitive, non-thinking coding.
Stubbing in a routine is fast, but then adding param checking, propagating errors, clean up, adding comments, refactoring sections of code into their own files as the code balloons, etc.
There's no thinking involved in most of the time I am coding. And thank god. If 11/12 of my time was spent twisting my brain into knots to understand the nuances of concurrency or thread-locking I would have lost my hair decades earlier.
I studied CS and taught programming 101.
In my experience, the main issue with learning to code are all the contexts you have to remember.
There is the static type level and the runtime level, all the scopes (class, object, function, nested functions, closures, etc.), the different machines (client, server, or even multiple servers, etc.)
That's probably the reason why most devs start with dynamic languages and frontend/mobile. It can get just as complex as backend development, but at least you can eliminate a bunch of contexts when starting to code, learn what's left and then add contexts later.
In my experience (slightly tweaked towards data science and AI research), programming is also experimenting, be it playing with the data, testing a new idea or even debugging.
There is a reason why LISPers (I'm not one of them though) praise so much REPL-driven development: the REPL is a laboratory.
Also, how much time did you spend testing a library, looking on the internet how to install it, debugging the weird compiler errors? In the end you found the one option that made everything work but it took you hours of research and experimentation.
That's also why it is difficult for me to tell what I've done in the standup meeting on another day. If I tell people I just spend time on "thinking", they will say it is too vague.
Too true.
I was introduced to a quote from cartoonist, Guindon: "Writing is nature’s way of letting you know how sloppy your thinking is." From Leslie Lamport.
Although in my experience, thinking is something that is not always highly valued among programmers. There are plenty of Very Senior developers who will recommend, "just write the code and don't think about it too hard, you'll probably be wrong anyway." The whole, "working code over documentation and plans," part of the Agile Manifesto probably had an outsized influence on this line of reasoning. And honestly it's sometimes the best way to go: the task is trivial and too much thought would be wasted effort. By writing the code you will make clear the problem you're trying to solve.
The problem with this is when it becomes dogma. Humans have a tendency to avoid thinking. If there's a catchy maxim or a "rule" from authority that we can use to avoid thinking we'll tend to follow it. It becomes easy for a programmer to sink into this since we have to make so many decisions that we can become fatigued by the overwhelming number of them we have to make. Shortcuts are useful.
Add to this conflict the friction we have with capital owners and the managerial class. They have no idea how to value our work and manage what we do. Salaries are games of negotiation in much of the world. The interview process is... varied and largely ineffective. And unless you produce value you'll be pushed out. But what do they value? Money? Time? Correctness? Maintainability?
And then there's my own bone to pick with the industry. We gather requirements and we write specifications... some times. And what do we get when we ask to see the specifications? A bunch of prose text and some arrows and boxes? Sure, some one spent a lot of time thinking about those arrows and boxes but they've used very little rigor. Imagine applying to build a sky scraper and instead of handing in a blueprint you give someone a sketch you drew in an afternoon. That works for building sheds but we do this and expect to build sky scrapers! The software industry is largely allergic to formalism and rigor.
So... while I agree, I think the amount of thinking that goes into it varies quite a lot based on what you're doing. 11/12? Maybe for some projects. Sometimes it's 1/2. Sometimes less.
I once did a weeks worth of 'debugging/looking at code, trying stuff and testing' before committing my two lines of changed code. About 40 hours of work to produce what would take less than a minute to type.
It wasn't even the worst code base I've inherited but it is the worst lines of code per hours worked I've ever had.
Everyone knows this who is a programmer. So this article is for other people, like managers?, who don't know how to measure their effectiveness...
Somemone say success is 1/10 genius 9/10 hard work (and a big supply of pencil paper and erasers), to -create- something (software too) is understanding how to do it right, not only how to do it work, is know the 'rules' (often standing on the shouders of giants) to maybe one day update (break too) those rules.
Well of course it is. With progress in knowledge, there comes a stage before that. That stage we can call learning. I don't care how you bend it, learning involves thinking in its base of it all.
So thinking does not merely make you a better programmer. It makes you a better programmer at every given time . Your progression never stops and like I just said, it's simply called learning.
> typing and tools are not the most important aid to quick code production
I think they are in an indirect way. Being able to touch type reasonably fast prevents the action of typing distracting you from your thoughts, or lagging so far behind your thoughts that it makes it harder to keep your thoughts clear in your mind.
Maybe something similar with good tools.
A good explanation of this is given on SICP. Ist about solving the problem, not getting the computer to do something.
IMHO Programming is mostly iterating (which involves thinking).
The title, read alone, with only a brief skim of the article might give PHBs the notion that you can just sit developers in a room and let them “think” for 5.5 hours and the hand them their keyboards for the last 30 minutes and get the product you want.
My architect introduced Architecture Decision Records to my company and it's made a world of difference. Are there other tools and mechanisms people have found helpful to facilitate and scale group thinking?
Programming is indeed thinking but thinking through coding. Think -> Code -> Evaluate. If you remove the thinking you have a code monkey. If you remove the coding you have analysis paralysis.
Code is more flexible than text for drafting the idea. Later on it will expand into a fully working solution. Defining non functional interface definitions and data objects for "scribbling" the use case works best for me.
This really tracks for me. Personally, I have abyssal typing skills and speed. Not only has this never limited my productivity as a software developer, in some ways it has forced me to be a better developer.
If so, is it a good idea to base programmer interview on live coding session?
> they have to recover from the previous day's backup
This is how I know it's a work of fiction. Sadly, even these days daily backups in most organizations, even IT ones are an impossible dream.
I thought so too, but now I have different opinion.
Programming has both analytical and creative part, which should be balanced. If you are over-analytical you don't get stuff done quickly.
11/12 thinking 1/12 typing sounds about right to me, provided that we count typing things that we'll eventually delete as thinking and not typing.
"Thinking out loud”… that’s how I view the process of writing code. I start with a concept, then think my way through the solution by writing code.
See also: "Hammock Driven Devleopment" (https://www.youtube.com/watch?v=f84n5oFoZBc)
I agree that programming is mostly thinking. But I don't agree with the how the post justifies it.
I thought it was 90% debugging? Perhaps it is 90% of the non-debugging that is thinking!
Wait… you have the diffs… why are you retyping the lost code by hand? What am I missing?
So is good writing actually.
In other words: the more useful Copilot is, the easier your job is.
And most of the time thinking about things that should not be done.
> Sadly, overnight the version control system crashes and they have to recover from the previous day's backup. You have lost an entire day's work. If I give you the diff, how long will it take you to type the changes back into the code base and recover your six-hours' work?
I accidently deleted about 2 weeks of my work once. I was a junior dev and didn't really understood how svn works :). It took about 2 days to finish the job, but I had no diff and it wasn't 100% ready, so after recreating what I had I still had to spend about a day to finish it.
TL;DR: I think 11/12th is a reasonable estimate.
Now with Github Copilot it's even worse/better – whether you like to type or not. Now it's 1) think about the problem, 2) sketch types and functions (leave the body empty), 3) supervise Copilot as it's generating the rest, 4) profit.
This is why I highly dislike the term "coding". It implies that the basis of the role is "typing code"
Great article, thanks for sharing!
So the waterfall model is the best after all?
In my experience, of some decades, with programming of wide variety, in recent decades
"Programming Is Mostly"
(1) making sense out of missing or, as technical writing, badly written documentation
needed to do the
(2) mud wrestling of system management.
Example 1: Had everything else working then needed a connection string or some such between my Visual Basic .NET code and SQL Server. Struggled with (1) and (2) full time for over a week, with frustration rising like a South Pacific volcano getting ready to erupt, finally reached by phone some relatively high executive who was surprised that anything so routine could be so difficult and quickly gave me the secret. Then my work raced ahead, no problems, and all my code worked fine.
Example 2: Wanted a way for occasional, simple, routine file copying between two computers on a LAN (local area network) from both being connected to the same cable modem. Looked at the old "NET SHARE" and "NET USE", encountered mostly unclear, obscure, undefined technical terminology, tried to make sense out of the obscure syntax diagrams, observed that apparently nearly none of the many combinations of claimed options actually worked, and eventually, from two weeks of full time work, like throwing mud against a wall to see what would stick, underhand, back spin, side arm, etc., did a lot of guessing about what could be wrong and why (mostly involving computer security), discovered that likely computer A might be able to initiate a read from computer B but no way could computer B initiate a write to computer A, etc., got somethings working, but still need to document the effort.
More problems on the horizon ahead:
Problem 1: How to have on one computer at least two instances of the operating system on separate (bootable) hard disks and be able routinely (a) to back-up to additional internal and/or external hard disks all of the installed instances or restore from those backups and (b) recover quickly in case any hard disk fails or any bootable instance becomes corrupted.
Problem 2: How to install PostGreSQL on Windows 7 Professional and/or Windows Server 2019 and get code in Visual Basic .NET to use PostGreSQL. Is there some good documentation?????? Will be thrilled to learn that in this case there is no problem!!!
Once (1) and (2) are out of the way and, as results, the basic tools are working, the APIs (application programming interfaces) are well documented, then the syntax and semantics of the programming languages are easy and the programming itself is the easy, short, sweet dessert after all the nonsense before. The heap data structure, B+-trees, key-value stores, the .NET platform invoke, matrix inversion and eigenvalues, the Gleason bound, .NET managed memory, semiphores for controlling multiple threads, base64 encoding, HTML, etc. -- all really simple, fast, easy. (1) and (2) -- well over 70% of the effort.
* (2014)
same as writting
...and getting stuck.
[dead]
[dead]
re·con·nais·sance noun military observation of a region to locate an enemy or ascertain strategic features.
I certainly notice folks who code about 30 minutes a day line-wise, but that's just because they're distracted, or don't care.
Also, very very rarely is someone just sitting around and pondering the best solution. It happens, and yes it's necessary, but that's forgetting that for so much work the solution is already there, because one has already solved it a thousand times!
This article is straight gibberish except for perhaps a small corner of the industry, or beginners.
Great article. I just want to comment on this quote from the article:
"Really good developers do 90% or more of the work before they ever touch the keyboard;"
While that may be true sometimes, I think that ignores the fact that most people can't keep a whole lot of constraints and concepts in their head at the same time. So the amount of pure thinking you can do without writing anything at all is extremely limited.
My solution to this problem is to actually hit the keyboard almost immediately once I have one or more possible ways to go about a problem, without first fully developing them into a well specified design. And then, I try as many of those as I think necessary, by actually writing the code. With experience, I've found that many times, what I initially thought would be the best solution turned out to be much worse than what was initially a less promising one. Nothing makes problems more apparent than concrete, running code.
In other words, I think that rather than just thinking, you need to put your ideas to the test by actually materializing them into code. And only then you can truly appreciate all consequences your ideas have on the final code.
This is not an original idea, of course, I think it's just another way of describing the idea of software prototyping, or the idea that you should "throw away" your first iteration.
In yet different words: writing code should be actually seen as part of the "thinking process".