Just thought I'd share a "developing in lock-down" tip, which I inadvertently invented (well, let's say discovered) last week. I'm going to call it recorded rubber ducking. The idea of rubber ducking being that if you talk out a problem, even to yourself, you may hit upon the answer.
That wasn't working for me, so instead I felt I needed to ask my colleagues to see if someone could see what I couldn't.
Importantly though - and really I was just trying not to waste people's time - I took the trouble to clearly write out the issue. What it was, what I'd found, and what still puzzled me. I planned to then post this in Slack, in one hit with all the information, rather than starting with a "@here, anyone know about X?" type of message and follow up from there.
And, as you've probably guessed, the act of doing that was sufficient to see the solution to problem* without even bothering anyone.
Clearly the action of writing, and forcing me to structure my thoughts more than if I was just thinking about it, was the key to recognising the problem.
* The details aren't that important, but to summarise, I had a situation where from one system, API responses were empty, but from another I could expected responses - even though they should be accessing the same data store. No errors on the API though. I remember writing something like "It's as if they are connecting to different databases"... and of course, they were. There was an Octopus Deploy scoping variable which meant settings for UAT were in production, meaning the API deployment was working from an empty database, with an unexpected name, that it had created.
Comments
Post a Comment