The Blog's New Direction, Explained

So much of this summer (and before, but it's a little different when one is being paid to solve problems) was learning that the big obstacle in development is filling in the gaps. The gaps between what a library is meant to do and what you need it to do, the gap between knowing a service can do the thing and knowing how to make it do the thing, the gap between knowing what broke your application and why it broke it, and many many more. I found the software development equivalent of "telling time by the stars" is sifting through Stack Overflow, Github wikis, discussion forums, and sometimes official documentation to find a solution.

So what? That's software development. Google is your friend.

 It is, but those forums--the library developers, the helpful souls on Stack, contributors to discussions of all kinds--are by and far time tellers. They *get* what is going on, and they can tell you exactly what time it is--which is great for the original asker who needed to know if it was 2:42pm on a Tuesday in 2013. What if I need to know if it's 2:42pm on a Friday in 2017? Cuz the solution is often different.

It would have been so helpful in so many cases if that post from 2013 ("Is it 2:42pm?") had been answered with more than a simple "It's 2:35pm, based on the angle of the shadow of this stick I stuck in the ground specifically for this one situation." I can't use that stick, because a) it may not even be there today and b) the cosmos has changed slightly but definitively since then and will give a different reading even if it is there.

"Can I get that without the side of metaphor coleslaw, please?"

I'll try...

If EntityFramework is pitching a fit because I didn't configure it properly, it will not tell me "Hey dipshit, you never configured that entity POCO to link to the ASP.net table." It will simply throw SQL errors that could potentially mean anything. And because we're dealing with specific tables that vary from project to project, a large number of answer on Stack will zero in on THAT specific issue-- "Add the 'required' attribute to your 'foo' property" or "Make sure BobEntity is inheriting from the FooTable."

If my scenario is *exactly* like the ones being answered (and they frequently are) then I can just swap table name and go. But what if the problem is actually a symptom of a deeper illness in my configuration or schema design or even some quirk in Visual Studio options? That's much harder to suss out in a Stack post, though I've seen some valiant efforts to help dig into root causes. The fact is, by and large, there are certain base-level knowledge expectations one is hard pressed to get explained in plain English on the web.

Where does a rookie developer still needing these resources himself come in?

More than twice, I stumbled across "tutorials" for an *exact* thing I wanted to do. And got super excited. Only to realize the author was taking certain things for granted--like my ability to set up a thing. Or what a base class for a certain object should look like. And the "first step" is actually closer to what I might consider step three or four. Or (even more frustrating!) the tutorial starts slowly, is easy to follow...and either changes course to something not quite advertised, or skips intermediate steps to more quickly get to the "good stuff."

By detailing my efforts in a true "Here's how I did it" fashion, I can at least provide a transparent, step-by-step guide--the kind of resource I found woefully absent nearly every time I went looking for one. That's it. That's the entire point--to be the change I want to see in the internet bog of software developer resources. If I can help just one other rookie get the flash of insight they need to fix a problem, or realize it might be easier than they thought to accomplish something, then I'll call these writings a 100% win.