Hiccupps

  Episode 20 of Oddly Influenced , Brian Marick's podcast, is concerned with Julian Orr's book, Talking About Machines .  Orr makes much of war stories , the tales that colleagues tell each other about work they've done to help solve a live problem, commiserate about something that's gone wrong, or build culture. I recognise this from the teams I've been part of, communities of practice I've participated in, and meetups and conferences I've attended and run. Those stories establish our credentials, and to an extent our status, in our peer groups. Almost as an aside, the podcast mentions another kind of story, this one aimed not at the peer group but at those who are asked to assess their performance.  The group of technicians followed by Orr in his book were evaluated in part by account managers at the companies they were assigned to; people usually very distant from the technical work. This lead the technicians to go out of their way to make the outcomes of

    Yesterday, reading The Year Without Pants by Scott Berkun, this leapt off the page at me:  Diversity of skill makes people self-sufficient. It's in a paragraph about the culture at Automattic, the people behind WordPress, when Berkun worked there around a decade ago. The paragraph continues: "They didn't need much help to start projects and were unafraid to learn skills to finish them ... They weren't afraid to get their hands dirty in tasks that in a mature engineering company would span the turf of three or four different job titles. That lack of specialization made people better collaborators since there was less turf to fight over." Last week at work I observed that my team's build pipeline was broken. I do not enjoy investigating this kind of infrastructure problem. The company Jenkins setup has a complex ecosystem with many moving parts, my mental model of how all the bits are interconnected is fuzzy, and in any case all the bits keep changing. The

  I saw Maaret's Pyhäjärvi's post on LinkedIn   the other day. This line chimed strongly with me: Sense of lack of time. Someone asked how to have joy of discovery when feeling always pinched with time. We have in many cases lost control over time, and I have done work I have not necessarily appreciated on making time flexible - always seeing there is a next day and having no schedules and small slices of work. I feel like I do my work at various granularities across multiple dimensions and so, to begin to get this idea straight in my head, I tried to list some of them. It was harder than I thought it would be because so much of this is instinctive, intuitive, and in the moment. Given that, here goes draft 0.1. Hopefully I'll begin to feel more familiar with the idea and be able to revise the model later on. Scope Parcel of work . My team's practices are reasonably common, I think. Tasks are portioned into into Jira tickets which progress out of a back

The product I'm working on at the moment is a Ada, a symptom checking app . The basic idea is that users enter a few details about themselves and their current symptoms and are then guided through a series of questions which leads to them being given a list of probability-ranked conditions they might have based on their answers. As you'd expect in this field, with this kind of data, a lot of care and concern is taken to understand how the app performs and what caused any changes in that performance across releases. There are many layers of testing. In one of those layers we have medical test cases. (And these are literally cases in the medical sense.) Each one represents data about an individual who might present to a doctor with a particular set of symptoms, a given medical history, possible comorbidities and so on. Each also comes with a set of acceptable condition suggestions and other expectations about how the software should behave when asking this kind of user questions

My team uses Dependabot to keep software dependencies up to date. The tool submits PRs against our repositories and we use a checklist/decision tree to help us judge how deeply to review and provide an audit trail of the decision. Patch-level updates of company-internal packages might be just waved in if the tests pass, for example, but a major update of an external library could require us to review or redo a risk analysis. For reasons , the Markdown source for the tree is not automatically added to the PR so we pick it up from another repo, copy it, and paste it into the PR we're looking at. This has got sufficiently irritating to me that I looked for another way. I know about bookmarklets and I've made them before, so I first tried to make one that would paste the text into a comment box on the PR. The checklist is long and I needed to escape various characters and retain line breaks and it was tricky to edit and debug in a simple URL field, so I aborted. I wondered if the