Software working conditions
17 May 2022If you’ve spent any time around a traditional workshop or machine shop, you’ve probably seen signs about how safety is everyone’s responsibility and about keeping the shared space clean. In an environment with sparks, unrated flammables left around are a risk. In an environment with rotating tools like lathes loose clothing that can wrap or snag and pull can lead to injury. Less extreme examples like sweeping up the shop and keeping the fridge clean all fill different parts of the same shared obligation to the other users of a space.
Another important question in a shared space is the space and its ergonomics. Are the tables the right height to be comfortable when in use? Are appropriate assistive tools like lifts and jacks available as needed? Is there working volume around all the tools so that multiple people can move parts safely and at once?
A feedback loop that’s well developed in physical shops and under-discussed in software shops is the relationship between workers and these ergonomic considerations of the space. In a physical space, it’s common and indeed easy to tweak a shop. Tables can be adjusted. Chairs that don’t come up to the appropriate height replaced. Drawers, vises and other working assists can be added. Toolchests moved or replaced with movable cabinets that the workers judge more convenient.
Particularly when working with metal or wood, the distinction between the manufactured goods used in the shop and the goods made in the shop becomes somewhat forced. If your business is making furniture, making your own is no great leap. If you work metal, welding up a shop cart or putting taller legs on a stool similarly is no great effort. The shop is itself as much a product of craft and capability as much as anything produced in it, and the quality of the shop enables (or limits) the quality of work done therein.
Software is somewhat similar.
The only meaningful difference between a program you wrote and one you pull from a package manager is how long you wait for compilers.
Once it gets fork()ed, it’s all the same.
Much like these other classes of workers, the tools of our craft are the same tools used to make our tools. And yet often times we don’t see the tools we use day-to-day as things we own or mold to fit our needs better.
I’m not talking about individuals editor configurations or shell preferences. Like personal toolboxes, these are personal choices are somewhat beyond critique. Everyone loves to argue about the best handplanes or has their favorite screwdrivers. They represent our personal working conditions, not our shared working environment.
I’m thinking here much more of the infrastructure that supports development processes. What’s your code review flow? What’s your acceptance criteria? How much testing do you do? How much testing can you do or could you do? Do the codebases you share with peers enable collaboration? Or do they have meaningful barriers to understanding? When changes are made, how is the balance between delivery and architecture struck? How is that reviewed and owned within the group?
In every sense, these tooling and process considerations represent the working conditions of a programming role but rarely do I see them discussed as such. Conceiving of these things as working conditions is valuable, because it shifts the frame from these things being arbitrary business decisions to acknowledging if not demanding agency over them.
Don’t like a tool? Why? What problem is it solving or not solving? Can you make it better? Is there an alternative? Can you make the workspace better for everyone by changing it?
Does your patch respect the current structure of the code? If it revises it, does it fit within the existing lines or does it establish new lines? If you’re abusing existing structure, how badly? Is it worth leaving a mess in the workspace for the next person?
Did you remember to sweep up and power down the tools before you turn off the lights?
^d