Skip to main content

Command Palette

Search for a command to run...

Month in review: August / September 2025

Updated
10 min read
Month in review: August / September 2025

Things that happened

  • I installed Linux Mint on my personal laptop. I know nothing about Linux but it's an old Windows 10 laptop which isn't capable of running Windows 11, and Windows 10 support of coming to an end. The installation was more effort than I hoped and I had to troubleshoot quite a bit, but I got there without an unreasonable effort. Performance is much better so I'm sticking with it for now.

  • I've used GitHub issues and Jules to create and update some of my user scripts. Jules has high enough usage limits on its free tier then it's effectively free at the moment. If you give it access to a GitHub repository, you can tag an issue jules and it will try to fix the issue and create a PR. The quality isn't great but it's an asynchronous workflow that I can trigger from mobile just as easily as desktop, so it's handy for ideas I have on the go.

    • I plan to publish my user scripts at some point, but they're not currently publicly accessible.
  • I've improved how I use Obsidian for work notes.

    • I'm getting better at using meaningful headings within my work item notes so the document outline becomes more helpful.

    • I'm trying to get in the habit of adding a timestamped progress summary to my work item notes whenever I stop work on one of them (e.g. at the end of the day, or when switching to a different task) in the hopes of making it easier to pick them back up.

    • I'm also going to try and add callouts at the top of work item notes with key details like how to run an app, repro steps for a bug, etc. when this sort of information is relevant.

    • I'm making heavy use of callouts. Callout Manager is a very handy extension for this. I've added several new callout types of my own. I'm also using the auto-collapse feature a lot for error messages so they're searchable but not in the way.

    • I'm also linking between my notes more, linking to specific headings, and modifying the display text for the links.

  • It was interesting using Claude to try and debug an issue with Application Insights telemetry not being sent to Azure. Claude made loads of useless suggestions and kept repeating suggestions that I had already told it didn’t work. It also tried to gaslight me into believing that everything was already working. Having said that, it also gave me some code snippets for getting diagnostic logs which were helpful, and the eventual fix was suggested by Claude and not by the Microsoft help articles about diagnosing Application Insights problems. It didn’t feel atypical that Claude was a mixture of useless, frustrating, and useful.

  • Claude has also been helpful for investigating obscure issues. I've investigated hosting problems in a .NET app which had no server side code, but used a web.config file to configure serving an angular app. I've also asked highly-specific questions about nuances of .NET Framework and .NET Core for individual pieces of code. Discussions with Claude were more fruitful for these obscure issues than they often were for more conventional requests — perhaps because my own knowledge was more lacking so I found lower quality answers helpful in a way that I wouldn't have done for subject areas where I was more knowledgeable.

  • My company has started training all employees in how to make the most of LLMs. As you might expect, the tone was enthusiastic about their use, but I appreciated that the advice was quite pragmatic. It was also emphasised that we humans are the experts, not the LLM.

    • Two pieces of advice that struck me as very sensible:

      • Timebox your prompting, and be disciplined to give up trying to use AI if it's not giving you what you want. Don't waste lots of time playing around with your prompts only to end up doing the task without AI.

      • If the LLM can get you 80% of what you want, it's often not worth the effort of using the LLM for the remaining 20%. Just make the required changes yourself.

    • I also appreciated the reminder to commit small and often, to limit the damage that an LLM will realistically do if it messes up the code.

Things I learnt

  • How did I not know about git grep? 🤯 I used it to search a very large git repository and it was super-fast.

    • I imagine this is largely because it knows to ignore everything covered by the .gitignore, which is what I wanted. If I was using any other tool (e.g. command prompt findstr, or notepad++ directory search, or a powershell script) then a lot of time would have been wasted searching node_modules and other irrelevant folders.

    • I've already used this many times since finding out about it. It's been especially helpful because I'm working in a repository containing about a dozen solutions which share some common code, so finding code usages isn't always straightforward.

    • Because I typically run git commands from windows command prompt, I've sometimes forwarded the output to a file (using git grep foo > file.txt to replace the file, or git grep foo >> file.txt to append to it) to keep a record of the results or perform further text manipulation on them.

    • The search term is treated as regex, but it's also possible to use git grep -F "search term" to search for an exact string without having to escape any regex special characters.

    • I also learnt about git ls-files which is the equivalent for searching files based on their names rather than their contents.

      • e.g. git ls-files "*package.json" to find all package.json files across the whole repository.
  • I'm becoming more familiar and comfortable with KQL for querying app insights telemetry. I'm still far from an expert, but I can find what I'm looking for a lot quicker than I previously could.

  • I now know how to type an em-dash in windows (it's ALT + 0151) and android (when using gboard — you have to switch to the symbol keyboard then long press the hyphen). I've read one or two blog posts lamenting the decline of the em-dash now that it's become associated with AI-generated text, and I'd never known before what the purpose of the em-dash is. I've never been a great writer and I barely even edit what I write on my blog, but I've realised that the way I write I often need an em-dash. Not knowing how to type them, I've never used them before — until now!

Things I've been thinking about

  • My company recently did its annual employee survey and one of the questions asked what area of my role I find most challenging. As I reflected on this, I think it's probably working with a new technology that I'm not familiar with — especially one which has a substantial learning curve and which I need to get up to speed with quickly. I get intimidated by large complex pieces of technology, or black boxes which require learning a lot of concepts in order to understand what they do (authentication libraries are a prime example of this). It seems to me that the way to become less intimidated is probably to broaden my experience.

    • I like the stability of a long-term project. I like getting to know the project well — which includes getting to know stakeholders, colleagues, the codebase and usually some project-specific processes. However, this does narrow the breadth of experience which I gain over time.

    • How much is this a problem? I'm not sure. It's not causing me any problems right now, but I hope to be in this industry for another few decades and I imagine that breadth of experience makes it easier to adapt to changes.

    • Would I mind working with the same technologies for the rest of my career? Honestly, I think it wouldn't be my preference, but I don't think I'd massively object to it if I knew that those technologies would carry me through to the end of my career. I don't feel any great need to be cutting edge, but I don't want to become obsolete.

Things I'm grateful for

  • As I was in July, I'm again grateful for the IT team at work. I raised a ticket that my laptop couldn't use the monitors on one of our hotdesks. It was investigated the next day and about a week later it had been replaced and the desk was useable again. I dread to think how long that would have taken in a large bureaucratic organisation.

Things I've read / watched / listened to

These are my own reflections from the content, not necessarily the main point of the content.

  • I've only recently come across the concept of interactive blog posts, and I've found them to be a really enjoyable way to learn a topic.

  • No, AI is not Making Engineers 10x as Productive

    One thing I've noticed about all these characters in AI coding hype pieces is there is almost always a degree of separation from the writer to the actual productivity benefits. The poster is a founder, or a manager, or an investor, making grandiose claims about someone else's productivity. There's nothing wrong with secondary sources but if you can't find a primary source, you might start questioning the reliability of the information.

    Presentations from actual engineers demonstrating how they achieve more productivity with AI are much more varied and much more muted in their praise. These demos show largely AI as the same technology you and I were familiar with before we got so anxious: a neat text generator that sometimes does magic but often requires you to take the wheel.

  • Obsidian Search: Five Hidden Features - Obsidian Rocks

    • I noticed the "Explain search terms" toggle in the obsidian search and wondered what it was for, as my searches didn't have anything worthy of explanation. This article was very helpful for understanding the built in functionality for searching within obsidian.
  • Why using Bun in production (maybe) isn't the best idea - DEV Community

    Production depends on sustainability, predictability, and trust.

    • This is a great summary of my concerns about using LLMs too.
  • AI-Generated “Workslop” Is Destroying Productivity

    AI generated work content that masquerades as good work, but lacks the substance to meaningfully advance a given task.

    The insidious effect of workslop is that it shifts the burden of the work downstream, requiring the receiver to interpret, correct, or redo the work. In other words, it transfers the effort from creator to receiver.

    When coworkers receive workslop, they are often required to take on the burden of decoding the content, inferring missed or false context. A cascade of effortful and complex decision-making processes may follow, including rework and uncomfortable exchanges with colleagues.

    Approximately half of the people we surveyed viewed colleagues who sent workslop as less creative, capable, and reliable than they did before receiving the output.

    • The point is that this is not merely doing bad work, but requiring others to fix the problems which it creates.

Things other people said

Quote of the month

  • "Keyframe animations are meant to be general and reusable. We can apply them to specific selectors with the animation property"
    An Interactive Guide to CSS Keyframe Animations with @keyframes • Josh W. Comeau

    • I don't do a lot of front end work and I've always been confused about how to use keyframes and animations. Knowing that the keyframe is meant to be reusable and the animation property is meant to use it somewhere made it all click together much better for me.

Things I've published

Things I haven't published

Most ideas I have for blog posts never see the light of day because I don't find the time to write them. Here's what I didn't get round to.

  • Claude at work: what worked and what didn't

  • My experience of installing Linux mint

  • Diagnosing why Application Insights telemetry wasn't sent to Azure

  • No, AI is not like a junior developer

  • Authenticating Augment extension in VSCode web

  • Extracting simple HTML tools from Lovable

  • Overriding Access-Control-Allow-Origin headers in chrome

  • First impressions of using claude.ai at work

  • Using collapsible callouts in Obsidian to prevent error messages disrupting flow

  • New Outlook quick steps and templates

More from this blog

T

Tim talks tech

76 posts