This article is about using large language models (LLMs) to write code, but gets there indirectly. First it talks about what makes things, such as programming and maths, hard and what doesn’t via a couple of historical things. Next, I will expand on complexity – how much is baked into some activity, and how much … Continue reading Whetstone of Witte, complexity and programming
Category: Coding
Tech debt as risk of friction
Tech debt is a term that’s used quite a bit in software development, and I recently realised a new way of thinking about it: the risk of future friction. I’ll explain what I mean below, starting with a brief discussion of what I mean about risk in general. Risk Before I get into risk as … Continue reading Tech debt as risk of friction
Commentate on your code
Sometimes a method mixes levels of abstraction, where one section goes into more detail than the rest of the method. This can make it hard to understand – code can be hard to understand when it’s on only one abstraction level, and introducing an extra level only makes things worse. One way to detect whether … Continue reading Commentate on your code
Generative AI and skills
There has been a lot in tech news and opinion recently about what generative AI will or won’t do, such as take away jobs from programmers and testers. I’ve had a long enough career in software to be able to put generative AI in a bigger context, which I think helps to understand some of … Continue reading Generative AI and skills
You’re probably wrong
In this article I make a suggestion that might sound absurd: when developing software, you should assume that you’re wrong. Once you make this assumption, it can influence quite a lot of what we do and how we do it in ways that I think help us to deliver better software. Why do I think … Continue reading You’re probably wrong
Nim
Nim is a simple game for two people. In this article I will describe it in case you don't know it (or don't know this version of it), and then describe how I've modelled it in a C# program and what I learned about the game as a result. The game There is a simple … Continue reading Nim
‘Roughly’ and ‘better’ can help usability
In this article I'll go into some fuzziness that we often encounter in the everyday world, that's often missing in the world of computers. Unfortunately we're used to this fuzziness, and so its lack can make computers hard to use. Star Trek shields I remember watching episodes of Star Trek where the Enterprise was in … Continue reading ‘Roughly’ and ‘better’ can help usability
Modularisation – coupling and cohesion
This is related to the second of the things requested by Jesper, which was encapsulation. Encapsulation is a tool to use when designing software. It’s a bit abstract, and I don’t think people always agree on what it means. To me, encapsulation is part of the bigger term modularisation, which doesn’t immediately help because it’s … Continue reading Modularisation – coupling and cohesion
Exceptions 4: Finishing up
This is the last article in a series about exceptions: BasicsTypes and filteringWhere to put catch blocks and handle exceptionsFinishing up Exceptions are an example of the Chain of Responsibility pattern.Image credit Finally If the code in the try block needs tidying up (e.g. it opens files, that will need closing at some point), then … Continue reading Exceptions 4: Finishing up
Exceptions 3: Where to put catch blocks and handle exceptions
This is the third article in a series about exceptions: BasicsTypes and filteringWhere to put catch blocks and handle exceptionsFinishing up Where your catch blocks are and where exceptions are dealt with matters - probably best to avoid sticking a pin into your code randomly to choose the spot.Image credit The location of catch blocks … Continue reading Exceptions 3: Where to put catch blocks and handle exceptions