4 ms·

I used to spend the vast amount of my time debugging. Fast forward a few years - Experience, good programming habits, and the gratuitous use of assertions. Now

by vbtemp 10y ago

I used to spend the vast amount of my time debugging. Fast forward a few years - Experience, good programming habits, and the gratuitous use of assertions. Now I spend a negligible amount of time debugging, and it never ceases to amaze me how frequently things just work the first time. Edit: I guess I want to say that there is one, and only one, bottom line: the relentless, ruthless pursuit of quality. It takes time to develop the good habits and watch for the pitfalls, but once you're there you develop your software products in a quarter as much time, with one tenth the stress, and everyone on your team feels proud of themselves and each other. Then with your free time you can focus on what's really important - your business and your life

agopaul 10y ago
This. And I'd add that the type and complexity of the workload your application sustains is almost proportional to the amount of time spent debugging it
franklinho 10y ago
I remember the first time I wrote an entire controller and everything worked exactly like it did in my head. There was a lot of whooping and dancing to be had. Not that it happens much.
closed 10y ago
Agreed, but with the addition of some periodic, many hour, something-completely-unanticipated-happened-and-I-am-so-perplexed debugging sessions.
- davismwfl 10y ago
  This but let's also define debugging. From reading some of the comments left throughout the thread it seems like people don't think that a test failing and you having to go back and fix code (or even the test) is debugging but IMO it is. There is a bug, you are going back, finding it and fixing it. It usually means it is easier and faster to find/fix, but it is still time spent "debugging". I spend more time creating then debugging when I write the code from scratch, but I still say I spend probably at most 70% coding if it is a new project. The rest is in failing tests and finding those weird screwed up errors that take multiple days of a debugging session to find. For existing code I take over, it is probably usually more like a max of 50-60% coding depending on the original authors skill.
VOYD 10y ago
"Quality? But how does that affect our bottom line?" :)
- dandelany 10y ago
  I know you're joking... But it really does affect the bottom line! I've learned the hard way that taking twice as long to do something the right way will be more economical in the long run than doing it quickly, and cleaning up the bugs that manifest themselves over the following months.
  - vbtemp 10y ago
    Yes, but this is also a false dichotomy. In my experience doing something the "right" way is generally no overhead over doing it the "quick" way. Adding a check, or a log message, or making sure you're using consistent styling, or an assertion before/after some kind of operation... these things don't add time or complication to something
    - dandelany 10y ago
      I strongly disagree. Thinking through and handling all of the edge cases that could break my code inevitably takes more time than getting it to work for the few examples I know of and calling it a day. For example, I just wrote a function to generate a rolling average from a timeseries dataset with one data point per day. All of my sample data has exactly one datum per day. But I just know that eventually there will be an issue that causes data gaps, and of course writing code to handle gaps when they occur takes more time than not doing so and ignoring the consequences. And that's not even mentioning the time required to write unit tests. Furthermore, a lot of the extra time comes not from the initial coding exercise, but the diligence and follow-up required. ie. Cool, I've implemented a feature, but did I go through carefully and ensure that I've removed all my console.logs and commented out experiments? Did I leave dead code anywhere? Did I make any changes that require renaming or refactoring of other parts of the codebase? I never submit a PR these days without carefully going through my own git diff and double-checking myself. I almost always catch something when I do. These things take time.

by vbtemp 10y ago

agopaul 10y ago

This. And I'd add that the type and complexity of the workload your application sustains is almost proportional to the amount of time spent debugging it

franklinho 10y ago

I remember the first time I wrote an entire controller and everything worked exactly like it did in my head. There was a lot of whooping and dancing to be had. Not that it happens much.

closed 10y ago

Agreed, but with the addition of some periodic, many hour, something-completely-unanticipated-happened-and-I-am-so-perplexed debugging sessions.

davismwfl 10y ago
This but let's also define debugging. From reading some of the comments left throughout the thread it seems like people don't think that a test failing and you having to go back and fix code (or even the test) is debugging but IMO it is. There is a bug, you are going back, finding it and fixing it. It usually means it is easier and faster to find/fix, but it is still time spent "debugging". I spend more time creating then debugging when I write the code from scratch, but I still say I spend probably at most 70% coding if it is a new project. The rest is in failing tests and finding those weird screwed up errors that take multiple days of a debugging session to find. For existing code I take over, it is probably usually more like a max of 50-60% coding depending on the original authors skill.

VOYD 10y ago

"Quality? But how does that affect our bottom line?" :)

dandelany 10y ago
I know you're joking... But it really does affect the bottom line! I've learned the hard way that taking twice as long to do something the right way will be more economical in the long run than doing it quickly, and cleaning up the bugs that manifest themselves over the following months.
- vbtemp 10y ago
  Yes, but this is also a false dichotomy. In my experience doing something the "right" way is generally no overhead over doing it the "quick" way. Adding a check, or a log message, or making sure you're using consistent styling, or an assertion before/after some kind of operation... these things don't add time or complication to something
  - dandelany 10y ago
    I strongly disagree. Thinking through and handling all of the edge cases that could break my code inevitably takes more time than getting it to work for the few examples I know of and calling it a day. For example, I just wrote a function to generate a rolling average from a timeseries dataset with one data point per day. All of my sample data has exactly one datum per day. But I just know that eventually there will be an issue that causes data gaps, and of course writing code to handle gaps when they occur takes more time than not doing so and ignoring the consequences. And that's not even mentioning the time required to write unit tests. Furthermore, a lot of the extra time comes not from the initial coding exercise, but the diligence and follow-up required. ie. Cool, I've implemented a feature, but did I go through carefully and ensure that I've removed all my console.logs and commented out experiments? Did I leave dead code anywhere? Did I make any changes that require renaming or refactoring of other parts of the codebase? I never submit a PR these days without carefully going through my own git diff and double-checking myself. I almost always catch something when I do. These things take time.