16 ms·

Speed Matters

197 points by U1F984 5y ago

AlexanderDhoore 5y ago
This obsession with productivity is not healthy, and a young man's game. Relax for a second, will ya. Think before you act.
- snek_case 5y ago
  I agree and I would say that choosing to work on the right things is much more important than being a fast programmer. Sometimes you need to spend more time thinking about a problem, do a bit of a "market study", or gather more data. Too many startups out there are solutions looking for a problem. On a smaller scale, as an individual programmer, it's easy to get caught into yak shaving or trying to optimize the wrong thing.
  - Jensson 5y ago
    > choosing to work on the right things is much more important than being a fast programmer 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.
  - wtetzner 5y ago
    Being able to quickly try things out is a great way to understand a problem better. Coding speed can help a lot with that.
- imachine1980_ 5y ago
  Old people don't understand, we need more reasons to use Adderall
- deleted 5y ago
  [deleted]
- TeMPOraL 5y ago
  It's not an obsession with productivity. Speed of the tools we use limit the thoughts we can think.
  - convolvatron 5y ago
    nothing is more frustrating for me that to have a goal, and a path, but be unable to get there because of .. issues. i know thats programming and working in an organization 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
- bob1029 5y ago
  You can still be hyper-productive without killing yourself in the process. Also, some people actually like to do these things. 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.
  - mental1896 5y ago
    It's possible to walk a line that straddles both approaches.
- chriswait 5y ago
  Maybe you misread the article - the obsession here is with "speedup", which is not the same as productivity. 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.
hinkley 5y ago
Doing something a second time is almost always faster. 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.
- MarkLowenstein 5y ago
  When something becomes routine for a developer, where they can predictably finish a work item without designing anything new, that task is immediately flagged in managers' minds as one that should be done by a more-junior/contractor/3rd-party/off-the-shelf solution. Almost by definition, then, good developers are relegated to only doing tasks that they are doing for the first time. The implications of this natural law are evident in the quality of the output, the predictability of the schedule, and career burn-out of people who are asked to be creative 100% of the time.
  - hinkley 5y ago
    I still spend a lot of my time manipulating lists. Although it may be fair to say that experience helps you realize that you can turn some problems into manipulating lists. Easier to write tests for, and for the next person to understand. 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.
DeathArrow 5y ago
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.
- ModernMech 5y ago
  I don't think the author is making that mistake. He worked on the Eve language, whose entire ethos was that the notion behind Fred Brooks' "No Silver Bullet" -- that there is no "one" change to development tolling/methodology that could produce a 10x speedup in productivity -- isn't really true anymore. In "Out of the Tar Pit", Mosely and Marks argue that today there is so much incidental complexity (from poorly designed or ill-fitting tools) slowing down our work, that removing it would result in those 10x gains Brooks argues can't be achieved in NSB. 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 https://en.wikipedia.org/wiki/No_Silver_Bullet http://curtclifton.net/papers/MoseleyMarks06a.pdf 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!")
TrackerFF 5y ago
By being an exceptionally fast worker, you're usually rewarded with more work.
- r00fus 5y ago
  By finishing your assigned work exceptionally fast, you can focus actual effort on the "sharpening the saw" aspects of your role and/or the organization, and helping others. Those are the workers who (in a competent organization) are promoted.
  - godDLL 5y ago
    The bigger the organization is, the more able it is to "promote" or segment it's workforce; and less likely to actually do any changes. 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?
  - massysett 5y ago
    Exactly. As a supervisor, of course I give more work to my staff who work faster. This means they get more opportunities to learn, more exposure to good projects, more development, and more opportunities for promotion (if they want that.)
    - spaetzleesser 5y ago
      Only if you have good projects , development and promotion opportunities to give to them . Often it’s just more work of the same kind.
      - massysett 5y ago
        Yes, only a fraction of the work is “good” work in that sense. The fast workers get many more opportunities to get it. It’s like the fast worker buying ten lottery tickets and the slow worker buying one. She who buys ten tickets has ten times the chance of winning, even if she buys nine losers.
dboreham 5y ago
Hmm...there are "hunt-n-peck" typing programmers?? How is that possible given that to become a programmer you need to type all day every day for years.
- unsui 5y ago
  they exist, although I imagine they are becoming rarer as typing skills are becoming part of the standard elementary/middle-school curriculum. 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.
- abacadaba 5y ago
  don't judge me
  - dfghjkh 5y ago
    Your public post is, unfortunately, being judged by hundreds to people (at least).
- ModernMech 5y ago
  I was a hunt-n-peck programmer because I learned how to program as I was learning how to type.
- jeffffff 5y ago
  hunt and peck is probably an exaggeration but typing speed is not the bottleneck for programming https://twitter.com/id_aa_carmack/status/1302651878065475584 https://twitter.com/id_aa_carmack/status/1302651878065475584
  - deleted 5y ago
    [deleted]
  - deleted 5y ago
    [deleted]
Traster 5y ago
One of the things that my most recent job really highlighted was - speed matters, but you need to know how 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. Speed does matter, but first, you need to know now.
yldedly 5y ago
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?
- irskep 5y ago
  I've been keeping a private notes file about this. People tell me I'm fast, and I agree with them, so I'm trying to track why. 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.
  - yldedly 5y ago
    >Have self-awareness about what is taking you time. It's simple, but so true!
- imeron 5y ago
  Sometimes I think the biggest slowdown for most coders is the inability to make a decision and start working in a certain direction. Not-deciding also includes masquerading procrastination as researching a subject :).
  - yldedly 5y ago
    That definitely matches my experience. I've learned that when I'm paralyzed by uncertainty, I just need to pick something, and in the act of implementing things I automatically make the decisions. But that habit needs to be honed..
- deleted 5y ago
  [deleted]
PaulDavisThe1st 5y ago
> 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. 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.
- kragen 5y ago
  Ant's Editor, Anthony Howe's entry to IOCCC '91, surely took him longer than 10 hours to write; David A. Wheeler's "SLOCCount" estimates about 0.65 person-months (because it's 289 lines of code), which is roughly 120 hours. In its unobfuscated form, it's 5065 characters of C, including comments, and not including the curses implementation it runs on. It's a vi clone that's complete enough to use for real work; you could reasonably argue that it is not "of value to anyone" because there are other editors available that are more featureful that can run anywhere it runs. It lacks, for example, yank, put, and undo. But it's definitely featureful enough to use when you don't have anything else. 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%.
buescher 5y ago
My thoughts on "good, fast, cheap, pick (at most) two": 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
- hyperpape 5y ago
  As the developer (but not the OP, of course), cheap is not an attribute I'm inclined to optimize for...
  - buescher 5y ago
    Yeah. Aspire to be good, fast, and expensive. Also, slow gets expensive fast anyway.
  - ansgri 5y ago
    I’ve come to expect ~80% of work requirements be ‘fast and cheap’ (regular projects) and the rest is ‘fast and good’ (well-funded startup, maybe internal). As I work near academy, there’s a fraction of ‘slow and very cheap’ (produce publications expected by grants by end of the reporting period). ‘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.
danielovichdk 5y ago
Speed doesn't matter if you're doing the right thing. 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
- ModernMech 5y ago
  > Then speed is set by how fast you type. 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" 13 characters total. But if I did this in Java for instance, well that's a different story. Now the program looks like this: class HelloWorld { public static void main(String[] args) { System.out.println("Hello World"); } } 87 characters total. The original program could have been written 6 times over in the time it took to write just this one. But that's not the real issue. The real issue is that not only do I have all that extra syntax, I have a whole bunch of new concepts to contend with including classes, scopes, functions, function composition, console arguments, lifetimes, access, types, arrays, objects, and methods. I can't just do a thing, I have to do all this extra work before I can do the thing. In the first case I have a single concept in my mind: String. In the second case I have to keep not only N concepts straight, but how they compose as well, and all the arcane rules therein.
  - jiggawatts 5y ago
    This is like those reviews of operating systems that are 50% about the installation process, even though most people install their own operating system at most once, and most likely zero times. Then go on to use it for years and years. Making the "issues" listed in the review something that affects 0.01% of the time interacting with the product being reviewed. 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.
hn_throwaway_99 5y ago
> 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. This seemed like a very, well, odd analysis to me. My typing speed is the last thing that affects my overall productivity.
- dgb23 5y ago
  I read it as being the upper bound and not the target of optimization.
  - fijiaarone 5y ago
    Wouldn't reducing the amount of typing by thinking about what you're doing instead of copying it increase that upper bound? And wouldn't thinking about what needs to be done (and what doesn't need to be done) increase that upper bound even more?
quickthrower2 5y ago
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) 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.
lordofmoria 5y ago
> 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. 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.
- fabianhjr 5y ago
  I learned Dvorak for the speed and remained due to a perceived lower strain on my hands. (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)
  - hello4353 5y ago
    * perceived lower strain * . Isn't it a proven fact?
- renewiltord 5y ago
  On my Macbook Pro, I have Caps Lock mapped to Esc. But every time I hit Caps Lock there would be a pause before the Esc triggered. Since I use vim bindings everywhere this was a nightmare as I switched to normal mode. I was like way less productive. It was nutty. Fixed it using Karabiner as recommended https://superuser.com/questions/317900/eliminate-macbook-capslock-delay/1429859 https://superuser.com/questions/317900/eliminate-macbook-cap... and suddenly I was better at life.
  - localhost 5y ago
    Another option is to map Caps Lock to CTRL and use the default vi CTRL+[ keybinding for ESC. You get the bonus of being able to use a more ergonomic CTRL for virtually anything else that requires CTRL.
eric_b 5y ago
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 can result in speed). 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.
ChrisMarshallNY 5y ago
I enjoyed the read. > 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 https://stackoverflow.com/story/chrismarshall [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/
- godDLL 5y ago
  Can you finish a thought tho? As in, why did you just type all that up? What is the point you're making? Respectfully.
  - ChrisMarshallNY 5y ago
    > Can you finish a thought tho? 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.
titzer 5y ago
Missed in this analysis is just how much time it takes to debug. 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. 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.
- Jensson 5y ago
  To me coding speed is the speed at which you write code with few enough bugs that it is fine to run it in production. So debugging is included in that number, if you have to spend so much time debugging your code then you aren't a fast coder. 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.
  - gnulinux 5y ago
    You can still write code, test it, debug it, release to production; then weeks or months later someone finds a bug in it (in prod). GP's point is that this kind of debugging sucks a lot more time than writing feature's v1 code from scratch. And I agree.
    - Jensson 5y ago
      But that bug is also chalked up to your original time. The time it takes to make feature X is the implementation time + all maintenance time. If that combination isn't low then you are slow. 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.
morelandjs 5y ago
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.
karmakaze 5y ago
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. Don't let weeks go by AFK for no reason.
slim 5y ago
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

197 points by U1F984 5y ago

This obsession with productivity is not healthy, and a young man's game. Relax for a second, will ya. Think before you act.

snek_case 5y ago
I agree and I would say that choosing to work on the right things is much more important than being a fast programmer. Sometimes you need to spend more time thinking about a problem, do a bit of a "market study", or gather more data. Too many startups out there are solutions looking for a problem. On a smaller scale, as an individual programmer, it's easy to get caught into yak shaving or trying to optimize the wrong thing.
- Jensson 5y ago
  > choosing to work on the right things is much more important than being a fast programmer 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.
- wtetzner 5y ago
  Being able to quickly try things out is a great way to understand a problem better. Coding speed can help a lot with that.
imachine1980_ 5y ago
Old people don't understand, we need more reasons to use Adderall
deleted 5y ago
[deleted]
TeMPOraL 5y ago
It's not an obsession with productivity. Speed of the tools we use limit the thoughts we can think.
- convolvatron 5y ago
  nothing is more frustrating for me that to have a goal, and a path, but be unable to get there because of .. issues. i know thats programming and working in an organization 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
bob1029 5y ago
You can still be hyper-productive without killing yourself in the process. Also, some people actually like to do these things. 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.
- mental1896 5y ago
  It's possible to walk a line that straddles both approaches.
chriswait 5y ago
Maybe you misread the article - the obsession here is with "speedup", which is not the same as productivity. 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.

hinkley 5y ago

Doing something a second time is almost always faster. 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.

MarkLowenstein 5y ago
When something becomes routine for a developer, where they can predictably finish a work item without designing anything new, that task is immediately flagged in managers' minds as one that should be done by a more-junior/contractor/3rd-party/off-the-shelf solution. Almost by definition, then, good developers are relegated to only doing tasks that they are doing for the first time. The implications of this natural law are evident in the quality of the output, the predictability of the schedule, and career burn-out of people who are asked to be creative 100% of the time.
- hinkley 5y ago
  I still spend a lot of my time manipulating lists. Although it may be fair to say that experience helps you realize that you can turn some problems into manipulating lists. Easier to write tests for, and for the next person to understand. 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.

DeathArrow 5y ago

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.

ModernMech 5y ago
I don't think the author is making that mistake. He worked on the Eve language, whose entire ethos was that the notion behind Fred Brooks' "No Silver Bullet" -- that there is no "one" change to development tolling/methodology that could produce a 10x speedup in productivity -- isn't really true anymore. In "Out of the Tar Pit", Mosely and Marks argue that today there is so much incidental complexity (from poorly designed or ill-fitting tools) slowing down our work, that removing it would result in those 10x gains Brooks argues can't be achieved in NSB. 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 https://en.wikipedia.org/wiki/No_Silver_Bullet http://curtclifton.net/papers/MoseleyMarks06a.pdf 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!")

TrackerFF 5y ago

By being an exceptionally fast worker, you're usually rewarded with more work.

r00fus 5y ago
By finishing your assigned work exceptionally fast, you can focus actual effort on the "sharpening the saw" aspects of your role and/or the organization, and helping others. Those are the workers who (in a competent organization) are promoted.
- godDLL 5y ago
  The bigger the organization is, the more able it is to "promote" or segment it's workforce; and less likely to actually do any changes. 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?
- massysett 5y ago
  Exactly. As a supervisor, of course I give more work to my staff who work faster. This means they get more opportunities to learn, more exposure to good projects, more development, and more opportunities for promotion (if they want that.)
  - spaetzleesser 5y ago
    Only if you have good projects , development and promotion opportunities to give to them . Often it’s just more work of the same kind.
    - massysett 5y ago
      Yes, only a fraction of the work is “good” work in that sense. The fast workers get many more opportunities to get it. It’s like the fast worker buying ten lottery tickets and the slow worker buying one. She who buys ten tickets has ten times the chance of winning, even if she buys nine losers.

dboreham 5y ago

Hmm...there are "hunt-n-peck" typing programmers?? How is that possible given that to become a programmer you need to type all day every day for years.

unsui 5y ago
they exist, although I imagine they are becoming rarer as typing skills are becoming part of the standard elementary/middle-school curriculum. 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.
abacadaba 5y ago
don't judge me
- dfghjkh 5y ago
  Your public post is, unfortunately, being judged by hundreds to people (at least).
ModernMech 5y ago
I was a hunt-n-peck programmer because I learned how to program as I was learning how to type.
jeffffff 5y ago
hunt and peck is probably an exaggeration but typing speed is not the bottleneck for programming https://twitter.com/id_aa_carmack/status/1302651878065475584 https://twitter.com/id_aa_carmack/status/1302651878065475584
- deleted 5y ago
  [deleted]
- deleted 5y ago
  [deleted]

Traster 5y ago

One of the things that my most recent job really highlighted was - speed matters, but you need to know how 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. Speed does matter, but first, you need to know now.

yldedly 5y ago

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?

irskep 5y ago
I've been keeping a private notes file about this. People tell me I'm fast, and I agree with them, so I'm trying to track why. 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.
- yldedly 5y ago
  >Have self-awareness about what is taking you time. It's simple, but so true!
imeron 5y ago
Sometimes I think the biggest slowdown for most coders is the inability to make a decision and start working in a certain direction. Not-deciding also includes masquerading procrastination as researching a subject :).
- yldedly 5y ago
  That definitely matches my experience. I've learned that when I'm paralyzed by uncertainty, I just need to pick something, and in the act of implementing things I automatically make the decisions. But that habit needs to be honed..
deleted 5y ago
[deleted]

PaulDavisThe1st 5y ago

> 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. 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.

kragen 5y ago
Ant's Editor, Anthony Howe's entry to IOCCC '91, surely took him longer than 10 hours to write; David A. Wheeler's "SLOCCount" estimates about 0.65 person-months (because it's 289 lines of code), which is roughly 120 hours. In its unobfuscated form, it's 5065 characters of C, including comments, and not including the curses implementation it runs on. It's a vi clone that's complete enough to use for real work; you could reasonably argue that it is not "of value to anyone" because there are other editors available that are more featureful that can run anywhere it runs. It lacks, for example, yank, put, and undo. But it's definitely featureful enough to use when you don't have anything else. 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%.

buescher 5y ago

My thoughts on "good, fast, cheap, pick (at most) two": 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

hyperpape 5y ago
As the developer (but not the OP, of course), cheap is not an attribute I'm inclined to optimize for...
- buescher 5y ago
  Yeah. Aspire to be good, fast, and expensive. Also, slow gets expensive fast anyway.
- ansgri 5y ago
  I’ve come to expect ~80% of work requirements be ‘fast and cheap’ (regular projects) and the rest is ‘fast and good’ (well-funded startup, maybe internal). As I work near academy, there’s a fraction of ‘slow and very cheap’ (produce publications expected by grants by end of the reporting period). ‘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.

danielovichdk 5y ago

Speed doesn't matter if you're doing the right thing. 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

ModernMech 5y ago
> Then speed is set by how fast you type. 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" 13 characters total. But if I did this in Java for instance, well that's a different story. Now the program looks like this: class HelloWorld { public static void main(String[] args) { System.out.println("Hello World"); } } 87 characters total. The original program could have been written 6 times over in the time it took to write just this one. But that's not the real issue. The real issue is that not only do I have all that extra syntax, I have a whole bunch of new concepts to contend with including classes, scopes, functions, function composition, console arguments, lifetimes, access, types, arrays, objects, and methods. I can't just do a thing, I have to do all this extra work before I can do the thing. In the first case I have a single concept in my mind: String. In the second case I have to keep not only N concepts straight, but how they compose as well, and all the arcane rules therein.
- jiggawatts 5y ago
  This is like those reviews of operating systems that are 50% about the installation process, even though most people install their own operating system at most once, and most likely zero times. Then go on to use it for years and years. Making the "issues" listed in the review something that affects 0.01% of the time interacting with the product being reviewed. 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.

hn_throwaway_99 5y ago

> 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. This seemed like a very, well, odd analysis to me. My typing speed is the last thing that affects my overall productivity.

dgb23 5y ago
I read it as being the upper bound and not the target of optimization.
- fijiaarone 5y ago
  Wouldn't reducing the amount of typing by thinking about what you're doing instead of copying it increase that upper bound? And wouldn't thinking about what needs to be done (and what doesn't need to be done) increase that upper bound even more?

quickthrower2 5y ago

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) 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.

lordofmoria 5y ago

> 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. 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.

fabianhjr 5y ago
I learned Dvorak for the speed and remained due to a perceived lower strain on my hands. (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)
- hello4353 5y ago
  * perceived lower strain * . Isn't it a proven fact?
renewiltord 5y ago
On my Macbook Pro, I have Caps Lock mapped to Esc. But every time I hit Caps Lock there would be a pause before the Esc triggered. Since I use vim bindings everywhere this was a nightmare as I switched to normal mode. I was like way less productive. It was nutty. Fixed it using Karabiner as recommended https://superuser.com/questions/317900/eliminate-macbook-capslock-delay/1429859 https://superuser.com/questions/317900/eliminate-macbook-cap... and suddenly I was better at life.
- localhost 5y ago
  Another option is to map Caps Lock to CTRL and use the default vi CTRL+[ keybinding for ESC. You get the bonus of being able to use a more ergonomic CTRL for virtually anything else that requires CTRL.

eric_b 5y ago

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 can result in speed). 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.

ChrisMarshallNY 5y ago

I enjoyed the read. > 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 https://stackoverflow.com/story/chrismarshall [1] https://littlegreenviper.com/miscellany/leaving-a-legacy/ https://littlegreenviper.com/miscellany/leaving-a-legacy/

godDLL 5y ago
Can you finish a thought tho? As in, why did you just type all that up? What is the point you're making? Respectfully.
- ChrisMarshallNY 5y ago
  > Can you finish a thought tho? 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.

titzer 5y ago

Missed in this analysis is just how much time it takes to debug. 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. 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.

Jensson 5y ago
To me coding speed is the speed at which you write code with few enough bugs that it is fine to run it in production. So debugging is included in that number, if you have to spend so much time debugging your code then you aren't a fast coder. 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.
- gnulinux 5y ago
  You can still write code, test it, debug it, release to production; then weeks or months later someone finds a bug in it (in prod). GP's point is that this kind of debugging sucks a lot more time than writing feature's v1 code from scratch. And I agree.
  - Jensson 5y ago
    But that bug is also chalked up to your original time. The time it takes to make feature X is the implementation time + all maintenance time. If that combination isn't low then you are slow. 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.

morelandjs 5y ago

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.

karmakaze 5y ago

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. Don't let weeks go by AFK for no reason.

slim 5y ago

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