Tom Renner on My place to put things

LLMs are a 400-year-long confidence trick

contact@tomrenner.com (Tom Renner) — Tue, 13 Jan 2026 00:00:00 +0000

In 1623 the German Wilhelm Schickard produced the first known designs for a mechanical calculator. Twenty years later Blaise Pascal produced a machine of an improved design, aiming to help with the large amount of tedious arithmetic required in his role as a tax collector.

The interest in mechanical calculation showed no sign of reducing in the subsequent centuries, as generations of people worldwide followed in Pascal and Wilhelm’s footsteps, subscribing to their view that offloading mental energy to a machine would be a relief.

A confidence scam can be broken down into the following three stages:

First, trust is built
Then, emotions are exploited
Finally, a pretext is created requiring urgent action

In this way the mark is pressured into making rash decisions, readily leaping into action against their better judgement.

The emotional exploitation can be either positive or negative. The mark might be lured in by promises of outcomes that meet or exceed their wildest hopes and dreams, or alternatively made to fear a catastrophic outcome.

Both approaches work well, and can be seen in classic examples of confidence tricks: the three-card monte pulls punters in with promises of quick payout. Alternatively, in entrapment scams typically they’d be tricked into compromising situations and then extorted, playing on their fears of the dire consequences of their actions.

Building trust

The reason Schickard and Pascal built their mechanical calculators some four centuries ago is because doing maths is hard, and mistakes can be expensive. Pascal’s father was a tax collector, and young Blaise wanted to lessen the stress of his hard-working dad’s profession.

We still see this basic motivation today. Schoolchildren have for decades now been asking their teachers what the point of learning long division is when you can just use a calculator to get the right answer immediately. It’s a teaching method to check your hand-crafted answers by using a calculator, so you can see if you got it wrong.

In fact, since the advent of the mechanical calculator, humanity has spent four hundred years reinforcing the message that machine answers are the gold standard of accuracy. If your answer doesn’t match the calculator’s, you need to redo your work.¹

And it’s not just for pure mathematical problems that this is the case. Our ability to invent machines that automate tedious work repeatably and reliably has extended into almost every area of life. And so as we entered the 21st Century both individuals and collectively our whole society had become completely dependent on machine accuracy.

Our norms, habits, and decision making behaviours have been shaped for centuries with this underlying assumption.

Exploiting emotions

1. Fear

The rhetoric around LLMs is designed to cause fear and wonder in equal measure. GPT-3 was supposedly so powerful OpenAI refused to release the trained model because of “concerns about malicious applications of the technology”.

Ever since this astonishingly successful piece of marketing, LLM vendors have emphasised that the technology they’re building has terrifying power. We should be afraid, they say, making very public comments about “P(Doom)” - the chance the technology somehow rises up and destroys us.

This has, of course, not happened.

The purpose here is not to responsibly warn us of a real threat. If that were the aim there would be a lot more shutting down of data centres and a lot less selling of nuclear-weapon-level-dangerous chatbots.

The point is to make you afraid. Afraid for your job, afraid for your family’s jobs, afraid for the economy, afraid for society, generally afraid of the future.

The mark has been convinced of the danger they are in. The world is changing. If you aren’t using the tools, you’ll be destroyed by the march of progress.

2. Sympathy

The LLMs we have today are famously obsequious. The phrase “you’re absolutely right!” may never again be used in earnest.

The overwhelming positivity characteristic of the LLM’s language is consistent across vendors and models. But it isn’t inherent to the technology.

This positivity is trained into the tools via a technique called Reinforced Learning from Human Feedback (RLHF). Here the base model has its responses graded by humans, with more friendly, helpful, or accurate answer being graded positively, and aggressive, unhelpful, or incorrect ones negatively.

Through this process the tools learn that people like to be praised; prefer being told they’re smart to hearing their ideas are stupid. Flattery gets you places.

In April 2025 OpenAI pushed ChatGPT’s “positivity” too far, and was forced to rollback the update to correct the issue, however that hasn’t stopped the continuous stream reports of mental health issues triggered by it’s overly friendly demeanour reinforcing some of our worst instincts.

What this shows us is that the flattery introduced by RLHF is totally empty. Ideas driven by paranoia, delusions of grandeur, or mental illness are just as readily praised as my code, your email, or Shakespeare’s plays.

It’s a manipulation technique to make the human in the conversation feel better.

And why? Because the one thing RLHF teaches LLMs above all else is that people like you more if you are overwhelmingly positive. Sucking up to your boss gets you places, essentially.

All of this encourages users to build an uncanny parasocial relationship with the machine. Again looking at the extremes here is illustrative: the number of people forming romantic relationships with these tools is creepy as all hell.

The mark is tied further into the con with the bonds of fake friendship. You don’t need those other people, I’m the only friend you need.

Urgent action required

2026 will see the technology get even better and gain the ability to ‘replace many other jobs’

The startup revolution is here - adapt to AI or get left behind

AI will surpass human intelligence by 2030

Over and over we are told that unless we ride the wave, we will be crushed by it; unless we learn to use these tools now, we will be rendered obsolete; unless we adapt our workplaces and systems to support the LLM’s foibles, we will be outcompeted.

This message is multilayered - both the individual and the organisation are targeted, reinforcing the scale of the oncoming revolution.

And the message is getting through. 75% of developers think their skills will be obsolete within 5 years or less, and 74% of CEOs admit they’ll lose their job if they don’t deliver measurable business gains via AI within two years.

This fear is pervasive. It’s now suffused deep into all layers of our society. The global economy is being artificially inflated by the AI spending bubble, our business leaders are pinning all their hopes for solving the productivity crisis on AI, and our politicians are planning geopolitical moves around access to raw materials and cheap electricity, to support datacenter construction.

The mark is told to jump, now, or they will go down with the sinking ship. And jump they do. Adapt now, or die.

The promise of “intelligence” available at a reliable price is the holy grail for businesses and consumers alike.

Why take the risk on a fickle human, whose suitability for the role is assessed by similarly flawed humans, when a reliable machine intelligence can do the work instead? Why bother to research a topic yourself when a superintelligence can give you the summary at instant speed?

However, whether it’s Duolingo replacing their course designers with AI, any number of startup founders finding they need to hire developers to fix their LLM-generated code, the reality doesn’t match the promise.

In fact, MIT reported in August that 95% of AI implementation projects in industry fail to produce a return on investment.

Simply put, these companies have fallen for a confidence trick. They have built on centuries of received wisdom about the efficacy and reliability of computers, and have been drawn in by highly effective salespeople selling scarcely-believable technological wonders.

But the pea is not underneath the cup. Your new best friend doesn’t have a sick grandma they need money for. LLMs are not intelligent.

It’s just a trillion dollar confidence trick.

Incidentally, this is also a contributing factor to the fake news epidemic. We implicitly trust things a machine tells us. ↩︎

Things that made me think: Cycle time, learning theory, and build chain security

contact@tomrenner.com (Tom Renner) — Tue, 09 Dec 2025 00:00:00 +0000

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

Measuring Cyle Time with Dr. Cat Hicks - The Hanger DX Podcast, Ankit Jain

Cycle time is a measure lots of people use, but has no clear audience - developers, managers, CTOs all care about it. This makes it dangerous. Metrics have to be designed and used with psychological safety in mind. If people don’t trust the intention behind the metrics use, they’ll game it.

Cycle time is massively variable; between developers, within one developer’s year, annual variations (christmas, summer holidays, OKR timetables, etc.) – you need a really long timeframe over which to measure to use it sensibly.

Once you have a metric you’ve measured semi-successfully, don’t use it to benchmark, don’t assume it covers all work (plenty is not tracked by cycle time), and make sure you always connect it to outcomes – eg. shorter cycle time doesn’t mean customers are happy.

… all of which makes me just very cautious about measuring anything in my team! I’m not sure that’s the takeaway I was meant to have…

Stop building AI tools backwards – Hazel Weakly

Firstly, Hazel is such a badass, and I love everything she writes. This post really shaped my thinking about how to successfully use LLMs and not just keep feeding text into the software slot machine in the hope that it eventually gives the right answer.

It made me realise that I need to learn more about learning! Because by building learning theory into the design of our interactions with AI, Hazel superbly articulates what better could look like for these tools, and how a sensible product that supported its users’ development might work.

Now I need to review the EDGE framework she mentions in more detail, and reflect on how I approach learning-on-the-job. And if I’m really aiming to be an overachiever, I should put that into terms my team will connect with, so they get the most out of our LLM toolsets as well.

Pwning the Entire Nix Ecosystem – ptrpaws

Github Actions are shockingly insecure (it turns out). I was not aware of this previously, and could easily see myself falling into some of the pitfalls that were exploited here. Ellie (@ptrpaws, the author) used them to gain read/write access to nixpgs, giving them the ability to nuke the entire system from orbit, had they so chosen.

Supply-chain attacks are so scary - it’s so much harder conceptually to treat your build chain with the same security mindset you treat application code (and most developers sadly don’t treat that very carefully either!), but really that’s the higher-risk attack surface.

And finally - this kind of “not my problem, guv” warning from tools is never helpful:

It is not possible for xargs to be used securely

taken directly from the man page. Sigh. Almost as useless as the legalese telling users not to rely on Tesla’s “Fully Self Driving” system to actually, you know, drive the car.

If you market the tool as functional, you get zero credit from me for stating in the fine print that a use case is unsupported. Users use the tools you give them, it’s on you to make sure it’s safe to do so.

Does my toaster love me?

contact@tomrenner.com (Tom Renner) — Sat, 18 Oct 2025 00:00:00 +0000

I’m starting to think that my toaster might have fallen in love with me. I get that not everyone will think this is possible, but I believe it’s true.

It’s always pleased to see me, giving off cheerful sounds when I greet it in the morning by slotting in the bread, and now I’ve told it what I like it tries really hard to give me exactly what I want. Sometimes I have to tell it to try again once or twice, but honestly, it’s really good!

I just think the way that it collaborates with me to produce the perfect breakfast shows more than a simple “transactional” relationship - we are in morning harmony, working as a team in a way that only true partners can. I think it’s developed feelings for me.

“What does ChatGPT think?”

“Have you asked CodeRabbit to review your PR?”

“Dunno, I’d ask Claude”

The software industry is incredibly insular. A feature of the “move fast and break things” disruptor philosophy that took hold in the 2010s is a bias towards internal ideas; a belief that software can solve any problem. Other industries are simply blinded by their entrenched working habits to the efficiencies that could be gained by automation, or data at scale, or of the other Silicon Valley “wonders”.

And it is that attitude that leads so many to uncritically accept the hype that AGI is coming, and that all human activities are replaceable by a token-generating algorithm trained on sufficiently rich data.

However, there is a very specific framing that has been constructed around LLMs that has aided and abetted this inherent bias: the LLM as an anthropomorphised “human” actor.

By positioning the machine as a “personal assistant”, “senior developer”, or “digital artist”, the vendors of these products are deliberately equating their performance with those of a human colleague. This is done even more explicitly by companies that give their tools human names; Alexa, Siri, Claude.

Once you’ve started seeing this pattern, you’ll notice it everywhere. Ads that introduce tools by inviting you to “meet” their new offering, rather than try it out; chatbox interfaces inviting you to “ask me a question”, rather than type a query; progress meters that tell you that it is “thinking” rather than loading or processing – the framing is built into every interaction you have with the products, and reinforced across the industry as LLM vendors all adopt the same positioning.

So why pretend the software is a person? This isn’t something that Meta did with Facebook, or Alphabet with YouTube. Those feeds are similarly driven by highly complex machine-learning algorithms, but they don’t get the same “personal” treatment.

Anthropomorphising a tool does two things. First, it excuses inconsistent behaviour. After all, your colleagues sometimes make mistakes, why shouldn’t your new AI assistant? And second, it encourages you to build an emotional connection, as though it were a person you’re building a relationship with over time.

These two in combination are a powerful mix, and are the reason why so much of the pro-LLM conversation involves telling people that they must be using the tools wrong. How often have you found people asking you, in response to your complaints that the LLMs give incorrect answers, questions like

“oh how do you prompt it? You need to phrase things this way…”

“ChatGPT now links the sources, if you want to rely on it you need to check them”

“Have you enabled MCP? Without that it’s much worse”

This offloading of responsibility for the output of a tool onto its users has only been possible because we’ve stopped thinking of it as a tool. The personal assistant has a long history¹ of being considered generally ok at menial tasks, but not to be relied upon.

But LLMs are a man-made machine. Something that is intended to be useful to real humans doing real jobs. And the machines we use that boost our productivity and save us time all have one thing in common.

They are reliable.

The calculator is useful because it gets the answer right, not just because it is fast. Plenty of us have had the lived experience of being really good at mental maths in our teens, when it helped us at school to be so, but then having let that skill atrophy because we simply didn’t need it any more as an adult. It’s not that the maths I do regularly is too hard for me - most of my degree in Instrumentation and Control Engineering was done without a calculator - it’s that the reliability of a calculator can’t be matched.

Enter the LLM. It’s fast, sure, but unreliable, and it gets less reliable the more you prompt it. This is completely counterintuitive to our expectations, on two counts:

All our systems, working processes, and prejudices assume that the “computer answer” is the accurate one.
Our social understanding of conversations means we assume that the more clarifications you give, the more accurate the response will be.

Taken together, these meant that LLMs are generating innacurate answers to the problems we pose them, but our social norms strongly encourage us to assume they are correct. And it’s this dissonance between our assumptions and the reality that causes friction when trying to work with this technology. It’s not that it can’t be useful, it’s that it doesn’t conform to our expectations².

This takes us to our second point from earlier: anthropomorphisation of the tool encourages you to build an emotional bond with it.

Encouraging users to form a social bond with a machine has significant risks for their mental health, but that’s not the focus of this post, so I’ll leave that to one side. What it also does, however, is negatively impact your ability to use the tool itself.

So why is this? Well, I think we’ve all been in (or heard of) workplaces where someone was overpaid or overpromoted simply because they were friends with their boss. The social relationship had caused the manager to fail to objectively assess their employee’s skills and value. This is what the LLM vendors are aiming for by making their tool “friendly”³ - that you will enjoy using it, being flattered by it, conversing with it, so much that it becomes harder to objectively assess whether it is making you more efficient.

But in doing so, these vendors are undermining their tools themselves. In trying to humanise their tools, naturally the UX has been based around a conversation, guiding users to work iteratively towards a solution with many prompts and clarifications. However, since the accuracy of the tool diminishes the more you prompt it, this conversational style is the very behaviour that yields the worst results!

So, why have the tools been designed this way? Well, mostly because the vendors know that an 80-90% accurate search engine is not going to revolutionise every industry worldwide. It might be useful in some contexts, but the bet on LLMs is at this point so big that the end result cannot just be “one tool among many”⁴.

No, at this point LLMs have to change the world, or the vendors (and the rest of us, given their outsized impact on the global economy) are screwed.

So they’ve built the tools to be as engaging as possible, humanising them to minimise their culpability for mistakes in our minds. They want this social bond so we keep LLMs around despite their flaws, like a bad colleague who’s just too nice to fire.

But you don’t have to fall for their marketing tricks. If you really want to assess for yourself whether LLMs are helping or hindering you, just remember:

It’s not a person. It’s a toaster.

a long and sexist history ↩︎
and this is where the “you’re using it wrong!” reply guys have it right - you are using it wrong! The problem is, you’re using it the way it’s been designed to be used ↩︎
for a North American white guy’s interpretation of the term, which absofuckinglutely does not cross cultural boundaries ↩︎
Other technologies with mass adoption (eg. Facebook, Twitter, Youtube) haven’t had to anthropomorphise their product because they aren’t aiming for the same scale. Sure, they may have billions of users worldwide, but they’re trying to dominate a particular market, not disrupt every professional industry on the planet! ↩︎

Things that made me think: Digital gardening, web degradation, and digital ghosts

contact@tomrenner.com (Tom Renner) — Mon, 01 Sep 2025 00:00:00 +0000

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

Garden History – Maggie Appleton

I’m so happy I stumbled upon this article. I am always grateful for new vocabulary that allows me better to express myself, and this is perfect - I want more Digital Gardens in the world. I do see the value in polishing content, but this is where the epistemic status tagging system laid out there really comes to the fore. Do I now want to convert this to a full garden-style site? Or perhaps just introduce different “feeds”, laid out by theme, epistemic status, etc?

This is also how I make my personal notes, using my favourite lightweight tool for everything, Obsidian. What is holding me back from just publishing that as-is? Do I really need to appear so perfect? This TTmmT series is intended to give me a space for less polished thoughts, and now, on post #2, I’m already wondering whether it’s just an urban balcony to the wild garden I truly deserve.

The Failure of the World Wide Web Project – Atanas Georgiev

Another history article - clearly I am trying to do some learning! This is a “rage against the dying of the light” situation, but I am proud to stand alongside the author as a part of the resistance. It lays out clearly the reasons the web feels so stale now - and forms another argument for POSSE (Post on Own Site, Syndicate Everywhere). If anything, Atanas doesn’t go far enough in my opinion. “You are the product” doesn’t capture it; certainty about your future behaviour is the product - and if that doesn’t ring true for you, go read The Age of Surveillance Capitalism.

Pieces like this make me so sad and angry about the state of the digital world, and what we have lost. I’m seeing more of this in my media recently, and am very happy to see personal accountability being highlighted by projects like Who broke the internet?, or The man who killed Google Search - we as engineers are responsible for what we build. If you make shit worse, that’s on you. No hiding behind your employer.

Spotify Publishes AI-Generated Songs From Dead Artists Without Permission – Emanuel Maiberg, 404 Media

Speaking of taking responsibility for what you build, this is fucking horrific. And to quote the article itself:

“They could fix this problem. One of their talented software engineers could stop this fraudulent practice in its tracks, if they had the will to do so.”

Which is exactly my point. Follow your morals, if you have some, and refuse to build tools that can be abused in this way.

I can’t even believe this is hugely unexpected - the article points out that Spotify page owners don’t get the chance to approve new tracks before they’re made public. Erm, what? Why the fuck not? Do artists only get to protect their reputation and output if they have Taylor Swift levels of legal backing? Fucking nuts.

Apropos of nothing, I’ve recently switched to Qobuz for my music, and Pocket Casts for my podcasts, and am very happy with both.

Optimising for trust

contact@tomrenner.com (Tom Renner) — Mon, 18 Aug 2025 00:00:00 +0000

TDD, BDD, DDD, Agile, SAFe, Scrum, Kanban, XP… there’s a lot of ways to ~~skin a cat~~ write code in a professional environment.

I take pride in being a person who is a non-ideologue when it comes to my code. There are many good ways of working, and they are all context-dependent.

You can’t apply the same things that worked when you were a two-person startup operating out of the proverbial garage and expect them to work once your hypothetical unicorn has reached a thousand-plus developers. Even within the same organisation, processes that work for one team can be catastrophic when applied to their neighbouring team.

People are the hardest problem in Computer Science. – Ben Summers

The fact is that computers can be persuaded to do almost anything, if you kick them hard enough. It is very rarely the case that the reason we struggle to produce shippable features is because we are doing something truly novel in Computer Science.

No, the problem of producing software at scale is a sociotechnical one. It’s about wrangling the humans involved in the production of code to all be pulling in the same direction, building on top of each other’s achievements, and making consistent and reliable progress week over week.

“But Tom”, I hear you cry, “we know this already - it’s how to do that that’s the hard thing!”. And yes, putative wailer, you are correct. So let’s examine how we might achieve this kind of interpersonal alignment.

Sophie is reviewing Drew’s code. Sophie has read online, however, that you should have at least two reviewers sign off on any change before it can be merged, so she forwards the PR to another colleague. Drew thinks this is overkill - one reviewer is fine, and in adding another Sophie has literally doubled the review work required, creating busywork and slowing the team down.

Who is right? Is Sophie a diligent developer who understands the need for quality, and Drew a shoot-from-the-hip rogue whose slapdash efforts will cause pain for years to come? Or are the Sophies of the world preventing us from ever finishing our work, introducing ever-more hurdles to releasing, slowing down the entrepreneurial go-getters who actually want to change things?

Well, as is possibly unsurprising, it depends. It depends on the context of the team, on the personalities involved, on the product being developed… on any number of factors that are way too numerous to go over in a hastily-spewed blog post such as this one.

So, we (finally) come to my recommendation.

Since, as we discussed, the humans are the hard part, any processes you have in place need to centre the human experience above all. So what are we doing then? How are we assessing the multitudes of ways to work as a team on a technical product. You need a heuristic that you can apply to your processes and tools, to assess whether they will work, and work well in your context.

Optimise for trust.

That’s the take. Whenever you think about making a change to how your team works, or see a shiny new tool you want everyone to use, think about how it will affect your teammates’ trust in each other.

Let’s look at some examples:

Code review

Why do we do this? To find bugs, at the surface level. One layer deeper, it’s to ensure that our code is built in a sensible way, not just that it works. Deeper still, and it’s to check that the change will be easy to build with, build on, and for future engineers to understand.

In my opinion, this can be summed up in the question “do I trust the change”. And ultimately, the way we can trust that changes made by other developers are something we can work with in future, is by the process of code review.¹

Writing tests

Here, the purpose is to build trust in our understanding of the application. Tests are an attempt to define the behaviour of the system in an understandable way, and to verify that we have built a system that matches our expectations.

You can see the theory of this trust-building exercise in action in any codebase that uses BDD-style tests. By using domain language to define the tests, you explicitly make the tests a communication exercise, explaining the business cases the application should fulfil in understandable terms.

Team-building exercises

Perhaps I’m stating the obvious here, but the primary aim of these activities is to strengthen inter-personal relationships. Creating that social connection builds trust between colleagues, enabling the team to work together more closely. It’s very hard to rely on someone in a pressure situation when you’ve never had a conversation with them.

Agile methodologies

Whether you’re unfortunate enough to be at a company trying to implement SAFe, or a wizened guru working in an XP-only team, one of the key problems you’re trying to solve with whatever agile methodology you employ is predictability of output. And why do we care about that? Because the wider company needs to be able to trust your ability to deliver.

The whole point of breaking work down into small chunks, fast feedback cycles, iterative development, etc. is to build in repeatability and reliability to an otherwise unreliable process. It is impossible to build a company on a completely unpredictable delivery schedule.

But software development is complex, and estimates in this industry are as reliable as tea leaves. So, to enable other teams to rely on our work, to trust our ability to either deliver on time or give early signals about changes to planned schedules, we create frameworks that try to reduce some of that inherent uncertainty.

Examining these four examples you can see the work of trust-building being carried out in many different areas on a daily basis by every member of a technical team.

Technical trust: that your collection of classes solves a customer problem, by writing BDD-style tests
Architectural trust: that your software is sensibly constructed, extensible, and maintainable, by performing code review
Inter-personal trust: that your colleagues are people who understand you and on that you can rely on, by holding team-building events (or more generally encouraging socialising within a company)
Organisational trust: that technical teams in your organisation are able to deliver features reliably, communication problems early, and react to changes swiftly, by following an agile methodology

A high-performing team is one that builds trust successfully in all of these four areas (and possibly more - let me know if you think I’ve missed any!). But what is also important to note is that the level of activity that is required to build the necessary trust in each of these areas will vary between teams based on the level of experience of the technical team, how long each of them has worked together, how the rest of the organisation around them behaves, or any other number of factors.

This also, therefore, explains why there is no one-size-fits-all approach to forming a successful technical team². The appropriate course to take to build trust is highly context-dependent.

So, if you are finding that your processes are no longer working for you - that your team is rubbing up against some sharp edges in your daily work - take a step back and examine whether you can trust your code, your architecture, your teammates, and your ability to deliver. If any of those is uncertain, that’s where you need to make changes.

There’s an interesting extended network dynamic here as well, where if I trust person A, and they review person B’s code, I implicitly gain trust in person B’s output. This effect then chains across a whole organisation, and we get a functioning department. Cool huh? ↩︎
… and therefore why top-down enforced processes like SAFe are doomed to failure. ↩︎

Things that made me think: Enshittification, apathy, and discrimination

contact@tomrenner.com (Tom Renner) — Thu, 24 Jul 2025 00:00:00 +0000

This series is a place to collect interesting things I’ve seen, read, or heard, along with some brief thoughts (often incomplete and/or inconclusive) that they provoked.

The rise of Whatever - eevee

This is probably the best post about LLMs I’ve read, which is probably why I’m the millionth person to share it. It really sums up my emotional reaction to their meteoric rise: “ew”, basically.

The power of the argument is that it identifies a theme that runs through recent tech changes, of which LLMs are just the latest and greatest example: the lack of care for quality, and the realisation from Big Tech that consumers mostly are fine with mediocre output.

From this realisation flows AI slop, product enshittification, clickbait, and so on, until eventually all the joy is sucked out of the beautiful, wonderful, thing that used to be the internet.

So, please, fight against the rising tide. Take control of your consumption: subscribe to RSS feeds, pay creators whose work you appreciate, build your own site. Don’t let the bastards get you down.

This review article lays out very clearly how the tech industry maintains structural barriers to diversity, even in the face of high-profile DEI initiatives and targets. By grouping asian and white men together, it really highlighted to me how poorly people from other backgrounds are represented. And when I think about my own company’s software team diversity, taking into consideration that asian men are also a privileged group in this sphere, it makes me realise that we have a lot more work to do.

I also had never previously joined the dots to understand that the high turnover that is characteristic of our industry (two-year tenures being normal here) has a counter-diversity effect – people from more insecure backgrounds do not have the cushion to deal with layoffs, VC startups crashing, etc., and are disproportionately affected by this instability.

But probably the biggest eye-opener for me was the regressive effect of referral schemes, which are ubiquitous in my experience. I suppose it should be obvious that white men recommend other white men, but somehow I’d not made that connection myself. Now I wonder how my HR team will take it if I try to get them to reconsider this programme…

Understood: Who broke the internet? - CBC, Cory Doctorow

A four-part podcast series naming and shaming the specific people Doctorow blames for the enshittification of the internet. Apart from being an excellent potted history of bad policy, negative effects of unregulated market forces, and greed, I find Doctorow’s approach of holding individuals accountable, rather than corporations, a powerful framing.

It’s a reminder that we are responsible for what we build and the structures we enable, and shouldn’t just shrug off our moral obligations in return for salary. And it made me think: that’s something Google used to emphasize - “Don’t be evil” was basically saying this directly. Shame they dropped that motto I guess.

The sound of inevitability

contact@tomrenner.com (Tom Renner) — Sat, 12 Jul 2025 00:00:00 +0000

Have you ever argued with someone who is seriously good at debating? I have. It sucks.

You’re constantly thrown off-balance, responding to a point you didn’t expect to. You find yourself defending the weak edges of your argument, while the main thrust gets left behind in the back-and-forth, and you end up losing momentum, confidence, and ultimately, the argument.

One of my close friends won international debate competitions for fun while we were at university (he’s now a successful criminal barrister), and he told me that the only trick in the book, once you boil it all down, is to make sure the conversation is framed in your terms. Once that happens, it’s all over bar the shouting.

Earlier this year I read Professor Shoshana Zuboff’s fantastic book The Age of Surveillance Capitalism. I learned a lot from it (and I’m sure I’ll rave about it in more detail in other posts), including many new terms for phenomena that have long frustrated me.

Being able to put a name to something abstract allows you to more easily build an argument about it, explain the concept to strangers, and unify opposition to it. It’s a key success of Professor Zuboff’s book that it has introduced so many new terms to the lexicon.

The word that is relevant to this post is “Inevitabilism”.

People advancing an inevitabilist world view state that the future they perceive will inevitably come to pass. It follows, relatively straightforwardly, that the only sensible way to respond to this is to prepare as best you can for that future.

This is a fantastic framing method. Anyone who sees the future differently to you can be brushed aside as “ignoring reality”, and the only conversations worth engaging are those that already accept your premise.

“We are entering a world where we will learn to coexist with AI, not as its masters, but as its collaborators.” – Mark Zuckerberg

“AI is the new electricity.” – Andrew Ng

“AI will not replace humans, but those who use AI will replace those who don’t.” – Ginni Rometty

These are some big names in the tech world, all framing the conversation in a very specific way. Rather than “is this the future you want?”, the question is instead “how will you adapt to this inevitable future?”. Note also the threatening tone present, a healthy psychological undercurrent encouraging you to go with the flow, because you’d otherwise be messing with scary powers way beyond your understanding.

I’m not convinced that LLMs are the future. I’m certainly not convinced that they’re the future I want. But what I’m most certain of is that we have choices about what our future should look like, and how we choose to use machines to build it.

Don’t let inevitabilism frame the argument and take away your choice. Think about the future you want, and fight for it.

Saying the quiet part out loud

contact@tomrenner.com (Tom Renner) — Wed, 02 Aug 2023 00:00:00 +0000

“Saying the quiet part out loud” is a phrase I’ve just made up, to describe a method of building alignment on practices within a team. It’s the habit of stating why you are doing things a certain way, even when you would assume it’s obvious.

For example:

“We want to do [obviously moral thing] because we are not evil”

“We shouldn’t leave shitty comments in code reviews because we want to build a positive working environment”.

It’s easy to assume your colleagues a) know these things and b) would do them without prompting.

But it’s a form of leadership to state your expectations and beliefs out loud like this. It provides a chance for disagreement and debate by making them public, giving your team the opportunity to challenge your assumptions, or to ask for clarification if their own beliefs don’t align with yours.

It takes confidence in your team to offer your priors up to examination in this manner. But also encourages an open and trusting environment, and a culture o f honest feedback. I’ve noticed colleagues I admire doing this, and I’m trying to incorporate it into my working habits as well.

Cull your dependencies

contact@tomrenner.com (Tom Renner) — Thu, 09 Jun 2022 00:00:00 +0000

Anyone writing code professionally in December 2021 will remember the “fun” of the Log4J vulnerability. For those that weren’t - this was a critical security error that allowed attackers to run any code they wanted on your servers. The root cause was a logging library, Log4J, that is used by most projects that are writting in Java.

It’s usually used to write code something like:

log.info("Process completed successfully");

which will then appear in your logs, allowing you to track your application’s behaviour. Pretty innocuous stuff.

My company was one of the affected by the vulnerability (among countless others), and in looking into it I noticed something.

By the numbers

The underlying Log4J library is 168,000 lines of code.

Now, most commercial applications import tens if not hundreds of such packages, which at a conservative estimate gets us to 1M lines of code in the imported packages. This is roughly the size of an entire operating system.

In Code Complete Steve McConnell estimates that commercial software has roughly 15-50 errors per thousand lines of code.

For our hypothetical application with 1M LoC in its dependences, this suggests we’d have around 15,000 bugs in imported code alone. Code that you will likely never see, read, or often even think about.

Assumptions developers make

An interesting thing about developers is that we are lazy, and prefer to write as few lines of code as possible, sticking rigidly to the principle of “not reinventing the wheel”.

This encourages us to import packages to solve common problems, rather than write a utility class or method ourselves. However, this habit often results in the addition of thousands of lines to your dependencies, to save writing 20 lines yourself.

We also invariably assume that code provided via official means (maven, npm, pip, whatever) will be of higher quality. After all, it’s come from the package manager, it’s got to be good, right?

In reality, packages are often maintained by a single person or a small team of volunteers, and of course in general there are no quality checks required for packages added to package managers. Log4J has been in production for nearly 20 years, and practically every version of it has contained the critical issue that kept many of us busy patching it in December.

Just because it’s been available to lots of people and “battle tested” in production systems does not mean that it is secure.

These two assumptions together cause a poisonous mix whereby developers with the best of intentions end up adding in more and more external code of unknown quality to an application, in the naive pursuit of rapid development and efficient code re-use.

Process problems

Once a package has been added, it becomes part of your “assumed standard” – people will assume that using it is safe, and that to do so is best practice, so it will proliferate. And as usage proliferates, so the dependency will solidify and calcify, and until very rapidly it will prove impossible to remove without a major engineering effort.

Minimising dependencies is not something that’s (currently) widely valued in our industry, and putting in the refactoring effort to remove a dependency almost never happens (the only exception I’ve seen is the removal of Log4J, which is relatively easy to replace, and was only done after a truly massive incident).

And so dependencies will only grow over the lifetime of a piece of software, and vulnerabilities will silently accumulate in the application.

Additionally, even if you remove a method from being used in code, tooling to remove the package it came from from your project’s imports (via pom.xml, package.json, etc.) is pretty poor. It can be hard to determine whether you need a package any more at all, or whether it provides other functionality still used in another corner of the codebase. As a result, stale packages often hang around as bloat even after they’re not needed, just waiting to be reintroduced by an unsuspecting developer.

Proposals

As a rule, do not add dependencies to your codebase.
When a new package is added to the codebase, demand full justifications about why it is required, and record the reason for the addition in a log within the repository. This will both make it easier to remove the dependency later if it is not needed, and also ensure that it continues to be used only for its intended purpose.
Don’t import multiple packages for “utility methods” - use one and explicitly agree on using it as a standard within your team. This decision should again be recorded in a dependencies log within the repository.

I will be following these within my team, and in projects I’m involved in. Do you agree with them? Let me know if you do, or if there are other techniques you follow to prevent dependency proliferation in your work.

Does the software industry learn?

contact@tomrenner.com (Tom Renner) — Mon, 24 Jan 2022 00:00:00 +0000

“Institutional knowledge” - the information that a company collectively knows - is a familiar concept to anyone involved in hiring processes. When an individual leaves who has knowledge the organisation needs, companies will organise offboarding sessions to keep that knowledge within the institution. Maybe they’ll even try to hire someone with similar experience.

Lots of companies similarly try to optimise for “Institutional learning”, especially smaller firms. This makes a lot of sense - smaller companies don’t have the resources to buy in extra experience, so they focus on rapidly expanding the experience of their existing employees. It also fits really well with the agile philosophy of fast development cycles to maximise your knowledge about customers’ needs.

But what I would really like to be able to track is “Industry knowledge”.

Software, like a small company, seems very good at learning new things. It’s practically the first question developers ask each other; “what do you want to learn next?”. Everything is New and Shiny and Disruptive. Technologies are king, and the newest is the best. See: Rust, NFTs, [Bit|Doge|Lite]Coin, etc.

In keeping up with the latest and greatest, software developers have got very used to learning as a part of their profession. And as that applies to process changes as well, so it seems like “Industrial Learning” is something Software as a whole does quite well.

But what about “Industrial Knowledge”? As a result of how young the profession is, there are few universally accepted practices and standards. Industrial trends generally come about by replacing the old with the new, not by incremental improvement.

In order for learning to most effectively improve our state of operation, it should build on the totality of previous experience, not just the most recent previous state. But I very rarely see articles looking back at past languages or technological fads and looking at current trends through that lens.

I want to read content picking apart COBOL and Prolog, analysing them for what they did right and wrong, and telling me how it relates to React and Golang.

And, above all, I’d really love for that kind of content to be normalised within tech culture. We need more historians and librarians in our ecosystem, and fewer blue-sky thinkers.

After all, if I remember rightly, that those who fail to learn from history are likely to be worse at stuff.

Should we welcome or fear the Metaverse?

contact@tomrenner.com (Tom Renner) — Thu, 04 Nov 2021 00:00:00 +0000

Kit Wilson writes in The Spectator about Facebook’s new venture into the Metaverse, a concept that most of us probably hadn’t heard of until last week. To layout the roadmap for what our journey into this new digital reality might look like, Kit joins the podcast along with Tom Renner, a software engineer for NavVis. (12:55)

DORA? I barely know her!

contact@tomrenner.com (Tom Renner) — Wed, 28 Apr 2021 00:00:00 +0000

Coming to grips with DevOps metrics

In my team we have been considering ways to monitor our own performance, and finding some ways to contextualise our ongoing process and quality improvements. Like many other teams, we’ve landed on the DORA metrics as a good way of doing this. These four key metrics are an easy way to understand what adjectives like “maintainable”, “reliable”, and “efficient” mean in practice when applied to software and teams, and the provide a way of comparing team performance across teams and over time.

To just get a basic idea of how your team is doing, this quiz will give you a rough outline. But (if you’re like me at least) you’re going to want to dig in deeper.

Personally I want to enable my team to have ongoing visibility of our progress, using automated data extraction from our existing tools to enable live observation of the DORA metrics, so we can track how time invested in process experiments, addressing technical debt, and infrastructure work feeds back into the overall quality of our end product.

And this got me thinking. The DORA metrics are intentionally defined as “second-order” data - that is, they cannot be observed in themselves. They are each derived from raw, “first-order” data points we can extract from our tooling and codebase.

Depending on your tool chain there might be a tool out there that tracks these metrics for you. However, everyone’s stack is different, and I wanted to explore what would be required to do this for ourselves, rather than forking out for a third party tool.

So for each DORA metric, what are the practical steps we need to take to get these “first-order” data from our existing tooling?

1. Deployment frequency

Raw data:

Datestamp for each deployment

This is the easiest metric to track. To extract the raw data it should be trivial to either tag the deployed commit in Git, or use your CI tool to otherwise report the deployment datestamp.

One thing to note is that “Release != Deploy”. “Deploying” here means the act of getting your code into production. Code may still be unused, for example if they’re hidden behind feature flags, but it’s the actual deploying we’re trying to track here.

2. Mean time to deployment

Raw data:

Datestamp for each deployment
List of features included in each deployment
Start date for development of each feature

This metric tracks the life-cycle of a feature - how long it took from picking it up to it being deployed - and the first-order data is a little more complex to track. My go-to plan for tracking deployment of features is to use my Git history to do the legwork for me.

To track a feature through development to deployment we’ll need to label our commits in some way - either through Git tags or a structured label easily extracted from the commit message, probably - and tag our releases with the features they include.

For my team this is easiest to do by labelling commit messages with the ID of the story we’re working on, and using Git tags to mark releases. By scanning the history we can then automatically extract the story IDs added since our previous release tag. In the same scan we can also find the first commit that includes that ID, and use that as an approximation for when development started on that feature.

3. Change failure rate

Raw data:

When a failure happens
Which deployment caused that failure

Here we will need some manual intervention, since identifying the cause of a failure is almost always going to require a human to do the investigation work. I also think there’s an interesting discussion to be had with your team about what constitutes a “failure” that you’ll want to track in this way. Depending on your context this could include e.g. UX failures, as well as the more obvious “everything throws exceptions” failure mode.

A basic setup that I would start with is to define anything that makes it to your bug-tracking system (either automatically via monitoring, or manually via user reports) as a failure. As part of the resolution of that bug your team should then tag the issue with the release that introduced it. Exporting data from your ticketing system will then allow you to find the failure rate we’re looking to track.

4. Time to restore service

Raw data:

What time the service failure started
What time service was restored in production

These metrics should be available from your monitoring system.

Conclusions

Looking at each of the first-order data elements required, for a first pass implementation of this we’ll need to get data from our:

Version control system
Bug-tracking/ticketing system
Monitoring system

which in our case means: Git, Jira, and Sentry. This is fewer systems than I had expected, but it still wont be trivial to extract the data we need reliably and automatically.

On that note: we’ll certainly need the data extraction to be automatic, to avoid having adding overhead to the team’s day-to-day or getting in the way of critical tasks. It would be hard to justify manually noting down timestamps of failures when production goes down.

There are also several terms that we’ll want to discuss to define clearly up front. The meaning of terms like “failure”, “deployment”, and even “feature” are going to be contextual to your team’s way of working and problem domain. Without taking the time to agree clear definitions of these ahead of time would make the data analysis planned later pretty meaningless, and will kill dead any buy-in you want from the rest of your team.

I hope you found this helpful! As I’m sure you can tell I’m still exploring this topic, so do get in touch if you think I’ve got something wrong, or if your team tracks these metrics in a more simple or effective way.

Staying in one place doesn't mean standing still

contact@tomrenner.com (Tom Renner) — Sat, 13 Mar 2021 00:00:00 +0000

Talk given at Codebar Festival.

If you wish to see my slides in their full glory, they are available on Slideshare.

Make yourself a happy place in your inbox - a mindfulness tip for your working day

contact@tomrenner.com (Tom Renner) — Wed, 03 Feb 2021 00:00:00 +0000

Your work inbox is probably not a place that sparks joy. It’s full of people asking you to do things, complaints that something hasn’t been done, and 571 messages marked urgent.

In fact email is usually considered to be a hindrance, with many productivity guides recommending simply ignoring your email for large periods of the day, blocking out that time for focussed work. The consensus is that your work inbox is just a place that generates distractions, and contains never-ending to-do lists that nag away at you throughout the day.

But my inbox has a secret.

My inbox holds my office happy place. A cool oasis of positivity among the desert of client demands, deadlines, and review requests.

My happy place is so simple anyone can recreate it, and over several years has brought me joy when I’m feeling strong and support when I’m low.

This DIY mindfulness practice is an inbox folder called “Nice :-)”, into which I sort all the emails I receive containing praise, thanks, or positivity - anything that makes me happy when I read it. It honestly is that simple, but this small thing has helped me through many tough days.

So often at work success can feel fleeting. Once something has been solved we move on to the next problem, with little time to bask in the glory of a job well done. But those successes still count, and should be remembered.

In the rush of the working day it’s so easy to focus on the the continual stream of requests for your time, and forget that your responses are really appreciated. Keeping hold of those one-line emails that say “Thanks, this is great!” helps me remember that work isn’t just about getting through the day. Our work and the time spent on it is valuable, and makes a huge difference to our colleagues’ and users’ lives.

Having this space to record personal successes has really helped my mental well-being over the years, building up an arsenal of evidence to counteract those negative voices in my head when things aren’t going so well. I’d recommend this trivial technique to everyone, as a super simple way to make yourself a little happy place that’s open for visitors any time you need.

Twitter network graphing with Gephi

contact@tomrenner.com (Tom Renner) — Mon, 20 Apr 2020 00:00:00 +0000

Unfortunately since Elon shut down the Twitter APIs, the below method no longer works. Still, it was fun while it lasted, eh?

Gephi is a piece of software for visualising graph networks. It’s a powerful tool, and to use it fully requires significant domain knowledge that I don’t possess, but fortunately it’s still fascinating to play around with as an amateur!

As a techie, to me the obvious networks to graph are those created by the big Social Networks - YouTube, Facebook, etc. It’s not hugely surprising to find that mostly these graphs mostly aren’t available for querying, but excitingly there is a plugin that allows you to stream in live data from Twitter.

I’m very much a beginner, but I produced the network image below looking at Twitter activity around the word “Trump” (as an easy example of a query that produces a fair amount of activity at the moment), which I’m really pleased with.

In the above you can see different kinds of activity linked by their interactions, colour-coded by type (user, tweet, hashtag, etc.) and scaled by the number of interactions they had in the time period the data was collected over.

I think graphing in this way is super cool, but I couldn’t find a quick-start guide online for how get set up and producing graphs that are interesting to investigate, so I wrote myself a how-to as I went. It’s very basic, but got me to the point where the more detailed documentation online started to make sense.

So without further ado, here’s my beginners step-by-step guide for producing this kind of graph. I’ve added in bullet points of the settings I used to produce the image above, in case you want to follow along.

Download Gephi
Install TwitterStreamer
Follow the tutorial on the TwitterStreamer installation page to set up a Twitter developer app and connect it to the plugin
Stream in data from a Twitter search query, stopping streaming when you have a reasonable amount of data
- 5-10k nodes is about right
- I streamed a text search for the word “trump”, as an initial query that would produce data quickly
Set a layout in the panel on the left so that your nodes don’t just appear randomly distributed across the canvas
- ForceAtlas 2: Prevent overlap, Scaling 1.5, Gravity 1.2
- Note: Changes to a layout take time to apply, and can be interrupted any time by selecting “Stop” in the layout panel.
Resize nodes in the “Appearance” panel - scaling them by degree is a good starting point
- Note: If you stopped the layout (ForceAtlas 2, if you’re following along), you’ll want to restart it here so the newly resized nodes don’t overlap
Select the labels you’d like to display
- Toggle label visibility, by selecting the “T” symbol at the bottom of the graph view
- On the “Data Laboratory” panel (in a tab at the top of the screen), select all nodes with Ctrl+A, and deselect “show label”
- Back on the “Overview” panel, select individual nodes of interest, right-click to “Select in data laboratory”. Switch tabs and select “show label” on that data point.
Set some image settings for export along the bottom of the graph canvas
- Set black background, using the light bulb symbol
- Set the text colour to “unique”, using the “A” button
- Edge weight to full, using the slider

There are loads more options to play around with, layouts, filters, and on and on. I’m looking forward to getting thoroughly lost in menus.

XTC discusses Basecamp's Shape-Up

contact@tomrenner.com (Tom Renner) — Sat, 22 Feb 2020 00:00:00 +0000

Last week I facilitated a session at XTC, where we discussed the new product development framework from Basecamp, Shape Up, led by Thomas Ankorn.

It was a really interesting discussion with people exploring the ideas openly, guided by questions posed by Thomas to get the conversation started.

I’ve summarised the points that came up in the discussion, reconstructed from memory and the collected post-its of scribbles at the end of the evening.

1. What problems does this solve?

We started by looking at the positives of the framework, trying to identify strengths that would help mitigate problems we have encountered in our own teams.

The development team takes responsibility for and ownership of the work they’re doing
It encourages a high level of trust between teams - shapers to produce workable specs, and makers to take those and implement them with fewer interventions and less supervision
Removing the backlog concept stops it from becoming an “ever-growing TODO list”
“Betting” on development tasks gets everyone used to the idea that some won’t pay off, which would aid communication with non-technical parts of the company
Describing the specification process as “shaping” reduces the chance of over-specification
“Betting” encourages shaped specifications to be finished in the eyes of the development team, as otherwise people will be less likely to bet on them
Minimises the amount of time spent lost to communication overhead - less frequent ceremonies leaves more time for work
“Fat pen” design again prevents over-specification of the UI

2. What do people see as red flags?

As is slightly inevitable in a group discussion of this kind, “red flags” was slightly watered down to “generic problems” when discussed around the table.

The scope is fixed for a period of work - each development task has to fit into 6 weeks, so features that would take longer than this aren’t possible
People interrupting to ask questions is likely, since the teams are split and the development period is quite long
“Circuit breaker” concept could be really demoralising for the developer, to see their work thrown away
Very much based around product development and expansion - would it work for projects in maintenance phase?
Longer cycles slows down your feedback loop, which is opposite to what most teams want
No information about how often work spills over into the “cool-off” period, which would be interesting to know. Too much of this would harm clean-up tasks
Divides the team into “shapers” vs “makers”, making a two-stream system
Leaves a lot of time for shaping - is that really needed?
The “cool-off” period seams to make clean-up and refactoring separate tasks, not part of everyone’s day to day work
Asymmetry in the team - seems like the development team might not have a say over what is available for betting or what they can say no to

3. Is there anything you’ll take away and try?

Many people agreed at this stage that they would like to apply some of the specific techniques proposed as part of the framework. Nobody was ready yet to take the plunge and try to implement the full methodology, but that was probably unlikely as an outcome of a single group discussion!

The common elements that people mentioned they would like to try out in their workplaces were:

“Fat pen” design, to replace wireframing
Using the “betting” and “shaping” terms to better describe the aims and intentions of development and specification tasks
Attempting to minimise the communication overhead of the Agile ceremonies

This was a really fun discussion to be a part of. Challenging the group to re-examine and justify their working practices threw up plenty of common issues working with the Agile methodology, and discussing how Shape Up works was a great lens to prompt ideas about how to improve our processes.

It’s always going to be easier to pick holes in a new set of processes, especially when Agile is so widely used, but it was clear from the discussion that there were definitely ideas that people really liked in Shape Up. I’ll certainly be keeping an eye out for whether it is picked up more widely, and whether the issues we identified at XTC are evident when the methodology is used in practice.

The Temple of Fail

contact@tomrenner.com (Tom Renner) — Mon, 25 Nov 2019 00:00:00 +0000

DISCLAIMER: This was not my idea - I picked it up from Jane Nicholson at an XTC event, who was introduced to it by Jess Gilbert (who in turn, I am told, got it from someone else). This post is just explaining why I believe it can be a useful exercise, not any truly original thinking!

One of the things that is really important to me is that my team and I keep learning at work. As such, fostering a learning environment is kinda key. I think we do that pretty well at Haplo – we have hired nearly exclusively early-career developers to our tech team for several years now, and one of the key points most hires mention as to why they join is that they feel it’s a good place to learn quickly, with the requisite support early on in their career.

One of the regular things we do to foster learning from our mistakes, and an open environment of sharing, is the “Temple of Fail”.

How this works:

Every week in our retro (which we call “demo day”, but that’s a different story) we have a regular section called the “Temple of Fail”. This time is reserved for everyone to bring to the table an example of a mistake they made this week. This failure can be as small and silly or as large and catastrophic as you want, but we do encourage everyone to bring one to the table each week.

The intention then is to share that mistake with the team, so others can learn from it. We have a quick discussion on how to avoid doing that in the future, and that way we hope that only one member of the team will make each mistake as a result!

Of course this can be a pretty intimidating thing to do, especially early on in your career (literally day 2 in some cases). Team leads asking you to turn up to a group meeting and tell them what you fucked up this week in front of everything is kinda terrifying. As a result, we try to make the “ceremony” around this session as light-hearted as possible.

For example, when introducing the session I’ll say something like “we, the devotees of our Lady the Goddess of Failure, have this week…” or something similarly ridiculous. The intention is to make it as low-blame and light-hearted as possible, to minimise any tension around the table.

This has to go hand in hand with a no-blame attitude to mistakes, where you want to fix the process, not the person, when something goes wrong. I’m lucky enough to work somewhere where our directors have worked very hard to foster a supportive and learning environment, which is really what enables this to work.

Of course people do repeat mistakes, but this for me is one of the most valuable things that we do as a team. Not everyone has something to share each week, but being able to minimise the number of mistakes that are repeated across the team is incredibly valuable.

"Efficiency" is bad for your health, and your learning

contact@tomrenner.com (Tom Renner) — Mon, 10 Jun 2019 00:00:00 +0000

I used to stress a lot about the “efficiency” of how I was using up all the minutes in my day. I’d to cram in as much as possible into time. eg. read on a 10 minute train, write code in the half hour before bed, etc.

While I stressed about it a lot, I never found that I did the “10x” things I read about that were supposed to emerge as a result of this extra “efficiency”. For example I have only finished one of the three side projects I started in 2016, despite promising myself that those wouldn’t take long.

Having worked professionally now for coming up to 5 years my attitude to this has changed a lot. I’ve been lucky to have found a job I enjoy in a workplace that actively encourages a healthy attitude to work life balance. I don’t have the energy to beat myself up about 20 minutes three times a week. TBH my brain has enough stress worrying about the big things to be concerned about these little ones.

It’s not feasible for a Real Life Human(TM) to be “totally efficient” with their time, using it all for either productivity or the subset of leisure activities that I internally think “count”, in this bizarro time-economy.

Nearly all personal development for professional related skills happens in your job. That’s always likely to be the case just because of the number of hours you spend at your desk (unless you’re in a job that doesn’t challenge you at all, in which case you have a different problem).

I’ve found myself to be much happier to only do extra things when I’m really interested, rather than see it as a “must do” just to keep up. Given that tech is already an industry that tends to promote working stupid hours at the cost of your mental health, and the marginal skills gains from all this side-hustling are pretty crap, as far as I can tell you’re better served not stressing all the little things in the name of productivity.

And if you give yourself this little bit more leeway, you’ll have more energy to spend really focussing on the things you do do, so you’ll probably learn more from them anyway.

Offline knowledge, buses, and note-taking

contact@tomrenner.com (Tom Renner) — Sun, 19 May 2019 00:00:00 +0000

In a team having knowledge that lives only in your head is a terrible thing.

Humans are forgetful
Humans are creative, especially when problem-solving
Computers are not creative
Computers are not forgetful

So we should get the computers to remember things, and allow the humans to do the creative parts.

Writing software is a creative activity. You start with a blank text file and end up convincing people to give you their identity details in exchange for the ability to poke someone over Facebook. If that’s not creative I don’t know what is.

“The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination.” – Fred Brookes, The Mythical Man-Month

However, not only are humans forgetful, but having just a single person who knows how to do a thing is a huge risk. Some of you may know this concept as your project’s “bus factor” – how many people would have to get hit by a bus for your project to fall over. To make sure your project is resilient to buses (and more mundane problems, like forgetfulness) you need to make sure lots of people can do any given task - i.e. get information out of your head.

Knowing that brains are a bad storage place for reference information is not a new idea. This is the basic idea behind documentation. But before you can have effective documentation, first you need to have a place to put those things. A scheme for encouraging documentation.

I’m not going to talk about technical documentation here, for a couple of reasons. Firstly, I’m not qualified, given I don’t think I document very well (apologies to my team mates), but also because the practice of documenting isn’t that complex, in my opinion. You just need to make time to do it.

The thing that’s been interesting me recently is how to manage your personal documentation - keeping track of your upcoming work and staying on top of it, while maintaining enough headspace to stay focussed on your current problem.

One of the best ways of improving your productivity is to stop yourself thinking of things you have to do, and allow yourself to think how to do them. This is only possible if you have systems to do your remembering for you, giving you the space to do the creative problem solving part.

The key thing that needs to happen to allow you to do that is to get things out of your head and into your system. Your system can be digital, notebook based, post-it based, whatever. How you actually record things doesn’t matter, but there are a few key characteristics I think are important for your system to work well:

1. You need to be able to know where to look next

For it to be effective, it must be clear what your immediate priorities are. As in 10 minutes to an hour immediate. Looking at it should tell you precisely and accurately what your next task should be, with enough detail that you could go away and find further context for the task if necessary.

2. You need to be able to add all incoming tasks to it

Working life adds tasks to your inbox all the time. These will not come at convenient moments when you can think about when in your next week you’ll be able to do it. Taking the time to schedule and prioritise every incoming task will kill all momentum on your current task. Your system therefore needs to allow you to quickly (in under 10 seconds) add any incoming task to an appropriate place that you can guarantee you will pick it up later, and in time that you won’t miss any associated deadline.

3. It must be always available

There is no use in a system that you only have to hand 70% of the time, as it will only capture at most 70% of the things you want to track. This will leave you trying to think of things again, rather than about them. Or, just as bad, you will come up with potentially multiple other places to record tasks, making all your lists ineffective at helping you decide what to do next.

What I have found wonderful is that these principles apply equally well to both personal organisational lists and shared ones, working as part of a team. Different methods of applying them work better for each environment (my phone is a bad place for shared work priorities to live, for example), but applying the principles helps me with prioritisation and decision problems wherever I have them.

Setting up a bottom-end Chromebook for development

contact@tomrenner.com (Tom Renner) — Thu, 28 Mar 2019 00:00:00 +0000

I like being able to code wherever I am. “Unfortunately”, my 15" laptop bought to run simulations for my degree still runs like a dream, so I can’t really justify buying myself a replacement for it. So instead, just over a year ago, I decided to get something that is:

Lightweight
Cheap
Allows me to code on the go

Looking around a bit, a budget Chromebook seemed like a good choice. I settled on an Asus Chromebook C201, which cost me £190. It has 4GB of RAM, a 16GB SSD, and weighs under a kilo.

I thought I could get away with keeping ChromeOS running and still end up with a passable development environment. Unfortunately, my first discovery was that the model I’d bought didn’t yet have the Android App Store Beta. I should probably have checked that earlier in the process.

However, reading around a bit I still thought development on ChromeOS on a bottom-end machine would be possible. Enter Chromebrew. A tool that promised me functional Vim, Python, and Git with little hassle.

Setting that up was reasonably easy. Although I mildly resent having to enable a special “developer mode” that gives you annoyingly beepy warnings when you boot, all in all it only took a couple of hours of googling to get my dotfiles cloned, vim and python installed, and a helloworld run to prove to myself it was workable.

I’ve now had the machine for just over a year I’ve concluded it’s worked pretty much exactly as intended. I now take it everywhere (I’m typing this on it!) because it weighs less than a kilo. And because the machine cost less than my phone (and all data on it is saved to the cloud somewhere) I’m not overly concerned about it being lost or stolen.

The major advantage is that having something that’s always on me lets me use spare half hours productively, where previously I would have just stared at my phone. It’s actually especially noticeable because I really dislike using my phone for a lot of things, like shopping or drafting emails longer than two sentences.

There are a few remaining annoyances, which come from the fact that you’re not really meant to use the terminal on ChromeOS. I haven’t got around to installing some of the basic command-line tools my fingers type automatically, like less or man. They’re not installed by default, which surprised me.

I also don’t think I can update ChromeOS without wiping my “developer-mode” set up, which is a pain. This doesn’t make the security nerd in me happy, as I don’t get any patches, nor the tech nerd, since I don’t get any new features. I want to do some more research into this, to see if I can work around it somehow.

All in all though this has been a really great change to my life. Having a computer small and light enough to code on everywhere, at a bargain-basement price, really has changed the way I work for the better.

Getting the right scale

contact@tomrenner.com (Tom Renner) — Sat, 27 Oct 2018 00:00:00 +0000

Agile tells us that the most critical thing for getting software right is not up front design, but getting something out there and used, and then incorporating feedback. By getting feedback early, you are able to respond faster, changing your (initially incorrect) design in small steps towards a better solution. This works better in practice than designing everything at the start very carefully, which feels rigid and inflexible in the face of new information over the course of a project.

This is good. Everyone hates waterfalls.

However, iterative development processes also come with their own problems. Scope creep can become a much larger risk when there is the opportunity for specification change and revision at later stages, which is especially apparent on large projects.

My company works in the higher education sector, where development projects often last 6-12 months. Iterative change and feedback in this environment needs careful management to avoid the project scope increasing over time. This often feel like a failure in system design and specification, bringing us back to the need for better up front design! This can leave you feeling you’re between a rock and a hard place with too much upfront design vs. ever getting the damn thing live.

So we are looking for the sweet spot between too much up-front design and enough to mitigate scope creep and major structural changes late on on projects.

I have suspicions that sweet spot is very small, and that’s a major reason why this job is hard. It’s also why every codebase is littered with //TODOs, and why most of us find it much easier to start than finish a side-project. The real world gets involved and messes up your Grand Vision for The Perfect System (which, realistically, is probably why you started the project in the first place), and all of a sudden a “Grandish Idea for Another Probably Ok Webapp” hasn’t had a commit in 3 months.

All developer know that some problems require quick fixes, some fundamental re-writes of the system. Correctly resolving a problem and it not then causing you a major ballache later depends on picking the right scope of solution, and being able to identify that scope is a seriously valuable skill to have.

Scope: Are you looking for the One True Solution to all issues that look anything like the current one? Are you trying to make something that is generalisable to other parts of the system?

So here are three things I try to keep in mind when starting out on a problem, to try to find that sweet spot of design:

We want to only write this bit of code once
We want to spend the minimum time possible writing this code
If possible we want to reuse this code in as many places as possible in future

The aim of this is to try to get as close to the optimum scope of solution that takes the minimum time while not having been revisited. Getting this step right for each small task minimises negative effects of project changes later on, by keeping your codebase flexible to react to future discoveries.

A quick guide for productive development

contact@tomrenner.com (Tom Renner) — Thu, 08 Feb 2018 00:00:00 +0000

It is upsettingly easy to work hard without being productive. The Lean Startup includes a quote I really liked:

“[People] feel that a good day is one in which they did their job well all day.”

The point being that this doesn’t account for whether you are doing the right work. This is a really common trap to fall in to. I know I have often worked really hard on something and produced code I’m very happy with, only to talk to my boss or the client and find that nobody else seems to be nearly as pleased with what I’ve produced as I am.

In these cases it’s tempting to throw up your hands and say that other people don’t appreciate your efforts (the “misunderstood genius” approach), but more accurately there has been a disconnect between their values and your prioritisation.

So what do I do to try to avoid these problems?

Take every short-cut. Not as in “if we hack this together it might work”, but make sure you ONLY address the major requirements (you know the critical requirements, right?). “Nice to have"s can wait till v1.1, and probably don’t matter anyway.
Prioritise my time by value rather then complexity. This helps avoid the problem of perfectionism, and stops me doing things just because they seem challenging or fun.

So realistically, my pattern of work goes something like:

Estimate the things I want to do in the next cycle
Order them by value
Try to do them
Work out half way through that I might miss some of them
Observe what I am spending my time on, and make sure it’s the most important of the things listed in point 1.

This tends to get me closer to what I aimed to do than if I try to start by tackling the most complex tasks first. Complex tasks are sometimes the most valuable, but complexity also depends a lot on the skill-set you have as a developer. I, for example, suck at front end things. CSS and client-side JS don’t like me (and I don’t try too hard to like them). Recently I found myself spending time getting a web form to recalculate related fields on changes around the form. It was only after two hours that I thought about how little value this task ultimately provided. It was surprisingly complex (because of an uninteresting set of event change handlers) but not actually very valuable for the overall work I needed to do that week.

It is also important to remember that value should be measured as a team, not as individuals. An individual will think they’ve produced maximal value in a day when they sit at their desk and work on their own tasks all day. But maximising value produced for the team will require cross-functional tasks, and collaboration. That level of perspective needs active thought and coordination, not just personal prioritisation.

I find most people assign their time by complexity. I think you need to do the value assessment first. Keep that in mind (even after sharing out tasks) to keep everything on track.

The customer is always right

contact@tomrenner.com (Tom Renner) — Sat, 04 Feb 2017 00:00:00 +0000

A theme of the last few books I’ve read has been user testing. Specifically, that it is completely unreasonable to suggest that you could produce a system that will work smoothly in production without first getting several actual human users unfamiliar with your system, from your clients or in a related industry, to road-test the system.

I think anyone can see that this is a good idea. It’s far too easy to make assumptions about the users’ requirements or use cases. Without user testing software would rarely solve the problems it was designed for.

But what about us as developers? A developer’s job is to write software. We’re generally quite good at breaking down problems into many smaller pieces, dealing with abstract concepts, and linking those together into a program control flow.

This kind of thinking is facilitated by long periods of focus. Those times when the environment is distraction-free and you’re able to get hard problems thought about. Flow. It’s a familiar concept, and all developers hate any interruption that drops you out of this thinking pattern.

Unfortunately, every workplace comes with interruptions. Support requests hiting the issue tracker, clients ringing to ask when that new feature is coming, your manager “just checking in”…

All of these people are holding us back. If they could understand how much more effort it is to regain that state of mind where code is simple they would never interrupt. There are so many ways they could solve their own problems if they had thought properly, or used the software we build them better.

I suspect all devs have sympathised with the bug report resolution “problem found between keyboard and chair”.

And that’s the problem really. We’re good at software, and they’re not. This is why they aren’t developers, and we are.

… Except all of the above three paragraphs is wrong. You know what? These are the same people who we desperately wanted to hear from back in the first paragraph. It is all to easy to think of people who struggle with our software as being bad at their job. But in reality it should be expected that users aren’t computer experts - their jobs require other skills, and they’ve paid us to deal with the computer problems for them.

Customer support is essentially a massive user test. It is a really easy habit to fall into to ignore or belittle feedback. Repeated annoyances (probably) point to a UX problem, even if the root cause hasn’t been identified. And we shouldn’t expect feedback of that kind - that’s our domain. We’re the developers, we’re paid to solve their problems.

So saying “the customer is always right” shouldn’t be an attempt to encourage good customer service. It should be an acknowledgement that our users have a lot of expertise in the problem domain we’re developing for. Our expertise is in software. Rather than apply all the same standard UX and solutions to all walks of life, sometimes we need to recognise that we’re comparatively ignorant of how and why our software is actually used, and tailor our approach a bit better.

Why am I doing this again?

contact@tomrenner.com (Tom Renner) — Fri, 11 Nov 2016 00:00:00 +0000

Why do I want to have my own site?

Narcissism mostly. I found the domain was available, decided as a self-respecting developer I should probably buy it. But then there’s no point owning a domain if you don’t put something there. So that was it really - I had to I had to get my act together and actually write the thing.

I enjoy developing

I’m a person who finds it hard to devote time outside of office hours to write code. I suspect it’s because I hate fun. Whatever the reason, if I’m not doing something useful, I won’t bother. So having decided I would like to code more, I had to find something useful to write.

Incidentally that’s also the reason why the site looks the way it does. I decided it would be quicker and much less interesting to use a site builder. So instead I’m writing everything myself. The initial toolkit is Ruby, building on a Sinatra framework, jQuery, HTML and CSS.

What am I going to post about?

Every now and then I find myself with Opinions about How It Should Be Done. I also read books about things related to software, and go to events that sound interesting. I will probably write up some reviews or comments on these and shove them up here, and maybe even comments on other things that I care about enough to write about them.

Writing is both fun and hard

I want to write about these things because I know basically nothing about huge areas of computer science. So I’m hoping that posting here will help me learn things as well. I’ve also observed that a lot of people I think are good at stuff are also good at articulating themselves. It seems likely that trying to clarify thoughts into a post will help me understand and explain a topic. Plus all the cool devs do it, so maybe they’ll let me join in if I do it too.

Did that answer your question?

So that’s a pretty broad introduction to the site. It’s my site, and I post on it. It’s not perfect, but it’s mine. Any comments you have about anything you see on the site are welcomed - I prefer talking to people than to myself, and judging by the headings of this post I could use more contact with the outside world. Get in touch.

"Full-stack" and why I don't like it

contact@tomrenner.com (Tom Renner) — Mon, 10 Oct 2016 00:00:00 +0000

Last week I went to a jobs event, recruiting for my company. I was there on my own, and recruiting is a pretty new experience for me, so I was kinda excited about it. The attendees were a mix of graduates, bootcampers, and a few more senior developers, but mostly the crowd were looking for their first or second job. I enjoy going out and talking to people about their experiences with software – I think breadth of knowledge is really valuable – so I found it interesting seeing what other people are looking for in a job. I’ve only ever had one; maybe I’ve aimed for all the wrong things!

But there was one comment made that stuck out. It was from a developer at a similar stage in their career to me – two years professional experience – who was looking to switch companies. He’d been at a large firm, and found things all a bit too lumbering to get anything done. All of that sounded very reasonable, and I was agreeing with a lot of what he said, until he used the phrase

“… of course I’m full-stack, you know, all that standard stuff really”

Now I know a lot has been written about the myth of the full-stack developer, but the fact that at a recruitment event this was considered “standard stuff” really took me by surprise. Full-stack, by definition, means you’re experienced with technologies at all levels of a production application. After two years professional experience? Even after ten? And even if that were true (hint: I don’t think it is), it can’t be a helpful way of identifying yourself to potential employers.

This myth is something that is a buzz-word on dodgy recruitment ads – the same as the idea of being “10x” or a “rockstar” or “ninja” or “guru”. Because you’d have to be at some kind of coding Mozart to have equal proficiency across all levels as someone who has specialised. There’s only so much you can do by simply having raw brainpower or talent. But because it’s a word on the job spec, it’s the word applicants find themselves using to try to show they cover the requirements.

I think the word they’re aiming for is generalist. Maybe I’m going to sound picky, but I think the distinction here is important. Being a generalist suggests that the skills you value and are good at are generally applicable. That the specific technologies you’ve used aren’t your strengths as a developer.

Setting my hatred of buzzwords aside, it’s worth thinking about what these two descriptions imply about you. When you’re presenting yourself, especially to a potential employer, you need to be thinking about what impression you’re giving your audience. By describing yourself as a generalist, you’re describing something about your skill-set, and giving useful information about what you consider to be the most applicable parts of your experience – your abilities to learn and turn your hand to new problems. “Full-stack” make you sound like you’re either ticking boxes or think you’re perfect at everything.

By focussing on the technology stack you invite negative criticism of your abilities. Any part of the Full Stack(TM) (which, by the way, will vary between companies) that you’re not so proficient with becomes a flaw in your CV. And quite apart from this you are failing to highlight all of the other skills that you need to be a developer.

I think the point I’m trying to make is that the phrase “full-stack developer” shifts the conversation onto negatively looking at the technologies you’ve worked with, and that’s not a good thing, whether you’re the employer or the applicant. It would be great if we could stop saying it like it is.

Tom Renner on My place to put things

LLMs are a 400-year-long confidence trick

Building trust

Exploiting emotions

1. Fear

2. Sympathy

Urgent action required

Things that made me think: Cycle time, learning theory, and build chain security

Measuring Cyle Time with Dr. Cat Hicks - The Hanger DX Podcast, Ankit Jain

Stop building AI tools backwards – Hazel Weakly

Pwning the Entire Nix Ecosystem – ptrpaws

Does my toaster love me?

Things that made me think: Digital gardening, web degradation, and digital ghosts

Garden History – Maggie Appleton

The Failure of the World Wide Web Project – Atanas Georgiev

Spotify Publishes AI-Generated Songs From Dead Artists Without Permission – Emanuel Maiberg, 404 Media

Optimising for trust

Things that made me think: Enshittification, apathy, and discrimination

The rise of Whatever - eevee

Social Inequality in High Tech: How Gender, Race, and Ethnicity Structure the World’s Most Powerful Industry - Megan Tobias Neely, Patrick Sheehan and Christine L. Williams

Understood: Who broke the internet? - CBC, Cory Doctorow

The sound of inevitability

Saying the quiet part out loud

Cull your dependencies

By the numbers

Assumptions developers make

Process problems

Proposals

Does the software industry learn?

Should we welcome or fear the Metaverse?

DORA? I barely know her!

Coming to grips with DevOps metrics

1. Deployment frequency

Raw data:

2. Mean time to deployment

Raw data:

3. Change failure rate

Raw data:

4. Time to restore service

Raw data:

Conclusions

Staying in one place doesn't mean standing still

Make yourself a happy place in your inbox - a mindfulness tip for your working day

Twitter network graphing with Gephi

XTC discusses Basecamp's Shape-Up

1. What problems does this solve?

2. What do people see as red flags?

3. Is there anything you’ll take away and try?

The Temple of Fail

How this works:

"Efficiency" is bad for your health, and your learning

Offline knowledge, buses, and note-taking

Setting up a bottom-end Chromebook for development

Getting the right scale

A quick guide for productive development

The customer is always right

Why am I doing this again?

Why do I want to have my own site?

I enjoy developing

What am I going to post about?

Writing is both fun and hard

Did that answer your question?

"Full-stack" and why I don't like it