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.
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.
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.
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”.
How is that possible given that to become a programmer you need to type all day every day for years.
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.
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.
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.
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.
(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)
Those are the workers who (in a competent organization) are promoted.
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.
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?
(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 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.
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.
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
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.
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.
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.
Correction: a Zaurus.
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.
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.
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.
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.
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!
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?
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.
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.
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.
> 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.
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?
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.
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.
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.
Speed does matter, but first, you need to know now.
Don't let weeks go by AFK for no reason.