
Why don't schools teach debugging? (2014) - joeyespo
https://danluu.com/teach-debugging/
======
erikb
It is a task that shouldn't be learned in university but in middle school. And
it's not just useful to stem, it's useful to many things in life. E.g. a
disagreement between two educated, smart people usually can be resolved by
debugging how everybody got to their point of view and then flashing out the
details. It's also how you figure out why the toaster isn't working any more,
or why your wife left you.

It's also actually two skills:

Analysing a state. What do you see, what is there, or isn't. What was
expected.

Backtracing. Getting from point y to point x by figuring out how y happened.

I'd say at least in my country we also actually learn these skills. But when
we learn the methods its in a completely different context, totally unrelated
to life. In real life, you hit a problem, you get overwhelmed by the
complexity, and then your brain needs to start applying the method. In school
you learn the method, no idea why. Then you apply it to totally theoretical
problems, no idea why. Then you get tested on how well you execute the method,
no idea why. Then nobody ever talks about it again. Now, how should your brain
in moment of being overwhelmed remember that method A it learned 20 years ago
may apply here? There's no way.

Teaching shouldn't be: theory->method->application->test. It should be
theory->enforce_problem->wait_for_questions->explain_how_theory_can_be_applied->review_of_application->goto:enforce_problem.

~~~
ChicagoBoy11
Your comment couldn't be more on point. I viscerally disagree with the
direction that a lot of "coding" initiatives are taking in schools nowadays.
The claim is that the intentional move away from actual computer science is
that it is a way to attract more people.

Fine. But when the course is just about making "whatever you want," then that
really valuable time of learning these debugging skills gets missed, 'cause
you can always pivot and do something else. The most valuable lessons I've
learned about coding -- and the ones which, like you wisely stated, are
applicable elsewhere in life -- had everything to do with needing to work
through a tough computational challenge.

That taught me how to know I don't know something, how to poke at an issue in
such a way as it would reveal something about the system (or my own
understanding), the oh-so-currently-hyped skill called "grit", etc.

Every thinker or scientist I deeply respect has a treasure trove of examples
of being stuck and working through hard and challenging problems even as
little kids. That somehow we think an avenue for a more educated populous
consists of presenting fewer experiences like that to youngsters is beyond me.

~~~
inimino
"populace", not "populous" (an adjective meaning "highly populated").

~~~
ChicagoBoy11
Won't let me edit, but thank you - I had no idea!

------
solatic
> why schools don’t teach systematic debugging. It’s one of the most
> fundamental skills

And herein lies Dan Luu's fundamental misconception: that universities see
themselves as places where students come to learn _skills_ , i.e. as places of
certification producing skilled workers for industry. Most universities see
themselves as academic places of learning for the pursuit of knowledge for
knowledge's sake, which only _incidentally_ graduates people whom industry
_happens_ to find their knowledge at least _somewhat_ useful. If the
university professor never needed to debug, use version control, or write
clean designs in order to succeed in academia - why should he consider it
worthy of being taught? If the university professor never benefitted from
remedial review on his academic path towards becoming a professor, why should
he consider it worth his time? Of course he's going to dismiss the notion to
the tone of "some people just can't hack it in engineering." It's academic
survival bias.

People talk about the STEM pipeline like some kind of demigod figure designed
it from on high specifically with the intent of producing skilled technical
workers, albeit with various flaws related to sexism and skill relevance etc.
Of course, this is a ridiculous way of looking at the STEM pipeline, so it
shouldn't surprise anyone that different actors in the pipeline have contrary
motivations.

~~~
uniclaude
I respectfully disagree with your argument in relation to this article.

Dan Luu is describing a method that would help people achieve a better success
in their exams and classes, he's not even pointing their usefulness in the
workplace. Therefore, your point about him thinking that universities are here
to produce skilled workers is a strawman.

~~~
erikb
His point is that university is here to produce/teach knowledge. Skills should
be learned elsewhere, e.g. in schools prior to that. The university's official
language is also a skill that is very important to the student's success, but
the university is not responsible to teach this language skill. You must have
it to enter university.

~~~
uniclaude
Then I bieleve the argument still stands. Universities would teach knowledge
better if they spent a comparatively tiny amount of time teaching appropriate
skills, as it would get students ready to learn.

The author demonstrated this point by showing how his classes could help
students learn better.

We can then debate about whether having successful students is a positive
thing to have for universities, but Dan Luu clearly seems to think it is.

~~~
erikb
That's a valid additional point. I'd also say that they should at least offer
optional courses with skills. That also applies to language. While
universities don't offer a major in English speaking/writing, many have
opportunities for second language learners to improve their English skills.

------
tallanvor
In school, you're always told to show your work. I'm sure a lot of us here
tended to be among the smartest in your class, at least before university, and
we often thought having to show our work was silly. That's why a lot of us get
tripped up when it comes to the type of debugging the author is talking about
(it certainly still happens to me sometimes).

Showing our work reminds us that solving problems is an iterative work, and
when we get the wrong answer, it lets us (with or without the help of the
teacher) step through and figure out what we did wrong. For teachers and
professors, it probably becomes second nature, and maybe they forget who
explained this to them, or when they realized it themselves.

Even once we're out of school, I think we need to remind ourselves that this
is the same reason we don't write a 1000 line function, rather we break it up
into smaller parts, each designed to solve a specific part of the overall
problem.

Now, what I really wish we had had in university was a CS course on using gdb
and/or WinDbg - not just to understand how to analyze a core/dump file or step
through running code, but also to help drill it into our head what compilers
do to our code, and how processors really work. --It's amazing how often I
have to remind people that debuggers will often lie to you, and you often have
to look into the registers for the real data!

~~~
jnordwick
> debuggers will often lie to you, and you often have to look into the
> registers for the real data

What do you mean by this?

~~~
gambiting
Well I don't know what OP meant, but I work in games programming, and the PS4
debugger will frequently lie to you in visual studio. You hover over a
variable and it's just giving you a completely wrong value, which is correct
if you look directly into memory window or assembly view.

I wouldn't consider this to be a very common use case though, it's a niche
within niche.

~~~
SticksAndBreaks
Its that way in all the niches, which makes it a set of all niches ==>
mainstream thing.

~~~
duncanawoods
Optimised C++ sure but you don't see this issue with C#. If you are using a
high-level language that does not have a reliable debugger, time to change
language.

~~~
ska
One of the things that happens here is the more static and optimized a
compiler output is, the harder it is to do source level debugging. Conversely,
more dynamic, less optimized languages are easier to write and verify
debuggers for. This isn't a strict ordering, of course, but a general trend.
Unfortunately, the very aspect that make some languages easier to debug make
them poor at some of the applications you might want the former for (cf C# and
c++ as you bring up).

Luckily debugging is not merely the act of using a debugger !

------
userbinator
I think the Feynman Method is equally applicable to debugging; I've also done
some teaching before, and seen far too many beginners open the debugger at the
first bug they find and start stepping aimlessly through the code, seemingly
unaware of what their code _should_ be doing. They eventually reach the point
where the program outputs the wrong result, and have no better understanding
of what they did wrong, because they were too focused on what the code _is_
doing to think about what it _should_ be doing. I call it "debugger-induced
tunnel vision".

My advice on this is to, before even thinking about using a debugger, think
carefully about and write down if necessary the conditions and values expected
at certain points in the code. Then, and only then, should you use the
debugger to confirm or deny those hypotheses. In practice, with those I've
taught, guiding them through this procedure, they often realise the source of
the bug before using the debugger.

~~~
romaniv
I completely agree. In fact, I think running a debugger should _never_ be the
first option. My process:

1\. Read the code and think about what it's really doing.

2\. If that leads nowhere, write (more?) unit/integration tests.

3\. Only if the above two fail, run the debugger.

"Contemplating" code has another benefit: since you're looking at the whole
picture rather than jumping line-by-line it develops your intuition about why
things fail.

------
majewsky
When I was half-way through my physics degree a few years back, they adjusted
the curriculum to include a "Programming for Physicists" course [1] that
tought a little C [2] and familiarized students with how computers compute, so
that, most prominently, they would be able to recognize and guard against
floating-point rounding errors.

I served as a TA on that course for the first few years, and after the first
year, I lobbied for a few adjustments. The most important one was to include a
specific assignment on debugging, where instead of asking the student to
implement a new program, an existing program is presented that has both syntax
and semantic errors. Students are expected to turn in a list of all the errors
that they find.

[1] A crash course, actually, but still way better than nothing.

[2] Nowadays they do Python, I hear.

------
lordnacho
I imagine it would be quite hard to come up with good debugging examples for a
class. Anything that has one right answer is going to smell like a made-up
classroom assignment.

The thing that makes debugging hard is multiple hypotheses (or amazingly,
exhausting all hypotheses). Your crash can be caused by errors on many
different abstraction levels, so your debugging process has to be thought
about on many levels. On one level, you have an illegal access via pointer. On
another, you have a user whose information is incomplete.

Once you find a bug it's often hard to trace back exactly what the original
state (including your state of mind) was, because you'll have taken the thing
apart in various ways, added logging, looked at the call stack, memory, etc.
And once you know the issue you shave down the explanation so that all those
tedious steps that didn't lead to the answer seem to vanish.

One thing that got me thinking was this idea that people are expected to fail.
To me, such a process is incredibly wasteful, and itself a failure. Are
engineering students immune to ordinary psychology? If you tell people half of
them will give up, you'll lose a lot of them, even ones who could pass.

You can make a course difficult, but don't tell people they will fail. I was
never confronted with such statements, yet after my first year about 10% of
the engineers had been booted due to failing exams.

His other point seems to be that courses are difficult because they aren't
taught to people with the prerequisites. That should never be the case. Where
I went the prereqs were a very standard set of math courses, and you could
access most non-math courses knowing just those.

~~~
majewsky
> Anything that has one right answer is going to smell like a made-up
> classroom assignment.

If you're doing C (or any other language where that particular problem
exists), it's always a nice exercise to have students write a program (or a
function) that takes the radius of a circle and outputs its volume. Most
students will write:

    
    
      double volume(double radius) {
        return 4 / 3 * M_PI * radius * radius * radius;
      }
    

Can you see the problem? ;)

~~~
the-dude
Circle has no volume

~~~
noxToken
Although I laughed, I'm sure GP meant sphere. That _is_ the correct formula
for volume of a sphere, and a sphere is a circle in 3-space.

~~~
majewsky
Aw snap. Yeah, of course I meant a sphere.

(And technically, it's the other way around. A circle is the 2-dimensional
special case of a (hyper)sphere.)

------
ajarmst
Any school that teaches programming will take a stab at teaching debugging,
although that is often limited to general familiarity with a debugger, say to
the level of stepping through code and inspecting state.

The problem is that debugging is _hard_ , and will tend to very quickly
manifest any flaws in a novice's understanding. When I teach it, I describe it
as a manifestation of the scientific method: observe the phenomenon (my
program isn't doing what I expect), hypothesis (it might be this), experiment
(if that's the problem then doing this should result in...). Repeat ad
frustratum.

Unfortunately, doing that effectively required some pre-requisites: (1) An
accurate mental model of how the program _should_ behave, with sufficient
detail to hypothesize about why it's not behaving that way, (2) Available
tools and instrumentation that allow you to inspect a running program (I'm old
enough to remember debugging by adding commands to print state to the
console), (3) sufficient experience and sophisticated understanding of the
system to be able to make valid hypotheses and design tests.

Only the second item easily lends itself to the classroom, and the third item
is critical: After I help a student identify and isolate a bug, they often ask
me how I knew what to try. The answer is, almost always, that _I 've seen that
before_. Hell, there used to be a type of memory fault in Borland C++ that I
could diagnose from across the room just by the icon and size of the error
dialog. (You get a lot of experience seeing error messages by teaching
Freshman programming).

So, short answer, the reason we don't do a good job teaching debugging to
novices is at least partly because they're not ready to learn it yet.

~~~
abhirag
I absolutely agree with the pre-requisites --

"(1) An accurate mental model of how the program should behave, with
sufficient detail to hypothesize about why it's not behaving that way" \--
While working as a firmware engineer, I once got a bug from a customer, he
reported that they were in Argentina and the device with the firmware would
lose an hour in the time displayed every time they had a power loss and that
the problem goes away when they put the time-zone to Brazil, this much was
enough to know that the problem was with the day light saving time part of
code. Some engineer hypothesized that problem might be with the NTP server but
his hypothesis was wrong because NTP server was dealing in UTC.

"(2) Available tools and instrumentation that allow you to inspect a running
program (I'm old enough to remember debugging by adding commands to print
state to the console)" \-- I dealt with code which installs the firmware,
frequent power cycles made keeping a debugger attached an exercise in futility
so I just continuously logged the top two frames of the stack by using a
system call. Crude way to trace the control flow but helped me in
understanding the installation process a lot.

"(3) sufficient experience and sophisticated understanding of the system to be
able to make valid hypotheses and design tests." \-- This was even more
important while dealing with firmware hangs, dealing with hangs made dealing
with crashes look easy. Crashes were the messy criminals leaving a lot of
clues behind. Hangs are the type of criminals who would have to be caught
while committing the crime.

I would also like to add one more --

"(4) When debuggers fail you, git-bisect is your only true friend." \-- I once
was dealing with a memory corruption bug, in a piece of memory which was
shared by two systems, the number of processes with access to that piece of
memory was bonkers. I decided to brute-force my way out, it worked in the last
release, it stopped working this release, I just kept doing a git-bisect
between clean and dirty states and found the code which caused the bug. This
way was definitely not the clever way to do it, but brute-force is sometimes
the only option left.

------
rosstex
At UC Berkeley, we are planning a lab devoted to practical debugging for next
year's Data Structures course. Your ideas/suggestions are appreciated!

~~~
koja86
Please make your lectures public.

~~~
rosstex
:(

------
Klockan
> those who were underperforming weren’t struggling with the fundamental
> concepts in the class, but with algebra: the problems were caused by not
> having an intuitive understanding of, for example, the difference between
> f(x+a) and f(x)+a.

Those taking that class have spent years trying to learn algebra and still
don't get it so we are already trying this.

> I’m no great teacher, but I was able to get all but one of the office hour
> regulars up to speed over the course of the semester.

Most likely they just memorized the new algebra rules as well. There are lots
of studies showing how hard it is to teach students anything tangible, instead
most will just try to memorize everything you say.

See for example: [https://www.amazon.com/Academically-Adrift-Limited-
Learning-...](https://www.amazon.com/Academically-Adrift-Limited-Learning-
Campuses/dp/0226028569)

~~~
suls
The linked book was published in 2011 -- lacking the US context, has the
situation changed in the past 6 years?

------
gregmac
This can really be extended to basic troubleshooting skills, and goes beyond
software development -- beyond technology, even.

Troubleshooting is really just a special application of general 'problem
solving', which _is_ something schools aim to teach. I'm not sure why
troubleshooting skills are not taught, especially something like "divide and
conquer" [1]. Even in very complex systems, so long as you have the right
access/visibility/logging to see what's going on at various places, it usually
doesn't take very long to isolate a problem down to a particular component.

[1] [https://en.wikipedia.org/wiki/Troubleshooting#Half-
splitting](https://en.wikipedia.org/wiki/Troubleshooting#Half-splitting)

~~~
Pamar
I wanted to write something similar, so I just upvoted you and piggybacked
here. "Debugging" is really a subset of "Problem Solving". My grandfather had
(by today's standards) very poor schooling, but he taught me some PHYSICAL
WORLD DEBUGGING techniques which proved useful later in life. Just one simple
example (I suppose this would be "Tracing" in IT) - once he was working on a
cabinet that had somehow warped and wouldn't close properly. His solution: he
cleaned the door and the frame, dipped his finger in oil and smeared it along
the side of the door that would touch the frame. Then closed the door and
opened it again - the point were some trace of oil was visible on the frame
was the one that needed to be pared down to allow the door to close.

He also used intuitively divide&conquer to find faults or leaks in wirings and
pipes and so on.

It is really something that should get more study and practice outside of IT
or science, and I am sure that mechanics and other craftsmen have their own
set of algorithms that can be used in various situations.

~~~
empath75
Yep, my dad was a mechanic when he was younger and worked on cars for fun, and
he taught me troubleshooting before we even had a computer.

------
kabdib
Beyond a few simple techniques (printing values, writing and examining logs,
practicing the scientific method) and defensive strategies (asserts, writing
good tests, parameter checking, etc.) debugging gets environment-specific
pretty quickly. Gronking through a bug in an embedded system is way different
from figuring out why your rack of servers has gone dark, though the root
cause might be the same.

I've found the best way to learn debugging is to should-surf someone who is
good at debugging. For instance, I'd spent six months at Apple before I
watched a resident wizard for an hour in the low-level debugger, and what I
learned in that hour improved my skills dramatically. Repeat for two other
companies: Encounter a tough problem (for you), find a wizard to help out, and
pay attention.

I think the sentiment in schools is that sufficiently challenging coursework
will force you to learn debugging techniques on your own, as a natural outcome
of you writing code :-)

------
sametmax
They don't teach you unit test either. Or how to read a doc efficiently. Or
how to make a technical choice. Or how to conduct a meeting. Or how to direct
a project.

At best they'll talk about best practice and will give you an exercice that
implies you should use one of those skills.

The amount of useful stuff that are not taugh in school is enormous.

------
fspacef
Profusely agree with the author. As someone who switched into CS from the
humanities, one of the biggest challenges for me was less about syntax and
more about figuring out the errors in my logic. For some reason though the
former seems to get more focus by professors.

 _" We excitedly explained our newly discovered technique to those around us,
walking them through a couple steps. No one had trouble; not even people who’d
struggled with every previous assignment. Within an hour, the group of folks
within earshot of us had finished, and we went home."_

This is great, I wish more people at my school did this, learning should be
collaborative (as long as you don't copy paste code). There seems to be an
obsession with secrecy and not sharing any ideas on a project as though there
is only one way to solve a Java homework problem.

~~~
wahern

      as long as you don't copy paste code
    

That's the million dollar question: how do you know whether a classmate is
being earnest or just copying you? Especially in highly competitive
environments, cheaters are extremely adept at leveraging your work without
substantially contributing anything back.

The way it works in law school is that students (at least the social ones)
break up into study groups early on. They may or may not be friends outside
the study group. The key is that the study groups span multiple classes, and
sometimes last the entire three years. In other words, it's an iterated game
that discourages cheating from the outset. Being ostracized from a group is a
huge liability, especially if you're a cheater.

This strategy doesn't work as well in undergraduate programs. There's too much
churn and variability (in the student population, in their intelligence, in
the number of subject classes, in the number of professors teaching the same
subject), which means it's easier for cheaters to come and go without having
to suffer repercussions.

I'm not a collaborator. To learn (and retain) I need to work through things
alone, especially on difficult problems. Talking with other people about a
problem is usually a distraction, and almost guarantees I won't internalize
and retain the material. The above descriptions of group dynamics is my
outsider's perspective.

~~~
averagewall
That sounds like awful pressure to not rock the boat of your study group but
maybe it's suitable for lawyers.

Cheating was solved in an engineering class I took that had us write a program
in our own time, but the assessment was a test where we were asked to modify
it and produce the correct output. If you had copied the code without
understanding it, you wouldn't be able to pass the test.

~~~
nradov
A rigorous honor code also solves the cheating problem, as long as the
administration actually enforces it by expelling violators.

~~~
RightMillennial
The problem is actually getting administration to enforce their zero tolerance
policies: expel cheaters despite the fact that they pay a hefty tuition.

------
galdosdi
> Why do we leave material out of classes and then fail students who can’t
> figure out that material for themselves? Why do we make the first couple
> years of an engineering major some kind of hazing ritual, instead of simply
> teaching people what they need to know to be good engineers?

Yeah, this is horrible and irresponsible on the university and professors'
part. But that's the way it seems to be in most large US universities
(anecdotally based on talking to friends in grad schools).

However, decent small liberal arts colleges often do exactly what you
prescribe, they correctly try to teach it to everyone and generally succeed.
Big box schools are just exploiting undergrads as cash cows, don't attend them
or send your children to them.

------
vishvananda
Debugging is a valuable skill that some of us were lucky enough to pick up by
chance. A friend recommended an excellent book that very nicely explains the
process: "Debugging: The 9 Indispensable Rules for Finding Even the Most
Elusive Software and Hardware Problems"[1]. I found myself nodding along while
reading. I think this would have been a hugely valuable primer if I had been
exposed to it before I figured out how to do it on my own.

[1]:
[https://www.amazon.com/dp/B00PDDKQV2](https://www.amazon.com/dp/B00PDDKQV2)

------
2sk21
I have always felt that I was better at debugging than programming :-) I have
often been able to debug really complex problems but afterwards I am not able
to retrace the steps that I took to come up with the diagnosis - so I'm not
sure if this skill can be taught.

~~~
camperman
I KNOW I'm better at debugging than at programming. My own working code is
terribly simple and straightforward but I've fixed kernel sound drivers, buggy
firmwares and complex interrupt-driven music players. Perhaps I find it easier
to construct a mental model when presented with a finished system rather than
when starting from scratch.

~~~
nissimk
Neal Stephenson writes about this in my favorite "the diamond age," he calls
it honer and forger. The type of engineer that is better at improving an
existing thing vs. creating something new.

There's a need for all types.

~~~
camperman
Aaaah, this makes so much sense. Thanks for the reminder. Here's the para in
question:

"Hackworth was a forger, Dr. X was a honer. The distinction was at least as
old as the digital computer. Forgers created a new technology and then forged
on to the next project, having explored only the outlines of its potential.
Honers got less respect because they appeared to sit still technologically,
playing around with systems that were no longer start, hacking them for all
they were worth, getting them to do things the forgers had never envisioned."

------
milansuk
When I was in school I showed my algorithm(on paper) to my teacher and He
said: "It's wrong". I strongly said: "It works!". He froze for few seconds and
than said: "Use these data for inputs" and I immediately saw the bug. Of
course the entire class laughed.

I know that The story isn't about debugging, but sometimes showing "right"
inputs can be very efficient way how to explain the bug to other person.

~~~
iamacynic
"froze" implied he was scared. try "paused" or "ruminated" instead.

~~~
twoquestions
I donno, when I see code that works and I don't know why I get plenty scared.

------
ZeroGravitas
One of my clearest and earliest memories of programming as a child is of
having a working program, making a few changes, and suddenly nothing worked,
being totally lost in the woods as I randomly tried fixing stuff and got
absolutely nowhere. I feel like it's had a big impact on my approach to
programming ever since, trying to break things down into manageable pieces
rather than one big ball of mud that's fragile to errors.

------
whack
Fantastic essay, and I think the same teaching could be applied to so many
other skills needed to succeed as well. When people talk about academia as an
ivory tower, this is exactly what they mean. Academia seems to be utterly
focused on _" cool ideas"_ and _" intellectual exploration"_, and they really
short-change the nitty-gritty skills that may not be as intellectually
stimulating, but are still absolutely needed to get stuff done.

To give another example, anyone who's working in a programming context can
boost their productivity by knowing how to set up their aliases, learning the
basics of unix tools such as grep, and mastering a good text-editor/IDE such
as vim/emacs/intellij. And yet, after 4 years in college, I didn't know a
single thing about any of the above, and slowly picked up bits and pieces
randomly over the course of my career. If a professor could have taught the
above in a intro-to-engineering course, it would have saved us countless hours
and allowed us to hit the ground running.

------
spydum
Interesting, just finished reading John Allspaws 2015 paper from some
debugging/problem solving at Etsy:
[http://lup.lub.lu.se/luur/download?func=downloadFile&recordO...](http://lup.lub.lu.se/luur/download?func=downloadFile&recordOId=8084520&fileOId=8084521)
(really slow.. sorry Sweden!)

While it focuses on time tradeoffs and such during resolving outages, one of
the major themes is that engineers/developers tend to use heuristics and past
experiences to drive problem solving. I think as developers we tend to do the
same, we look for common patterns for types of problems we've encountered. The
debugger is just a representation of log analysis.

So how do you teach those experiences? I think a lab-based approach with
examples is probably the right course.

Sun Microsystems used to have a Fault Analysis class they taught for Solaris..
It was essentially just a lab of 50 broken systems/scenarios that you had to
diagnose and fix. I think more of that sort of thing earlier on would be
helpful.

------
csours
I haven't seen anyone mention the following yet, and it's INCREDIBLY
important!

When something is not working right and you have to debug it, you need to re-
evaluate your abstractions and drop down a level in your technology stack.

In Dan's case, he had to look at, and think about how the logic gates worked.

In a more modern case, when your REST calls aren't working right, you may have
to debug HTTPS stuff.

If your HTTPS stuff isn't working you may have to look at key negotiation and
exchange, etc etc.

If your Entity Framework isn't working, you may have to (horrors!) look at
what's going on with the database.

If the database isn't working, you may have to (gasp!) look at the hardware
it's running on.

Too often people look at surrounding code or state, and do not verify the
abstractions of lower-level code or hardware. Those things have "always
worked" \- it's never the compiler's fault, until it is (or a bad assumption
of how the compiler works)

I've seen people here talk about iterating, which is fine and good for many
problems. For many debugging problems iterating will take you until the heat
death of the universe to solve.

I don't really think "fullstack" devs are always the best solution, or a
scale-able approach to development; but a fullstack dev with a debugging
background is hard to beat when you have problems.

Edit: To put it another way: If your technology isn't working, you have to
examine the engineering under it. If the engineering isn't working, you have
to examine the science. If the science isn't working, you have bad
assumptions, or you've found new science! (you probably have bad assumptions)

~~~
Terr_
IMO debugging is actually the most practical _definition_ of the buzzword-y
"full stack" developer.

> There's no authoritative definition, but I see it as "I can trace a visual
> problem down through CSS styles, debug the JavaScript code that sets them,
> intercept the AJAX call with the problem-data, debug the backend language
> that is run, diagnose the SQL that finds the malformed row... And apply a
> fix on any of those levels where it is needed."

> You might not like the code you wade through, but...

------
paulsutter
"90% of programming is debugging. The other 10% is writing bugs" \- Bram Cohen

------
golergka
> the problems were caused by not having an intuitive understanding of, for
> example, the difference between f(x+a) and f(x)+a

Does the author really advocate that the instructor of advanced college course
needs to spend his time on explaining the difference between f(x+a) and f(x)+a
to his students?

I don't have any idea how someone with such an understanding of algebra could
even get into a college even if he wanted to learn humanities. If a college
student doesn't get it, it's the college mission to fail him as fast and
possible, not to spend time trying teach him something middle school should
have.

~~~
empath75
What kind of middle school did you go to????

~~~
golergka
I have to admit, I changed several math-oriented schools - but trigonometry is
supposed to be standard middle school subject, no? If you don't understand the
difference between sin(x) + y and sin(x + y), I can't imagine you can pass a
simplest high school entrance exam.

But I guess it depends on the country. US math education, from what I hear,
never ceases to amaze me - the contrast between the abysmal level of your
schools and the best CS departments in the world is just astonishing.

------
bnolsen
People abuse debuggers (I see this esp with windows programmers). It's better
to write test drivers and simulations to force the breakage. If this is how
debugging is done you'll enhance your test drivers and simulations. Just
running interactive debuggers on a main application you lose much of this.
Honestl I spend less than 1% of my time in a debugger and all of that time as
post mortem crash analysis. I also work with heavily threaded code where
runing a debugger tends to make the code run without exhibiting the bug.

~~~
bpicolo
> It's better to write test drivers and simulations to force the breakage.

Those aren't mutually exclusive. It's much easier to write a test for an issue
if you know what the issue is.

------
galdosdi
The more egregious thing schools don't teach is working in large existing
codebases, i.e., the skill of reading and figuring out code.

Instead they focus on /writing/ code. In the process of writing code, at least
some incidental debugging experience is gained (this article is actually an
example of that -- the debugging wasn't formally taught, but the assignment
clearly forced the author to learn it a bit), but almost no /reading/ code
experience. It took me a while in industry to make up for this deficit.

------
microtherion
Some schools are not just _indifferent_ to teaching debugging, they are
actively _hostile_ to it, arguing that teaching debugging interferes with the
"proper" approach of programming through correctness proofs.

This pernicious attitude, at least in my alma mater, could be traced back to
E.W. Dijkstra, e.g.

[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD273.html)
[http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EW...](http://www.cs.utexas.edu/users/EWD/transcriptions/EWD03xx/EWD303.html)

And he may not have been entirely wrong; it's not uncommon to see people spend
insufficient time on reasoning about the correctness of their code from first
principle, and jump directly into testing/debugging.

On the other hand, using correctness proofs as the sole and sufficient means
of writing code is just not a workable approach for most non-trivial problems.

------
altcognito
We should also probably start teaching how to effectively unit test.

------
JoachimS
There are a number of ways one could teach debugging. There are for example a
number of CTF challenges with reversing that can be used to train persons in
using debuggers to find and fix issues. The good thing with CTF challenges is
that they have clear goals (find the flag) so you know when you are done.

Another way which we have used is to engage students in open source projects.
Look at bug trackers to find a few issues and then try to solve them. This
also teaches students a lot of other things like: \- How to work in existing
projects \- How to ignore large parts of a code base to focus on a given issue
\- How to write test cases \- How to create patches that match project code
style \- How to communicate and participate in projects.

------
wolfgke
The problem with teaching debugging that I see is that I am not aware of any
systematic course for debugging available with suitable exercises, systematic
theory etc.

If there were, I can believe some universities might at least be interested in
offering an optional course.

------
whazor
Debugging is a composition of simulating software in your mind, verifying what
you wrote down, and observing what the computer does. The reason why I think
that there is no course on debugging, is because it is equivalent to learning
how a computer works.

------
smarks
I was once on a project with a tech lead who was really good at finding bugs
by inspection. In the "How to Reproduce" section of bugs he'd file, he'd
always simply write "Eyeball the code."

------
bertlequant
All of this greatly depends on the teacher. While I have never specifically
seen a debugging class offered at university, some professors do a good/decent
job ensuring that you have debugged/tested your code.

------
brightball
What schools DON'T teach debugging? Simple trace statements were one of the
first things we learned in 101.

Maybe I was just lucky to have a good teacher. I still remember him not liking
my solution to a problem when I was extremely proud of how smart I'd made an
object, so that it reacted properly based on whatever was passed in. Instead
of arguing with me he offered an extra credit assignment to take all of the
logic out of the object and see if I could get it working that way...I did it
and realized how much simpler his way was.

Hindsight makes you appreciate the patience that took.

~~~
erikb
It's the first time I hear that anybody got taught debugging, honestly.

~~~
brightball
That's a little bit horrifying.

------
nemoniac
Can someone point to an online resource that teaches debugging?

------
cm2187
My first encounter with programming for engineers was in college with already
antiquated machines running Unix (in 2001-2002), and with a professor
requiring us to use some basic text editor and debugging by printf. It put me
off from programming for several years before I came back to it with higher
level languages (VBA then .net) and rich IDE (the excellent Visual Studio).

The IDE (and debugging experience) is as important if not more than the
language in my opinion.

------
rmetzler
I wonder why whenever such a discussion pops up, almost nobody mentions the
stacktrace. I've seen so many CS students, who fail at reading that first
representation of a problem, I really wonder why that is.

Also I like debugging via print much better than with a debugger, because it's
easier for me to spot the problem. Breakpoints are great though.

~~~
problems
That's not quite the sort or debugging being discussed here though - they're
talking general theory of how to think through a problem to locate the issue,
which applies to more things than just software including computer hardware,
cars, circuit boards, just about any large system really - you do common
things like replacing or disabling parts of the system, probing values at
certain points, logging values, etc. For the most part, these things have a
lot in common, but few people know how to approach such problems.

It's interesting that I see them saying "the more talented the engineer, the
more likely they are to hit a debugging wall outside of school". I was only
ever a good engineer in school because I was able to debug. You don't
understand something til you tear it apart.

------
esmi
I went to university when few people had their own PC. It's true there was no
catalog class in debugging but we all got very good instruction and learned
many techniques in the lab, especially from the lab TAs. I would suggest the
author seek out where the comp sci students congregate these days and talk
through issues there.

------
PaulHoule
Back when I was in college I had a bit of reputation as a "hacker" and one of
my friends wanted my help at stealing somebody else's homework for CS101.

Turned out the program we stole didn't quite work and the process of debugging
it was at least as educational as starting from scratch.

------
tmat
for the same reason kids come out of college woefully prepared to build
software in the real world.

college is an absolutely horrible environment to learn programming.

programming should have a journeyman apprentice program like electricians.

I learned more from a mentor than I ever did in school.. it honestly was a
waste of money.

------
Radle
Is this normal? That's pretty bad considering how much studying costs in
america.

------
mrcactu5
I nearly failed out of intro Computer Science class since I didn't allow for
90% debugging time. Also I wish I could save some of my errors since they are
coming from my own fingers -- they are the most instructive.

------
mathattack
When asked "How do you debug programs?" my Programming Languages professor
responded, "I don't. I prove every line correct before I write it."

~~~
wslh
This can be done in the context of algorithms but not in professional
programming in general. Software has dependencies with zillions of components.
If you want to formal proof everything, the software field would move like a
turtle, with wisdom but very slow.

~~~
mathattack
I hear you. The general reaction of the class was, "Thank you for nothing."

The real world is different.

------
failrate
Other important skills not addressed in (my) schools: source control, IDEs,
practical (not theoretical) encapsulation, design patterns

------
thomk
Schools should teach Project Management and Quality Assurance too. Why they
have not adapted is beyond me.

------
gumby
I thought the whole point of lab classes (in contrasted to lecture classes)
was to learn debugging skills.

------
lr4444lr
Rite of Passage, man, rite of passage. (Not that I endorse that.)

------
pryelluw
Because a lot of them hardly teach programming as it is.

------
partycoder
Well, not only debugging but also performance profiling.

~~~
livarot
Debugging is much more important though.

~~~
partycoder
If you had to chose between both, sure.

But I think there might be some time to at least walk students through the
basics of profiling, it can be very valuable to have some exposure.

Then when it comes to memory management, there's a fine line between debugging
and profiling.

I was playing with left leaning red-black binary trees yesterday as a
refresher and got a memory corruption due to a bug. With valgrind (a tool I
generally use to catch memory leaks) I caught it immediately, very helpful
tool.

------
yummy
TL;DR: "Writing down the solution" without "thinking real hard" is a much
better method

~~~
syockit
Yeah. And then iterate for better solution. Sometimes, after a long time, the
bugs bite back at you real hard. But at least you didn't miss the deadline.

