Programming as Teaching
Andy Hunt and Dave Thomas write about learning
here and
here (sorry 'bout the awful URL).
Programmers must spend their entire careers learning; the best
programmers love to learn, and remain fascinated by their chosen
subjects for several decades. Dave and Andy write to that learner,
with good advice about mindful learning. If you're aware that you
need to learn some skill or language or system or technique, then
you have the opportunity to do so in a planned and measured way,
and to make the best use of your learning time.
What do programmers most frequently need to learn? In my
experience, we most frequently need to learn to assimilate huge,
ancient, misbegotten, broken, heterogenous, poorly-structured C
monstrosities. Legacy code. Cruft. How is it structured?
Where is the overview? Where are the hot spots, where one might
look for performance issues? Where are the ugly spots, where
buggy code is most likely to be found? Where are the debugging
hooks, functions designed to be called from the debugger, logging
or debugging flags that can be turned on, unit tests that can be
run?
Given the universal need for programmers to learn, you'd think
that there would be more literature about the flip side: programming
as teaching. Not teaching the computer things, but teaching the next
poor schmo who'll inherit your code, what you did. Teaching your
successor how your algorithm solves this problem, how it
fits together, where the tricky bits are, what alternative solutions
were considered, why they were rejected, and what was omitted because
you didn't have time to "do it right". Seems to me that these
mostly-contextual issues are given short shrift in most programming
shops.
My suggestion to anyone writing or maintaining code ever,
anywhere, and even to those inhaling a large body of code
that's new to you: be more mindful about teaching ... write
up little blurbs about things you learn, to smooth the learning
curve for the next inheritor of that code [*], and of your
modifications to it. Possible channels for this sort of thing
include comments, design notes, occasional presentations or
seminars or code reviews, and internal project weblogs.
Notes:
Michael Feathers' book
Working Effectively with Legacy Code is worth mentioning here.
I wrote previously about Programming as Teaching ...
here
and (tangentially)
here.
[*] It's entirely likely that the "next inheritor of your code" might be yourself, six months older.
11:22:52 PM
Random radio Weblog