Strong opinions should be earned, not borrowed. If you want to propose a change, do the work first.
Understand the trade-offs before you walk into the room.
I see the same pattern again and again in software teams. Someone reads a blog post, watches a conference talk, picks up a new buzzword, or sees how a company like Spotify talks about working, and by the next meeting they are proposing that the whole team change how it works.
The idea often sounds compelling at first. But the moment you ask about the trade-offs, the case falls apart. There is no real research, no serious risk assessment, and no clear plan for what to do if the change creates new problems rather than solving the old ones.
That gap between enthusiasm and understanding is where teams get into trouble.
It's like a new diet pill has hit the market, promising instant weight loss with no effort, and now everyone's scrambling to get their hands on it because it's all over their TikTok.
Some folks are talking about DeepSeek as if it's the second coming of AI.
The clamour might be because it's the first serious open non-US model with reasoning capabilities from China.
Most people are confused about which version of DeepSeek they're using.
Most providers offer a distilled, watered-down version that'll run anywhere, so you're not getting the actual full fat version people are talking as to really see its magic, you'd need a small fortune in computing power.
It's like being promised a rare vintage white wine, only to find the bottle filled with slightly grape-scented water. Same brand, same label, but all the depth and character stripped away, leaving you with a hollow imitation.
The hype suggests it can keep pace with anything OpenAI does, which might sound thrilling if you're already tired of whatever ChatGPT or its siblings spit out.
But here's where the alarm bells should start ringing.
Building AI products with stakeholders requires a fundamentally different approach than traditional software development.
From my experience working with AI, success depends not only on technical implementation but also on bridging the gap between AI capabilities and stakeholder expectations.
In this post, I’ll share lessons from guiding stakeholders through AI’s possibilities and limitations.
Should you build UI components and then add them to a page or build the page first then break it down into UI components is the chicken and egg of software development?
You've probably heard someone quote Norm Kerths' Prime Directive during a retrospective
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
In my experience, engineering teams doing their best at that time inevitably end up having to shoehorn features as requirements change or new information becomes available.
In this post, I'll discuss why great products need strong foundations.
In 2015 I was hired by Cambridge University Press to develop a web application providing digital access to over 35,000 books and 1.5 million journal articles, consolidating several smaller sites. The application would go onto have over 2 million users a day and generate £65 million in revenue per year.
It was a fantastic technical learning opportunity, but it was our culture and approach to product development that would teach me the most important lesson of all.
