4 ms·

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 som

by 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.
    - gnulinux 5y ago
      Saying "you're slow" doesn't solve anything. I know I'm slow, but I'm still faster when there is a robust type system with good guarantees.
UnpossibleJim 5y ago
|I found over the years to avoid long debugging sessions, I can instead write better tests, do smaller commits, and write less clever code| 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 =)
FridgeSeal 5y ago
This is why I find myself preferring static languages (Rust currently) over my previous focus (Python). 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”.
wtetzner 5y ago
> Coding speed is irrelevant in the long run. It's only relevant for quick scripts and throwaway code. Except writing tests is coding.
fijiaarone 5y ago
It always gets me when people talk about typing speed in programming. Maybe it's because I can't think faster than 50 words per minute, so it doesn't matter if I could type faster. 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.

by titzer 5y ago

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.
  - gnulinux 5y ago
    Saying "you're slow" doesn't solve anything. I know I'm slow, but I'm still faster when there is a robust type system with good guarantees.

UnpossibleJim 5y ago

|I found over the years to avoid long debugging sessions, I can instead write better tests, do smaller commits, and write less clever code| 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 =)

FridgeSeal 5y ago

This is why I find myself preferring static languages (Rust currently) over my previous focus (Python). 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”.

wtetzner 5y ago

> Coding speed is irrelevant in the long run. It's only relevant for quick scripts and throwaway code. Except writing tests is coding.

fijiaarone 5y ago

It always gets me when people talk about typing speed in programming. Maybe it's because I can't think faster than 50 words per minute, so it doesn't matter if I could type faster. 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.