My First Published Article

I’ve been blogging now for almost 6 years and presenting at conferences for… 12 years (really? Good grief!). I’ve even written and delivered several courses, ranging from 1 day to 3 days in length. However, up until now I’ve never been what I would term published – ie managed to persuade another organisation or person to publish something I have written.

That changed a few days ago when the latest UKOUG “Oracle Scene” magazine came out, which included the first of a small series of articles I am doing on how the Oracle RDMBS works – the processes and activities that underlie the core RDBMS engine. It’s based on my “how Oracle works in under an hour” presentation where I give the audience an overview of things like the redo mechanism, what a commit *is*, how data is moved into and out of memory and which parts of memory it resides in, how a point-in-time view is maintained… things like that. Many people don’t really know any of this stuff, even skilled and experienced developers and DBAs, as you can get by without knowing it. But understanding the core architecture makes a lot of how oracle works make more sense.

The below is a screen shot of the title and first paragraph, but you can use the link above to see the whole article.

Title and first paragraph of the article

I’m not sure why it has taken me so long to publish something other than via my blog and presentations. I know part of it is the fear of putting something out there that is wrong or misleading. If it is on my blog, heck it’s only a blog and I stick to things I give test cases for or my thoughts and opinions (which are intrinsically open to interpretation). My presentations are certainly put “out there” but again I of course try to ensure what I say I can back up. I think the key thing is that in both cases it is very obvious who you can blame if it turns out I have made a mistake. Me.

But when something is going to be published I feel that (a) it might be taken more seriously so I need to make extra sure it is correct and (b) if I get something wrong or, more concerning, mislead anyone then the people publishing the article could also be put in a poor light. I think that is what has made me wary.

The irony is that the first thing I get published, I know that there are some inaccuracies in there! The article (and also the presentation it is derived from) is an introduction to a lot of technology and I have to simplify things and ignore many exceptions to keep it small and easy to digest. It’s how it works 90% of the time and you need to know that so you will better understand the exceptions and finer detail I don’t have time to tell you about. For the physical presentation I spend a minute at the top of the talk saying I have simplified, occasionally lied, but the overall principles and feel is correct. I had to drop that bit out of the article as, well, it took a lot of words to explain that and the article was long enough already!

Another reason NOT to publish is it takes a lot of time and effort to prepare the material in a way that is polished enough to be printed and I know from friends that the actual financial payback for eg writing a book is very, very, very poor. No one I know makes enough from royalties on technical books to make the effort worth while {though there are other less tangible benefits}. But I have time at present so I can afford to do these things.  If you want to make money out of publishing, write about a load of elves, an often-wimpy trainee wizard or something with sex in. Or all three together.

I did nearly put a technical book together about 10, 12 years ago, called “The Little Book of Very Large Databases” as it was something I knew a lot about but the issues were rarely discussed publicly – most VLDBS were (and are) run by financial organisation or “defence” {why can’t they be honest and refer to themselves as “Killing & Spying”} and they don’t talk. O’Reilly was doing several small, A6 booklet-type-books at the time that it would have suited. I can’t do it now, I know nothing about Cloud and some of the 12C features that would help with VLDBS, so I missed the boat. I regret not giving it a go. However, there is a possibility I might be involved in a book sometime in the future.

I have to thank Brendan Tierney for hassling me into doing this series of articles. I’m not being derogatory when I say he hassled me, he did, but Brendan did so in a very nice way and also gave me the odd toe in the backside when I needed it.

I also have to thank Jonathan Lewis. If this article had been a book he would have got a huge mention for being my technical reviewer. He was good enough to look over the article and let me know a couple of things he felt I had over simplified, some things with the flow and also something I had simply got wrong. You know that bit in books about “thanks to Dave for assisting but all mistakes are mine”. Well, I always thought it was a bit overly… defensive? Well now I don’t.

All mistakes are mine. I want no blame falling on the people who helped me!

I still can’t take my Bio too seriously

Advertisement