Back to The Honest Programmer
The Honest Programmer (otherwise known as Zen and the Art of Program Maintenance!) is an idea
born of a group of Cambridge software engineers as a vehicle for our
insights and opinions about the craft of software engineering.
The Honest Programmer should be an editted collection of essays
discussing the pragmatic issues of getting software written and working
rather, detailling the rules-of-thumb and guiding principles that we use
in practice. I want to avoid the psychobabble prevalent in books on the
methodology of software engineering, project management, etc., so it
should be chatty and anecdotal in style with lots of punchy and incisive
points. With a variety of authors it should present a broad church view
rather than push any particular One True Way - there is rarely
such a thing as The Right Answer!
Here is a seeding list of topics to start you thinking:
- A quick comparative survey of the major programming languages, stressing
their strengths and weaknesses as well as a very quick guide to getting
started in that language. (A good programmer should be multilingual
even if with a preferred main language).
- Know a craftsman by his tools. A survey of the various types of
programming tools with quick summaries of important capabilities and
some pointers to when to use them and when not to. This can cover
everything from editors, browsers, debuggers through Unix shell tools to
GUI designers and scripting languages.
- Design & Implementation
- This is a pivotal topic being one of the ways a real craftsman shines.
I envisage a blend of guiding principles (such as Borris's ZOM -
Zero-One-Many, Eddy's Accidence vs. Essence), anecdotes, paradigms,
visualisation, and examples. Should include discussion of the lifecycle
of a project and future-proofing the initial design. Obviously more
than a nod towards Zen and the Art of Program Maintanence!
- Testing & Fixing
- Another pivotal topic as the more devious bugs require real insight to
track down. Everything from what to think of when building a test-suite
(and how to manage it) to how to debug real-time random failures with
limited tracing facilities. But also warn against placing too much
faith in testing.
- Start with a survey of text markup languages from roff to TeX and
SGML/HTML, as well as brief mention of word processors. Something on
literate programming and the distinction between self-documenting code
and undocumented code. Also to include advice on writing user manuals,
technical reports, grant proposals, etc! Style is everything here.
- Management and Marketing
- Few programmers are lucky enough not to have to worry about keeping
management happy. Some tips on how to explain technical problems to
idiots (no I mean managers!). But more seriously: something on project
planning, utilising resources, avoiding synchronisation delays, etc.
Advice on presentation to nontechnical people is important - you can't
blame the marketting men for cocking up a sale if you didn't explain it
to them properly. Can also include comments on dealing with customers
(particularly the thorny issue of how to get clear requirements).
- Genres of code
- Modern computers have now pervaded most areas of human endeavour. This
section should survey the various categories of programming required
from numerical sci/eng programming, real-time hardware control,
artificial intelligence, database, through to financial and business
data processing. The main emphasis here is how the various demands of
these applications affect the algorithms chosen, the development
language and tools, and the overall process.
- Scales of development
- Different approaches are required for a quick 100-line utility that
will never need to be changed, to the million-plus-line major program
worked on by many people over many years. To include advice on
appropriate and inappropriate methods and tools.
- A quick survey of the algorithms that get used in 90% of real
applications. OK, that's not much more than a couple of sorts and
searches - but I'm after a practical toolset. More a reference list than
a reference. To include also: discussion of flexible versus fast
implementation, generalisations of algorithms (so you need remember
- Resource location
- One major skill a programmer needs is to be able to find resources for a
project: from finding an algorithm from the academic literature, to
getting some public domain tools to do part of the job to using
discussion groups such as usenet news or DevCon. Can also include tips
on acquiring hardware and finding suitable people to take on.
A collection of such URLs is available on the Honest Programmer
Please mail firstname.lastname@example.org with
Back to The Honest Programmer /
Mail the Editor
© Dave Lloyd. Last updated 23 Nov 1996. / email@example.com