Code · Programmer

Coding vs. Debugging?

Harpreet Singh Senior QA Engineer (Freelancer)

February 5th, 2017

I'm curious as to how other people's time is split at work, between developing new code, extending existing code, and maintaining existing code. Anyone care to share?

Ib Warnerbring Co-founder, UI/UX designer, full-stack developer

February 6th, 2017

It obviously depends on the project, but the most common product path is:


1. Build quick, which creates dirty/legacy code

2. Launch

3. Extend and add features, further dirtying the codebase

4. Spend weeks or months refactoring the code once everything has calmed down


This could all be avoided if co-founders would allow developers to be slower in step one, instead focusing on refactoring on-the-go to make sure the codebase is lean and somewhat optimised at launch.

Gabor Nagy Founder / Chief architect at Skyline Robotics

Last updated on February 6th, 2017

Of the time spend on EQUINOX-3D, its about 60% on new features, maybe 30% on testing (I also use it heavily as a CAD designer / 3D artists), and maybe 5-10% on debugging.

When I start working on a new feature, especially a complex one that may affect other parts of the system, I force myself to get away from the computer, go for a walk, etc., so I can really think things through.

I try to ask myself "in 20 years, will this design still be robust, or am I going to have to rewrite it a dozen times?"

Sometimes I just think about it for hours, or even a couple of days, without writing any code.

I find this really helps to avoid a lot of redesigns and unmaintainable code.

I rarely ever have to re-factor things, and forcing myself to really think a design through, rather than just coming up with it as I code, tends to help me remember it better too, even years later.

An hour spent thinking a design through beforehand, could save you a week or more of coding / rewriting later on.


Raja Kumar Code Surgeries | Micro Fixed Bids | Scala | Go | Kotlin | ReactJS | Android | Java | NFR Doctor

February 9th, 2017

Any company, where T&M is the billing, we have seen more than 80% time is in figuringout,log analysis or debugging. As that is the way to bill more..


These days, poor code is everywhere and hence, do expect more than 60% time on debugging and fixing the fixes

John Cwikla I build. You sell. Boom.

February 9th, 2017

Build fast. Debugging should be done to make sure you meet the requirements as close as possible. Avoid the 1% case. Nail the 90% case. Your eng team should be making sure what they build meets requirements. Your product team/PM should be the ones accepting their output (they are the users proxy). The luxury is building tests and cases for everything you do. If you can, groovy. If you can't, concentrate on what the users are using. If you don't know - launch and let the users hit the problems of your software so you can fix them.


If you run into the same problem multiple (3) times, it's time to debug as that's where your customers are spending their time so now it's worth your effort to fix it. Otherwise, the code you are fixing - noone is using - so who cares?**


** I leave a caveat for finance, laws, compliance, etc where an error can sink your efforts.

Michael Peralta I ask of lot of questions. A lot. All the time.

February 9th, 2017

nativetap.io


their software recreates and almost "breaks" your app before a customer has to go through the misfortune of experiencing it.


I don't know much about when you'd like to finish your product, but from what I know about testing periods is that they can only find so much. Nativetap.io finds everything and then highlights the affected code.