Skip to main content

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.
Labels:

Comments

Post a Comment

Popular posts from this blog

Use Cases: The Theory

They told me in my CSCI-1275 Systems Analysis and Design course there's a tendency for programmers to just start coding stuff without thinking, and this was nigh on tantamount to total catastrophe. I didn't fully understand this until a little later in the semester. We had just learned about arrays and collections in my CSCI-1630 C# Programming I course, and I found this to be a perfect excuse to write a little application that would synthetically divide polynomials . (That's a really great way to master synthetic division, actually, if you're interested in brushing up on that skill. Although my wife still insists the time would have been better spent putting more time into my algebra homework. Two types of people...). At any rate, long story short: I made the program work perfectly, for 3rd degree polynomials that divided evenly. Then I realized it broke when I tried a polynomial of the 4th degree. And then again when the 3rd degree polynomial had a remainder. ...
Post a Comment
Read more

Sequence Diagrams: Theorizing

The activity diagram is all well and good, and can even be super useful in a lot of cases. But for my money, so far in my limited experience, the sequence diagram is where you really start to get a handle on what you need to do as a programmer. Before the sequence diagram, you're dealing with steps in a process. What needs to happen, in what order, and you could just as easily be talking about employees or way stations or widgets or nothing at all. They're really about systems analysis--that high level, what needs to happen kind of stuff. Really important work, but totally dull from a programmer standpoint. The sequence diagram is where we start seeing method names and parameters being laid out. The interaction between classes and layers. You start to see what methods you'll need, in what classes, and get a feel for what properties those classes will need. You can see the flow of the data from the start of the operation to the end, note the inputs and the outputs. I...
Post a Comment
Read more

Activity Diagram: Theory

So I've got use cases figured out. Not all of them--only a fool or a genius thinks he can sit at a desk away from the end user and think he's got all the use cases figured out (and a genius would never truly believe it). But you can't sit around trying to anticipate every possible use case before you start, so once we have enough to cobble together a complete program or part of one we can move on for a bit. Side note, this is the beauty of the agile approach: "Yeah, we know we gotta go to the moon. But we have to do it in 10 years, so we can't spend 5 years thinking up every problem we might need to solve before we start solving them. How about we start with 'design a rocket that reaches orbit without killing anyone' and build on that when we finish?" That's called an iteration, but more on that later. Fleshing out what that use case needs is the next step, and there are a couple tools I remember being taught. One of them is the activity diagra...
Post a Comment
Read more