What have you tried?

Asking for help as a software engineer — a second look at a “historic” view.

Back in 2008, Matt Gemmell wrote a blog post I really valued titled “What Have You Tried?”. I really valued this article, and saw it as a really positive look at “helping others to help you”.

Unfortunately, it somewhat backfired for Gemmell. Although the post contained really useful content, Gemmell’s frustration with people seeking answers without being prepared to invest effort in asking questions was clear from the article. The post was somewhat hijacked by the grumpier experts on StackOverflow, becoming the most-linked reference on the StackOverflow site for a time, and featuring frequently in put-downs of novices.

Following this, Gemmell wrote a follow up to the article, and it no longer exists anywhere except the Internet Archive after a refocus of Gemmell’s work away from tech. This always struck me as a great pity — whilst I recognise the article’s intentions were hijacked, there was much of value.

Asking for help in 2025

It’s easy to think we no longer need expert help in 2025 — after all, surely AI chatbots such as ChatGPT, Claude and others have all but replaced human experts in forums?

Only a few years ago, it was a standing joke in the software community that Stack Overflow going offline would cause developer productivity to tank. However, in today’s climate, commentators are talking about Stack Overflow’s decline — unheard of a few years back. Large Language Models (LLMs) have a part to play in this decline — why risk a putdown on Stack Overflow, when ChatGPT or Claude will answer your question without the snark?

But, whilst LLMs don’t have sarcastic comebacks, without an effective prompt, LLMs will at best return useful information you don’t need, and at worst rubbish. So, Gemmell’s 2008 “What Have You Tried?” is 2025’s “Prompt Engineering”.

Whilst LLMs are a significant presence in 2025, there’s an inherent problem ahead of us. LLMs answer questions based on reading vast quantities of information already published, including from forums and Q&A sites such as Stack Overflow. If we stop asking questions from humans in public fora, and humans no longer need to answer such questions publicly, where will the training data come from to teach ChatGPT to answer 2030 or 2035 or 2040’s challenges?

There’s a bit of the “predator-prey” in LLMs. As LLMs become more dominant, they replace traditional media and therefore have less content to “prey” on, causing their usefulness to decline. A decrease in LLMs’ usefulness causes more traditional content, allowing LLMs to improve training and causing a fresh cycle of replacement. So therefore, whilst LLMs currently appear to be “replacing” traditional fora, I strongly suspect a decline in new content to train LLMs will trigger a shift back to humans-asking-humans, and eventually some degree of equilibrium between the two.

So, being able to ask for help effectively remains and will continue to be a useful skill.

Motivation

Being able to ask for help effectively is a software development superpower. Our discipline is so broad, noone can hope to be an expert in everything.

Good developers can solve problems more effectively than their peers; GREAT developers can leverage their colleagues’ expertise to solve multi-disciplinary and more complex problems more effectively and efficiently than good software developers working alone.

When I work with a developer junior to me, the best indicator on how quickly they’ll progress is how effectively they can ask for help. My aim, therefore, in revisiting some of Gemmell’s ideas is to help more juniors achieve greatness through developing the superpower of asking for help effectively.

Your Expert Colleagues

Your expert colleagues, in 2025, are likely to be under pressure. Technology has always been a broad landscape but the recent crystallisation of AI has seen businesses look to IT to provide new efficiencies by automating knowledge-based work. This places broader demands on teams, particularly senior colleagues.

Alongside this, rising costs mean many organisations are looking at headcount reductions, and IT is not immune from this. So alongside a desire to do more, there’s a pressure to do so with less.

The pandemic has also changed our relationship with work. An increase in working from home impacts how we work with colleagues, and brings an increased focus on work-life balance.

Overall, senior colleagues are under more pressure to do more with less across a wider tech landscape, meaning they have less time and a greater need to focus on a wider range of subject matter.

For my part, I haven’t significantly reduced my working hours or patterns of work, but I am spending more of my time on newer tech than say, 10 years ago, broadening my expertise but also the range of subject matter escalated to me. I’m also being significantly more intentional with my time — I have dedicated “windows” to work reactively with others versus time periods when I’m focussed on proactively moving my workload forwards. A question I can answer off the cuff in half an hour or so with minimal research falls into my reactive time; something that requires me to go away and do a bunch of work to figure it out needs scheduling later in my proactive time.

So, whilst I have a responsibility as a senior colleague to make myself available, and be willing and able to help, my junior colleagues can significantly influence my ability to do so in a timely and efficient way.

The Goal

The dream here is, to borrow from the helpdesk paradigm, First Point Resolution. I want to be able to provide all the help my colleague needs on an issue in one “go” on the first time of asking. This is the best outcome for both of us — I minimise my work in progress, and they get their answer ASAP — win/win.

I’m going to describe 6 components of asking for (and receiving) help from senior colleagues, with the intention of helping you and your team be more productive.

Know Your Team
Describe the Problem
Frame the Problem
What Have You Tried?
What Next?
Closing the Feedback Gap

So let’s dive in.

Know Your Team

Obvious, I know, but the first step is make sure you’re asking the right person. From a technical standpoint this is self explanatory — making sure the person you’re asking has the right technical specialism.

It also, tho, applies from a cultural standpoint — making sure you’re respecting the organisation and team cultural norms in making your request for help.

As well as what and who, these cultural norms also extend to when and how. Your colleagues will have multiple competing priorities vying for attention. Respecting their time by accommodating when and how they feel answering questions or requests best fits into their workload goes a long way to establishing mutual respect.

Describe the Problem

The technology landscape is so vast, you can never hold all of it in your head. Whilst some people undoubtedly hold more of it than others, the shortcut to boosting your “software expert” powers used to be framing a perfect Google search to find useful solutions to the problem in front of you. Now it’s probably framing the perfect AI prompt!

Smart people know lots of stuff. REALLY smart people can quickly find answers to the stuff they don’t yet know.

The first step in that is being able to succinctly describe your problem.

There’s a technique in business improvements called “elevator speech”. Apply that technique here — imagine your only opportunity to speak to your department’s “expert” is catching him in a lift (elevator). How can you get across your request for help in under 30s between floors? “The widget page isn’t working” isn’t massively helpful. “The widget page is intermittently failing because the underlying api call runs in 10–60+ seconds causing timeouts” is much easier to visualise.

Your goal then is to describe the problem precisely, concisely, accurately, relevantly and sufficiently so that your senior colleague can get straight to work helping you.

Framing the Problem

With the best will in the world, I’m much better at “things I can answer right now” than “things I have to come back to”. That’s human nature, and the basic premise behind first point resolution — if you do it right now, it’s done — if you have to come back to it, it drags on ages.

Inevitably, there will be some questions your expert colleagues can’t answer on the spot. In those circumstances they might ask you to put in a forum post, helpdesk ticket or drop an email — not to be obstructive, but as a way to make sure it’s followed up later.

However there’s a significant cohort of requests which should be doable here and now, but for insufficient information.

Like many with a strong technical focus, I tend to hyperfocus on a technical “problem” until it’s done. That’s what makes me an effective problem solver. But to make sure my team doesn’t wait too long for my help, I try to use “meanwhile time” to answer questions. Waiting for a build, that 10 min gap before my meeting starts, on a train, over breakfast — meaning a lot of my help is provided on mobile.

So, sending me a link with a note saying “I’m stuck — please help” immediately places a barrier. I may struggle to view on mobile, there may be substantial history I need to assimilate, I may have to ask more questions. The chances of me being able to help “now” just dropped.

On the other hand, a pithy “I asked Fred for any pointers on the API, he said it is using these underlying database calls and thought you might be able to help with why they’re sometimes taking 10x as long” frames the problem and makes it far more likely I can help.

This was central to Gemmel’s article, and remains true.

It’s far more motivating for your colleagues to work WITH you to solve a shared problem, than to pick up a problem you’ve deemed “too hard” and shipped off to someone else. So make yourself an active participant, a partner, a colleague by making yourself part of the solution.

What have you tried so far to solve the problem, and what happened?

“I’ve tried rebuilding the indexes on the widget table, which didn’t seem to improve things. I did look at the optimisation and got a warning about a missing index on the size and colour fields but wasn’t sure if that was relevant…”

Great — I can dive straight into thinking about what the problem could be.

The corollary to this, though, is that sometimes you’re just plain stuck. Whilst your expert colleagues may appreciate your tenacity in taking months to reimagine a way to improve the process of dragging heavy loads, your line manager might not appreciate you tanking the release schedule to reinvent the wheel. So know when to ask for help.

The key skill here is telling the difference between “stuck-but-moving-forwards-slowly” and just plain “stuck”. I usually give my team an hour as a rule of thumb — if you’ve been stuck for an hour, make sure I know. I might still ask you to persevere with it, but at least I’m in the loop.

Having an element of “early warning” helps you avoid the pitfalls of spending days solving a 5 min problem because you wanted to try everything — your colleagues can act as a brake on this.

What next?

Well, firstly, what do you want to happen next? Be really clear (within the expectations of politeness) at what you want from your expert colleague. Are you asking for pointers? A solution? Tapping out completely and need someone else to take over? A sanity check on an approach you want to try? It’s a lot easier to help if I’m clear what I’m being asked for.

Most of the time, my default will be to provide pointers and direction rather than a fully formed “answer”. This tends to be more time efficient (better to have some pointers now than an answer in 21 working days) but is also part of the learning process. My junior colleagues learn more by solving the problem themselves with some helpful direction, than they would by just copy/pasting my code and calling it done.

Again, working as a team to solve the issue is more motivational for all concerned, so expect to be an active participant in solving the problem.

Closing the Feedback Loop

At a risk of throwing a pity party, whilst being stuck is stressful, being an expert can be pretty stressful too.

So, it’s nice sometimes to hear what happened next. Did the advice help? Did the solution work? Great. That’s a good motivational boost for your expert colleague as well as you.

Or did you try it, it didn’t work and you went a different way? That’s useful learning, and your expert colleague will value knowing so they can better improve their own knowledge and better help others in future.

So, try and close the feedback loop where possible, by updating your colleagues on what happened next.

Conclusion

Whether you work as a team, or as a solo developer, asking for and receiving help is a key skill for a software engineer. Whilst it’s tempting to think that LLMs and chatbots might remove the need to develop this skill, in my opinion it will simply become more valuable than ever.

The guiding principle is, problem solving is in the most part a team activity. The more you can collaborate with colleagues to be helped (an effective helpee, perhaps?) the easier, more responsive and more rewarding that help will be.

About the Author

Rob Walters is a software architect with over 2 decades’ experience writing software, maintaining software and leading software projects. An early career in bespoke software development gave Rob broad experience in a variety of projects ranging from web portals to complex AI research applications (long before AI became fashionable!).

The majority of Rob’s work time is devoted to his role as Software Architect at PatronBase — with a primary focus on R&D — and where his primary tools of choice are C# / .NET / WPF, PHP / Laravel, SQL Server, Azure DevOps and a sprinkling of Terraform / OpenTofu thrown in.

A limited amount of Rob’s time is available for consultancy or architecture through Sett, where Rob’s wider team is available for greenfield or legacy bespoke software projects either taking the lead or as part of a larger team.

In addition to software architecture and project management, Rob spends most of his time making, growing or fixing things, and blogs on this as well as topics around neurodiversity and inclusion.