Tony Meyer

Python monolith organisation, particularly interesting:
- Using import linter to enforce layered imports.
- Charting tech debt progress over time.
→ 1:54 PM, Jul 21

“Prefer to push fixes upstream instead of working around problems downstream”

→ 12:38 PM, Jul 20

“Waste, inefficiency, a suboptimal outcome. Some of the brightest minds in our economy are earnestly engaged in stamping it out. They’re winning, but everyone’s losing."

→ 12:24 PM, Jul 20

Using ‘process linters’ to avoid hitting ‘feedback budgets’ (the appendices are the most interesting part).

→ 11:43 AM, Jul 20

Interesting post-mortem on a bug caused by changing randrange() behaviour across Python versions.

→ 11:27 AM, Jul 20

“People said I did the impossible, but that’s wrong: I merely did something so boring that nobody else had been willing to do it.” Jacob Kaplan-Moss - I have done & seen this too. Worth it, when you pick the right job.

→ 8:48 PM, Jul 17

Interesting introduction to ChatGPT’s Code Interpreter via Simon Willison

→ 10:47 AM, Jul 17

I’ve used all of these deployment patterns (really release patterns), and strongly prefer feature flagging everything with a layer of permission for user-facing changes as well.

→ 8:09 PM, Jul 16

“Where are the networks that deeply in their bones understand hospitality vs. performance, safe-to vs. safe-from, double-edged visibility, thresholds vs. hearths, gifts vs. barter, bystanders vs. safety-builders, even something as foundational as power differentials? I don’t think we have them, except piecemeal and by chance, or through the grace of socially gifted moderators and community leads who patch bad product design with their own EQ."

→ 5:59 PM, Jul 15

Good post on why speed matters although it completely misses any discussion of quality, which is critical. It’s all about balance, not just prioritising for speed.

→ 5:50 PM, Jul 15

Summary of a paper covering the past, present, and potential future of tech debt.

→ 5:23 PM, Jul 15

Interesting thoughts on monitoring (logs, metrics, traces).

→ 10:49 AM, Jul 15

Good intro to using Vulture with Django.

→ 6:25 PM, Jul 14

Deep dive into tech debt and the financial debt analogy (good for people not that familiar with finance, or, probably, people familiar with finance but not tech).

→ 3:22 PM, Jul 13

Speaking of Ben Hoyt, another post with more details on good naming.

→ 12:19 AM, Jul 10

My thoughts on Pythonic library API design in response to Ben Hoyt’s post a few weeks back. More on the stdlib email package when I find time.

→ 11:56 PM, Jul 9

Good list of lessons learnt in software engineering.

→ 7:22 PM, Jul 6

“1966! … Yet this person seemingly knew more about software development in 1966 than most managers of software product development companies do today. These are not new ideas, and sometimes it baffles me that they are not more widely known”. So true, and so sad.

→ 4:16 PM, Jul 6

My first experiments with using an LLM to help write code - TL;DR: disappointed so far.

→ 10:50 AM, Jul 5

Stamina looks great - an opinionated wrapper over Tenacity [via Simon Willison, who is for some reason still linking to Tweets?]

→ 9:37 AM, Jul 5

Reply: 10 Laws of Tech
Of these 10 laws of tech:
- “A technology that was built for good will eventually be also used for bad” - I’m sure I agree with this. It seems like there’s a lot of tech that just isn’t useful enough to be bad with.
- “A company’s technology stack will be based on the experience and preferences of the first technical person in that company” - for the most part, but more based on those of the most senior people, which is to be expected, and the first person tends to be the most senior for some time.
- “The most painful, and least useful projects are migration projects, yet companies will replace technologies every 4 years” - 100%
- “Every major technology is going to be followed by a movement to eradicate that technology because it’s going to ruin us” - huh?
- “A highly communicative and collaborative team of average engineers, is going to outperform an uncommunicative and non-collaborative team of great engineers” - most of the time, yes.
- “Left alone, a product team will optimize to the closest and easiest goal” - mostly, yes.
- “Some aspects of tech are pseudo theological” - yes, which is why these decisions need to get automated away; the choice doesn’t matter, taking away the discussion does.
- “When you hire someone from another company, you take some of that company’s DNA into your own company” - yes, see also acquisitions.
- “Everyone celebrates version 1.0.0 — but it is version 1.0.3 that actually brings customer value” - yes, although a lot of things don’t have an explicit version number like that any more, of course.
- “Someone in 10 years is going to call your shiny new software “old crap” and will wonder who the hell designed such a bad product” - 100%, sigh.
→ 12:41 PM, Jul 4

Good suggestions on processes to follow when making technical decisions - documenting the entire process of coming to a decision really has so many benefits.

→ 8:53 PM, Jul 3

Explanation of how to best serve various sizes/qualities of images. Is it wrong that I hate how complex this is?

→ 8:47 PM, Jul 3

The suggestion for handling streak recovery here is exactly what Knotwords (an excellent game) does, and it works really well.

I’ve broken streaks from unexpected busyness, ill health, or simple forgetfulness but have recovered them and it’s still motivating to continue.

→ 12:03 PM, Jun 27

Good tips on designing Pythonic library APIs from Ben Hoyt.

→ 12:17 PM, Jun 26