Doing something a second time is almost always faster.<p>You can’t draw any information from this, except perhaps that the author avoided Second System Syndrome.<p>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.<p>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.<p>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?<p>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.
Missed in this analysis is just how much time it takes to <i>debug</i>. I have found over the years that I spend at least an order of magnitude more time debugging something than writing it. And that gets worse if the debugging is separated from the writing by days, weeks, or months, because of the context reload and the general head-scratching trying to figure how it is supposed to work and what I did wrong.<p>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.<p>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.<p>Coding speed is irrelevant in the long run. It's only relevant for quick scripts and throwaway code.<p>Don't get sucked into debugging.
> An example of one of these, the most commonly cited bad-thing-to-optmize example that I've seen, is typing speed (when discussing this, people usually say that typing speed doesn't matter because more time is spent thinking than typing). But, when I look at where my time goes, a lot of it is spent typing.<p>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.
> If I was 10x faster yet it would have been 10 hours. That's a long plane ride. Even with a full-time job I would still be able to squeeze in a couple of text editor sized projects every month. I would be able to learn so many new things.<p>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.<p>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.<p>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.
To me, this is not a lesson about speed, but rather a lesson about "compound interest". He was able to compound all his learnings from the first go round in to the second. That doesn't always mean it will go faster, but it does usually mean you don't make the same mistakes as the first time (which <i>can</i> result in speed).<p>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.
I enjoyed the read.<p><i>> 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><p>I never learned to touch-type, but I've also typed <i>a lot</i> of stuff[0]. I seem to be a lot faster than most folks, and I write <i>wordy</i> code. Take a look at my codebases, to see what I mean. <i>Lots</i> of documentation[1].<p>Also, I have a friend who is an <i>amazing</i> 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.<p>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.<p>[0] <a href="https://stackoverflow.com/story/chrismarshall" rel="nofollow">https://stackoverflow.com/story/chrismarshall</a><p>[1] <a href="https://littlegreenviper.com/miscellany/leaving-a-legacy/" rel="nofollow">https://littlegreenviper.com/miscellany/leaving-a-legacy/</a>
> There are ~33k characters in the rematch repo, most of which are tests. I type ~500 characters per minute. So if I could sit down and type the correct code first time, without making mistakes or getting distracted, it would take 66 minutes. I don't see any fundamental reason why I shouldn't be able to at least approach that bound for such simple code - maybe get within 3 hours, say. So there is potentially room for another 10x speedup.<p>This seemed like a very, well, <i>odd</i> analysis to me.<p>My typing speed is the <i>last</i> thing that affects my overall productivity.
There are all sort of programmers. I personally am sensitive to the creative side of it. Problems tend to have an infinite number of solutions and I feel unsatisfied if I don't get close to the ideal one. I can feel my solution is wrong and I can feel when I get inspired out of nowhere. I have no control on this, the only solution I found for this is to let the problem macerate for a few hours/days if it's possible. I think it's analogous to a painter artist who leaves his frame unfinished for days/months and comes back to it till he feels satisfied. It's the creative part of the job that's uncompressible. Of course you can have programming jobs with no creative part, in which case you can do 10x sometimes 100x depending on who you compare yourself to
Hmm...there are "hunt-n-peck" typing programmers??<p>How is that possible given that to become a programmer you need to type all day every day for years.
I asked myself how can I code faster just now and I asked myself what slows me down. At the moment it’s local build times. I often drop into Linqpad to sanity test code as sometimes even running a unit test is painful (because of building the code not the test itself)<p>The team is longer term looking at splitting up libraries but maybe I should see what quick wins .Net has to offer.<p>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.
The author makes a point of noting that many small improvements work together to make a larger speed increase, but are there 80/20 interventions here? What is the most effective way to become a faster coder?
One of the things that my most recent job really highlighted was - speed matters, but you need to know <i>how</i> it matters. In my particular niche essentially there were cliffs. If you were faster than x, you got y, if you were faster than x2 you got y2. Basically, you could halve the latency of your system for 0 benefit. You could decrease the latency of your system by 5ns and the benefits would be amazing. You could gain 5ns and it'd be nothing.<p>Speed does matter, but first, you need to know now.
For self-started projects what matters far more is maintaining consistent motivation and progress. For sure, there will be places where a good choice will pay off and save lots of work or bugs, but how often that happens matches the level you're at. The post is saying this will happen more often with practice, which I completely agree with. The important thing is that you keep on making. Consistency also matters.<p>Don't let weeks go by AFK for no reason.
Speed doesn't matter if you're doing the right thing.<p>Writing code can't be done quick without knowing what you need the outcome to be.<p>Then speed is set by how fast you type.<p>But it's a theory, and practice no one writes code without having to put thinking into it.<p>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
I think one thing that often gets lost in these types of discussions, is it’s not just fast versus slow. It’s also patient versus impatient. In certain situations you absolutely need to be methodical, because you are stacking and layering complexity in a manner than is impossible to fuck the impatient way of it goes sideways.
My thoughts on "good, fast, cheap, pick (at most) two":<p>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
The author mistakes coding for typing. You maybe get faster at typing, but coding also involves thinking and doing research. Unless you do very repetitive tasks and you can type from memory.