Stackoverflow.com Overflow

You know you’ve done it before.

  • You encounter an issue during your development cycle… no, no, better… during the second half of an uneventful Friday on the cusp of a bright and sunny weekend bursting with promises of R&R.
  • So you want a fix… FAST!
  • You google with the tightest permutation of error keywords.
  • A stackoverflow.com post tops the list of search hits. SURPRISE!
  • You click it.
  • Problem solved.
  • …or so you think!?

It doesn’t take very long for the bandage to come undone and expose the nasty gash you had thought you healed. Let’s stay away from specific examples because we all have our own favorites, don’t we? quote1

Before I go on, let me clarify that I have nothing negative to say about stackoverflow.com itself. It is a great aid to developers all around, as are other forums like it.

But there is something to say about the excessive reliance some of us in the development community exercise on this techie forum. We scan madly for the first post sporting that green check greencheck with little to no regard for the accuracy/relevance of the solution to our specific problem at hand.

I’ve been guilty of this too. It wasn’t until a covey of super-smart developers mocked me for one such hastily adopted solution that I did some serious introspection. Since then, I’ve been a lot more cautious and deliberate about how I use that forum (and any other) to my advantage.

So, here is a stackoverflow.com sanity checklist:

1. Start with some independent thinking

I’ve stressed this in a previous post too. Your first order of business when you have a problem is to think about it. You need to research the problem first before you research the solution. You can’t truly solve a thing you don’t understand.

So, step away from the desk and think about it for a while. You will be amazed at the dividends this little step pays. The subconscious is an amazing little beast that proffers ideas when you least expect them. But YOU have to take the first step of thinking about the problem, of prodding your subconscious into action first. Stimulate those impulses.

2. Spend some time on the post(s)

Read the problem description fully. Take the time you need.

Read the solution you plan to adopt fully. Take the time you need.

And finally (this is important), read every single reply to that post fully. Take the time you need.

Nothing feels more like a kick in the rear than discovering later that a solution marked as correct was soon after refuted by a community member with a note that is super-relevant to your specific scenario. Tragically the refuting response is right under the green check from heaven, but too obscure for you to notice because you are desperate for some of that greenness.

Read carefully. Take the time you need.

3. Test the hell out of the solution you adopt

Test. Test. Test. Test. Test. Test. Test.

Oh, and one more thing… you guessed it… TEST.

4. Get a peer-review

There is no substitute for a peer-review. In my experience, the best catches haven’t come from unit tests, or even QA cycles. They’ve come from casual reviews by fellow-developers eyeballing your code as they devour that last praline. (We had pralines in the office today.)

Besides, a peer-review is great at many levels. Even if the specific fix you adopted from stackoverflow.com is perfectly acceptable, a peer-review might expose an issue with the way that code is integrated into your codebase, or better yet, it might catch something totally unrelated to your fix, but critical to the greater good.

Your code is a shared cache of intellectual property. Get some eyes on it.

5. Record the source of your solution

Dedicate a portion of your commit log to referencing where you got the solution from. Personally, I like the version control commit log for this type of thing. Other places to record this maybe the wiki or even the issue tracking tool. I don’t think it makes sense to add this information in code comments, especially if the code is being delivered to another team or group, but if that fits in better with your development culture, that is fine.

The point is to leave some breadcrumbs for the next guy that stumbles across your adopted solution. If he or she is motivated to improve it, they will thank you immensely for the tie-back to where it all began.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s