Chosen links

Links - 4th July 2021

The access doctrine

There is a familiar, attractive story here: get online, learn to code, secure your future. Both liberal and conservative politicians have repeated that story for decades, updating it for the technology of the day, in an attempt to persuade the public that their individual and collective economic futures depend on their access to the right skills and tools. The narrative is so pervasive that it has become political common sense.

I call that political common sense the “access doctrine”. The access doctrine decrees that the problem of poverty can be solved through the provision of new technologies and technical skills, giving those left out of the information economy the chance to catch up and compete.

Like other forms of political common sense, the access doctrine mixes factual claims with ideological ones. It is clear, for example, that finding a job without an internet connection and a PC is difficult — just try filling out an application to work for CVS, let alone using USAJobs, on your phone. It is less clear that there are plenty of good tech jobs out there, just not enough coders to fill them. Economic reality is more complicated than political slogans might admit. Getting online and learning to code won’t change the rest of the labor market by itself.

The skills-gap narrative shifts the responsibility for training away from business owners and toward young individuals at the beginning of their working lives, as well as toward the public institutions that train them: universities, community colleges, and local and state governments. As management researcher Peter Cappelli has shown, what little evidence we have suggests that employers today devote very little time to on-the-job training relative to the postwar “golden era” of long-term, single-firm employment.

Unix shell programming: the next 50 years

There is no point denying it: the shell has many shortcomings and is hated by many. Shell scripts are unmaintainable, easy to get wrong, and inflexible with respect to performance; once a script is written it is difficult to refactor it to avoid redundant computation or properly utilize all the available computational resources. To make matters worse, the shell has been mostly left for dead by both academia and industry, considering it an unsalvageable piece of junk that needs to be replaced at the first opportunity.

The features and abstractions of the shell are well suited to the Unix file system and file-based abstractions. Unix can be viewed as a naming service, mapping strings to longer strings, be it data files or programs. Naming is both convenient and essential to (powerful classes of) computation.[1] Processes, PATH entries, files, streams, and environment variables are all names, and the shell is the tool for manipulating and interacting with these names.

Bitsy is Beautiful! (exploring the Bitsy space and some of my favorite Bitsy games)

I think a big part of the appeal is how egalitarian it is. A Bitsy game will look like a Bitsy game no mater how advanced of a developer uses it. There’s no room to invalidate people’s work as amateurish because, by definition, it exists just to make small things in it.

It creates space for people to just make something, while allowing for some very impressive art to grow out of its constraints… many developers even find their own voice with it. It’s beautiful to see people say that they got into game development because of Bitsy!

Focus vs coordination

Teams need both focus and coordination to thrive. Teams without focus are unproductive, while teams without coordination are counterproductive. A team without focus may be on the same page, but that page never turns. And a team without coordination may turn many pages, without ever stopping to ask if the book makes any sense.

But there’s a tension between our needs and our capabilities. We cannot focus and coordinate at the same time. Focus demands attention towards problems, while coordination demands attention towards people. Focus and coordination are opposing forces, pulling on the single thread of attention. This tension creates the focus-coordination tradeoff.

And if pair programming sessions are “coordinated focus”, then group planning sessions are “focused coordination”. Great all-hands meetings rarely start with: "`alright everyone: what’s the plan?`” But transforming dark, cloudy horizons into bright and compelling futures is the explicit purpose of planning sessions. Planning sessions should foster divergent ideas, then converge those ideas into a coordinated plan. But in order to pull off that transformation, these sessions need to be focused. Unfocused planning sessions feel like sprinting in place, with lots of talk and nothing to show for it.

The more people we add to a focus session, the harder it will be to focus. More time will be spent aligning ourselves instead of moving forward, and the more chances there are that communication either blows up or falls flat. Anyone who’s had a stressful but unproductive meeting knows this pain. Conversely, smaller groups are more focused, but their output will be less coordinated. Useful perspectives are more likely to be missing, and more people will need to be informed after the fact. You know this pain if you’ve ever come out of a meeting with an exciting plan, only to learn that important information was missing because critical people were not involved. This tradeoff between moving forward and moving together is just the focus-coordination tradeoff at play.

1. OlinShivers.2018. What’s in a name? Accessed: 2018-09-27.