Speed Matters
scattered-thoughts.net
scattered-thoughts.net
You can’t draw any information from this, except perhaps that the author avoided Second System Syndrome.
In college I worked with students who had programming jobs. While my classmates were spending fifteen+ hours on assignments, one of these coworkers who I shared a class with said he was spending two hours and I thought he was lying. Another was claiming three or four. This must be bravado I thought.
Next summer I got a programming job too. That fall I was spending six hours on homework, and by year’s end I was down to three.
When everything is new you go slow. You have to solve problems without muscle memory, and you have to fight nervousness. Am I doing this wrong? Is this even a good answer?
They talk about 10000 hours and mastery, but there are also clear breakpoints at 100 and 1000 hours, where you know enough to do a lot, and you don’t have to stop to consider your first moves.
The problem, from the manager's standpoint, is that the really good solutions are simpler than the really bad solutions. That may not sound like a problem, but the concise, correct answer is often self-evident in retrospect, diminishing the gravity of the situation.
Lots of people make suggestions you instantly agree with, but you would not have come up with all of those suggestions on your own. A bad boss won't understand that, until you make another self-evident decision that you would get more money and respect working somewhere else. Maybe not even then.
I mentioned to him: "Did you know you can pull up your past commands by hitting up arrow?"
His mind was blown. I think that comment doubled his productivity.
history | grep pattern
With all the useful grep abilities (like peaking at commands before or after the given pattern).
vi users will probably laugh at this.
Whenever I switch editors, I quickly look for the following shortcuts:
* How do you delete a word forwards and backwards? (there might be a better shortcut such as Ctrl+W)
* How do you move to the word ahead and the word behind?
* How do you kill a line?
* How do you duplicate a line?
* How do you move a line up and down?
* How do you activate multiple cursors?
* How do you comment/uncomment a line/block?
* How do you expand/contract a selection?
I think that covers about 80% of the common actions, and learning them will make you instantly productive in your new editor.
set -o viCtrl-up/down will move the cursor past newlines, so you can more quickly navigate when there are long lines with lots of wrapped text.
I've found more like that at: https://www.redhat.com/sysadmin/cli-speedup
(And so many coding tools are inefficient to me because I cannot use vi keybindings.)
Letting them see/discover the change will drive them to try
https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/dirhi...
When I was a TA marking assignments I saw a huge range in the number of lines of code between my students' assignments. If I took all the students who got full marks, there was often a 2x or 3x size difference between the smallest submission and the largest. And the large assignments didn't look bloated. If you gave me the code from a random student, it wasn't obvious where in the size range their code would land.
And a couple years ago I worked as a professional programming interviewer. One of the assessments we did was a half hour programming problem. I interviewed over 400 interviews. Most of them had some professional experience as software engineers. Candidates use their favorite language and their own computer & tools. Quantitatively, there is a massive difference between the better candidates and the worst. The strongest candidates could get about 2-3x as much done in the same amount of time as the average. And the weaker candidates (even those with professional experience) could barely implement hello world within half an hour.
As software engineers, we don't have a culture of practice. Its assumed that with enough time working professionally, we'll keep improving. But that might be naive. There are almost certainly ways to measure our skill and improve over time. Its weird we don't even have that conversation.
Man, this is exactly what I've been thinking lately.
I don't have that much professional experience and have a background of competitive gaming where there is a really strong culture of explicit practice.
Coming to software development where people with a lot of experience can't articulate their process or the steps they took to improve is really fucking annoying.
I don't expect a step-by-step manual, but I do expect something instead of it all being tribal/intuitive knowledge.
I’ve heard this described as “10 years of experience” vs “1 year of experience 10 times”.
I found over the years to avoid long debugging sessions, I can instead write better tests, do smaller commits, and write less clever code. To prevent the kinds of bugs that crop up months later, it's really important to write really good, comprehensive tests.
A lot of tests that are too coupled with the design are also bad, though. They slow refactoring. So you have to get good at writing the kinds of tests that don't inhibit refactorings, or get good at designing things so you don't have to refactor.
Coding speed is irrelevant in the long run. It's only relevant for quick scripts and throwaway code.
Don't get sucked into debugging.
If you write a ton of bad code yesterday and got nothing done today since you had to debug all day, then you weren't fast yesterday and slow today, you were slow both days.
For example, lets say you spend a full year writing a full product. The a bug you write at month 2 and fix at month 6 is still the time it took to build this product. Being a quick coder therefore includes being good at managing technical debt, bugs etc. There is no reasonable interpretation of being fast at it that doesn't include these aspects, as the clock doesn't stop ticking until you are done.
So when people say you should learn how to become a fast coder, what they mean is that you should learn how to produce code at your current quality level but in much less time. They don't mean that you should throw quality out the window and just write crap without thinking.
The less clever code part is the key, for me. If I can write my code out, in a relatively simplistic way and go back to refactor and optimize it, I save myself hours of debugging headaches.
Doing it and saying it are different things, but I fully intend to do it every time I start =)
Midway through a late-night debugging of a service I’d written in Python, I realised I’d spent more time bug fixing and debugging to add more error handling/resiliency (all of which added to the general mess of the code) than would have taken to implement the solution in a statically-typed language, and I ultimately had less guarantees and less performance than the statically-typed language would have given me.
So yes, don’t get sucked into debugging and don’t get sucked into “but it’s faster to write”.
Except writing tests is coding.
But even if I could -- it's not about how fast I can think either.
You're right that it's about how much work I can avoid by thinking about how to keep it simple, how I can write good tests that won't cause someone else to do more work later, and how I can build something in a way that can be modified later.
And you can't get there with linear thinking at all.
If the programming you're doing is can be done by rote -- and the primary task is getting it out on paper -- either it's something that could be automated, or you're much much better than me. Possibly both.
The author of the original article is clearly much smarter than me, but he spends a lot of time doing things like building simple text editors for his own use, writing text matchers in obscure languages like Julia, and learning how create a SQL query planner through trial and error.
Tasks that are all way beyond my ability, but also well beneath my productivity.
I’m glad someone agrees with me on this. The argument that “I don’t spend a lot of time typing” is just false. Furthermore, if you’re good at typing, you free up brain cycles to allocate to higher level work. Slow typers severely underestimate how much brain power is spent on that.
Fixed it using Karabiner as recommended https://superuser.com/questions/317900/eliminate-macbook-cap... and suddenly I was better at life.
(Another bonus is that now I cannot hunt and peck since my keyboard still has the qwerty imprints and I guess that is the biggest contributor to typing speed from learning Dvorak)
I can feel my brain stutter every time I need to type an esoteric operator.
...okay I know what I'm doing this weekend.
...You should
<3
Yes exactly! I finally learned to touch type including symbols on ortholinear keyboards. This frustration of having to look down constantly is gone. I’m free to focus on editing code.
If you aren't good at running, you're gonna have bad time playing soccer. However, running fast definitely doesn't guarantee you will play soccer well.
Typing is similar.
Those are the workers who (in a competent organization) are promoted.
I often feel being too good at the daily grunt work makes you too important for that and management wants you to stay there.
Depends entirely on the company. Big tech companies are very good at promotions and retention.
The rewards of job hopping also saturate quicker than people expect. Push it too far and it starts to become a negative. When an employer sees a resume that has a new job every 10-12 months for the past 6 years, they're going to assume the employee will be temporary at their own company, as well.
I don't know about you but the job-seeking process seems like another job itself. If you're good at that job (esp. while executing on your current job) then I guess the world's your oyster.
If you're lucky. Mostly it's when there's relaxed oversight over your work, so you can hide the fact that you technically finished your work already and are languishing doing what, to many people, seems like a waste of your time even if you know that's not true.
(Not saying that you are wrong - not at all, you're actually quite correct that many of the people that get promoted are over normal performers, usually combined with some other talent or skill.)
The smaller the organization is, the more it is competent at what it's doing, the faster it can change to adapt. But there are sometimes no practical value to promotions at all.
You are seeing it differently, I understand. Why?
However it then leaves you vulnerable to the naive worker who will voluntarily push all gears because they’re such a hard worker.
I see a dilemma here. Nobody, not even 10x faster than the author, writes a full-fledged text editor in 10 hours. You can create something interesting that does text editing in 10 hours (or 100), but it's mostly going to be a learning exercise. You won't have created a piece of software that is of any value to anyone but yourself.
So the dilemma involves the tension between rapidly speeding through many interesting "efforts" that result in nothing of any use to anyone, but lots of learning value to the programmer; or spending much, much more time creating software that is genuinely useful to people who are not programmers, but risking getting stuck in a given language, problem domain or project and not learning as much.
I made my bed - I opted for 21+ years focused on a single project, but I was lucky in that it spanned everything from kernel-side stuff to hard-realtime to UX and I felt I'm still learning new stuff even today.
You could if you had enough components to assemble the text editor from.
Sure, I could cook one of those up, probably in less than 10 hours. But that's all it would do, and all I'd have done is learnt a few things. If I stopped right there, that's the only outcome: me learning some stuff.
Presumably at some point, the learning needs to be applied to something that is actually useful?
That's not what I mean, and I don't think it's what the author of TFA means, by "write a text editor".
If you type 90 words per minute of English, which is a speed that most people reach with a little practice, you can almost certainly type C at 45 words per minute, which is 270 characters per minute, 4.5 characters per second. (Jamie's 500 characters per minute is obviously higher than this, but I think he's a faster typist than most.) That would allow you to type in the Ant's Editor program in about 20 minutes, if you were just typing, not having to figure anything out.
20 minutes is shorter than 10 hours. Like, 30 times shorter. If you had everything totally clear in your mind, you could write 30 times that much code in 10 hours.
Now, is it plausible that somebody could write a whole usable text editor without having to figure anything out, so that their typing speed was the main limitation? Maybe if they'd written a lot of text editors previously. I'm skeptical, having spent half an hour getting binary search right last week, but then, there are much better programmers than me out there. (I still find that SLOCCount systematically overestimates the effort required for things; the calculator program with a generic numerical solver I mentioned here a couple of weeks ago in another comment was 261 lines of Python and took me 12 hours, and SLOCCount estimated it at 0.59 person-months, which would be 100 hours.)
I think writing things in very high-level languages like Python instead of C helps a bit, too. Not an order of magnitude, but maybe 2-5x, especially for small projects like these. I wrote a text editor on an iPaq in Python on my honeymoon.
So, while I agree that you're almost surely not going to write a text editor that will steal users from Vim, VS Code, or Emacs in 10 hours, I do think you can write a text editor in 10 hours. You could probably write a significantly more full-featured editor than ae.
Surely the optimal amount of effort to spend on such "learning efforts", which are expected to teach you things but not produce a program for you to use, is neither 0% nor 100%.
After several decades of different people working on text editing, we now have some fairly good ideas about how to do this efficiently, but they are (a) non-obvious (b) not the sort of thing I'd expect to be trivially available in high-level-language-of-the-day. My expectations have been known to be wrong, however.
And yes, missing undo in a text editor makes it effectively dead in the water.
(If you just keep your buffer in a Python string, you incur the 4.1-millisecond cost every time you insert a character near the beginning of the 12-MB string, possibly twice, and you need enough memory for multiple copies of the buffer. The gap buffer saves you this time cost except when you're moving the insertion point or you run out of gap, and keeps your space cost limited to slightly more than enough to hold the text itself.)
In a garbage-collected language on a modern machine (meaning, lots of RAM) I'd be tempted to use ropes, since they make undo trivial. Here's an implementation of ropes I wrote in 45 minutes and 45 lines of code just now, which seems to more or less work, though I'm sure I'm overlooking a few things:
#!/usr/bin/python3
from collections import namedtuple
from functools import cached_property # 3.8 or later
def as_rope(obj):
return obj if isinstance(obj, Rope) else Leaf(obj)
class Rope:
def __add__(self, other):
return Concat(self, as_rope(other))
def __radd__(self, other):
return as_rope(other) + self
def __str__(self):
return ''.join(self.walk())
class Leaf(Rope, namedtuple("Leaf", ('s',))):
def __getitem__(self, slice):
return Leaf(self.s[slice])
def __len__(self):
return len(self.s)
def walk(self):
yield self.s
class Concat(Rope, namedtuple("Concat", ('a', 'b'))):
def __len__(self):
return self.len
@cached_property
def len(self):
return len(self.a) + len(self.b)
def walk(self):
yield from self.a.walk()
yield from self.b.walk()
def __getitem__(self, sl):
if sl.start is None:
sl = slice(0, sl.stop)
if sl.stop is None:
sl = slice(sl.start, len(self))
if sl.start < 0:
sl = slice(len(self) + sl.start, sl.stop)
if sl.stop < 0:
sl = slice(sl.start, len(self) + sl.stop)
# Important special case to stop recursion:
if sl.start == 0 and sl.stop == len(self):
return self
a_len = len(self.a)
if sl.start >= a_len:
return self.b[sl.start - a_len : sl.stop - a_len]
if sl.stop <= a_len:
return self.a[sl]
# At this point we know we need part of a and part of b.
# Since slicing a leaf creates a Rope, we can blithely just do this:
result = self.a[sl.start:] + self.b[:sl.stop - a_len]
# Avoid making Concat nodes for lots of tiny leaves:
return Leaf(str(result)) if len(result) < 32 else result
Syntax highlighting, markers that move when text is inserted, etc., do imply more effort, but, again, there are well-known solutions to these problems. And an adequate redisplay is no longer the major research effort that it was 37 years ago.
So, while it's true that the data structures you need for a reliably responsive text editor aren't trivially available in Python, or Lua, or JS, I think you can just write them. I wrote the above code at about 6 words per minute because there were a lot of things about ropes (and about Python) that I wasn't clear about and had to figure out in the process; surely I could have written it 2-5 times as fast if I knew what I were doing.
If you're interested in learning about this stuff, Finseth's book is the classic, and Raph Levien has blogged a bunch of really nice up-to-date stuff about his rope-based editor Xi, which he wrote in Rust.
Correction: a Zaurus.
I find this notion of compounding to be much more useful in life than just in terms of finance and interest. Starting early, or doing something more, yields a compound benefit down the road. You get better at a thing faster, which compounds and lets you get better still. It's how expertise is realized and why there will never be equal outcomes between different people with different levels of motivation and persistence.
> If you compare two coders, one who can touch type and one who has to hunt and peck, the difference between them is not just down to typing speed. The hunter-and-pecker has to think about typing! This consumes attention and short-term memory that is sorely needed for thinking about the program itself.
I never learned to touch-type, but I've also typed a lot of stuff[0]. I seem to be a lot faster than most folks, and I write wordy code. Take a look at my codebases, to see what I mean. Lots of documentation[1].
Also, I have a friend who is an amazing programmer, but has been absolutely clobbered by RSI. It looks like the worst case I've seen. He's had at least one operation. Maybe two, by now. I think they didn't fix the issue, just ameliorated it a bit. It really does break my heart, because I consider him to be a treasure to programming.
I like my code to be performant, and I seem to be able to get releases out the door in good time, but I suspect the author would go crazy, looking at me work.
[0] https://stackoverflow.com/story/chrismarshall
[1] https://littlegreenviper.com/miscellany/leaving-a-legacy/
Respectfully.
Yes ... No ... Maybe ... Tell ya what ... lemme get back to you on that. I gotta ask my wife...
> As in, why did you just type all that up? What is the point you're making?
Huh? It pretty much speaks directly to to the OP.
I’ll pretend that this wasn’t a rather strange troll, and answer the ... um ... ”question.” I'll try to use vernacular, so it's clear.
The author talked about how they have a process that they use to speed up the “raw” mechanics of software development.
They specifically wrote that they believe that a “touch-typer” is a more effective programmer than an untrained “hunt-and-pecker.”
I wrote that I am a “hunt-and-pecker,” and that I believe that I am quite effective. Since this is HN, I backed up my statement by pointing to proof (the canon of my work, as catalogued in my SO story), and, as extra credit, I also pointed to an article that I wrote, discussing how I document my code.
I've been writing since I was a wee bairn. I've written a 400-page book (which was never published, because it was embarrassingly out of date, by the time the editing was complete), and, if you follow that link I provided, you'll see a lot of writing. You may be bothered by my longform posts on HN, but these are TL;DR, compared to my normal prolix prose.
I also mentioned a personal anecdote, about a good friend, who is a trained touch-typist, and an excellent software engineer (and about a quarter-century younger, but I didn’t feel the need to mention that). His touch-typing directly led to a serious case of RSI (Repetitive Stress Injury), that required two operations (UPDATE: He hasn’t received his second one yet). This RSI was bad enough to negatively affect an extremely lucrative career.
Speed can be a curse, as well as a blessing.
> Respectfully
Sure, whatevs.
but if it is going to take me a year to deliver an X, I probably wouldn't choose to do it. a month, hell yes. the worst - pulling the trigger on X assuming it will take a month + delta and have it take a year.
there's also the reward and momentum factor. if i keep getting nice wins i get pulled into doing more interesting work. if its going to be another 6 weeks before i can see any demonstrable progress... i'm actually going to go alot slower and be tempted to just forget the whole thing.
some of us are actually in it to _do stuff_....not just show up at standups and collect a check. honestly though maybe i have less to show for wanting to dig into real work.
another important context here is that Jamie is driven by a desire to make programming more useful and accessible to people. the fact that he's trying to quantify that is quite interesting and relevant to that goal.
so .. put in your 40 hours and have a life. there are other people with differnt goals.
edit- sorry temporal, it doesn't sound like it , but i'm really agreeing with you
Keep in mind that there is a point where relaxation turns you into a worthless bum, and constantly analyzing things before you act will mean you struggle to learn which paths don't work in reality.
Choosing to work on the right things is completely orthogonal to being fast though.
> Sometimes you need to spend more time thinking about a problem, do a bit of a "market study", or gather more data.
You can do this even if you are a fast coder. Only difference is how long it takes to test things, build MVP's and show them to potential users. MVP's are a great way to better understand what to build or do market studies, so I don't see why this goes against being fast.
The author gives the example that instead of simply doing more X, being faster can enable you do Y instead of X (where Y might be only working half-days). Very much "work smart not hard", which is where a lot of grind-y productivity stuff lands.
This seemed like a very, well, odd analysis to me.
My typing speed is the last thing that affects my overall productivity.
And wouldn't thinking about what needs to be done (and what doesn't need to be done) increase that upper bound even more?
How is that possible given that to become a programmer you need to type all day every day for years.
My dad was a hunt-n-peck programmer all of his life. Electrical Engineer PhD, often programming in fortran or c (although all his c code was actually just fortran too). Two-finger typer all of his life.
His son: 140-160 wpm on Kinesis Advantage 2, thanks to typing classes in middle school.
There are people joining the workforce as "IT professionals" who have not used a keyboard as their primary input device for most of their life. Many people have now grown up with phones or tablets as their primary computer.
It says a lot that 90% of the time I click a WikiPedia link in an online forum, it is the ".m." mobile version, not the desktop version.
Over the next decade this is just going to get worse.
Nobody ever asked "are you a proficient typer?" in an interview. And no one ever followed up with "show me".
Coders, on the other hand, aren't applying for typing positions. You could say that the "Draw the Pirate" tests, given by many companies, these days, are like typing tests (but I don't think so. I won't go into my thoughts on that).
I have heard, anecdotally, of programmers being tested for speed of coding, as part of the interview process.
Pray tell how exactly can you be tested for coding speed? Or would it be speed / correctness? I can't really picture how this would work in an interview situation...
The team is longer term looking at splitting up libraries but maybe I should see what quick wins .Net has to offer.
For side projects it’s normally the startup stuff, so using those starter kits eg saas with login set up etc. makes sense. I’d definitely look at all the code so I understand it but it saves all that wheel reinventing and discovering the same issues everyone has.
Some examples:
- Be a fast typist. At 120WPM, typing is not a limiting factor. I know professional programmers who do 40WPM and it limits them a _lot._
- Have self-awareness about what is taking you time. Ask whether you can stop doing that. A good example of this is having good autocomplete: if you're looking at docs when you could configure VSCode (or whatever) to have the answer a tab keypress away, you're losing minutes per hour.
- Get really good at using the fuzzy finder. Stop clicking on files.
- Write scripts for common actions, either in `~/bin` or in your source directory.
It's simple, but so true!
These are things I did as a fairly junior to intermediate developer. (so the first 10-15 years)
Later on it's about knowing what to do, the right approach can be infinitely faster than the wrong approach that doesn't work.
EDIT: as someone else said, know your tools, whether it's your IDE, your editor, your debuggers, your compilers, profilers etc.
0. Make less code. Define your problem-space in a new tooling-space, resulting in a new solution-space.
1. Sleep well, exercise regularly, eat sparingly and in company. Your mind is only as good as your brain. And your brain has a support system. Support it. That's a no-brainer.
2. Type less code. Make scripts to suggest common things, configure your autocomplete to not include unhelpful options. Use math-like single/two-letter notation and possibly a comment where it makes sense.
3. Type faster. I type comfortably at about 45WPM. I can see how 120WPM would be three times faster, and beyond wouldn't much matter. But I am at a vantage point that pecker hunters never visit.
4. Do less. Don't be hiding things in tabs and drawers, don't be managing your windows. Don't be looking for and opening files. Don't be fighting for your uninterrupted time. Be prepared.
5. Be prepared. Read up on the problem space. Read and run some solutions to some aspects. Prepare your workspace. Make time.
6. Do it. Sit down and do 23 minutes of it, as if you were to be torn away after. It's not hard, you can do 23 minutes of anything, really. Write stuff down. Throw up some code. Run it.
7. Keep at it. Make a plan for the next 3 hours. Put a buzzer to buzz you every 23 minutes and check yourself. Breathe, adjust, and persist. Is it fun? Are you shoveling shit? Those two require different check-lists.
8. Don't be looking busy. Be advancing. Are you enjoying your results, is it right? Are you shoveling some necessary shit? Or are you looking busy?
Speed does matter, but first, you need to know now.
Don't let weeks go by AFK for no reason.
Writing code can't be done quick without knowing what you need the outcome to be.
Then speed is set by how fast you type.
But it's a theory, and practice no one writes code without having to put thinking into it.
So speed is not a measurement I would ever count as a good trait in terms of quality. And quality cannot be measured, so we're back to why speed is even interesting in productivity of software creation
Ideally, but that's not always the case. For example, let's say my goal is to write the program that outputs Hello World. In some languages it's as fast as writing the literal characters. The only extra burden is maybe to put quotation marks around them.
"Hello World"
class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}
Most developers are working on a codebase where they did not personally write that "void main(...)" boilerplate! Someone else did all the initial scaffolding, they joined the team years later, and they're adding new feature "X".
In terms of productivity, all of those things you listed as negatives due to the mental load they impose are absolutely essential for this scenario of a team member joining and having to modify a large code base. Scopes, lifetimes, classes, interfaces, etc... are the levers for the mind that enable teams to work together successfully.
Obviously one can't take the time from zero to Hello World as a benchmark for productivity.
Most developers yes. Most programmers, no; Excel is the most popular programming language in the world by far. Imagine if Java were used instead of Excel to solve the same kind of problems Excel is used for today. Think about how much extra boilerplate would be in this world for no reason. Because the many hundreds of millions of people using Excel have done so for their purposes without missing the features you claim are essential for team development.
And maybe they are! But to my point, if you're not doing team development, then why do you need to even think about these features that aid in team development? If you are not trying to implement an object-oriented system, then using a tool that prescribes a maximalist object-oriented design philosophy is going to add a lot of extra work with no clear tangible benefit to the actual problem you're trying to solve. This is incidental complexity, and it's going to slow you down no matter how fast you type compared to a system that excludes this complexity.
The system that eliminates incidental complexity will provide the least amount of friction between you and solving your problem. That's the ideal. Any tooling you add to the task is going to introduce some complexity. That complexity may ultimately be beneficial or it could get in your way. It depends on what you want to do.
1) If you're not fast you will never get good 2) There's no such thing as "good, slow, and cheap" and if there is, that person is booked for the next 30 years
‘Good and slow’ requires exceptional planning or some kind of a lifestyle business, and thus is uncommon in software, AI in particular. Most work conditions require tight deadlines to coordinate with other (relatively isolated) business entities, therefore gotta go fast to deal with possible scheduling conflicts and unaccounted for parts of work.
The question then is how do we remove that incidental complexity? Eve tried to do this through programming language design, combining Prolog-like semantics with a relational database and modern web technologies. In some scenarios it really is at least 10x more productive than other languages, letting you do very sophisticated things in a few hours or days that could take experienced developers a literal week or more in other languages.
The author is musing here about how much he could get done as long as his tools get out of the way. i.e. how much more productive could he be if he only had to deal with the necessary complexity of the problem, rather than being mired in all the incidental complexity of the tooling. What if a programmer could express themselves as freely as a writer can? Where typing and imagination are the only barriers between your mind and expression. It's a nice fantasy future.
Yes there is a lot of thinking and doing research in programming, any experienced programmer knows this. I think if you look at this developer's history you would agree he is an experienced developer who knows these things to be true.
https://en.wikipedia.org/wiki/No_Silver_Bullet
http://curtclifton.net/papers/MoseleyMarks06a.pdf
(edit: also, I think the author addresses your criticism directly here: "When I think about speed I think about the whole process - researching, planning, designing, arguing, coding, testing, debugging, documenting etc. Often when I try to convince someone to get faster at one of those steps, they'll argue that the others are more important so it's not worthwhile trying to be faster. Eg choosing the right idea is more important than coding the wrong idea really quickly. But that's totally conditional on the speed of everything else!")
Just to clarify for others, Brooks' paper does not say that there will not or cannot be 10x (order of magnitude) improvements in programming.
He made two principle statements in his paper:
1. That there will not be a 2x improvement in programming every 2 years (comparable to Moore's Law about the increasing density in transistors that was roughly every 18-24 months). That isn't to say that there won't be 2x improvements in some 2 year periods, but there will not be consistent 2x improvements every 2 years.
2. That within a decade of 1987 (that is, a period ending in 1997) there would not be a 10x (order of magnitude) improvement in programming (reliability, productivity, etc.) from any single thing.
So trying to refute Brooks' 2nd assertion, what lots of people try to do, by looking at changes post 1997 is an absurdity as it ignores what he actually said and the context of it.
That said, on the topic of environments and tools Brooks writes, "Surely this work is worthwhile, and surely it will bear some fruit in both productivity and reliability. But by its very nature, the return from now on must be marginal." This claim is not timeboxed to a decade, but is instead projected to perpetuity. He boldly asserts without support that that from now on, improvements to tooling environments definitionally cannot yield 10x improvements in programming. I think this is where people have taken issue, and have shown this claim to be wrong.
I think this error comes from a misconception in the previous paragraph: "Language-specific smart editors are developments not yet widely used in practice, but the most they promise is freedom from syntactic errors and simple semantic errors."
There is no reason to believe that language-specific smart editors could only save you from simple semantic errors and syntax. In fact, language specific editors in the ethos of Eve and Light Table supported sophisticated debugging and development modalities:
- time-travel debugging capabilities that rewind the state of a program to a previous point in its execution history
- what-if scenarios to test how the program would respond to different inputs without restarting it
- provenance tracing of program state to see how it was calculated
- live debugging and modification of a program while it's running
- saving, sharing, and replaying program state to trace bugs
- the ability to ask new questions about program output e.g. "Why is nothing drawing in this area of the screen?"
These are not "simple semantic errors" but deep program analyses and insights that are not even supported by most (any?) mainstream languages (nor could they be without changing core language semantics or adding on new language features with orthogonal semantics). Brooks doesn't imagine any of this and dismisses it all as "marginal" whereas in my experience actually using these tools, I found them literally transformative to my productivity and workflow.
Some of the items in your list sound like things that were features of Smalltalk IDEs back in the late 80s ?
- time-travel debugging
- live debugging and modification
- saving, sharing, and replaying
p304 "Debugger Windows" "Smalltalk/V 286 Tutorial and Programming Handbook"
https://rmod-files.lille.inria.fr/FreeBooks/SmalltalkVTutori...
----
And later, Rewrite Rules:
A very large Smalltalk application was developed at Cargill to support the operation of grain elevators and the associated commodity trading activities. The Smalltalk client application has 385 windows and over 5,000 classes. About 2,000 classes in this application interacted with an early (circa 1993) data access framework. The framework dynamically performed a mapping of object attributes to data table columns.
Analysis showed that although dynamic look up consumed 40% of the client execution time, it was unnecessary.
A new data layer interface was developed that required the business class to provide the object attribute to column mapping in an explicitly coded method. Testing showed that this interface was orders of magnitude faster. The issue was how to change the 2,100 business class users of the data layer.
A large application under development cannot freeze code while a transformation of an interface is constructed and tested. We had to construct and test the transformations in a parallel branch of the code repository from the main development stream. When the transformation was fully tested, then it was applied to the main code stream in a single operation.
Less than 35 bugs were found in the 17,100 changes. All of the bugs were quickly resolved in a three-week period.
If the changes were done manually we estimate that it would have taken 8,500 hours, compared with 235 hours to develop the transformation rules.
The task was completed in 3% of the expected time by using Rewrite Rules. This is an improvement by a factor of 36.
from “Transformation of an application data layer” Will Loew-Blosser OOPSLA 2002
Here's the silver bullet that seems to work very well.
> Master your current stack.
Time and time again I see programmers who know computer science but really don't know their language. They run to stack overflow for everything from sorting to reading files. They make obvious syntax errors. They pause constantly not to think about problems, but to remember how to implement something simple.
Most programmers can 10x themselves just by learning their language and stack really well.