„The primary task of a developer is not the writing of code but to understand a problem. The writing of tests helps to understand a problem step by step. The tests do not drive the development as an end in itself. They drive the development to trigger the required thought processes.”

RT @Grady_Booch@twitter.com

Let's be clear:

An LLM does not create any new truths; they are architecturally incapable of abductive reasoning.

LLMs only generate statistically interesting strings of words that are surprisingly coherent yet untethered to any metric for truth.

🐦🔗: twitter.com/Grady_Booch/status

I stopped trying to define Unit Tests (I would define it as Feathers defined it) and now exclusively use the terms:

I/O-Based tests: has I/O in the test (accesses clock, database, etc.)

I/O-Free tests: no I/O access in the test (no current date/time, no random numbers, no file access, no network access, etc.)

I'll slip up and use "Unit" when I really mean I/O-Free (and "Integration" when I mean "I/O-Based"), but for the most part I've switched.

There's so much baggage and debate around "what's a unit?", when that isn't always the most important question. I've found it much easier to explain that when doing #TDD, we want to use I/O-Free tests as they'll be sufficiently fast to get feedback in less than a couple of seconds.

post number 14 in my sincere dev manifesto series. I've never been this close to the end.

"I commit to adapting each test to the level of granularity that looks the most stable to me, and to maintaining a consistent and frugal campaign"


@kiview @javahippie My reason is that in A and B all classes have to public. In C very often package-protected is enough

Sounds very similar to all the no code programming, model driven development stuff which had been seen before.

It falls into the same fallacies

1. You just need to specify what you want
(That is usually the hard part and what you want might be dynamic and change)
And 2
That it generates 80% of the code, you only need to tweak 20%, therefore your 5 times more productive.
Which is a fallacy in 2 ways
2a to tweak the 20% you need to understand at least parts of the other code. This is not free.
2b initially writing the code is only one part of software development. Correcting, adapting, and extending the software is (for successful software) the far larger party

As AWS is brought up at an example multiple times, let's do a little thought experiment. Imagine it's 2003 and you had the current state of the art LLM based coding assistant with today's computing power at your disposal. Trained in als the data available in 2003.
Do you think Ruben Ortega and Al Vermeulen could have used it to create AWS by specifying it to the coding assistant?
I belive no. At that time the idea was not available in the training data. While the building blocks were there to combine them in this novel way would have required such a detailed specification that it would have been indistinguishable from code.

Sorry to hear that! If you still need a cross platform testing tool you could try Approvals for python or TextTest, also written in python. Don't know if they would work for your use case?

Be kind. Dispose of the unkind.

Python 001 - Python and Pygame
I've decided to work with Python a bit. I think I'll enjoy it as much as Kotlin, and I'll certainly enjoy being further away from Gradle.

Once you've realised that software development's comprised of many more activities than "coding" - to the extent that it's just a small part of a developer's day - claims that A.I. will mean "one developer could replace 10" seem a little naive.

We don't even need to bring YAGNI into the discussion (especially given that the workshop is time limited and not all teams get as far as the optional requirements): I pointed out that, by my estimation, two lines of code would need to be updated.

So this is something we also need to communicate more clearly: updating is not reworking. The word 'rework' implies something else and, in the context of refactoring and adapting code to the flow of time and change, it's a word that can be toxic.

Show thread

At first I thought that using GitHub's Codespaces to teach my news apps class was mostly for my benefit.

But more and more, I see this as much an equity issue as a convenience. Here's why:


I did a training on TDD for a client recently and was very happy to see this feedback the team lead gathered afterwards

“This report is a clarion call to massively fast-track climate efforts by every country and every sector and on every timeframe. Our world needs climate action on all fronts: everything, everywhere, all at once.”

– UN secretary general, António Guterres

Show thread

As an experiment, since I have a 20-year-old-blog, I’m going to occasionally repost particularly juicy 20-year-old pieces. Today: How, in 1988, I personally took down AOL.: tbray.org/ongoing/When/200x/20

Arlo's Danger Sense is hard to find on the internet, so I'm amplifying it here:

1) More than 15 mins since last checkin.
2) The code I'm working on is not unit tested.
3) The code I'm working on is not visible in the UI.
4) I'm feeling anything but calm, relaxed, and happy.
5) I'm trying to think -- about anything.
6) I haven't said anything in 2 minutes.
7) I'm remembering something -- anything -- for later.
8) I'm proud of the code I'm writing.

Show older
Software development is a social activity

A social place intended as a chill hangout place for software testers, developers, or just about anyone involved in delivering software and who is interested in both the technical as well as the social side of things.

sw-development-is.social is supported by the Association for Software Testing.

For more information about this instance,