Earlier quoted context omitted.
"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.
Ask HN: Do you spend more time coding or debugging?
71–77 of 77 posts
Re: Ask HN: Do you spend more time coding or debugging?
#72Earlier quoted context omitted.
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
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.
Re: Ask HN: Do you spend more time coding or debugging?
#73Earlier quoted context omitted.
Same here. I often spend time wondering if it's simply that this field isn't for me, 40hrs a week kills my drive, or if it's a bigger issue like depression. Only thing I enjoy now are exercise and music.
Have you ever coded for a project you were excited about? Where you could feel really good about delivering a quality, useful product? If possible, try and find that at your current job. If not, a new job may be the best route. Management and bureaucracy are great at squashing good vibes here. Also, see if you can find some satisfaction in expanding your programming skills through reading and learning. Not sure your…
I intend to spend no free time on my career outside of work. There are far too many other things in life I would prefer to work on and experience, hence why I wonder if this is the right field for me.
Sorry if I sound so negative, it's just how I've felt since first starting out in my field.
Re: Ask HN: Do you spend more time coding or debugging?
#74Re: Ask HN: Do you spend more time coding or debugging?
#75Re: Ask HN: Do you spend more time coding or debugging?
#76Earlier quoted context omitted.
> I definitely wouldn't assume that someone who spent more time debugging was a "worse" programmer I believe that more time spent debugging, the worse the code you're debugging is. Now if you're spending most of your time debugging your own code, then likely you're a novice who hasn't learned the many ways to write quality code that "just works". If, on the other hand, you inherited a codebase from someone who did no…
I find myself doing the exact opposite. The time I get paid for is mostly spent fixing bugs in a codebase of variable quality that I've inherited. The hobby projects I get up to are entirely my own code and thus I get to spend the majority of that time implementing new features.
So I'm trying to modernize it by building a separate app that can interoperate with the 4 different schemas and do all the same things that the old app did. It's an interesting exercise in replacing legacy code piece by piece while still using it (all the leagues would not function if the site didn't work, and there's basically 3 weeks out of the year when the leagues aren't playing).
Professionally, on the other hand, I work at a startup where I've more or less had my hands in the code from day one.