In Your job is to deliver code you have proven to work Simon Willison writes: As software engineers we ... need to deliver code that works — and we need to include proof that it works as well. He is coming at this from the perspective of LLM-assisted coding, but most of what he says applies in general. I think this is a reasonable consise summary of his requirements for developers: Manual happy paths: get the system into an initial state, exercise the code, check that it has the desired effect on the state. Manual edge cases: no advice given, just a note that skill here is a sign of a senior engineer. Automated tests: should demonstrate the change like Manual happy paths but also fail if the change is reverted. He notes that, even though LLM tooling can write automated tests, it's humans who are accountable for the code and it's on us to "include evidence that it works as it should." Coincidentally, just the week before I read his post I told one of my...
In yesterday's Angry Weasel newsletter, Leadership is a Constant Experiment , Alan Page was explaining how, as a leader, he gets better results by trying things intentionally, in public, in a safe way: But in real work, confidence isn’t the superpower. Curiosity is. I feel this too, although confidence, or the appearance of it, can get you a good way up the greasy pole, if that's your chosen destination. In a post on LinkedIn today, John Cutler made an analogy between a software development teams and a restaurant kitchen where busyness is not a useful metric, and success means that great food is delivered as ordered in a timely fashion. He sadly concludes that: ... in software, effort is easy to generate, activity is easy to justify, and impact is surprisingly easy to avoid. This is a tragedy that plays out over and over. My primary goal in software is to help us to metaphorically put the right food on the right plates on the right table at the right time more oft...