James Broad

It's that time again! I've got a talk up this year that started out as a discussion in a DigiLocal CIO session about the best ways of talking to young people about testing the code you've written and led to me writing a basic testing framework in Scratch and seeing how feasible TDD was in that environment. The talk is called "Testing from Scratch" and if that sounds in any way interesting I'd really appreciate any votes to get it into the programme, but there are loads of great talks on offer (in particular, I'm curious to see what both Lorraine Pearce and Michael Luke are talking about) so do have a scroll and see all the wonderful things on offer

8

1 Comment

Really happy to share this piece published on DjuroAI. The core idea: AI is most useful when it lives close to the people and hardware doing the work. Small local models, not massive black boxes that only well-funded companies can access. This is what AI for good looks like. If we want AI to actually help people, whether in renewable energy or anywhere else, it has to be something they can understand, adjust, and run themselves. Not something handed down from the cloud. The article walks through how the Renewable Energy Dashboard works and the thinking behind it. The project started during my time at Erdos Research where Rosie and I collaborated on it. Thanks to Rosie Djurovic and DjuroAI for the opportunity. Link in comments 👇

5

3 Comments

All set for this morning's TDD workshop for self-funding learners. Last time I ran weekend workshops was in the early days of Codemanship, and it's proving to be as fun this time around as it was then, even if we can't go to the pub afterwards. People who *want* to be there, and have paid with their own hard-earned money, are a qualitatively different experience for a trainer. I shall reward them by demonstrating in Java, which is the dominant language in today's group. Next month, my plan is to run 2 sessions on Specification By Example (BDD, ATDD etc), which feeds into TDD very nicely. All these Essential Code Craft workshops will dovetail. They're like Pokemon - gotta' collect them all! And that'll be a non-coding workshop, so if you're a tester or a product manager or anyone else who *should* be involved in defining system behaviour, you'll be very welcome. Keep your eyes peeled for registration going live soon.

17

2 Comments

Validate First. Build Later... Especially with customer facing software. In software development, it’s dangerously easy to spend months (even years), and thousands of pounds building a product no one ends up using. You launch with high hopes. You wait for traction. And then… nothing. Not because the tech was bad, but because the problem wasn’t properly validated, and the solution didn’t land with your target audience. Before building the software: 👉 Validate the customer problem 👉 Test the market demand 👉 Build a lightweight proof of concept or landing page 👉 Get real feedback from real users 👉 Then commit to full development Whether it’s a SaaS platform, booking system, app, marketplace, or customer portal; skipping validation can burn time, budget, and opportunity. ✅ Have you spoken to potential users (not just internally)? ✅ Do they need it, or just say it sounds “nice”? ✅ Would they pay for an early version? ✅ Are you solving a painful problem or offering a “nice-to-have”? Custom software can be incredibly valuable, but only if it solves a real customer problem! #SoftwareDevelopment #BusinessSoftware #StartUp #SaaS #PaaS

6

1 Comment

Claude is offering a double usage limit until 28th March. applicable for free, Pro, Max subscription. this applies for the less active time. I suddenly noticed I am using Claude a lot but still it's not hitting rate limit. anyway yesterday Claude showed a pop-up, saying the news. if you didn't know this, try it. it has become extremely helpful for people who are opposite in American time zone. because for EST guys this free limit applies at night time. but for us (Asian) it's our day time.

2

Been wanting to do some vibe coding? Bolt, one of the top dev tools along with Vercel's v0, Lovable, and Replit Agent, is free for the next 2 days. I've been flat out on other things and haven't been playing with the tools recently so will hop in again myself. A few thoughts if you're just getting going on Bolt. You don't start by typing into the Bolt screen, you should plan first, even if you're just playing. Work out a clear idea of what you want to create, imagine how it will function. Use an LLM to get feedback on the idea, refine your idea so it is clear. Use Claude or o3 with a prompt like this: "I want to build: [IDEA DESCRIPTION] Help me create a complete Bolt-ready brief including: 1. A refined 1-sentence product description optimized for web apps 2. 3-5 core features ranked by importance (focusing on what's possible in a single-page web app) 3. Specific user flow from landing to completion of main task 4. Visual style guide (colors, typography, layout approach) 5. A technical prompt I can paste directly into Bolt Keep everything focused on what Bolt does best - interactive web experiences without complex backends." Read the output. Edit directly or iterate with the LLM, asking for any changes. You're ready. Input this into Bolt. Use 'Enhance prompt' Generate your first version. Try it out. Consider what you want to change. Get functionality right, then work on how it looks. Follow the “one change, one prompt” rule, don't work on more than one thing at a time. Be as specific as possible in any changes requested. If Bolt isn't doing what you want, get help from an LLM, or break your instructions down into smaller steps. Go into preview and test it, make sure it all works as it should, get fixes as needed. Deploy! Any other suggestions for people jumping in to try out Bolt (or similar tools)?

10

Are you paying for your own plugins? Last week I wrote about the number of plugins we often see on websites we take over. One of the reasons this gets expensive is how plugins are sometimes used by agencies. In some cases, plugins become a revenue stream. An agency might have a multi-site licence for a plugin that costs them, say, £300 per year. That licence could legally cover hundreds of websites. But the client is still charged a full single-site licence fee, often £200-£300 per year. If that plugin is used across 100 or 200 client sites, the maths is obvious. The cost is passed on, and then some. What’s being sold as a necessary expense is actually off-the-shelf code with a markup. The bigger issue is incentives. If an agency profits from a specific plugin, they are less likely to suggest the best option for you. They are more likely to suggest the option that makes them the most money. That’s personal interest over client interest.

15

7 Comments

Vibe coding prompt of the day... try it after your LLM coding agent has just finished a significant coding task... "yes, all that sounds good, but... can you apply best practice software engineering principles for efficient algorithm design to optimise the code you just wrote?" The results may surprise you... Efficiency Improvements 📊 Performance Optimization Results: DB Queries (offers) - Before: ~3,574+ - After: ~4-8 - Improvement: 99.8% reduction DB Queries (listings) - Before: ~5,600+ - After: ~6-10 - Improvement: 99.8% reduction Memory Complexity - Before: O(1) per item - After: O(n) batch - Trade-off: Memory for speed Insert Operations - Before: N individual - After: 4 batch - Improvement: ~500x fewer round trips  "Algorithmic Improvements  1. Duplicate checking: O(n) → O(1) per item using HashSet  2. Asset mapping lookups: O(n) → O(1) using HashMap  3. Database round-trips: O(n) → O(1) using createMany with batching  4. Expiration updates: Individual updates → Single bulk updateMany The optimizations follow best practices for batch data processing: minimize database round-trips, use hash-based data structures for lookups, and process data in memory before committing to the database." #VibeCoding #PromptEngineering

7

3 Comments

If you’re paying a web agency for a retainer, say a few hundred quid a month for development, should they A) wait for you to send stuff over or B) proactively find things on your website to improve Most web agencies choose A. They sit back, invoice you every month and wait for instructions. But here’s the truth. If you have to tell your agency what needs doing, you don’t really have an agency. You have a liability. A good web partner should drive progress. Spot issues before you do. Suggest improvements. Keep your website evolving. That’s the difference between a traditional web agency and a web partner like Wrev®

6

2 Comments

Claude code or Codex? No one is maxxing AI harder right now than software developers. Last week at DevConf I asked some devs in attendance what their weapon of choice is. What is yours?

55

15 Comments

“Don’t optimise early” is *right* for software But “don’t optimise ever”? Only if you want bigger bills and more expensive power I’m looking at 5 - controversial - ways software engineering could do better this week. Number 1 is “optimisation”. The maxim most people know is “Don’t optimise early!” And that’s right. Otherwise you’ll waste time and money almost all of the time. But “don’t optimise EVER”? A big mistake. These days, many people feel that it’s cheaper, easier, quicker (pick any you want) to just throw more cloud resources at a problem. And some application spaces, like LLM construction. often rely directly on pure brute force. (Honourable mention to all teams developing more cost-conscious approaches though!) Because - and this isn’t just about AI and LLMs - hugely increasing cloud usage and forecast usage is… ⚠️ driving up electricity prices [plus factors too, of course] ⚠️ creating water scarcity ⚠️ costing more money! What’s your take - is optimisation a thing of the past, or should it be growing in importance?

17

14 Comments

A long Long LONG time ago Ross Duncan told me "It's amazing how little code you write when you do TDD" after having had the privilege of working with some famous legend in London. It's my observation today that it's amazing how MUCH code <your LLM of choice> writes if you don't tightly constrain it. Ask for a simple script to do X? Get a tiny masterpiece with correct set options inc pipefail and a sophisticated usage function and who knows what else. Far in excess of what you'd have done yourself and totally overkill for the task at hand. But yet it's MORE effort to get the simple script that you imagined without the bells and whistles because to do so you must write enough to overcome the built in "be very helpful" driving force in every LLM and get it to "be very reasonable" instead - something they're not always good at. Now I'm just wondering does Ross remember that conversation? :-) he probably didn't know he popped into my head periodically over the years with that short punchy line. :-)

3

3 Comments

I'm excited to go to the ClawCon Boston event this week. In preparation, here's the setup I've been working on: - Openclaw is running in an isolated docker instance - Installed on a Mac Studio with Gemma 4 31b as the local/free AI inference - Using remote screenshare/tailscale to manage the Mac Studio from my laptop - Using Composer 2/ Cursor to plan and build the skills and settings within OpenClaw Still figuring out what skills and use cases to get this setup running with. Starting small and simple for now to help with some marketing/sales work. Any suggestions?

10

9 Comments

Such a blast recording pod with Timothy Armoo yesterday, so many nuggets in this one for folk who are building, considering building or thinking about exits. My favourite? How the best businesses are built around what Timo calls "The Expertise Gap". A simple concept but deeply consequential. Think about the world of software development, for example. Till now you'd have paid a dev agency (or hired a team) to build any kind of software. And they could charge a fair whack for their expertise because you lacked the time, desire or interest (all of which build into expertise) to learn how to do it yourself. That game has shifted. Collapsed even. Because now the only expertise you need is how to describe a problem and the outcome you want and (with a bit of to and fro to figure out the detail) and with the right app and some tokens you've just compressed not only the cost to build, but the time to build too. Watch out for this episode of Nothing Ventured over the coming weeks - it's a gem 🔥

13

1 Comment

Rebuilding a website doesn’t always mean starting from scratch. For https://www.2dotcom.net/, the focus was clarity: who they serve what problem they solve how enquiries happen We re-imagined their online presence, improved user flow, and added chat-based enquiries. The result was over a 15% increase in conversion — without chasing trends. Quiet improvements often deliver the best results.

4

The standard dev shop isn’t appealing anymore. As an agency owner I’ve never been wowed by the idea of just spitting out lines of code for the sake of it, and let’s be honest, neither are clients. No, websites and dev shops aren’t going anywhere just yet. But in the future the focus is going to be more about solving a different array of problems instead of just coding.   Code is democratized now so that can’t be the end game as a developer or as an agency (nor should it ever have been). A developer’s job is to solve problems using code, whether that means building a website, a web app, a mobile app or creating something entirely new. So this has got me thinking about the future of dev work, software engineering and agency work. At Ghost Savvy being design-first has always been our launch. But lately we’ve been doubling down on what customers truly need, and that’s a way to solve their problems. That starts by understanding the customer problem first, then building the right solution even if that solution isn’t what they first asked for. If it needs a website we build a website. If it needs an app we build an app. If it needs hardware we do that. Sometimes, we might even tell a client they don’t need a website. Because that website isn’t the end game, the outcome that solves the customer’s problem is. That’s where I see the agency of the future. One focused on innovation and problem solving and that’s what we’re building at Ghost Savvy.

1

Having spent quite a bit of time at developer events in the last few weeks I am absolutely amazed that the majority actively engaged in these communities seem to be so sceptical and dismissive of the effect AI is likely to have on the industry. On the the flip side LinkedIn is full of stories from vibe coding founders who built their SaaS product, are AI-hacking their marketing and should be able to exit in a fortnight. The reality is somewhere in-between, is messy and is moving so fast it is hard to keep up. Social networks obviously favour extreme views but the middle ground is where the really interesting stuff is happening and both groups would benefit from listening more closely to the other.

25

5 Comments