Another example that I think is similar. Recently spoke to a friend who is an editor at an academic publisher about AI concerns in publishing. He made a comment to the effect of, “the table of contents is the most important part of writing a book. An author has to decide what goes in and what is left out. And, in what order should you organize the ideas. That’s where expertise lies.” Designing a project is different than writing code, and designing the ToC is different than writing a book (as in putting words on a page). Right now LLMs would do a crap job on both of those first steps where true expertise is needed. And, related to another point you make, you develop expertise in part by the second steps of coding and writing.
Getting it right the first time is even more important in another field: the architectural level of engineering. That means high level conceptual design before coding begins. That's what I did for many years. The architecture spec MUST be correct. Otherwise, errors show up later when they are MUCH more expensive to fix. If you get it right the results are amazing.
The alternative is what we call BITIFY: build it, try it, fix it.
(There's a British expression that something is "a bit iffy.")
BITIFY tends to produce suboptimal or simply wrong solutions.
This is the education sector's AI problem in miniature. You can't learn to do the hard things except by beginning with the relatively easy ones, on which it is easy to cheat.
Great, great post whose essential premises are broadly applicable to any complex project or program, even in decidedly non-scientific, non-engineering, non-technical realms. As someone whose vocational DNA was built in the former but who is now working in the latter, I would say this is a minority opinion.
Yes yes yes to everything in the post. I started coding in the mid 1970s and turnaround for every test was overnight. Also from writing the code on paper to getting the punched c
Also from writing the code in pencil on paper to getting an executable card deck was 8 hours. So we learned to write detailed architecture, design and specs, and desk check to the n’th degree. It built good habits of thought that paid off right up to retirement just before COVID.
Reminds me of the apocryphal story of the class of software guys plus two hardware guys. Homework was to write a program in pencil. The next day the HW guys’ program was the only one to run correctly first time. Everyone else was astonished. The HW guys said, “We didn’t know we were allowed to have bugs.”
“Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: they had been forced to learn programming without the luxury of endless computer time."
I think this is true. I used to work for an investment bank in London and our Moscow office employees were superb. They were careful, precise and always delivered on time. Mind you, you had to be careful what you asked for otherwise they would deliver to spec and on time but you'd be cleaning blood off the walls.
It also resonates with me personally. I started programming in 1977 (Department of Employment) and we faced similar conditions to Russian programmers: you could compile, run and test your program once every two days. You'd write your code and test data in London and it would be sent up to Runcorn overnight; it would be run the next day and the results sent back on the van to London. A chap I started with was fired after two weeks because he hadn't learned that he needed to be meticulous.
Dijkstra was a big proponent of this way of programming. See e.g. his interview here https://www.youtube.com/watch?v=mLEOZO1GwVc and his comparisons with Beethoven vs. Mozart. He must have written about it a lot too.
The biggest advantage of a tight write-compile-test cycle is that there is only a little bit to undo at any one time.
Quite aside from the issue of design - an issue with methodologies like Agile quite aside from the application of AI - I find that aids like Copilot almost always get something wrong at any scale and that keeping their additions at a very small scale is the only way to keep them genuinely helpful (as that allows fixing the problems to be made much easier). It's great for generating boilerplate I wouldn't have to think about anyhow, but I shudder at trying to get it to write new logic and handle all the edge cases properly.
I'm not a coder. I don't understand a big bunch of your essay, Adam, but the little bits I did get make sense to me! Figure out where you're going (and hopefully how), before you set out on your travels. Chances are you'll arrive in one piece. Another bit I like: Advanced ideas are usually built on simpler ones. For sure.
My dad, whose first job in computers was COBOL on a mainframe in the early days of the 1960s, always felt strongly about this, because he, too, learned that way of necessity. He advocated for me to learn this also even though my early days were already a bit less restrictive, mid- to late -70s.
There are many industries and trades which benefit from those who plan well and test their plans well in advance of picking up tools, but few have such great opportunities to substitute iterative try-and-adjust near zero cost repeats as modern coding.
Many people dislike Dijkstra. His Dutch style of imposed authenticity offends American cautiousness. But once one passes the boundary where one no longer has to be cautious, his insights seem sounder and sounder.
There's no fundamental reason that structured design need be "intellectual" per se. Other than the American educational system and memes that forget about prepared thinking, such as "move fast and break things".
In a context of prepared thinking, with previous work as precedents to better by refactoring, "move fast and break things" is how refactoring for generality can break through. It's the cold ignorant adoption of memes like that that give progress a bad reputation, alas
Another example that I think is similar. Recently spoke to a friend who is an editor at an academic publisher about AI concerns in publishing. He made a comment to the effect of, “the table of contents is the most important part of writing a book. An author has to decide what goes in and what is left out. And, in what order should you organize the ideas. That’s where expertise lies.” Designing a project is different than writing code, and designing the ToC is different than writing a book (as in putting words on a page). Right now LLMs would do a crap job on both of those first steps where true expertise is needed. And, related to another point you make, you develop expertise in part by the second steps of coding and writing.
Getting it right the first time is even more important in another field: the architectural level of engineering. That means high level conceptual design before coding begins. That's what I did for many years. The architecture spec MUST be correct. Otherwise, errors show up later when they are MUCH more expensive to fix. If you get it right the results are amazing.
The alternative is what we call BITIFY: build it, try it, fix it.
(There's a British expression that something is "a bit iffy.")
BITIFY tends to produce suboptimal or simply wrong solutions.
Good points. Also, sent me down an ‘iffy’ rabbit hole and apparently it’s down to Roosevelt? https://newsfeed.time.com/2013/01/16/from-iffy-to-mulligan-words-american-presidents-made-famous/#:~:text=iffy%20(adj.)%3A%20describing%20a,dismiss%20questions%20at%20press%20conferences.
This is the education sector's AI problem in miniature. You can't learn to do the hard things except by beginning with the relatively easy ones, on which it is easy to cheat.
Great, great post whose essential premises are broadly applicable to any complex project or program, even in decidedly non-scientific, non-engineering, non-technical realms. As someone whose vocational DNA was built in the former but who is now working in the latter, I would say this is a minority opinion.
Adam, thank you! I am sending your email to my kids highlighting "...develop the habit of looking ahead before that happens"
Yes yes yes to everything in the post. I started coding in the mid 1970s and turnaround for every test was overnight. Also from writing the code on paper to getting the punched c
Also from writing the code in pencil on paper to getting an executable card deck was 8 hours. So we learned to write detailed architecture, design and specs, and desk check to the n’th degree. It built good habits of thought that paid off right up to retirement just before COVID.
Reminds me of the apocryphal story of the class of software guys plus two hardware guys. Homework was to write a program in pencil. The next day the HW guys’ program was the only one to run correctly first time. Everyone else was astonished. The HW guys said, “We didn’t know we were allowed to have bugs.”
“Russians had a reputation for being the best programmers on Wall Street, and Serge thought he knew why: they had been forced to learn programming without the luxury of endless computer time."
I think this is true. I used to work for an investment bank in London and our Moscow office employees were superb. They were careful, precise and always delivered on time. Mind you, you had to be careful what you asked for otherwise they would deliver to spec and on time but you'd be cleaning blood off the walls.
It also resonates with me personally. I started programming in 1977 (Department of Employment) and we faced similar conditions to Russian programmers: you could compile, run and test your program once every two days. You'd write your code and test data in London and it would be sent up to Runcorn overnight; it would be run the next day and the results sent back on the van to London. A chap I started with was fired after two weeks because he hadn't learned that he needed to be meticulous.
Dijkstra was a big proponent of this way of programming. See e.g. his interview here https://www.youtube.com/watch?v=mLEOZO1GwVc and his comparisons with Beethoven vs. Mozart. He must have written about it a lot too.
The biggest advantage of a tight write-compile-test cycle is that there is only a little bit to undo at any one time.
Quite aside from the issue of design - an issue with methodologies like Agile quite aside from the application of AI - I find that aids like Copilot almost always get something wrong at any scale and that keeping their additions at a very small scale is the only way to keep them genuinely helpful (as that allows fixing the problems to be made much easier). It's great for generating boilerplate I wouldn't have to think about anyhow, but I shudder at trying to get it to write new logic and handle all the edge cases properly.
I'm not a coder. I don't understand a big bunch of your essay, Adam, but the little bits I did get make sense to me! Figure out where you're going (and hopefully how), before you set out on your travels. Chances are you'll arrive in one piece. Another bit I like: Advanced ideas are usually built on simpler ones. For sure.
My dad, whose first job in computers was COBOL on a mainframe in the early days of the 1960s, always felt strongly about this, because he, too, learned that way of necessity. He advocated for me to learn this also even though my early days were already a bit less restrictive, mid- to late -70s.
There are many industries and trades which benefit from those who plan well and test their plans well in advance of picking up tools, but few have such great opportunities to substitute iterative try-and-adjust near zero cost repeats as modern coding.
Visual (Big Picture) versus Auditorial (Micro Detail) functions of the brain.
Right Brain hemisphere (Visual).
Left Brain hemisphere (Language Detail).
Whole brain works better than one sided brain dominance. Takes time, experience, training for habit-forming skills to perform future tasks.
Many people dislike Dijkstra. His Dutch style of imposed authenticity offends American cautiousness. But once one passes the boundary where one no longer has to be cautious, his insights seem sounder and sounder.
There's no fundamental reason that structured design need be "intellectual" per se. Other than the American educational system and memes that forget about prepared thinking, such as "move fast and break things".
In a context of prepared thinking, with previous work as precedents to better by refactoring, "move fast and break things" is how refactoring for generality can break through. It's the cold ignorant adoption of memes like that that give progress a bad reputation, alas