
The Art of Debugging - nkurz
https://remysharp.com/2015/10/14/the-art-of-debugging
======
ThePhysicist
I always found debugging to be one of the most important skills in software
development and programming.

Most people seem to think of debugging only as finding and fixing unexpected
behavior in finished software projects, but it is actually a big part of the
development process itself: When I implement a new feature, I normally use the
following pattern:

* Make a mental model of what I want to accomplish (e.g. "add payment form to the web app")

* Split that into individual chunks of work (e.g. "create the web form and have it accept the data")

* Write a chunk of code and see its effect on the software

* Find unexpected behavior (i.e. "debug" the feature)

* Fix the unexpected behavior to match the desired one

Ideally, the loop above is not performed once for an the entire feature but
many times on tiny, individual parts of it (writing tests for each small step
is even better). By this definition I probably spend 50 % of my time
"debugging" code, if not more.

Debugging is also the most important skill that I try to teach to other
programmers when onboarding them into a team. Why? Because a programmer that
is effective at debugging will save himself/herself and everyone else on the
team an incredible amount of time. Developers that aren't able to efficiently
debug problems themselves will get stuck frequently, which means that someone
else on the team has to "unblock" them by doing the debugging for them. In
that case, the "debugger" will usually be a more experienced team member,
which means your team will waste not only the time of the inexperienced
developer, but also that of the experienced one. I believe this is the main
reason that adding another programmer to a large team can actually slow
progress down rather than accelerating it.

On the other hand it's of course the responsibility of the experienced
developers and the team lead to make sure that only a minimum amount of
(unexpected) debugging is required to begin with. In practice this means
having (among other things) strict development guidelines, software tests, a
continuous integration system, very good documentation and a thorough code
review process.

Also, I might be saying nonsense here but I think the reason that people from
Physics or other STEM fields are usually very good programmers is that they
are thaught a lot of "debugging" skills during their training, especially in
experimental fields.

~~~
hga
_Also, I might be saying nonsense here but I think the reason that people from
Physics or other STEM fields are usually very good programmers is that they
are thaught a lot of "debugging" skills during their training, especially in
experimental fields._

I believe this is true, at least for myself, if you limit the STEM to Science,
but I'll note it starts with your first bullet point, "Make a mental model".
Here's a pretty good (top Google "process of science") diagram and description
of the The Scientific Process:
[http://www2.nau.edu/~gaud/bio372/class/behavior/sciproc.htm](http://www2.nau.edu/~gaud/bio372/class/behavior/sciproc.htm)
and you can see how pretty much every part of it has direct utility in the
mechanics of software development.

I'm weaseling with "the mechanics" because software development almost always
involves a lot more direct, unscripted, and frequent interaction with other
people. By comparison, what happens in science can be a lot more constrained,
with the closest part of that sort of thing being funding. You also need to
keep the people who you're delivering your results to happy, be they
scientific journals or superiors and peers who need them for more direct uses,
and having a working relationship with those under you, which for a PI could
be postdocs, grad and undergrad students, and lab techs. And depending on the
field the usual bureaucracy regulating what you do.

The mentoring model is almost infinitely stronger in science. When you're an
undergrad, you get mentored by your grad student TAs, and if your smart, you
spend at least a little time your favorite professors (in the best cases, they
get free or much cheaper labor, potentially on high risk and/or apparently low
gain work). In my personal experience, if you don't waste their time,
Nobelists are at minimum happy to provide a little advice in passing.

The grad students both mentor the undergrads and are mentored by their PI and
his more experienced postdocs and grad students, it's an apprenticeship model.
Once you have your Ph.D., there's still a good chance you'll do, or should so,
some mentoring in whatever lab you end up in, industrial or academic. In the
academic track you'll be expected to formally teach classes, and good schools
will demand adequate performance. If a PI, you cultivate your crew of lab
techs, students, and postdocs. Personal reputation is also more generally
important, especially lower down.

(Note that I've seen these positive behaviors at 3 levels of academic
institutions, the low end one level above community college 4 year college
where the professors are there to teach, a highest end "R1" university, and a
middling "high research activity" university.)

Hmmm, there's also a lot of gatekeeping in science which isn't present in our
field. It's legendary how many "college dropouts" for whatever reason ($$$ in
mine) go on to be successful, whereas it probably isn't easy to become a
bottom of the totem pole lab tech without an undergraduate degree. Which is
the gateway to grad school and the Ph.D. where you can become more
independent, and doing that in the American model requires passing quals,
doing original research and defending that. There are of course exceptions to
the typical path, but they're a lot more unusual.

~~~
ThePhysicist
very good points, thanks for sharing!

------
thangalin
Also of interest, "How do you fix a bug you can't replicate?"

[http://stackoverflow.com/a/1268464/59087](http://stackoverflow.com/a/1268464/59087)

~~~
cpfohl
Install a exception reporting tool and get a stack trace for it. My favorite
(disclaimer, I now work for them) is Rollbar.

------
adamwong246
God, I just love the Chrome debugger. It is, hands-down, my favorite computing
environment.

~~~
wh-uws
Ever use it with node?

Its pretty awesome [https://github.com/node-inspector/node-
inspector](https://github.com/node-inspector/node-inspector)

~~~
adamwong246
yeah, but with limited success. Loads sloooowly.

------
Scarbutt
_my work requires that I write JavaScript. Vanilla JavaScript, not JavaScript
that interacts with the DOM._

Does he means he only uses JS for scripting CSS and producing information?

~~~
Klathmon
I think he just means that the vast majority of his time is spent in the
actual "business" js code rather than "glue" js code.

And i kind of feel similar. I spend most of my time coding the actual app,
making tests, etc... Less than 10% of it is just taking data from the dom, and
putting it back in.

(this is all for web-app style things instead of your average website)

