I’m not Steven Feuerstein, should I even bother blogging?

If you’re not into PL/SQL, substitute Jonathan Lewis, Tanel Poder, Maria Colgan, or any other technology great you might respect. Doesn’t even need to be Oracle related.

The answer still, quite simply, is yes.

First – it’s not a competition. If it were, then yes, I concede to the guy that literally wrote book on “Oracle PL/SQL Programming.” I don’t blog to show I know more or even as much as he does. I blog to share examples, interesting quirks, and use cases I’ve encountered. For all of the syntax descriptions in the Oracle manuals and all of the code downloads and explanatory videos out there, maybe my contribution will be the one that clicks with some reader googling for a particular problem. The point of my code isn’t that nobody else could have written what I did, but simply that I did write it, and maybe somebody else can benefit from it.

So, if you’ve written something you thought was interesting, by all means share it. Maybe it’s something with nested table collections that has been covered a thousand times before. Post it anyway, maybe your specific example, with your choice of descriptive phrasing will be the one that catches the next reader’s eye.

Second – more diverse voices matter. I’ve been told my style of writing is too casual and sometime unprofessionally conversational. I’ve also been told my writing helps make new syntax and/or complicated problems more approachable. So even if my content might be exactly what someone needs, if my delivery doesn’t work for them maybe the message gets lost. I’d feel a little bad about that; but it happens. Some of it just implicit. I only read one language well, English, so I only read blogs and watch videos in English. I’m sure I miss out on some good content because of that limitation. Others might too.

So, maybe you have something to say about collections that you know for sure Feuerstein has covered before. Go ahead, say it anyway. Use your code, your words, your language. Get your message, explained your way out there. If you happen to be a polyglot, even better. Translate your own work.

Third – what you’re posting is probably new to someone I’ve been coding in PL/SQL since version 7. I’ve written tens of thousands of lines of code. I don’t believe there is anything I’ve written that couldn’t have been written by lots of other people, but nobody is writing everything. You might be surprised with what others will look for. Month after month, the hottest article on my blog (by far) from search engines is one I wrote several years ago on using DBMS_PARALLEL_EXECUTE to run parallel pl/sql . I posted it because I thought it was a kind of quirky thing to do. I had no idea so many other people would search for exactly that. I’m going to guess I’m not the first or only person to do it; but I bothered to blog about it, so now that article is a resource out there for others. If I picked my blog articles based on what I thought would garner the most “hits” then I never would have written that article. My goal is one. If one person likes a post then I’ve done my job. Two and up is just bonus.

So, if you’ve got some strange use case and think it’s too obscure to be helpful to anyone else – post it anyway. Even if you’re right that it can’t be used in your exact form in other code; your approach, or general idea behind your solution might be the inspiration somebody else needs to get their problem solved.

Fourth – blogging is also helpful to the author. The act of of writing an instructional blog about code is different than the act of writing the code itself. It’s also different than writing comments for the code. When you write a blog article about some block of code you are removing that code from the context in which it was originally written. So, comments you might leave in the code for yourself or future maintainers might be meaningless when read with a stand-alone example. Similarly, intent may be obvious within the context of an application, but in isolation a code block could be opaque. Also, you don’t know your audience, so you need to write in such a way that it aids the intended reader. This may mean exploring syntax minutia and documenting features that are or are not used in order to give scope to your code. These extra steps improve your skill as a writer; but you will often find you learn more about your own code as you start fleshing out the areas around it.

So, if you got some code or practice that you think you have some expertise, challenge yourself to write about it so a novice can understand it. Or, you can flip it around. If there is something you want to learn about for yourself, start writing about it. You don’t have to publish immediately at each twist, turn, trial and error; but as you reach milestones – write about them. Your own blog can then be a reference for yourself as well.

Fifth – start the conversation If it’s your first line of code or your millionth, you have something to say about what you’re doing. Write it down. If you’ve got something good – show it off. If you’ve got a question – ask it. Maybe it’s something in between, a little code block, nothing fancy, but explained well. Put the code out there, get some feedback. You might get kudos and thanks, you might get questions, you might get corrections. Any kind of feedback is good. You might get nothing. That’s fine too. Most people don’t comment, “like”, or “vote” on posts. It’s ok, post anyway. When I started I was getting 1 or 2 visits per month, then a few more, then a dozen, then a few dozen, then a hundred, and another hundred, and another hundred, and so on. The audience is growing in silence but growing. But, let’s say it didn’t. A lack of traffic would itself be feedback. Maybe you need a different topic, different writing style, different audience. Maybe there are no problems with your content, but simply your blog’s interaction with search engines.

So, everyone had something to share, go ahead and share it. You might feel self-conscious about posting some code you’re not sure about it. You can either take a little more time to refine it or go ahead and post it, and ask for improvements. Maybe you’re afraid you’ll post your awesome toolkit and somebody better will come along and tear it to shreds, detailing hole after hole. For one, that’s probably not going to happen. If it does, and it’s bad enough, you can delete the article and repost later after applying corrections, or simply append to the article showing before and after. The work of changing could itself become an article series. I once wrote a 3-part series exploring syntax variations of a single query to solve a question posed by a friend. All but the very last example in the third article are objectively bad ways to do the work; but the point of the series was to explore and explain different approaches to the problem. I intentionally posted answers that I would not recommend for the sake of the exploration. Had I jumped immediately to the simple solution I gave him it wouldn’t have been as interesting or educational. When my friend asked me how to do it, he already assumed I could. When he read all the different ways I came up with he responded “I didn’t know you could do that!” I both solved the problem and showed him something new, making the whole exercise worthwhile.

In conclusion, if you’re thinking about starting a blog, just start. Some blog every day, some once a week, some once a month. Some are regular, some in bursts. It doesn’t matter, just start. Push out some content, talk to some people. Who knows? The next person to read your blog might be a potential employer that didn’t know you existed until he or she saw your work.

Go, put fingers to keyboard and welcome aboard!