
Why Don't Schools Teach Debugging? - danso
http://danluu.com/teach-debugging/
======
dmlorenzetti
I did an electrical engineering course. Especially with hardware ("welcome to
tweak week"), there was a real sink or swim approach. I ended up feeling like
it had to do with testability. It's easy to grade a test if you just look for
right answers, and mark everything else off. It's easy to grade labs if you
just look for the circuit tracking the input frequency. Grading either based
on some assessment of how well the student understands what's actually
happening is much, much harder.

My older brother and I went through the same classes and labs together. He
brought to the table 15 years of experience playing around with electronics,
so when we took labs, he had a clear sense of how to debug hardware.

He would wave his hand over some part of the circuit, and make gnomic
pronouncements like, "When the input goes over about 5 volts, this part goes
apeshit and starts firing back at it." Then he'd swap out a cap or a resistor,
and everything would start working. I just went along for the ride.

I had decent math skills, so I did all right in the program. But I never
learned that intuitive, heuristic, holistic way of grokking circuits like my
brother did. Nor could I ever see that the school had any way to reward people
like him, who "got" things at a deep level.

My sense was always that his approach didn't test well. If you test people for
calculating the right voltage, you end up rewarding people who "plug & chug"
quickly, even if they don't know what the voltage means, or why it would make
some cluster of components go apeshit when it goes over about five volts.

~~~
gonnakillme
Does anyone have advice for learning this kind of "intuitive, heuristic,
holistic way of grokking circuits"?

~~~
drakaal
Buy the radio shack 150 in 1 electronics lab. Complete all 150 projects.

In between play with Lego Technics.

Buy all the parts and a breadboard, do 10 projects using solder to make the
result permanent.

~~~
ldng
Do radio shack still edit it ? It does not look like it still does

Sparkfun should propose something similar then :)

~~~
drakaal
This is really close.
[http://www.amazon.com/gp/product/B00005K2SY?tag=griffindigit...](http://www.amazon.com/gp/product/B00005K2SY?tag=griffindigita-20)

------
tsomctl
It's more like they don't teach general diagnosing/understanding why things
don't work. I consider the skills needed to debug a computer program, to
diagnose a hardware problem, to fix a car, and to fix commercial coffee
brewers to be almost identical (and I have done all of these things, a lot).
In fixing a computer, you have a mental checklist of all of the things that
could contribute to it (failing hard drive, bad termination, failing memory,
loose cable). In fixing an engine, you think of what the problem is (rough
idle), what can cause it (plugged fuel injectors, vacuum leak, exhaust leak),
and slowly determine which one is the culprit (probably not the fuel system,
goes just fine 75 down the freeway. Oh, that vacuum line is disintegrating.
Good job, Toyota).

They all follow a similar pattern of identifying what the problem is, what
physical manifestations can actually cause that problem, and then eliminating
them one by one. This involves looking at the whole picture to narrow it down.
This is not something I learned in school, I just figured it out growing up.
I've found friends that don't necessarily know anything about computers, but
are mechanically inclined, think similarly to how I do. I do have an innate
desire to understand how everything works, and this definitely helps me
understand what can physically cause the problem. That said, I did just take
an Intro to Math Thought, for my math degree, and while it didn't really teach
problem solving as I described above, it dramatically improved the way I
thought about proving things rigorously.

------
blah32497
I never knew this was a problem in EE, but I know for a fact it's a _huge_
issue in CS.

They don't want to teach any "tools" b/c CS professors find teaching people
how to be good developers as beneath them. They honest to god think CS is an
actually hard science on par with math and physics. You can sum up their
attitude with: "It's not an associates degree goddamnit!" (even though it
should be)

Another source of reluctance is that by the time we'd graduate it will be sort
of outdated. I remember we learned subversion and Apache Ant. Everyone now
uses git and I'm not even sure if anyone uses Ant

95% of students used std::cout for debugging and 95% of students never set up
an IDE.

If I had spent a couple weekend properly learning to use Visual Studio, all of
my programming assignment for those 4 long years would have been 10x easier.

~~~
mandor
CS prof. here.

We don't want to teach "tools" (e.g. IDE) because they are always changing.
There is no point is knowing how to set up an IDE when the IDE will have a
different GUI before the student graduates. We teach"unix tools" a bit more
because they did not change much during the last decades.

My goal is to teach "concepts" (which is hard) and use tools as examples of
these concepts. Dealing with the specifics of a particular IDE or tool is
pointless. We are trying to give students general skills that will be useful
for the whole life of the students, and not skills that the industry needs
this year.

That said, I do my best to teach debugging (mainly using gdb and valgrind).
The real issue with debugging is that it relies on a lot of experience, which
students do not have, by definition.

~~~
RogerL
We aren't asking for vocational training, but for teachers that teach how to
think, how to design, how to run experiments, and so on. So many schools (even
the 'top' ones) turn out people that cannot do this, and I find it appalling.
These things are foundational, they are not vocational. Unfortunately that
does in fact meaning having to learn some tools which will become obsolete. So
what? I did EE labs, and while resistors are the same none of the digital
components really are. I learned how to design NPN junctions, which are now
largely replaced with CMOS, but so what? It was the experience that mattered.
You can't hand wave that away ('you' is global, not you mandor), teach the
math of junction biases, and expect that anyone will be able to do anything
with it once they graduate. But so many CS programs try to do exactly that. I
walked out of undergrad knowing how to do recurrence relations, prove the
complexity of graph algorithms, and so on, but with almost no clue about how
to actually design an algorithm, how to structure and design software, and so
on. It took grad school and some good teaching professors, to change that.

I've rewritten this three times or so - it is hard to address without sounding
like I'm attacking you, which I am not. But I am truly dismayed about the
skill sets of people graduating from CS programs. I'm not asking for Java
vocational training, but for a recognition that 99% of the graduates will be
asked to function as "engineers", not "scientists". The people that come out
and that function well seem to do so despite the schooling, not because of it.

Incidentally, the best EE teacher, or any teacher, that I ever had, had worked
in industry for many years, decided he wanted to teach, and went into
teaching. His classes were practical and pragmatic. Oh, you were failing if
you didn't master the math and theory behind the material, but he taught you
how to design, how to think, how to manipulate all of this book learned stuff
to make real things that worked. We had to cost out our projects, write design
reports, and so on. Extremely hard courses, but absolutely fantastic, because
of, not despite, the focus on what might be called 'pointless' things (who
cares what the cost of a transistor was in 1986, after all?!)

Unfortunately, you cannot gain experience, and develop the process, without
using tools. It needs to be part of the education. Just look at the post by
the poor person you are responding to. Think of how much better his entire
education would have been if in some freshman level lab he had been taught
some of these basics. I shudder to think how much he probably spent for that
education vs what he got.

------
alexhutcheson
It's certainly not exhaustive, but Andreas Zeller's Udacity course[1] has
helped me bring a more systematic, methodical approach to my debugging
sessions. In addition, his focus on using using tools to assist our debugging
effort has encouraged me to automate a lot of what I would previously have
done manually. I'll admit my first instinct is still to throw in a couple of
printf statements and see what they say, but for harder problems I know have a
richer set of tools to work with.

[1]
[https://www.udacity.com/course/cs259](https://www.udacity.com/course/cs259)

~~~
vdm
[http://www.whyprogramsfail.com/](http://www.whyprogramsfail.com/)

------
scott_s
_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._

The first part of the sentence is in direct contradiction to the second part.
If you did that, it means you had patience, were willing to explain, re-
explain, and find alternative ways to explain. And you _cared_.

~~~
Spellman
So much truth here. Especially the fact that you cared.

As someone who had his share of poor TAs and was a TA, caring is what sets
apart the good teachers from the poor ones. Taking the time to sit and figure
out the fundamental misunderstanding and then a good way around it is
essential. It may look obvious to you, but the other person is obviously lost.
The only way to solve that isn't by special power or teaching acumen, but
taking time to figure out the core problem.

Aptly, it often involves debugging the person! Figure out where the chain of
thought broke down!

~~~
scott_s
Yes, very much. It requires a deep understanding of the material, empathy, and
abstract thinking.

You need a deep understanding of the material, obviously. You need to have a
model of the correct thing in your head. The empathy bit comes in from first
caring, but also being able to quiz the student's understanding so you can
start to understand what the (incorrect) model is in their head.

Then you need to figure out how to build a bridge between their model, and the
correct one. And you may need to build multiple bridges if the first one
doesn't take.

------
brudgers
The author mentions the answer in the first paragraph:

    
    
        ECE 352 was the weedout class that would be responsible 
        for much of the damage.
    

Weed out courses are common in undergraduate education. In some disciplines
the logic is plausible because the resources available for upper division
undergraduates are limited and vast numbers of Freshmen choose the track. The
first year biology sequence is a good example.

The problem is that weed out classes substitute the easier task of deciding
who is prepared for the harder task of preparing students. The author's
success in the class was primarily due to the skills and knowledge they
brought to the first lecture: relative success in the class was not a result
of what was taught but of what was not taught. The "difficult" final still
only required a few hours coding and not developing the habit of coding every
day for several hours.

In my field, architecture, structures is the notorious weed out class at the
undergraduate level, and truss design is the the rock which dumps all but an
arbitrary few into the sea. Architects don't design trusses in contemporary
practice. Hell, outside engineers employed by fabricators structural engineers
working on buildings rarely design trusses (mostly they specify their
structural requirements).

But my structures course was different. I studied architecture in grad school.
Grad schools weed out during admissions and afterward their goal is largely to
prove they made the correct decision. Having been in the industry before
schooling. I could see that my structures course taught the important elements
for practising and skipped the difficult for the sake of difficulty.

Interestingly, participating in Coursera classes I have seen that the more
accomplished teachers tend to focus more on what is important and less on how
hard the class should be. When the instructor wrote _the_ book, maybe they
know that the ideas are hard enough.

~~~
thedufer
> The problem is that weed out classes substitute the easier task of deciding
> who is prepared for the harder task of preparing students.

I don't think this is the intent, at least in some disciplines. For example, I
minored in math and went through the weedout class. It wasn't intentionally
difficult (for some it wasn't even difficult). It weeded people out because it
was the first class where you actually learn what math is - proofs, mostly.
The people who thought it was going to just be algebra/calculus backed out.

I think maybe an important point is that almost no one fails the course - it
was structured and taught such that anyone who cared could get through it.
People backed out because it wasn't what they thought it was, not because it
was too hard.

~~~
brudgers
The difference is that in the math class, what sent people away was not a lack
of success but a lack of interest. The people who remained at least found the
idea of performing proofs better than a sharp stick in the eyey. In the
author's class a person could be interested and passionate about coding and
not succeed and a person who felt that a few hours solving a homework was a
lot of time spent coding could.

~~~
thedufer
Right, I get that. My point was that there is a legitimate way to weed people
out of a major, and that lumping all weedout classes together as evil isn't
really fair.

------
Figs
I read Agans's _Debugging: The 9 Indispensable Rules for Finding Even the Most
Elusive Software and Hardware Problems_ back when I was in high school and
still pretty new to programming. I learned a lot from it, and still recommend
it.

When I was in college the administrators were redesigning the CS curriculum
(and are probably still fiddling with it). One of the newer classes they had
come up with was a mandatory lab course on debugging.

Sure enough, they had everyone read Agans and emphasized thinking of debugging
as an application of the Scientific Method. There were also constructed
debugging exercises to solve too, but given how hard it is to _deliberately_
craft good bugs that are nevertheless still predictably solvable by beginners
within the time frame of a lab session, I think most of the value that people
got out of the course was from reading the book.

~~~
evanj
I second this recommendation. Its the best description I've found of how to
systematically approach debugging. I read it after I already had lots of
industry experience, but still found it useful because it provides a "formal"
description for what is usually an ad-hoc process. Its a useful way to think
about things.

------
xradionut
It's not debugging as much as what us old timers call troubleshooting. At the
university I had an insane advantage over those folks that had never seen a
Simpson multimeter nor soldered a component nor seen a schematic. I had spent
my teenage years building radios and computers followed by formal training in
the military. And the Navy taught us how to troubleshoot large systems down to
the component level. So college was mostly easy and extra beer money was
earned fixing other students electronic devices and tutoring.

------
MaxScheiber
The short answer is because they're supposed to figure it out themselves.

I've been on the teaching staff of CIS 120 and CIS 121 at Penn for five
semesters now (the second and third classes in the intro computer science
series). Both have units on debugging, both in Eclipse and independently of an
IDE. We teach students proper testing fundamentals, how to use the debugger,
and how bottom-up design can make debugging much simpler.

However, it's up to the students to actually use these tools and techniques to
figure out why they're so much more effective than print statements. (After
all, could you imagine taking French while never having to speak or listen?
Piano while never touching an instrument? Same principle here.) Some students
will learn to use these tools quickly, but others can still logic through
these courses.

However, everyone eventually learns. Take CIS 380, our operating systems
class. The final project involves building a simulation OS with kernel,
scheduler, file system, shell, etc. Pretty much all system calls aside from
read, write, malloc, and free are written from scratch. Even for the hotshots
that didn't need to learn how to debug, they eventually learn to use gdb,
because you simply can't logic your way through several thousand lines of C,
even if you did write them all yourself.

Any computer science or engineering curriculum that doesn't teach debugging
fundamentals does students a disservice. However, we can't directly force
students to practice these skills. It's up to them to try applying these
techniques.

~~~
lstamour
I agree. Though writing my assignments for a C course was made so much easier
thanks to Xcode and the ability to quickly view what's in memory at a
breakpoint. Sadly, the course never mentioned debuggers -- likely as a way to
weed out students. I suspect this has changed since, but it's up to the prof,
so who knows. Part of it is that few profs understand the practical reasons to
favour some tools over others -- if you don't write the code day in and day
out, you won't know which tools to recommend when. I think maybe there's room
for a "practice of programming" course on methodology, tools and open source
licensing.

------
obeattie
This is by no means isolated to engineering or mathematics either. Nearly all
students, especially in higher education, will have gaps in their
understanding of topics they are expected to just know. The classroom simply
isn't able to personalise learning to each student in the way that's needed.
The only thing that really can help here the is clever application of
technology.

This is part of the problem that I'm working to solve with my startup Ellumia.
Some others are making great strides in areas like language learning, but
there's still lots to be tackled. We're building a mobile platform that blends
bite-sized content with a highly personalised, social experience – something
that would be immensely helpful to the students mentioned in this post. If
you're interested in innovative learning methods, please check us out:
[http://www.ellumia.com](http://www.ellumia.com)

~~~
stdbrouw
Um, what you're doing might be super-duper valuable, but "bite-sized
personalized social innovative learning", frankly, sounds more like a game of
buzzword bingo than like a product description.

~~~
obeattie
That's a valid criticism.

Specifically, we offer courses that are far shorter and more targeted than a
"traditional" offering (or one that you'd find on a MOOC). Content is broken
down to the concept level, and available in multiple presentations. This
facilitates delivering content that is most suited to a learner's personal
style, as well as spaced repetition whereby a student exposed to the same
information multiple times over a period of time, in an altered format or
context. As I mentioned, this is on mobile, a space that's largely ignored
aside from educational games in higher learning.

I hope that is a little less buzzword-heavy, though I suspect it may still not
be as BS-free as it could be. Learning what messages work best for different
audiences is all part of the fun with a startup…

------
SmackAtom
Late 90s' UW Engineering grad here. First mistake, as a non-EE I thought I
would enjoy this course as an elective. Second mistake, not attending lecture.
Third mistake, waiting till the last minute to do the final project. Bad
times. It really struck true to me. As a developer today, looking back the
'hardest' part of my CS and ECE courses there, was that they completely
focused on the theory, and not the practice. Knowing how to debug my code
would have maybe made the difference. At the time, I was told in the lab, by a
TA that we were being left to 'sink or swim' so as to weed out the scrubs.
This combined with requiring us to sign a 'no cooperation / or sharing' pledge
made the experience a failing one. It took me nearly 5 years after school to
rekindle the interest.

------
Fuxy
Well I guess students are supposed to figure out the things they are not
taught for themselves maybe with a little bit of google-fu but i suspect the
amount of things the professors require them to figure out requires more time
then they have to the next course.

I regard universities as the pace you go when you already know most of what
you need and you just need to get the papers to prove it maybe get better in
the areas you missed.

But if you into university not knowing most of what they are going to teach
you you are going to have a hard time there's just not enough hours in a day.

That's how i see it anyway because every time i learn something i usually end
up researching more then i need for that specific assignment and end up
spending an entire day on just one thing maybe even more.

------
alexmarcy
Engineering programs are designed to weed people out and give the ones who
stay the ability to teach themselves new things. Debugging is an example of
one of those new things. If you go to school and have your hand held through
the entire process you won't be very well equipped to function in the real
world where it truly can be sink or swim.

My Chemical Engineering program was designed around the approach of "give the
students homework with no instruction and review the problem sets after they
are due". This was tough to handle and weeded a lot of people out every
semester yet was a great introduction to working in the real world where a lot
of times you have to figure out complex situations with little to no help from
anyone else.

------
osteele
This is an excellent essay. I remember sitting in my parents’ basement in high
school with a fully assembled electronics board that I’d soldered together
from a schematic, and no idea what to do about the fact that it didn’t work.
Had I understood that learning how to build involved learning how to debug,
I’d probably have built more things and fewer programs (for better or worse).

I must have known this about _software_ and _math_ , in order to be doing what
I was doing in those areas then, but not figured out to generalize it to {
_electronics_ , _mechanical objects_ , _project plans_ , _social interactions_
, _habits and motivational systems_ , and _creative writing_ } — and only
partially to writing essays.

------
drakaal
While it has been a number of years, I took CS and EE classes at Michigan
State University, Tri-State University, MIT, and Notre Dame.

These are all very different schools, but all of them taught debugging. At
Tri-State one of the classes was even dedicated to debugging.

I think the lack of teaching skills may be that more and more schools are
degree mills, and more and more the teachers have only ever worked in a
classroom so they don't know how to do things outside of the text.

But I have a hard time believing that MIT has dropped debugging, or that Tri-
State which is an Engineering school has either.

------
henrik_w
I find the professor's attitude quite puzzling. You often learn best when you
have made a mistake, and then figure it out ("expectation failure"). Why not
take advantage of that? I think bugs are quite useful as "teachers", as I
discussed in "4 Reasons Why Bugs Are Good For You"
[http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-
goo...](http://henrikwarne.com/2012/10/21/4-reasons-why-bugs-are-good-for-
you/)

~~~
ZenoArrow
henrik_w, the professor's attitude is not puzzling once you consider this...
the teacher in question intentionally wants to make the students struggle,
because it validates their own achievements.

Then you will see that it's not about the teacher doing the most to help the
student succeed, it's all about the teacher's ego. Of course such an attitude
is not one worth promoting, but everything in the article suggests this is
what we're seeing.

------
Kapura
Ability to debug is really a function of general domain knowledge, "skill" of
accessing documentation and/or examples, and good understanding of
experimentation. It's difficult to teach, as different coders approach
problems in different ways. First, I'll explain what I think makes one good at
debugging:

1\. Domain knowledge, which I'll consider code that the programmer has either
written herself or has otherwise become intimately familiar with, cannot
really be taught. But you can at least prepare a bit so you don't get lost in
the woods. I think it's good practise to understand the basic file structure
of what your working on and, generally, what is in the files you might be
working with. More detailed knowledge of code will come through being able to
trace data through files. This is not trivial in larger code bases, again, I
recommend using notes or whiteboards. This is necessarily lower when you first
encounter significant code that is not your own, and people who can leverage
their other skills tend to do better before acquiring knowledge of the
surrounding code.

2\. I say "skill" at finding documentation in quotes because sometimes, good
documentation does not exist. But the only way to increase your knowledge of
what's happening in your programs is to start figuring out what the components
you are using. Generally, newer programmers tend to find that the code they
are writing doesn't operate the way they hope because they have made a mistake
in arguments or syntax. Examples really help alleviate this. I'm not certain
this can be taught very well except for pointing students towards
documentation, but good debuggers tend to understand the benefit innately
before too long.

3\. If you're having problems with code that you think should be working, you
need to be tracing data. At each step, you should know what your variables are
and what you expect them to be. This is not trivial, and it can be very
difficult to determine just where something is going wrong. But this is also
the heart of debugging: being able to figure out where your signals are
getting turned around.

When you have nothing else, you can just start testing components for
correctness and model a cull cycle of your algorithms. I don't think this can
be taught, because many bugs are not like one another. After time, you might
grow to recognise code that would more probably produce bugs, but I don't
think there is a teachable process for finding bugs. Sometimes, things just be
broke. But knowing the manner in which things fail, you can find solutions
that bypass the sorts of code that cause errors. I'm not saying this is easy,
but I'm saying that it's something that you kind of need to learn for
yourself.

~~~
emidln
In the EE/CE program I went to, the first class you were required to take was
"Intro to Digital Systems". It consisted of a little bit of classroom basics
k-maps, binary/hex/octal math, gate logic, etc mixed with a lab that took a
breadboard and applied the knowldge you learned in the classroom to make
blinky lights/sounds. Not very impressive, but in the course of making the
light blink you learn rules for debugging systems that are applicable
everywhere (change only one thing, then test after every change, think about
what each change means in terms of expected output given an input, etc). If
you know how to do basic electronics going in, you have an easy A and a bunch
of free time. If you are learning it all for the first time, you probably
spend 10-15 hours a week on a 3 hour lab until it clicks.

The class had something like a 90% pass rate so I don't think this is
something that can't be taught with a mixture of normal classroom plus TA+Prof
help in labs.

------
skywhopper
Troubleshooting, as important as it is to engineering and computer science, is
a general skill that should be taught to kids starting in pre-school.

I'd argue that you can generalize all non-creative disciplines (science,
business, plumbing, etc) down to a specific area of troubleshooting. And for
the creative and athletic disciplines, troubleshooting will be needed to get
the best output from your tools, be they chisels, oboes, your voice, your
muscles, paints, or anything.

------
interstitial
It's a top secret recruiting method. Only the top 1% learn to debug code or
hardware on their own. Since it's a secret, it's still not a gamed in the
interview process by the me-too crowd. Please downvote this story, you will
make recruiting much harder.

------
userbinator
The best way to find the source of a problem can be summed up in two words:
binary search. On the other hand, having witnessed humans physically search
for things in ordered collections, it seems we're instinctively programmed to
perform a linear search.

~~~
henrik_w
In my experience, good logging is the first step to good debugging. Having
good logs lets you find a lot of problems without even debugging "properly"
(using a debugger say). [http://henrikwarne.com/2014/01/01/finding-bugs-
debugger-vers...](http://henrikwarne.com/2014/01/01/finding-bugs-debugger-
versus-logging/)

~~~
MarkSweep
Good logs have been especially useful while integrating new motion controls in
our wafer handling robot. We have a vendor who's product sometimes does not
respond correctly to motion commands. Before logging each movement command,
debugging a weird movement error would involve repeatedly moving the robot
until the error happened again. Now I just pull the last N commands out of the
log file, reproduce the issue, and send a script to the vendor so they can fix
it.

------
quasse
I really enjoyed this post having attended the same school and taken some of
the same classes. I'm actually currently in my final months of a mechanical
engineering B.S. at Madison, and I think the problem goes beyond a "hazing" of
freshmen.

For me, my ECE 352 was Introduction to Dynamic Systems. For anyone here
without a physics background, it's basically an introduction to "more real"
mathematical modeling of physical systems, beyond what you would learn in your
first few semesters of college physics. Think "applied differential
equations."

This class naturally involved some fairly high level math compared to what we
had been using before, and I think the professors honestly didn't know (or had
forgotten) how to transition into it. Suddenly the class was using things that
they might have done one or two homework assignments on in differential
calculus a year a go, but there was never any "here are the overarching
concepts used in this class and how they fit into the two years of calculus
you have already taken." The class was just dumped off the Laplace transform
deep end and left to memorize steps to solve problems.

I think the problem was that the professor had honestly forgotten what it was
like to not have an intuitive grasp of what a Laplace transform did or how to
linearize a dynamic system. I've found myself falling into almost the exact
same trap when teaching people object oriented programming for example. To an
experienced programmer, an object is the most natural thing in the world, you
can pass them around, perform operations on them and they just "work" for you.
It's so simple for you that it's hard to remember that it may be a completely
foreign concept to someone brand new.

The thing is, it's comparatively easy to just teach someone the steps to solve
a specific problem when the alternative is teaching them to think in such a
way that they could solve it on their own. It's the same with debugging, it's
the same with math, and with programming. I spent the rest of that semester
watching the professor spend every single lecture doing one or two difficult
examples, and nothing else. Teaching someone so that they can gain a deep
understanding of a given subject is _really hard_ , and I think it's the rare
school and professor that can do it effectively.

I ended up doing well in that class, but it was really by rote memorization of
every single mathematical "scenario" that I thought likely to be on the exams.
It wasn't until a year or so later that dynamic systems finally clicked into
place, and it was because a professor in an unrelated class happened to spend
45 minutes on a good intuitive explanation of what they meant.

I think teaching real systematic debugging is similar in that it's something
that requires a real mental investment on the part of the teacher. That's not
to say it's impossible, because it certainly isn't. It just requires someone
to make the investment and explain the _why_ as well as the how.

~~~
sjs1234
6.002 midterm at MIT in 91 had a problem trivial to solve with a Laplace
transform ... Actually it had a couple. Of course Laplace transforms would be
taught in the second half. The few students who already knew the transform or
somehow knew to read, ahead did well. I spent 20 minutes on one problem
solving the differential equations from scratch without the damn transform. I
felt sorry for those who weren't taking it as a freshman (it was pass/fail for
all classes your first year at MIT).

That guy was a useless jerk. (As a teacher.) I did have professors that were
useful jerks ... Difficult homework every single class with spot on directed
feedback by the very next class. Unfortunately teaching well at a research
university is just a mark of being eccentric. It seems to be negatively
correlated with getting tenure. The 'useful jerk' already had tenure. He was
mean, but an awesome teacher.

------
shadesandcolour
Debugging isn't a science that can be taught. In this particular case,
everything was made up of the same things a the fundamental level, so it was
an easy rabbit hole to follow i.e. since one of these inputs is wrong, then
one of these other inputs must be wrong, and follow all the way down.

Debugging a more complex system has to do with the system in question. Sure
you can teach people to set breakpoints and to run the debugger, but that's
about it. Learning how to observe what is going on in any particular system is
something that you learn how to do by banging your head against that system
for a long time.

------
milesvp
>> I’ve even seen people talented enough to breeze through the entire degree
without ever running into a problem too big to intuitively understand; those
people have a very bad time when they run into a 10 million line codebase in
the real world.

Reminds me of the classic Eric S. Raymond email to Linus Torvalds, where he
says essentially this.
[http://www.vanadac.com/~dajhorn/novelties/ESR%20-%20Curse%20...](http://www.vanadac.com/~dajhorn/novelties/ESR%20-%20Curse%20Of%20The%20Gifted.html)

------
fredgrott
Okay real life example....

In Mobile Operating systems the application lifecycle and the OS application
system sandbox collide to give you this nice Jaberwoky of output in a debug,
for example Android...

They way I did Id was use some example Android Apps to learn what the normal
android OS would show in a debug output as far as the OS components themselves
start up the android OS and than the application..

I can always look at logcat and see where things are hanging and just know
where to look in my code because of what OS components I see reporting in

------
nuriaion
During my Education to Electrical Technician ("Lehre") in Switzerland we had a
lot of exercises to learn debugging. One was that we got a blackbox with some
pins and some maximum ratings and we had to find out what circuit is inside.
Or we got a Circuit with a defined function and had to find out if it works as
expected or not. And so on. This was also a big part of our exams.

Then on the University the education shifted to a very theoretical approach.

------
existencebox
back when I was CS at JHU; there were some very strange divides in how some
professors viewed "programming vs. CS". (that I only got a taste of as an
undergrad; the real opinions didn't come out until I was talking to the
professors after my tenure as a student) What I would call useful "life
skills" (debugging, good code style, VCS, various development workflows), they
called "a waste of time getting in the way of their study of PURE CS(tm)".
Certain professors foster some of these skills, certain professors pretend
none of them exist at all. So it's a grab bag of what skills you'll end up
graduating with, aside from those you take the classes for. (which, credit
where its due, with the giant qualifier of "within higher end CS", was never
terrible.)

------
jcubic
The more important issue, at least in my case, is that schools don't teach
programming at all, only programming languages and programming is what you
learn on your own while you write code, teachers don't help in that process.

------
rpedela
Yeah there are two fundamental things that are not taught well in many (not
all) computer science programs.

1\. Debugging as the author explains.

2\. How to properly use version control and work with others using version
control on the same codebase. Hopefully Github for education will help with
this one.

~~~
pacmon
The author is talking about engineering not cs classes. That being said, I
would completely agree with you, having been through a cs degree myself.
Version control and working in a group with it would have been very beneficial
in school. Although, when I was in school that would have meant svn not git
which I have grown to love, but felt the pain of having to learn the hard way.

~~~
aestra
Who the heck went through a CS degree without using version control? We used
it from day 1 until graduation and you didn't get credit if you didn't use
version control, even on your projects you did yourself. How does one do group
projects in school without version control?

Git didn't exist when I was in school either.

~~~
krapp
If by 'version control' you mean 'delete and resubmit zip files into Moodle'
then sure... my courses use version control...

>How does one do group projects in school without version control?

Dropbox. If you're lucky. Otherwise, attaching files through gmail.

FWIW I wish Git were part of my curriculum. I also wish the Java curriculum
included Android. You gotta take what they give I guess.

~~~
aestra
I'm old. Dropbox did NOT exist when I was in school. Neither did Gmail...

> If by 'version control' you mean 'delete and resubmit zip files into Moodle'
> then sure... my courses use version control...

No I meant real version control. When I started CVS was standard.

~~~
krapp
If it helps, the last time I was in a CS class before this current iteration
(more or less to improve my career options) we were playing around with
DOSSHELL and Turtle Graphics.

------
alexnewman
RPI covered using version control and debugging. www.rpi.edu

------
kerkeslager
Other skills not taught in a CS degree:

1\. Version control 2\. Unit testing

------
kaonashi
I learned gdb in our systems/assembly course.

------
gailees
Because it isn't fun or exciting.

~~~
henrik_w
What do you mean? It is both fun and exciting. It's like solving little mini-
mysteries. Hmm, how come this variable is null here? That shouldn't be
possible! But it is, so how did that happen? Mystery!

You can also learn from it. Often a bug is caused by some misunderstanding, so
figuring that out teaches you something. Here's an example where I learned
several things finding and fixing a bug:
[http://henrikwarne.com/2014/01/27/a-bug-a-trace-a-test-a-
twi...](http://henrikwarne.com/2014/01/27/a-bug-a-trace-a-test-a-twist/)

~~~
72deluxe
It does teach you a lot. I spent ages wondering why my inherited class was
blowing up on destruction in C++ - the parent destructor was not virtual and I
was deleting the object using a pointer to the base type. So working this out
has meant that there is a big burn mark in my brain to not do this again.
Debugging really is good fun and helps with learning.

