Software Engineering as a Craft An Article by Thomas Wilson thomaswilson.xyz The decreasingly tangible product of code, i.e. that all we have are files on a hard-drive, may make it easy to forget that writing software produces a thing. If you produce a wonky chair or an overly long fork, it’s easy to see the quality of work was not great. By calling for a perception of software as a craft, we fight against that ability to forget or not notice the final quality of the product. You could watch two software engineers with different levels of experience, or in different domains, and it wouldn’t necessarily be so easy to guess which is which, at least from a distance. So maybe there is something to be said for the value of software as a craft, for sometimes focusing on the practice of making better, or at least different, software just for the sake of it. craftsoftware
I don’t believe in Zoom fatigue An Article by Matt Webb interconnected.org It’s not Zoom fatigue, it’s Zoom whiplash. It’s a hunch. I can’t prove this. The trick to get around this is to move smoothly up and down the gradient of social interaction intensity, never dropping below a basic floor of presence: the sense that there are other people in the same place as you. Instead of having two modes, “in a call” and “on my own,” we need to think about multiple ways of being together which, minimally, could be: In a video call In an anteroom to a video call, hearing the sound of others In a doc together On my desktop but with the sense that colleagues are around And the job of the designer is to ensure that their software ensures the existence of these different contexts, instead of having the binary on-a-call/not-on-a-call, and to design the transitions between them. communicationworktransitionssoftware