Stimergy

I've always been attracted to the idea of self-organization by informal means, and there was an article not long ago talking about stimergy in a software development context.

The idea is that everyone somehow knows what to do without talking to each other, but just by doing the work and observing the signs left behind, implicit and explicit.

For instance, how do we add a new page to the app? By copying an existing. How do we know something is wrong? Well, either someone already removed the problematic part so we don't see it anymore, or someone added a FIXME note with the intention of doing it later. Or perhaps it just sticks out so visibly that nobody is in doubt it's bad.

Arrows

I think of it as a room full of arrows lying on the floor.

If you are bad at software development, the arrows will be pointing in random directions, and confusion ensues at every point in the process. You can never sprint, only stumble.

The goal is to make sure everything is tidied up so the arrows point in the same direction, the direction we want to go in. We need to constantly check and revise the code to align the arrows, not only align them to each other but also align them with the evershifting goals of the system. The goal of training newcomers is to teach them to read the arrows and make new arrows point in the right direction.

For instance, if a function is named after how it was conceived, not after how it is currently being used, it's pointing in the wrong direction. When you later try to reason with it, your mind will tend to go down the wrong paths and you'll reach the wrong conclusions, leading to bugs, or at least waste time having to retrace your steps.

You can add a comment to the function, but it's far more powerful to fix the name so it's pointing in the right direction, even if it's more work up front. Arrows matter.

I think this is a powerful metaphor.

Simple processes

I also think it's a powerful method.

Everything is done by engaging with the main activity, programming. It's through this activity that we learn and exchange the acquired knowledge.

Anyone can contribute to the direction. The value of the contribution is correlated with the confusion the contribution leaves in the greater system. It can be negative, but it can also be a stroke of genius, the subtle touch that makes the arrows of the system appear in greater clarity and alignment.

It is dynamic. If a bad decision is made, it's precisely as fixed as the program. The effort it takes to fix the program is the effort it takes to change the decision, no more and no less. Once something enters the program, it takes a life of its own, removed from the egos of programmers involved. The ego might point in one direction, but the code has its own signs.

Yet it's really simple. It works for ants.

Ant by Katja Schulz

Ants

Of course we're not ants. We need to and should communicate. We can pre-align our internal arrows to solve a complex problem much more efficiently than a bunch of ants that are mostly relying on evolved instincts.

But once the program starts, the communication becomes fragmented and loses some of its relevance compared to the work we actually do. You want to know what I did last week? Look at my commit log.

The unspoken truth about managing geeks

This opinion piece was funny.

Emacs: ido is currently the replacement for iswitchb, not icomplete-mode

So Emacs recently, well, recently in Emacs time, obsoleted iswitchb, the package I've been using to switch buffers.

The suggestion is to try icomplete-mode instead. But icomplete-mode isn't really tuned for buffer switching in the same manner as iswitchb. After some digging, it looks like there was a plan to gradually integrate the features of iswitchb/ido into icomplete-mode, but that hasn't happened yet, and yet iswitchb was obsoleted.

Fortunately, it looks like ido these days allows one to only turn it on for buffers. This will do the trick as a replacement for (iswitchb-mode 1):

(ido-mode 'buffers)

Once that's done, you can even enable icomplete-mode safely without having it meddle with buffer switching, so:

(ido-mode 'buffers)
(icomplete-mode 1)

Last-minute bugs

You've just completed a new big feature.

There's been ups and downs - you started thinking how hard can it be, then discovered the inherent ambiguities, the dissonances with the existing code base, got stuck, pacing the floor of the office, chatting to coworkers, slowly building, discarding and rebuilding refined models, getting stuck and unstuck again and again, then gradually transcending into a coding frenzy, with the code bending towards your goals and your will, constantly in the zone, writing tests, wrapping things up, thoroughly testing everything manually, finally letting some trusted users try it out.

And now you're ready for release. Release!

Except just now someone remarked how something is a little bit odd. Perhaps it's even yourself, the overworked brain having mentally let go of the whole thing and suddenly remembering a little forgotten detail.

Ah. But I just need to fix this. It is simple. The world is my feet. And the test works. I can do this.

Except you didn't bother running the full test suite. Or going through the full test procedure. Or full release procedure. Or checking with the users.

This is the time of the last-minute bug where the little innocent fix turns out to violate an assumption somewhere else.

My piano teacher Karen-Marie once explained to me that finales can be the most dangerous parts for a musician. When you stop thinking ahead, instead thinking about what you've accomplished, letting concentration slip.