Around the web
As you may have noticed, I write a lot. But writing about my work and writing in my work are different things. A blog like SICPers or this newsletter are the things that are on my mind, presented my way, often devoid of context. Within a project you need more contextual information: not "Graham thinks this is a good way to write software" but "Graham, Jennifer, Abhijit, and Tham met (Richard was on leave) and decided that this was the best way to proceed, for these reasons, given these constraints, and that we'll review that choice at this time".
Matt describes a few of the documentation tools (think templates, not text editors) that support that way of working. A common theme across his recommendations is the (semi-)permanence of things like RFCs and retrospective notes. Anything that gets written in a chat application is ephemeral, so doesn't become part of the collective knowledge of the organisation. And in knowledge work, an organisation is its collective knowledge.
In my current project we follow more or less the model here, although our RFCs start as Github issues or even draft issues in the project view. We know we need to do this, but we don't know how: what do you think of this approach? People comment, maybe meet, refine the understanding until there's enough concrete information in the issue to start working.
And that gets me to a missing point on Matt's list: effective meeting minutes. Things that were said in Meeting Room 367 or on the chat log in Zoom are even more fleeting than things typed into Slack. If folks agree that something needs doing, say as a result of a retrospective, then they should probably agree what that is, who will do it, when it will be done by, and how we will know that it is done. And that needs to be written down before it mutates into "oh, I thought I was splining the reticulates, and Doris was reticulating the splines".
I will also mention that presentations can be an effective and compelling tool for sharing some of this information. They can also be dull and supercilious, but when they're good they're much better than written documentation.
Steven and I use ARexx a lot on the Dos Amigans stream to build automated tests of our AmigaOS applications. It's just like a command shell in that respect, you say
address MYAPP and then every verb gets sent to the app port and interpreted by the host application effectively as its own scripting DSL. AmigaOS has its own
ReadArgs() library function that's used both by command-line programs and Rexx handlers, so there's a strong consistency across the OS that's missing from, say, Bash and GUILE on GNU/Linux or Powershell and VBA on Windows.
But I hate having to remember all the weird edge cases that programming languages have. I tried it once, with Objective-C, and look how useful that information is now. So articles like this are great as a sort of "anti patterns library" for the language. If I get an error I don't understand, I'll take a look at this post and ask "is my case described by any of these sections"?
Helge Heß demonstrates the valuable contribution of the MVC pattern and the consistency between building applications in SwiftUI, in WebObjects, and in Cocoa.
MVC started life in the Smalltalk land as Trygve Reenskaug’s Thing-Model-View-Editor, and was never really written up (it was due to be the subject of a book in the Addison Wesley Smalltalk-80 series, which didn’t get published). It’s impressive that four decades and countless implementation changes later, it’s still a great template for UI design.
I’m in this picture and I don’t like it.
I go back and forth on paper or digital note taking setups (or both/intermediate: Livescribe pens, penultimate and related apps, Remarkable tablet). Pen writing is way better for helping me remember things. But digital note taking is way better for helping me find things I’ve forgotten later.
I have notebooks going back at least to my undergraduate degree in 2000, and have “imported” some of them to Evernote on and off. But it can’t read my cursive, neither can Remarkable or Apple Notes. Honestly, I can’t sometimes. So I end up knowing that I have my notes but unable to use the information in them.
This needs fixing: suggestions welcome.
A counter argument to my plea for a better knowledge management system. I don’t buy it for two reasons. One is the unsubstantiated claim that ability to manage knowledge is genetic (I could believe a genetic component, I could more readily believe an educational component, but either way show me some evidence!).
More important is that the argument refutes organising knowledge as a web of hyperlinks (or a zettelkasten, or any other indexed system) ignoring the affordance of a search facility. If Google can “organise the world’s information and make it universally useful and accessible”, then a search tool to organise my information and make it personally useful and accessible should be readily tractable.
This article is a fascinating look at how one operating system manages a part of its asynchronous multiple processor system. An ARM-based Mac has both "performance" and "efficiency" cores (an arrangement called Big.little by ARM) and the operating system needs to balance the demands of the running applications, daemons and services with the users' expectations of responsivity, performance, and energy efficiency.
The documentation for Apple's XNU kernel includes a design rationale for the thread scheduler explaining why the traditional Mach approach was inappropriate and how the modern system improves on it. The Eclectic Light Co. article explains what that looks like in use.