I’ve noticed a technique that’s been very helpful for me when writing software. Hopefully it’s a tool you might use, too.

When I come to an impasse — when I’m not quite sure what the next step in my work is — I find that I often hit a particular technical problem I can’t trivially solve. The problem that prompted this blog post was one that mashed together problems in Entity Framework, Generics, and Entity SQL. I realised this wasn’t going to be trivial, and I wasn’t sure how to proceed.

So, I hit stack overflow, clicked ‘Ask a question‘, and got to writing, I spent a while formulating and re-writing the question for the unknown programmers of the internet, trying to state the core of the problem and the way I wanted it solved. It included the problem, my approaches, my half-baked architectures.

Interesting alchemy starts to happen when you do this. You start to realise your problem in more detail. You start to see the flaws in your own thinking. You come to understand how you may have limited yourself, driving for the wrong kind of solution. When you get your own thoughts out on paper, you can see, then correct, the flaws.

So a question that starts;

“I’m having trouble querying for tables…

transmutes through

“Entity Framework doesn’t allow generics…

through

“I’m thinking of using code generation…

to

“If I can get hold of the EDMX model, I can run a code generator…

And you start to realise the shape of the problem you really help with.

In the end, stating the problem clearly for the folks on Stack Overflow (and this is a minimum standard for asking a question) is often all you need to see the solution to your own problem. So you may not need to post the question in the end. In this respect, it’s very similar to Rubber Duck Debugging, but with the additional benefit that, should you not figure it out, you can immediately post a high-quality, thoughtful question to Stack Overflow.

Anyway, you probably use something like this already, but it’s just a reminder that the technique is available.