Discussions are not always requests for solutions

Discussions are not always requests for solutions

Merely wanting to talk about a problem does not necessarily mean I am incapable of solving it myself. Sure, that might be the case, but that's only one possible situation. It's entirely likely that something else is going on. Allow me to provide a situation to make this easier to understand.

Earlier today, I started working on building a fairly big module for one of my newer projects. It has client-side Javascript, HTML, and CSS, plus even more happening on the backend. The server has to deal with incoming POST data and cookies, build a request, and then fire that off at a third-party service provider. It has to take the response from them, parse it as JSON, pull out some tasty bits, and then make sense of it. If it all checks out, then it does a commit to its own local database and sends an approval back to that client code. The client then takes it upon itself to rewrite the page with fresh content.

None of this is very special, really. It's the same general pattern you find all over the web to do just about anything you can imagine. There are no mysteries here. The service provider has gone to great lengths to make their API as accessible as possible, with extensive documentation, examples, and just general cluefulness from what I've seen. All of the plumbing is straightforward. It's just a matter of hooking it all up.

I am capable of understanding all of this and performing all of the work. It just happens to be a rather long process with many steps, and each of those steps tends to split up, fractal-style, into many sub-steps. Getting the sequencing right matters here, and thinking about all of the places where it could go wrong and testing for those possibilities is a non-trivial part of the work.

So, when I want to talk about something like this, it's not because I don't know where to start, what I'm doing, how to do it, or even if it's possible. I do know where to start, what I'm doing, how to do it, and yes, it's obviously possible. It's just so much easier to do these things after talking about them and laying it all out in terms of a narrative.

That narrative tends to swirl around and loop back on itself a bunch as those individual pieces are subdivided, laid out, and implemented, but you get the general idea. There's a journey from point A to point B, and while it may sport a whole bunch of important details, it will happen.

When I don't have someone available for discussion purposes for whatever reason, that's when my "lab notebook", marker board, or even diary type things come into play. I tend to keep a running log of what's going on as it happens, including calling out things which have purposely been ignored for the time being. Maybe I know that it's not totally correct to do X, but hard-coding it right now will allow me to proceed on four other things which are far more important.

I only write about this now because I became self-conscious of this running log while working on this earlier and flashed back to a particularly bad manager interaction I documented a couple of years ago. This was a guy who assumed that if you were talking about a problem, you couldn't solve it yourself and needed help. No, dude, I just needed to put it into words to get more of my brain involved with sorting it all out. If I needed assistance, rest assured there would be actual questions in the mix and not just descriptions of what is going on.

(I will add a side note here: talking to actual people is a great way to find out potential "gotchas" in a field you might not know about, and that's always welcome. But, that's not what I'm talking about in this case.)

I'm not going to second-guess myself just because someone doesn't get it. I keep logs of my development work and I'm proud of it. So there.

As for my project? It's not ready yet. I took a time-out from it to get this post written for the day, and since I'm flirting with the "stupid hour" here, it will be a while longer before I announce what it is.