//No comment

It’s been a contrasting couple of months. Initially, I spent far too much time lounging on the sofa watching any old nonsense on telly, including some police dramas. How many times did someone arrested say, “No comment”? Several times. Having done very little, I then volunteered for Safer Spaces [SaferSpaces] at the Leeds Festival. They are a charity trying to prevent domestic violence. They offered a space with bean bags and comfy sofas at the festival, so people could chill out and have a chat if needed. I’ve not done any youth work for a while. There were some older people, but this festival lets 16+-year-olds in, so many younger people came along. For many, it was the first time in a tent, or possibly even the first time away from home. The chill out space we provided was useful, and the staff were on hand to help. It was important to be prepared to listen rather than talk. No comment, but in a different sense to fictional characters being arrested. Trying to get back into writing after a break is a challenge, so you guessed it. I haven’t got an editorial for you, as ever.

Now, back to technical matters. I have seen differing opinions over comments in code in my career. Some people insist on writing comments, but many would rather the code spoke for itself. Sometimes inexperienced people prefer comments: it can take a while to get used to reading source code, so a human sentence or two can seem easier to read. However, the comment may not match the code because comments can be left behind as code moves on. Comments can get out of sync with code, which is surely even more confusing than no comments at all. Delete the comment, and fix the code, right? You know it makes sense. I don’t trust comments. However, I do sometimes write comments, for example giving a reference to an academic paper, if I have encoded an algorithm or calculation, so people can go read more. Comments can be useful, but there are other ways to figure out what code does, for example by writing a few tests, or doing a scratch refactor.

Nowadays, comments are often used to get ‘AI’ to write code. The comment acts as a prompt, and the code spews forth. Now, should you save these prompts? Opinions seem to be divided; for example, I have seen various discussions on Reddit [Reddit]. Trying to pick your way through a code base littered with AI prompt comments sounds like my worst nightmare. I have also heard tales of people getting AI to write documentation or README files, perhaps even comments. Now, I’m not fully qualified to have opinions on how to manage the prompts, but traditionally, we have kept the code we wrote in version control, academia notwithstanding. (Aside: I did persuade an academic to use version control once, which I count as a win.) We don’t add notes about our thought process to version control too. We may keep architectural decisions records, explaining choices and context [Fowler26] or similar, but I’ve never seen anyone write out what they were thinking when they wrote code. Sometimes you can follow a small trail of clues to figure out how code got where it is. I found a typo in a comment once, which helped me trace which part of the internet it was copied from though. When I copied the tests over too, I found the source of a problem that had been puzzling me. Comments can have their uses!

I mentioned Reddit earlier. I have a long streak going. I have forgotten why I even started looking to be honest, as often happens with habits. Sometimes I scroll a long way down a discussion, reading the ‘the bottom of the internet’ comments. I’m sure you know what I mean: things go off on tangents, and people start being rude. It’s not all bad, but you need to pick your way through discussions if you want to join in. “Don’t feed the trolls,” as the saying goes. Now, the internet hasn’t caused trolls. Some claim people are more likely to leave anonymous comments online than actually say something rude directly to people. That may be true, but some people have always felt the need to say something they consider funny even if others find it rude. The Safer Spaces tent at the festival had hair dryers and similar on offer for free. Several young lads wandering passed asked “Where’s the Man Cave?” Oh my, aren’t you funny! When the rain started, one or two guys asked if they could use a hair dryer. Enough said.

Maybe you don’t do volunteer work. Don’t forget you can get involved with ACCU: write a book review or try out a ‘homework question’ or ‘code critique’ in the members’ CVu magazine. There are a few volunteer posts awaiting someone too: advertising, local groups, publicity, social-med, study-groups-officer. If you’d rather sit back and just read, that’s fine. Each to their own.

One thing I learnt of the festival was how valuable listening is. That’s an important skill at work too, particularly if you end up in a more senior role. Rather than grabbing the keyboard and driving, it’s useful to let a less experienced person take the lead. You learn when you listen, but you need to learn to listen. It’s too easy to assume you know what someone is going to say or do next, or concentrate on what you want to say rather than hear what is really being said. If you want to know more, look up ‘active listening’. I’m no expert, but you need to actually listen, avoid being judgemental, clarify, maybe by asking questions, and summarise, by restating what you think the other person said. Words are not precise, so misunderstandings can creep in. Repeating back what’s been said in your own words gives an opportunity to clear up miscommunication. It’s too easy to pass comment or give unsolicited advice.

Now, sometimes people freeze up, so you might need to say something to keep the conversation going. Just a small prompt can work. At the festival, asking which band the person had enjoyed or was looking forward to helped cheer people up or at least distract them from feeling down. Asking how someone intended to get home was useful too. You could find out if they were sorted or needed help. Perhaps you have a few handy prompts to help you code with someone. “How are we going to test this?” “What is this class for?” And so on. If you find yourself in a more senior role and a less experienced person asks a question, never be afraid to say “I don’t know. Let’s find out.” That’s much more useful than making things up! Yes, I’m looking at you, AI.

We all freeze up from time to time. Open-ended questions at interviews being top of my list for stalling mid-sentence, not that I’ve been interviewed for a long while now. Once I was asked to sketch the architecture of the system I was working on at the time. Simple, right? Well, yes. But I wanted to caveat the diagram with the comment, “Bear in mind, I am looking for another job. For exactly these reasons.” Once I’d finished drawing and explaining as I went, they told me that was a terrible design. I know, right?! With hindsight, I could have started by saying “There’s a simpler system trying to escape from the weeds.” Then I could have drawn a fictitious setup. I can see how talking about what you are working on at the moment is a good interview question. It opens up the conversation and ideally should allow discussion around best parts and what you’d like to improve. I didn’t get that job: part of the feedback was I lacked architectural skills. Fume! I didn’t get my choice in how the system worked, so was looking for a new job. Oh well. I’m sure there’s a lesson in there. At a later date, I was asked a similar question, and said I would rather talk about a system in a previous job, because the architecture was much better. That worked out OK. Asking about someone’s experience at an interview is a sensible, open-ended question. However, be prepared for them to have different experience to you. If you’re not careful, you might get the famous Blade Runner (1982 original) ‘Tears in the rain’ quote [IMDb]:

I’ve seen things you people wouldn’t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhäuser Gate. All those moments will be lost in time, like tears in rain. Time to die.

I personally have seen code some people might not believe. I’ll tell you more if you buy me a beer. Of course, some of the bad code was mine. You live and you learn.

I’ve seen some great code too. To be fair, I’m not sure exactly how to qualify what I mean by good code. There can be a fine line between a neat trick and far too cute. We have ideas about clean code, and try out words like SOLID or FLUID. Chris Oldwood wrote about this in his ‘KISSing SOLID goodbye’ article many years ago. [Oldwood14]. He managed to pare the five principles down to two: program to an interface and separation of concerns. Neat, though not the cutesy acronym to help you remember the principles. I’ll offer my own here: NEAT.

• Necessary
• Expressive
• Adaptable
• Testable

Comments welcome. ☺

There are various types of comments. Passing comments, throw away comments, single line, block comments. The human language versions are often more like remarks or asides, so in a sense distractions from the main point. Code comments often work like that too. People also sometimes say they aren’t qualified to comment. I’m not sure what qualifies you: I guess the context. When you only know a little about something, you might be more likely to speak up than when you know lots. The more you know, the more you might spot subtleties and nuances, realizing there’s no one neat response to make. I’ve been reading Klaus Iglberger’s C++ Software Design book recently [Iglberger22]. It’s a great book. He made one small remark or comment in the context of performance: “Do not rely on gut feelings.” Sometimes gut feelings are helpful, but you often need to go further and actually check the details. Even fact checking can go wrong, if you approach a topic with preconceived ideas. It’s easy and tempting to cherry pick research. This is known as ‘motivated reasoning’ [Wikipedia-1]. You can often find some data to back up your point of view, but there may be other oppositional research. An unbiased viewpoint would admit to both sides of the argument. One of my favourite comedians, Stewart Lee, once said, “You can prove anything with facts.”

Let’s avoid throwaway comments, learning when to speak and when to simply listen. In his Tractatus Logico-Philosophicus, Wittgenstein said, “Whereof one cannot speak, thereof one must be silent.” [Wikipedia-2] He investigated the relationship between language and reality. It’s relatively hard to read, being a list of numbered thoughts, without reasons or arguments. You could suggest the book is a sequence of passing comments. However, if you can’t figure out what to say or how to say it, maybe pause for a bit and listen. Or start an email discussion on accu-general, or write an article and get some feedback. Getting your thoughts in a straight line is hard, and writing an editorial is even harder, as I have proved many times over.

References

[Fowler26] Martin Fowler ‘Architecture Decision Record’, posted 24 March 2026, available at https://martinfowler.com/bliki/ArchitectureDecisionRecord.html

[Iglberger22] Klaus Iglberger (2022) C++ Software Design: Design Principles and Patterns for High-Quality Software, O’Reilly.

[IMDb] Blade Runner quote: https://www.imdb.com/title/tt0083658/quotes/?item=qt0378266

[Oldwood14] Chris Oldwood, ‘KISSing SOLID Goodbye’, in Overload 22(122):14-17, August 2014, available at https://accu.org/journals/overload/22/122/oldwood_1957/

[Reddit] ‘How are you managing prompts in your codebase as your AI features get bigger?’, available at https://www.reddit.com/r/webdev/comments/1pgwkcc/how_are_you_managing_prompts_in_your_codebase_as/

[SaferSpaces] ‘Preventing domestic abuse and sexual violence, against women and girls, at festivals and events through education, training and immediate specialist support’: https://www.saferspaces.co.uk/

[Wikipedia-1] ‘Motivated reasoning’: https://en.wikipedia.org/wiki/Motivated_reasoning

[Wikipedia-2] Wittgenstein: https://en.wikipedia.org/wiki/Tractatus_Logico-Philosophicus

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD using AI and data mining. She’s written a book about machine learning called Genetic Algorithms and Machine Learning for Programmers, and one to help you catch up with C++ called Learn C++ by Example. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.