Friday Philosophy: Be A Hero – OR Be The Best August 26, 2016
Posted by mwidlake in Friday Philosophy, humour, Perceptions, working.Tags: behaviour, Humour, perception, system development
19 comments
There is a crisis! The database is not responding, the apps can’t work and the business is suffering. Management are doing what management are there for – panicking and demanding “Someone Do Something!!!”.
Step forward a DBA who logs into the server, checks the alert logs, spots what is wrong and fixes it. The database starts processing requests, the applications are all working fine and the business is back on track. What a hero!
The Mantra of the DBA Hero
Such situations are not just the preserve of the database and the DBA of course. You get the hero System Administrators who step in and sort out the lack of storage space at 3am. Or the programmers who look at the code that has been running slow for weeks, that others have not been able to fix, and make it run in 5 minutes rather than 5 hours. All heroes who then bask in the gratitude of management and colleagues. Thank goodness for the Hero Developer/DBA/Sys Admin or whatever. You even get articles and advice on how to be The Hero in some quarters. I’ve even seen job ads like “Are YOU our next Developer Hero?!?”.
Only, 9 times out of 10, whatever was wrong should never have occurred. Yes, there are always going to be hard-to-predict failures or unavoidable catastrophes. But the majority of situations I have seen when the database goes seriously wrong, a critical program messes up badly, or a server goes offline, it is down to something that could and should have been spotted before hand – or never set up in the poor manner that it has been. These are things like Archive Redo log areas filling up, an “innocuous” network tweak taking out a major connection or a data processing program that goes wrong if it is run with no data to process. Just a little bit of thought or testing will avoid these sorts of issues.
As you get better at your role, and I mean really, truly better and not just older, you learn about better ways to do things. Either you make mistakes yourself and have to fix them (the best way to learn, even though it does not often feel like it), correcting something someone else did poorly or you read about how to set up systems to be more fault tolerant. You become more experienced with the tools and you grab hold of any new features that are going to make the systems run better. I’d hope we also all learn skills and working practices that help avoid disasters, such as proper testing methodologies (something that we seem to get less and less time & resource for) and proactive rather than reactive monitoring of our systems. If I am owning a database and it unexpectedly runs out of space for the data files or archive redo – I failed. The database did not, I did – as I know how to set up checks for those things.
The best technicians (in my opinion) that I have worked with are all like this. They don’t monitor for things that have gone wrong so much as monitoring for things that are going wrong. Every week or month they will change something that was OK – but it could be better, more resilient. The end result is a much quieter life and a substantially better service provided to the business.
But that’s where the rub is. That’s where things become unfair. When you are being the Best DBA or the Best Developer, things just work without a fuss. There are no disasters that impact the business and thus no need for The Hero. The systems run smooth & fast and management figure you are probably not doing that much. Heck, you seem to be spending all your time tinkering rather than fixing stuff! They often don’t get that the “tinkering” is what stops the disasters and the need for Heroes. That can lead to a lack of appreciation for what you are doing and it is extremely hard to see someone get praise for fixing an issue that they should never have let happen and even getting a pay rise and you get just a “yeah, thanks for, like, keeping the lights on I guess”.
I had this in spades in one role. I turned up and the critical databases would all be going down once or twice a week. People just accepted it. I worked on the problems, got my team together (and trained them!) and improved the service. For a couple of years I was a card-carrying member of the cape and spandex pants club. I was a Hero. We provided more services and incidents became very rare. And then they decided I was not doing enough. No problems were occurring so what did they need me for? After I calmed down from that (it took a few months) I decided I agreed with them and left. But I left behind a fantastic team and rock-solid systems. {It actually took me years to stop resenting the way they handled it, to be fair, but I never stopped being proud of what I did and that team}.
blowing you own trumpet can help – a little
So what do you do when you are being the best you can and not the hero and, as a result, you are fading into the woodwork? Well, I advise people to do several things, some of which you can see from a slide (taken from my “disasters” presentation) shown to the left. Record the number of incidents and how they go down as you improve things. Document improved up-time and better performance (which might be the same response time under higher workloads). Generally blow your own trumpet. However, it never seems to be enough to counteract the prestige people get from being the hero. It’s not “Right” but it just seems to be the way it is. I know some people take the other approach, which is to actually let (or even create?) disasters in which they can be heroes. After all, this is your career.
One fix is to just move on. After all, in the situation I described above I had actually completed my job – I had been hired to put in place a professional service and I did. So it would have been best if we had all been grown up and decided it was job done and time for me to move on. As a contractor/consultant this is a lot easier to do. Turn up at a client, be a hero for a while and then do your real job of making the systems solid. And then move on.
But not everyone has that luxury to move on. There may be few opportunities where you live or you would lose other aspects to your job that are very important (good child care is one example I have seen). Or moving roles might be something that gives you a lot of stress. So if you are “stuck” in your role and you are doing the best that you can, it is massively demoralising to fade into the woodwork as a result. What is the reward for all your work – pride and less interrupted nights are good but not getting the credit you deserve is hard.
But in the end I think you have a choice. Be a Hero or be The Best You Can Be. I have to aim for the latter, I can’t knowingly allow disasters without trying to at least warn management it could happen. And if you decide to be the best you can be perhaps you have to accept that, unless your management is very unusual, it may well mean less respect than you deserve. But *you* will know. I suppose it is a pride thing.
Are you a Hero? Or are you Simply The Best!
My first book is now physically in my hands. August 22, 2016
Posted by mwidlake in Instrumentation, PL/SQL, publications, SQL, writing.Tags: books, PL/SQL, SQL
7 comments
Proud “parent” of a bouncing baby book
Today a box arrived from Oracle Press. In it were a few copies of “Real-World SQL and PL/SQL” which I co-authored with Arup Nanda, Brendan Tierney, Heli Helskyaho and Alex Nuitjen. I know I only blogged about the book a couple of weeks back, how I became involved and the impact it had on my life for several months. But as I can now physically handle and read the final article, I could not resist putting up a quick post on it. Honestly, I’ll stop being a book bore soon.
My contribution to the book was three chapters in the section “Essential Everyday Advanced PL/SQL”. The idea was to covers some core, standard ways of using PL/SQL which are often overlooked or implemented without considering the impact they can have. There are a few things I cover that are often talked about, generally regarded as a good thing to do – but so often are not done! So just to quickly summarise my chapters:
Chapter 6 is about running PL/SQL from SQL, ie calling both built-in and user defined functions from SQL. It’s a great way to compartmentalise your business logic and extend the capabilities of Oracle’s SQL implementation in an easy and seamless manner. Only people are often unaware of the potential performance and read consistency impact it can have, or how Oracle 11g and 12c help reduce these issues.
Chapter 7, “Instrumenting and Profiling PL/SQL”, covers something that I feel is a major oversight in many PL/SQL development projects. Instrumenting your code, any code (not just PL/SQL), is vital to producing an application that is professional and will continue to work correctly for many, many years. However, it’s a bit like washing your hands after going to the loo – we all know it is the correct thing to do but so many people just don’t! Without instrumentation it is almost impossible to see how your code is performing, where time is spent and where problems are when they occur. I’m sick of having to guess where the problem is when people report slow performance when some basic and light-weight instrumentation will tell you exactly where the problem is. And as for profiling PL/SQL, it’s one of the rarest things to be done but it is so helpful.
It physically exists
Chapter 9 is on using PL/SQL for Automation and Administration. Like many people, I have automated many tasks with a PL/SQL harness – backups, partitions maintenance, metric gathering, data life-cycle management, regular data loads. You end up writing the same sort of process over and over again and usually there are several versions of such controlling frameworks across a company, written by different people (and sometimes the same people!). A large part of this chapter takes the code for creating the examples from chapter 6 and the instrumentation from chapter 7 and builds up a simple but comprehensive framework which can be used to control almost any data load or administrative task you need to do with an Oracle database. The key thing is it can be used for many, many processes so you need only the one framework. So you don’t have to keep writing them as it’s boring to keep writing them. And because the framework demonstrated includes instrumentation, the framework you implement will be easy to monitor and debug in years to come. I have to confess, I kind of wrote that chapter “just for me”. It is my standard automation framework that I now always use, so I can concentrate on the actual task being done and not the nuts-and-bolts of controlling it, and I’ve wanted to properly document it for years.
Something all the authors agreed on is that whilst most technical books describe how elements of a language or feature work, they do not really talk about the “how and why” you do things. The stuff you learn by using the language for a long time and doing a good deal of things wrong. In this book we attempt to put in some of that “how and why”. In my chapters there are a few anecdotes about when things have gone wrong and, as a result, you learn some of the “how not” 🙂
I’m at a lot of conferences over the next few months, including OOW16, DOAG16 and UKOUG Tech16. If you get a copy of the book and want it signed, you’ll find me very happy to do so. Many of my co-authors are at these events too, so you could get us all to scribble all over the book. NB this will not work for electronic versions 🙂
BTW do you like the t-shirt?
This Autumn, I am mostly being a Conference Tart. August 12, 2016
Posted by mwidlake in ACED, conference, Meeting notes, Presenting, User Groups.Tags: Meeting, Presenting, user group
add a comment
The first half of this year was a little quiet for me on the presenting front. I was concentrating on writing and also on organising events, as opposed to going to them, so most of my trips were for personal reasons (that means “holidays”…). I presented at the Ireland conference and a few UK user group events but that was it – quite a few European events this spring fell on dates I was not available (including the Israeli and Finnish conferences where I was asked to attend and would have loved to). Or, oh the shock of it, my submissions were not accepted! {How dare they 🙂 )
However, the final third of this year is the total opposite. I’m at a conference at least once each month from September to the end of the year. In the spring this year I decided to make up for my poor showing speaker-wise by offering talks to a few more events. I knew I would probably do Oracle OpenWorld as, being an Ace Director, the Oracle OTN program is incredibly kind to us and help us attend the conference itself and the ACED briefings just beforehand. Despite my best efforts to scupper my own chances of attending OOW16 (I did not respond to an email I should have for ACED and I only submitted technical talks and not fluffy cloud ones) the ACE program have sorted me out and I’ll be there. I’m not presenting (unless my status as standby for the EOUG lightning talks and OakTable World morph into actual slots) but it’s nice to do a conference with no duties.
In December it is the total opposite for UKOUG Tech16. This is “My” conference, as in not just my home conference and the one I nearly always present at, it is the one I help organise. This year I am the project lead for Tech16, rather than the Database community lead role that I filled for the last two years. It sounds like a promotion and it sort-of is, but in reality there is less work than being a community lead, as I have a lot less to do with organising the content and agenda. But I will have duties to do at the event as well as the one presentation I am doing (I keep it down to one presentation when I have other responsibilities) so for me it is quite a demanding conference.
Between these two book-ends I decided to offer talks to DOAG in Germany and I was asked to speak at the Slovenian and Croatian user groups, which I was delighted to do. DOAG accepted two of my submissions so that was 5 conferences, which is a nice number.
Then the Polish user group announced their next conference and I had promised “the other ORA600” to submit for that one. Then last week I was asked to consider doing the Nordic OTN tour. I said yes to both. The Nordic OTN tour is not finalised yet but it looks like it could be 3 or 4 meetings in different countries on consecutive days.
On top of this, my wife is relocating to Switzerland in October for work and I’ll be trying to assist with that. So I’ve had to put together a spreadsheet of where and when I’ll be. It’s all rather busy. It would be foolish to add to all of this.
So I plan to submit to the Autumn Bulgarian conference too because, well, it’s a cracking conference.
The saving grace? Most of the conferences I am going to have asked me to do the same presentations. So I only need to prepare 3 (or is it 4… I’ll check my spreadsheet).
Why do I do all these conferences? Because (a) I actually like presenting and sharing what I know and (b) I meet people and make new friends. So, if you are at any of the above events, come over and say “hi”.
I suppose I should update my “Appearances and Meetings” page.
The Book. August 4, 2016
Posted by mwidlake in PL/SQL, SQL, writing.Tags: PL/SQL, private, SQL, writing
6 comments
I’ve just added a picture to the right side of this site. It is for a book about SQL and PL/SQL. If you look at the image of the front cover, at the bottom is a list of authors and, near the end, is my name. It’s all finished and at the printers, but it is not out yet – It should be published in the next few weeks.
The British part of me wants to mumble and say “oh, yes, hmmm, I did contribute to a book… but I think you should concentrate on the chapters by the other chaps, they are proper experts, very clever gentleman and lady… I was just involved in a couple of lesser chapters…”
The part of me that spent weeks and months of late nights and long weekends writing it wants to scream “Look! LOOK! I damn well got it done! And it was way more painful than any of my author friends told me it would be as, despite their best efforts, I did not get How Hard Writing A Book Is!
I BLED FOR THAT BOOK!”
And the final part of me wants to say “If you buy this book, would you mind awfully sending it to me and I’ll cut out my chapters and paste in new ones with a few more things covered and a bit more clarity and I really should have mentioned… and I’ll send it back”. Apparently this is exactly how Douglas Adams and Terry Pratchet felt about all their books, so I feel in good company in that respect. I re-wrote one chapter 3 times and I still think I could do it better. Think? I know I could do it better!!!! Next year I’ll do it better than the current better…
How did I get involved in this… nightmare? It was Brendan’s fault. I hate Brendan. My wife hates Brendan. My cat, before she passed on, hated Brendan. When I am drinking beers with him in September, around the fun-fair that is OOW16, I’m going to suddenly turn around and hit him Really Very Hard somewhere soft. Somewhere reproductive I think…
It was, I believe, March 2015 that Brendan Tierney asked me if I had ever thought of writing a book. I said “yes” and explained how I’d had some ideas back in my Teens about what “intelligent aliens” would really be like and the oddities of people – but then found Mr Adams had covered that way better than I ever could. And then I had thought about a spoof on Dungeons and Dragons but then found Pratchett had that totally covered and I now had only one idea left… “No…” he said “I mean a technical book – about Oracle”. Oh! After all, he said, I blogged, presented and wrote articles. What was the difference?
Brendan and Heli Helskyaho had come up with the idea for a book about SQL and PL/SQL which was not an intro book and not a huge tome about all aspect of either – but more about using both languages to solve real-world issues, based on real experience. It would be aimed at those who could write reasonable SQL and who could throw together a quick PL/SQL program/package but wanted to know more about how experts used the languages based on experience. They had Arup Nanda on board already as well as Alex Nuijten and Chet Justice. I knew these people! Arup is a brilliant DBA and teacher, Alex is one of the best presenters on the circuit and Chet is Oraclenerd! All are ACE Directors. So I said no – looking at the 5 of them, I was not an expert. I’m just a skilled-but-still-learning journeyman.
At this point Brendan got tetchy at me (‘being tetchy’, for non-UK people, means ‘easily annoyed but doing a very poor job of hiding you are annoyed’). “how long have you programmed in SQL and PL/SQL?” about 25 years – before PL/SQL was really ‘out there’…
“When did you last develop a production solution in PL/SQL?” About 2 months ago – it was cool, it was fully instrumented, restartable and used plain SQL for the heavy lifting…and bulk processed the rest…
“Who’s better at this than you”. Well, Adrian Billington, Boneist Dawn, Andy Clarke… for SQL Stew Ashton, Chris Saxon is sh1t hot… “so you can name your peers?!?”.
“what is the most challenging thing you have done with PL/SQL?” – I listed a few things…
The point he was making was, I’ve used both languages for two and a half decades to solve problems others had struggled with. OK, I am not the “Best”, but I’m not bad and I’ve done things wrong often enough to learn some lessons! I know I can deliver a solid solution that will either still be working properly in 10 years or, in my eyes more importantly, telling you why it is not. And the key thing was, as Brendan pointed out, I was happy to share.
So I agreed to contribute in a minor way.
And then Chet had to pull out for personal reasons – and guess who inherited half of what we was covering? :-). I thus became an equal player. (Just a quick note, Chet stayed as our tech editor and he kept me “honest”. Everyone on the book helped me, the new guy, keep up.)
Writing a book is a lot, lot, lot harder than writing a blog or an article. I’d been told about this – I was a non-technical reviewer(*) for Jonathan Lewis’s “Oracle Core” and we talked a little about it the whole process – and there was a long, long discussion between the Oaktable members about the effort and financial reward of book authorship (“an awful lot” and “sod all” respectively). I still did not get it. If you are writing a chapter that is 20 times longer than an article it is not simply 20 times harder or takes 20 times as long. It is both, plus a dash more. Part of the reason is the need to get a flow through such a large body of text and I wanted to do that across my 3 chapters. The other is, somehow a book feels more important and you want to makes sure your mistakes are kept to a minimum – both for your own pride and so as not to mislead the reader. Also, as a shared book (and I was the only new author involved) I was very conscious of letting the side down.
So the reality was that for 6 months I worked on those 3 chapters and, during that time, I struggled to maintain my duties as a house husband, the garden went to hell and my regular exercise ceased. Occasional days were so bad that the cat went unfed and my wife had to cook her own dinner. The hard stares were difficult to take, as was my wife being annoyed with me. And I was only doing a few chapters!
But it is done and I am now looking forward to seeing a copy “in the flesh”. I think that will feel weird. One of my regrets in life is that I did not stay in science long enough to be published. I feel this makes up for that.
Would I do it again? No. I’d rather go back to commuting into London every day and I hated that.
Will I change my mind in a year or two? Maybe. I still have that one idea for a Sci-Fi book.
(*) I represented the “knows some stuff but is still learning” intended reader of Jonathan’s book – I was not correcting mistakes or advising him on technical content. I was saying “please tell me more about X as I’m still confused”. I rather enjoyed it.
Martin Widlake's Yet Another Oracle Blog 