Hacker News Reader

Comment by vbtemp | Hacker News Reader

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

View on HN

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

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.

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

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.

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

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.

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

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.

Reply on news.ycombinator.com