Programming Leftovers

posted by Roy Schestowitz on Mar 25, 2026

• Chris ☛ Lines of code are useful

  Lines of code measure code complexity. That is well established. You don’t have to take my word for it: [...]

• Buttondown LLC ☛ Choose Boring Technology and Innovative Practices

  This means while we should be conservative in the software we use, we can be more freely innovative in how we use it. If we get three innovation tokens for technology, we get like six or seven for practices. And we can trade in our practices to get those tokens back.

• Roman Kashitsyn ☛ Kirk, Scotty, and Spock

  Agents are drowning humans in subtly broken code, but they can also alleviate the problems they created if we require them to provide machine-verifiable proofs. lean and spark, though unlikely to become mainstream, serve as models for future verified toolchains that should feature a clear separation between interface and implementation (so that people know where to look) and easy-to-use, fast provers (so that agents can iterate quickly).

• Florian Maas ☛ Readable code: Writing future-proof applications

  In my opinion, the most important aspect of code is that code should be easy to read. I would even argue that readability is more important than functionality.

  To illustrate, consider a project that works properly but which consists of code that is hard to read; while there may not be a problem today, problems arise when a new feature should be added to the project or when the project contains a bug that should be solved. Not only will it be difficult to make the required changes due to the poorly readable code, the probability of introducing more issues into the codebase while modifying it is also high. Now consider a project that is well written and easy to read, but it does not (yet) do what it should be doing. That is a problem today, but since the code is easy to interpret, modyifing it to improve its functionality should be an achievable task.

• Rlang ☛ odds_summary: Turning Probabilistic Estimates into Clear, Decision-Ready Insights

  Model tuning and estimation has evolved from simple extrapolation to sophisticated probabilistic modeling frameworks.

• Rlang ☛ You shall know a word by the company it keeps — so choose your prompts wisely

  In computational linguistics, word meanings are shaped by their contexts. As the British linguist John Rupert Firth put it in 1957, ‘You shall know a word by the company it keeps’ (see Brunila & LaViolette, 2022, for a re-examination of the intellectual history).

• Python

  • Anže Pečar ☛ Speeding Up Django Startup Times with Lazy Imports

    The problem we started noticing was that loading all these 3rd party integrations has made our Django app feel very sluggish. While this was noticeable around deployments and starting scans, it hurt the most during local development. It was taking around 10s to run ./manage.py check which meant that any Django command ended up being slow. Devs felt this the most with development server restarts and when running tests.

• Java/Golang

  • Redowan Delowar ☛ Testing unary gRPC services in Go

    This post walks through testing a unary gRPC service at two levels: calling the handler directly without any transport, and using bufconn for in-memory integration tests that exercise the full stack - including interceptors, deadlines, metadata, and rich error details. Streaming RPCs have different patterns and are out of scope here.

    I’ll use a small BookStore service as the running example.

  • Alex Edwards ☛ Eleven Tips for Structuring Your Go Projects

    When working with Go, you have three main building blocks to help organize your code: files, packages and modules. But as Go developers, one of the common challenges we have is knowing how to best combine these building blocks to structure a codebase.

    In this post, I'll share a mix of mindset tips and practical advice that I hope will help, especially if you're new to the language.