I promise to work for a better world, where science and technology are used in socially responsible ways. I will not use my education for any purpose intended to harm human beings or the environment. Throughout my career, I will consider the ethical implications of my work before I take action. While the demands placed upon me may be great, I sign this declaration because I recognize that individual responsibility is the first step on the path to peace.

Student Pugwash Group pledge, as quoted by Sir Joseph Rotblat (1999).

Craft

I've been ruminating on craft – a.k.a. craftsmanship. [If I refer to someone as a craftsman, please do not imagine I am saying or assuming anything about their genitalia – or, indeed, about any other characteristic of them that would be a distraction from the discourse.] It's a topic I've discussed with my programmer friends and includes generic truths that yield fruitful discussions with my elder brother (James, antique watch wright) and my friend Kim, a civil engineer. Along with other denizens of chaos, I have an avowed intent to articulate any useful thoughts I can muster on the topic.

I aim to explore the form in which craft appears for me, as a toolwright: I leave it to hackers to identify any commonality between this and hackerdom – and, indeed, to decide whether to call me a hacker. As for hackers, so for practitioners of any kindred craft.

Extant fragments (all, like this page, waiting until I know how to improve them):

Toys

• My take on Jim Propp's self-referential aptitude test.
• An implementation of the cellular automaton John Horton Conway invented and named life.
• Helpers for solving Su Doku puzzles and substitution ciphers.

Ramblings

• why security analysts should publish exploit code.
• guilds, from the perspective of utility.
• Hackers and cross-talk on Eric Raymond's essay Homesteading the Noosphere.
• An examination of algorithmic complexity when computing Fibonacci's sequence
• A talk about a few decades in computing.
• A talk on the care and feeding of make.
• A ramble about using directed graphs (and graph theory) to make better UIs for interacting with networks and webs that aren't simply hierarchical trees.
• On the importance of measuring and managing quality, and its application to software.
• Memories of DCL/VMS, a system on which typing help actually got you something helpful.
• Some thoughts on revision management.
• A few happy coincidences between Norwegian and Unix vocabularies.
• The importance of only warning users seldom.
• A heinous hack of which I'm mildly proud.
• On how (not) to mark up names.
• Why software is buggy.

Explorations

• An idea for a dynamic form of hypertext, in which a page adapts its links to take account of what you have read before.
• Thoughts about the circuits that implement logic gates in computers.
• A sketch of a possible approach to sub-modules in git (ignoring the existing git submodule support).
• Playing with python and thoughts related to just how powerful a language one could build along similar lines …
• Thoughts on the design of a text editor.
• My (antique) sundry library and its spin-offs – assorted C code which I have found useful. I describe them, though incompletely, and leave you to care whether they would serve you well. If you want the code of these or of the shepherd (below), drop me a line and I'll package it up for you when I have the time. But they really need re-written (in python, probably).
• The shepherd, a library built on the above; a crude generic system for implementing evolutionary problem-solving – which I would need to rewrite before doing much more with it.

Blog posts and talks

Elsewhere (up to 2023, always for work) I've written some blog posts; some of which start life as talks.

• An April 2023 talk on getting time-zone information out of an operating system.
• An April 2023 blog post based on a presentation to colleagues, Unifying Qt::TimeSpec within QTimeZone, on a Qt 6.5 API improvement.
• A May 2022 blog post, Extending the range of time, on work I'd done to remove artificial boundaries.
• A Nov 2020 blog post, Teaching QLocale more about number formats, including how I shrank a data-set while adding more information to it.

Warning

Your mileage may vary

Keep It Straightforward, Simpleton

Straightforward needn't be naïve – it provides facilities which it makes sense to use straightforwardly, allows that these may be used otherwise, but specifies how it will respond in such plain terms as to leave it as clear as even these cases could hope for – just like python, in fact. While keeping things simple is generaly a Good Thing, making something useful needs to allow for non-simple things.

I won't pretend to understand the heated debates about init systems on Unix variants, but Rich Felker's critique of systemd includes a delightful example of straightforward at the end, in his proposed C code for a Unix-style process 1. Even I can make sense of that, and I don't know anything about the low-level machinery of the kernel.

See also

• If you want to get good at programming, rather than just be able to get by, be prepared to devote some time and effort to it. Learning any skill requires deliberative practice; there are no short-cuts.
• Having others (constructively) review your attempts at coding is also a great way to get better at programming. This is also a prerequisite of determining the only valid measure of code quality.
• On the virtue of trolling about operating system choice.
• By the way: the customer isn't always right.
• On how to give presentations.
• Niklaus Wirth's seminal paper (PDF) Algorithms + Data Structures = Programs (1976) and his later short work (PDF) Algorithms and Data Structures (1986).
• Learning about programming by playing games:
  • Untrusted, or The Continuing Adventures of Dr. Eval; hack the (JavsScript) code that generates each dungeon level to enable the player to escape.
  • Deadlock Empire, teaching about concurrency (in C#) by having the player take the rôle of the scheduler and try to find a way to make concurrent code get stuck.
• Kevin Henney, in the course of talking about how how to test code let on that the well-known problem of metrics becoming meaningless once motivated first entered the western academic literature thanks to one Charlse Goodhart, an economist, observing in 1975 Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes. In his response to the last audience question, he highlights another flaw of such metrics: putting hard limit on such a statistic leads to perverse behaviour. I can add that such a hard limit tends to give folk permission to get way closer to it – but that's OK, I'm within the limit – than they should.
• A proposal for a hypocratic oath for scientists (quoted above, at top of page), as a bulwark against the develoment of unethical technology; and a more recent one for techies. Canadian engineering's iron ring tradition might serve as a relevant framework. For contrast, here's an example of why it matters.
• Programming computers needn't be encumbered with fussy punctuation rules, as frameworks like Alice, Sugar and Scratch and languages like KidsRuby and python have shown, by enabling children to discover what fun it can be to get a computer to do your bidding.
• … nor need web design be a black art.

Maintained by Eddy.