Greasy hands, always.
982 stories

Jennie Alexander (1930-2018)

1 Comment


Editor’s note; This morning we received word from Peter Follansbee that Jennie Alexander has died. Her health has been in decline for some time, but her enthusiasm and spirit was intact. Just last week she called to give me a rash of crap about something I had written. Classic Jennie.

It’s impossible to overstate Jennie’s influence on the craft (and woodworking publishing). Her book “Make a Chair From a Tree” launched the book-publishing program at The Taunton Press and influenced and inspired thousands of woodworkers to pick up the tools and become chairmakers or green woodworkers.

I encourage you to read this profile of Jennie that Kara Gebhart published that covers the entire scope of Jennie’s life, from jazz musician to attorney to green woodworker. There is, of course, way more to the story of Jennie’s life, but this is as good as it gets.

Below I’ve reprinted an article I wrote on Jennie several years ago with photos from my first visit to her shop in Baltimore.

— Christopher Schwarz


Built in Baltimore. While many people associate Jennie Alexander’s chairs with country woodcraft, she lives in urban Baltimore, where she developed the design for her chair.


Make a Revolution from a Tree

A curious attorney helped kick-start ‘green woodworking’ with a single chair & a book.

Of all the unusual twists and turns in the life of Jennie (formerly John) Alexander, surely the most incredible has been to be pronounced dead in the media while being very much alive.

When her second woodworking book was released, some reviewers said she was deceased; others assumed “Jennie” was John’s widow.

So let’s set that fact aside – John is now Jennie – because it has nothing to do with Alexander’s incredible woodworking career, the iconic chair she designed or her profound influence on woodworking during the last 36 years.

Alexander’s first book, “Make a Chair from a Tree” (Taunton Press and later Astragal Press), was the 1978 lightning bolt that ignited the woodworking passions of thousands of woodworkers and brought “green woodworking” out of the forest and into the modern workshop. Even after the book went out of print, the chair continued to inspire through a DVD of the same name published by ALP Productions.

The chair that is featured in the book and DVD is both old and new. While it is based on traditional ladderbacks and deep-lignin science, Alexander’s chair is not tied to a particular period or style. Its parts are shaved instead of turned. It looks at home in a log cabin or an urban loft. It weighs almost nothing but is as strong as a suspension bridge. And it is definitely the most comfortable chair I have ever sat in.

There is something about the back that is simply incredible. The two slats hit you in the right place, and the back legs are curved in a way that pleases your eye and your muscular system.

As soon as I sat in one of her chairs, I knew I had to make one.

I’m not alone. Thousands of chairmakers have been smitten with the design. And many of them, such as chairmaker Brian Boggs, went on to become professionals. So if you are one of the tens of thousands of people who now build chairs from green wood or carve spoons or bowls, you are almost certainly part of the lineage that began – in part – with a Baltimore boy who was handy around the house.

Obey Snowball
Born in December 1930, Alexander was the son of a mother who was a secretary to the president of an insurance company. She would leave a to-do list for Alexander to tackle after he came back at night. She arranged for Boulevard Hardware to provide tools from the store’s extensive stock of Stanley tools. Jerry and Miss Irma at Boulevard filled the bill.

The owner also gave Alexander handouts on tool use that were printed by Stanley Tools, which Alexander kept in a three-ring binder, including a guide to sharpening and using hand tools.

“That,” she says, “was my bible.”

Another important part of the home picture was that Alexander’s mother, a former Sloyd student in Massachusetts, had collected some old furniture, including a post-and-rung chair with a fiber seat. “It had always been there,” Alexander says about the chair. “I liked that chair. It was comfortable, low and stocky but had an elevated air to it.”

Alexander attended Baltimore City Polytechnic Institute, a four-year high school that specialized in engineering – graduating there would give her a year’s head start at university. In high school she studied engineering with extensive shop work, from combustion to electricity to woodworking – things that stuck in her scientific mind and would come in handy later on when bending chair parts with heat and moisture.

After graduating, Alexander enrolled at Johns Hopkins University as a sophomore to study engineering. But she was shocked to learn the school was teaching the same material from high school, but to to four decimal points of precision instead of two.

“I was bored,” she says. “I was interested in music,” she says.

And she founded a repertory jazz trio and played around Baltimore, playing piano in bars instead of studying. She left Johns Hopkins and went to night school to study mathematics. Then she quit that, got a job as a draughtsman and then at the War Plant – all while singing and playing jazz piano with the Southland Trio.

But one morning, Alexander was lying in bed unable to sleep and heard a voice from her childhood speaking to her. It was the voice of Snowball, a voice on the radio show “Uncle Bill and Snowball,” which featured a blind banjo player who would sing in the high falsetto voice of Snowball.

“Go to law school,” Snowball says. Alexander takes the disembodied advice and by 3:15 that afternoon is enrolled in law school at the University of Maryland at Baltimore.

Alexander graduates law school in four years instead of three because she decides to attend night classes to prevent her from playing jazz on weeknights. After coming in first on the bar exam, Alexander married “a wonderful girl” named Joyce, now deceased, and starts a traditional law career. Which might have been the end of the story if it weren’t for meeting Charles Hummel at Winterthur Museum.


Broken chairs. Alexander’s research has been informed by many bits of research, including looking at bits of chairs that have broken to learn why they failed.

Shaker Chairs
Like many young people, Alexander and his wife fixed up an old house and Alexander  starts reading English books on traditional trade, including chairmaking. She fixes up a fishing boat (which later became a pond for storing wet wood for chairmaking), starts making stools and decides to make some chairs.

“I called a firewood man and said I want a hickory log so long and so straight,” Alexander says. Later on, “I hear a great sound at the back. He’s dropping off hickory logs. Don’t ask me how I broke those down to get them on the lathe. But it’s time to make a chair. I got those legs up on the lathe, and the lathe was jumping across the room.

“When the rough, split spindle finally turned round, 6’-long sopping-wet strands of hickory traveled up the gouge and hung themselves up on my right ear. I said, ‘I will never go to the lumberyard again.’ ”

And she never has.


Almost homemade. Alexander enjoys making effective tools from inexpensive raw materials. Here she made an useful side hatchet from a standard double-bevel hatchet.

Alexander and Joyce are fascinated by the Shakers. They make several trips to the Sabbathday Lake Shaker community, where Sister Mildred there becomes Joyce’s “spiritual guide.” Alexander decides to make a Shaker chair with a one-slat back.

“So I made some very clunky Shaker chairs with one slat and we used fake twisted paper (instead of rush or tape for the woven seat),” she says.


Boring the joints. Alexander demonstrates boring the mortises in a leg using a benchtop fixture that simplifies the process.


In the meantime, Alexander joins the Early American Industries Association and meets Charles Hummel, the author of the book “With Hammer in Hand” (University Press of Virginia) and a curator at Winterthur.

With Hummel’s guidance, Alexander becomes an expert on antique chairs made by the Dominy family on Long Island, including one interesting chair in the study collection that could be disassembled when the humidity is low (she was permitted by the museum to disassemble the chair, by the way).

All of this leads Alexander to experiment with wet wood. To test theory after theory on joinery, moisture content and how wood behaves. Some of the chairs work fine. Some do not. At some point Alexander decides to write a book about her chairs and travels to New England in 1977 at the suggestion of fellow craftsman Richard Starr. Alexander says she and Starr visited John Kelsey, the editor of Fine Woodworking magazine, at his home with a draft of the manuscript for “Make a Chair from a Tree” (Alexander says she “just happened to have the draft in hand”). Kelsey stayed up the night to read the draft.

“Kelsey read the draft overnight and hired me in the morning,” Alexander says. “Kelsey also hired Bruce Hoadley to read the text. Hoadley advised Kelsey, and I listened to every word.”

Make a Chair From a Tree
“Make a Chair from a Tree” was the first woodworking book published by Taunton Press, Alexander says. At the time, the new magazine was just getting started working on books with Tage Frid and Bruce Hoadley, but Alexander was ready to go, says Kelsey, the then-editor.

“I remember thinking it was a perfect topic for the then-new Fine Woodworking audience, the concept was so elemental and fundamental, and so unlike anything then in print; it cut to the very core of what we were trying to do,” Kelsey says. “At the same time, the publisher, Paul Roman, had a more conventional view of our woody audience and judged it a risky proposition, perhaps a very hard sell. But we didn’t know, and it wasn’t going to be a huge investment of time or money, so we agreed to jump and find out.”

Kelsey and Starr traveled to Baltimore to work on the book with Alexander. Roman, the magazine’s publisher, shot the photos, Alexander says. The team worked to shape up the manuscript for its 1978 release. (Upon reflecting on the process, Alexander says she was “eternally grateful” for Starr’s help in particular.)

Meanwhile, Alexander continued to investigate on the chair technology and offered huge changes right up until the moment the book went to press – an unconventional way to make a book (or a chair for that matter).

One of the biggest last-minute changes was in how the parts were shaped. Alexander had been using a lathe to turn the components. But right before an Early American Industries meeting, Alexander was told she couldn’t use a lathe because it was too dangerous to the audience if something flew loose.

“I was down in the shop kicking stuff. I didn’t know what to do,” Alexander says. “Joyce gives me a cup of tea. She says, ‘You shave stuff eight-sided to put it on the lathe don’t you? Well keep going.’ ” Alexander went to the meeting and returned with a shaved chair.

Alexander switched to shaving the chairs instead of turning them. Kelsey then had to re-write the book, Alexander says.

“But we wanted a great little gem of a book and we didn’t want to be issuing revised editions within a year or two, so we rode the pony right to the ground,” Kelsey says.

“Make a Chair from a Tree” hit the market in 1978 with multiple advertisements in the magazine that were supported by articles from Drew Langsner and Alexander on green-wood techniques and technology. Kelsey says the book  – 128 pages in an unusual 9” x 9” format – was a hard sell with most readers. But it was aimed right between the eyes of Peter Follansbee in Massachusetts.


Chair in use. While Peter Follansbee was the joiner at Plimoth he would use this chair made by Alexander to explain some aspects of joinery and chair technology.


“I was in my shop with a table saw and a drill press,” Follansbee says. “I think I was trying to make a bookcase. With those two articles I was just captured.”

Follansbee bought the book, started making chairs and in 1980 saw that Alexander was teaching a class at Country Workshops in North Carolina. Though Follansbee didn’t drive a car, he found a way to the school via an airplane, two buses and 25 miles of hitchhiking and walking. In time he became a regular at the school, and he and Alexander became friends through a love for green woodworking and a twisted sense of humor.

At the time, Alexander was exploring theories of how case pieces had been made using 17th-century green-woodworking techniques such as riving stock, and joinery techniques including drawboring that Benno Foreman, Robert Trent and Hummel at Winterthur were also researching. They helped open the door for Alexander’s research in giving her access to old pieces.

“He (Alexander) was looking for someone to test his theories,” Follansbee says. “He was practicing law and didn’t have time to build a complex piece. So I ended up saying, ‘I’ll go fart around with some of this.’ I had given up all my power tools. I had found a good-sized log. He (drew out) the joint on the junk mail on his table. I rose to the bait.”


In the country. Jennie, Peter and Theodore during their early days at Country Workshops.


That moment launched a long correspondence between Alexander and Follansbee, who would swap letters and photographs from their homes in Baltimore and Massachusetts. And eventually the letters led to the book “Make a Joint Stool from a Tree” (Lost Art Press), which explored 17th-century joinery and stock preparation.

This dunking into the world of green woodworking led Follansbee to become the joiner at Plimoth Plantation for more than 20 years, where he continued to explore 17th-century furniture.

“All in all, (Alexander) has been a huge part of my life,” Follansbee says.

Country Workshops
Follansbee was similar to many woodworkers who discovered green woodworking through “Make a Chair from a Tree.” They started with the book and ended up studying it deeply under the direct tutelage of Alexander at Country Workshops in rural North Carolina.

Drew and Louise Langsner founded Country Workshops in 1978 shortly after the couple had written a book titled “Handmade,” and Drew had just finished a book called “Country Woodcraft.”

“Almost as soon as that book comes out I get a letter from John who was very excited about the book,” Drew says. The two resolve to meet when Drew traveled to New England to speak at the Woodcraft Supply store.

During the visit, Drew invited Alexander to Country Workshops to teach a class on building a simple stool. That class soon evolved into a class on building a simple chair with one slat and finally the chair that appeared on the cover of “Make a Chair from a Tree.”

And Country Workshops became the flash point for woodworkers who wanted to explore traditional woodworking in a deep way that was rooted both in tradition and science.


Sitting pretty. Alexander’s chair (background) with a simple antique ladderback in front. You can see both the similarities in form but the vast differences in style.

Even today, people come from all over the world to study chairmaking at Country Workshops, many of them inspired by Alexander’s incredibly lightweight chair.

“In fact, some students (from Australia) were here last week were sent here by Jennie,” Louise says. “She is always encouraging people. I think that is a special thing about her – generosity.

“Woodworking is such a special part of her life and she wants to share.”

So what is it about Alexander’s chair that still continues to inspire people to build it? Drew says it’s interesting to him because Alexander’s chair is essentially a historical ladderback design that appears over and over.

But Alexander was not content to just build a reproduction and call it done. Alexander, a jazz singer, likes to explore variations on a theme.

“The Appalachian chairs were a little clunky,” Drew says. “John’s are really slender and elegant. How he came up with that look I don’t know. But the look changed everything. He refined the chair just perfectly.”

In fact, Drew says he’s about to start making a set of them for their house and daughter. And they were going to be exactly the same chair shown on the cover of “Make a Chair from a Tree.”

“It’s like Alexander took an old piece of music,” Drew says. “She’s following all the 300-year-old notes and making it new again.”

— Christopher Schwarz

Read the whole story
6 days ago
Brooklyn, NY
Share this story

"C Is Not a Low-level Language"


David Chisnall, "C Is Not a Low-level Language. Your computer is not a fast PDP-11.", ACM Queue, Volume 16, issue 2.

"For a language to be "close to the metal," it must provide an abstract machine that maps easily to the abstractions exposed by the target platform. It's easy to argue that C was a low-level language for the PDP-11.
it is possible to make C code run quickly but only by spending thousands of person-years building a sufficiently smart compiler—and even then, only if you violate some of the language rules. Compiler writers let C programmers pretend that they are writing code that is "close to the metal" but must then generate machine code that has very different behavior if they want C programmers to keep believing that they are using a fast language."

Includes a discussion of various ways in which modern processors break the C abstract machine, as well as some interesting speculation on what a "non-C processor" might look like. The latter leads to thinking about what a low-level language for such a processor should look like.

Read the whole story
15 days ago
Brooklyn, NY
Share this story

Shinichi Suzuki: Ability Development from Age Zero


We must think deeply about the fact that Casals, at ninety-one years old, even now practices the cello two hours every day so as not to be stagnant at even his high level of ability.

Even if someone becomes a fine person who does great works, he is not so exalted that he does not need to study. Rather the opposite is true, because he finds more and more problems to study and he has the will to grow higher and higher. He is in a world so advanced that we cannot even imitate him, but we learn that people train themselves more and reach for truer beauty.

Read the whole story
35 days ago
Brooklyn, NY
Share this story

RT @ReinH: git pro tip: stick to a consistent style for git commit messages. I suggest starting them with “In which our hero”. E.g., In wh…

1 Comment and 2 Shares

git pro tip: stick to a consistent style for git commit messages. I suggest starting them with “In which our hero”. E.g.,

In which our hero fixes JIRA-2317

Posted by ReinH on Tuesday, June 5th, 2018 4:14am
Retweeted by SwiftOnSecurity on Wednesday, June 6th, 2018 8:55pm

3350 likes, 1155 retweets
Read the whole story
43 days ago
41 days ago
Brooklyn, NY
Share this story

Josh Barro on Twitter: "Bourdain's most essential writing, IMO, is the "How to cook like the pros" chapter in Kitchen Confidential. It explains why restaurant food tastes better than your food at home. The main answers are: shallots, lots of butter in eve

1 Share

Josh Barro: "Bourdain's most essential writing, IMO, is the 'How to cook like the pros' chapter in Kitchen Confidential. It explains why restaurant food tastes better than your food at home. The main answers are: shallots, lots of butter in everything, high-quality stock, and demi-glace..."

Read the whole story
41 days ago
Brooklyn, NY
Share this story

Write code that's easy to delete, and easy to debug too.

1 Comment and 2 Shares

Debuggable code is code that doesn’t outsmart you. Some code is a little to harder to debug than others: code with hidden behaviour, poor error handling, ambiguity, too little or too much structure, or code that’s in the middle of being changed. On a large enough project, you’ll eventually bump into code that you don’t understand.

On an old enough project, you’ll discover code you forgot about writing—and if it wasn’t for the commit logs, you’d swear it was someone else. As a project grows in size it becomes harder to remember what each piece of code does, harder still when the code doesn’t do what it is supposed to. When it comes to changing code you don’t understand, you’re forced to learn about it the hard way: Debugging.

Writing code that’s easy to debug begins with realising you won’t remember anything about the code later.

Rule 0: Good code has obvious faults.

Many used methodology salesmen have argued that the way to write understandable code is to write clean code. The problem is that “clean” is highly contextual in meaning. Clean code can be hardcoded into a system, and sometimes a dirty hack can written in a way that’s easy to turn off. Sometimes the code is clean because the filth has been pushed elsewhere. Good code isn’t necessarily clean code.

Code being clean or dirty is more about how much pride, or embarrassment the developer takes in the code, rather than how easy it has been to maintain or change. Instead of clean, we want boring code where change is obvious— I’ve found it easier to get people to contribute to a code base when the low hanging fruit has been left around for others to collect. The best code might be anything you can look at quickly learn things about it.

  • Code that doesn’t try to make an ugly problem look good, or a boring problem look interesting.
  • Code where the faults are obvious and the behaviour is clear, rather than code with no obvious faults and subtle behaviours.
  • Code that documents where it falls short of perfect, rather than aiming to be perfect.
  • Code with behaviour so obvious that any developer can imagine countless different ways to go about changing it.

Sometimes, code is just nasty as fuck, and any attempts to clean it up leaves you in a worse state. Writing clean code without understanding the consequences of your actions might as well be a summoning ritual for maintainable code.

It is not to say that clean code is bad, but sometimes the practice of clean coding is more akin to sweeping problems under the rug. Debuggable code isn’t necessarily clean, and code that’s littered with checks or error handling rarely makes for pleasant reading.

Rule 1: The computer is always on fire.

The computer is on fire, and the program crashed the last time it ran.

The first thing a program should do is ensure that it is starting out from a known, good, safe state before trying to get any work done. Sometimes there isn’t a clean copy of the state because the user deleted it, or upgraded their computer. The program crashed the last time it ran and, rather paradoxically, the program is being run for the first time too.

For example, when reading and writing program state to a file, a number of problems can happen:

  • The file is missing
  • The file is corrupt
  • The file is an older version, or a newer one
  • The last change to the file is unfinished
  • The filesystem was lying to you

These are not new problems and databases have been dealing with them since the dawn of time (1970-01-01). Using something like SQLite will handle many of these problems for you, but If the program crashed the last time it ran, the code might be run with the wrong data, or in the wrong way too.

With scheduled programs, for example, you can guarantee that the following accidents will occur:

  • It gets run twice in the same hour because of daylight savings time.
  • It gets run twice because an operator forgot it had already been run.
  • It will miss an hour, due to the machine running out of disk, or mysterious cloud networking issues.
  • It will take longer than an hour to run and may delay subsequent invocations of the program.
  • It will be run with the wrong time of day
  • It will inevitably be run close to a boundary, like midnight, end of month, end of year and fail due to arithmetic error.

Writing robust software begins with writing software that assumed it crashed the last time it ran, and crashing whenever it doesn’t know the right thing to do. The best thing about throwing an exception over leaving a comment like “This Shouldn’t Happen”, is that when it inevitably does happen, you get a head-start on debugging your code.

You don’t have to be able to recover from these problems either—it’s enough to let the program give up and not make things any worse. Small checks that raise an exception can save weeks of tracing through logs, and a simple lock file can save hours of restoring from backup.

Code that’s easy to debug is code that checks to see if things are correct before doing what was asked of it, code that makes it easy to go back to a known good state and trying again, and code that has layers of defence to force errors to surface as early as possible.

Rule 2: Your program is at war with itself.

Google’s biggest DoS attacks come from ourselves—because we have really big systems—although every now and then someone will show up and try to give us a run for our money, but really we’re more capable of hammering ourselves into the ground than anybody else is.

This is true for all systems.

Astrid Atkinson, Engineering for the Long Game

The software always crashed the last time it ran, and now it is always out of cpu, out of memory, and out of disk too. All of the workers are hammering an empty queue, everyone is retrying a failed request that’s long expired, and all of the servers have paused for garbage collection at the same time. Not only is the system broken, it is constantly trying to break itself.

Even checking if the system is actually running can be quite difficult.

It can be quite easy to implement something that checks if the server is running, but not if it is handling requests. Unless you check the uptime, it is possible that the program is crashing in-between every check. Health checks can trigger bugs too: I have managed to write health checks that crashed the system it was meant to protect. On two separate occasions, three months apart.

In software, writing code to handle errors will inevitably lead to discovering more errors to handle, many of them caused by the error handling itself. Similarly, performance optimisations can often be the cause of bottlenecks in the system—Making an app that’s pleasant to use in one tab can make an app that’s painful to use when you have twenty copies of it running.

Another example is where a worker in a pipeline is running too fast, and exhausting the available memory before the next part has a chance to catch up. If you’d rather a car metaphor: traffic jams. Speeding up is what creates them, and can be seen in the way the congestion moves back through the traffic. Optimisations can create systems that fail under high or heavy load, often in mysterious ways.

In other words: the faster you make it, the harder it will be pushed, and if you don’t allow your system to push back even a little, don’t be surprised if it snaps.

Back-pressure is one form of feedback within a system, and a program that is easy to debug is one where the user is involved in the feedback loop, having insight into all behaviours of a system, the accidental, the intentional, the desired, and the unwanted too. Debuggable code is easy to inspect, where you can watch and understand the changes happening within.

Rule 3: What you don’t disambiguate now, you debug later.

In other words: it should not be hard to look at the variables in your program and work out what is happening. Give or take some terrifying linear algebra subroutines, you should strive to represent your program’s state as obviously as possible. This means things like not changing your mind about what a variable does halfway through a program, if there is one obvious cardinal sin it is using a single variable for two different purposes.

It also means carefully avoiding the semi-predicate problem, never using a single value (count) to represent a pair of values (boolean, count). Avoiding things like returning a positive number for a result, and returning -1 when nothing matches. The reason is that it’s easy to end up in the situation where you want something like "0, but true" (and notably, Perl 5 has this exact feature), or you create code that’s hard to compose with other parts of your system (-1 might be a valid input for the next part of the program, rather than an error).

Along with using a single variable for two purposes, it can be just as bad to use a pair of variables for a single purpose—especially if they are booleans. I don’t mean keeping a pair of numbers to store a range is bad, but using a number of booleans to indicate what state your program is in is often a state machine in disguise.

When state doesn’t flow from top to bottom, give or take the occasional loop, it’s best to give the state a variable of it’s own and clean the logic up. If you have a set of booleans inside an object, replace it with a variable called state and use an enum (or a string if it’s persisted somewhere). The if statements end up looking like if state == name and stop looking like if bad_name && !alternate_option.

Even when you do make the state machine explicit, you can still mess up: sometimes code has two state machines hidden inside. I had great difficulty writing an HTTP proxy until I had made each state machine explicit, tracing connection state and parsing state separately. When you merge two state machines into one, it can be hard to add new states, or know exactly what state something is meant to be in.

This is far more about creating things you won’t have to debug, than making things easy to debug. By working out the list of valid states, it’s far easier to reject the invalid ones outright, rather than accidentally letting one or two through.

Rule 4: Accidental Behaviour is Expected Behaviour.

When you’re less than clear about what a data structure does, users fill in the gaps—any behaviour of your code, intended or accidental, will eventually be relied upon somewhere else. Many mainstream programming languages had hash tables you could iterate through, which sort-of preserved insertion order, most of the time.

Some languages chose to make the hash table behave as many users expected them to, iterating through the keys in the order they were added, but others chose to make the hash table return keys in a different order, each time it was iterated through. In the latter case, some users then complained that the behaviour wasn’t random enough.

Tragically, any source of randomness in your program will eventually be used for statistical simulation purposes, or worse, cryptography, and any source of ordering will be used for sorting instead.

In a database, some identifiers carry a little bit more information than others. When creating a table, a developer can choose between different types of primary key. The correct answer is a UUID, or something that’s indistinguishable from a UUID. The problem with the other choices is that they can expose ordering information as well as identity, i.e. not just if a == b but if a <= b, and by other choices mean auto-incrementing keys.

With an auto-incrementing key, the database assigns a number to each row in the table, adding 1 when a new row is inserted. This creates an ambiguity of sorts: people do not know which part of the data is canonical. In other words: Do you sort by key, or by timestamp? Like with the hash-tables before, people will decide the right answer for themselves. The other problem is that users can easily guess the other keys records nearby, too.

Ultimately any attempt to be smarter than a UUID will backfire: we already tried with postcodes, telephone numbers, and IP Addresses, and we failed miserably each time. UUIDs might not make your code more debuggable, but less accidental behaviour tends to mean less accidents.

Ordering is not the only piece of information people will extract from a key: If you create database keys that are constructed from the other fields, then people will throw away the data and reconstruct it from the key instead. Now you have two problems: when a program’s state is kept in more than one place, it is all too easy for the copies to start disagreeing with each other. It’s even harder to keep them in sync if you aren’t sure which one you need to change, or which one you have changed.

Whatever you permit your users to do, they’ll implement. Writing debuggable code is thinking ahead about the ways in which it can be misused, and how other people might interact with it in general.

Rule 5: Debugging is social, before it is technical.

When a software project is split over multiple components and systems, it can be considerably harder to find bugs. Once you understand how the problem occurs, you might have to co-ordinate changes across several parts in order to fix the behaviour. Fixing bugs in a larger project is less about finding the bugs, and more about convincing the other people that they’re real, or even that a fix is possible.

Bugs stick around in software because no-one is entirely sure who is responsible for things. In other words, it’s harder to debug code when nothing is written down, everything must be asked in Slack, and nothing gets answered until the one person who knows logs-on.

Planning, tools, process, and documentation are the ways we can fix this.

Planning is how we can remove the stress of being on call, structures in place to manage incidents. Plans are how we keep customers informed, switch out people when they’ve been on call too long, and how we track the problems and introduce changes to reduce future risk. Tools are the way in which we deskill work and make it accessible to others. Process is the way in which can we remove control from the individual and give it to the team.

The people will change, the interactions too, but the processes and tools will be carried on as the team mutates over time. It isn’t so much valuing one more than the other but building one to support changes in the other.Process can also be used to remove control from the team too, so it isn’t always good or bad, but there is always some process at work, even when it isn’t written down, and the act of documenting it is the first step to letting other people change it.

Documentation means more than text files: documentation is how you handover responsibilities, how you bring new people up to speed, and how you communicate what’s changed to the people impacted by those changes. Writing documentation requires more empathy than writing code, and more skill too: there aren’t easy compiler flags or type checkers, and it’s easy to write a lot of words without documenting anything.

Without documentation, how can you expect people to make informed decisions, or even consent to the consequences of using the software? Without documentation, tools, or processes you cannot share the burden of maintenance, or even replace the people currently lumbered with the task.

Making things easy to debug applies just as much to the processes around code as the code itself, making it clear whose toes you will have to stand on to fix the code.

Code that’s easy to debug is easy to explain.

A common occurrence when debugging is realising the problem when explaining it to someone else. The other person doesn’t even have to exist but you do have to force yourself to start from scratch, explain the situation, the problem, the steps to reproduce it, and often that framing is enough to give us insight into the answer.

If only. Sometimes when we ask for help, we don’t ask for the right help, and I’m as guilty of this as anyone—it’s such a common affliction that it has a name: “The X-Y Problem”: How do I get the last three letters of a filename? Oh? No, I meant the file extension.

We talk about problems in terms of the solutions we understand, and we talk about the solutions in terms of the consequences we’re aware of. Debugging is learning the hard way about unexpected consequences, and alternative solutions, and involves one of the hardest things a programer can ever do: admit that they got something wrong.

It wasn’t a compiler bug, after all.

Read the whole story
44 days ago
Solid gold right here
Brooklyn, NY
Share this story
Next Page of Stories