Using critical resources

For a short period of time a few months ago I was writing a lot of PL/SQL code myself on one project. I was covering up the team of 7 DB people who had enough Oracle knowledge but never really understood business domain so were unable to write effective hotfixes to patch a mission-critical system in production. And since it was often an Emergency threatening the very core business process of the customer (we replaced their obsolete core system with the brand new platform) somebody just had to fix it.

I maintained detailed To-Do lists of all items to be taken care of and was double-checking that whatever I’m working on is the most critical NOW. I knew I only have myself to rely on and I wanted to make sure I use my own capacity for the best possible value, understanding there’s no way I could do all of it. And as a result I knew that whatever I didn’t do during a day was less important that what I did do. See the point? there will always be something that will slip thru the cracks. And there may be a lot (!) of stuff. But as long as you know that it’s of less importance compared to what was taken care of plus you know there’s no more effort you could have put in – you’re good. As good as you could be, I mean.

Design Patterns

We have a very nice bookcase in our headquarter in Lawrenceville, NJ. It holds a few shelves of old books written five, ten, some even twenty years ago - all about writing software or using a particular software package or product. It really serves a purpose of a wall paper:) but I sometimes stop by and randomly pick a book and flick thru the pages reading paragraphs here and there. It either fills a little break that we all sometimes need to keep ourselves concentrated and focused, or just a spare minute when I'm waiting for someone to have a meeting and don't want to go back to my office when I know it's really a minute or two I have at my disposal so cannot really do any concentrated thinking.

Today I picked the "Pattern Hatching: Design Patterns Applied" by John Vlissides (1998) and here's a quote of the day:

------

"Misconception 5: Patterns guarantee reusable software, higher productivity, world peace, etc.

This one's easy because patterns don't guarantee anything. They don't even make benefit likely. Patterns do nothing to remove the human from the creative process. They merely bring hope of empowerment to a possibly inexperienced, perhaps just uninitiated, but otherwise capable and creative person.
...
Patterns are just another weapon in the developer's arsenal. To ascribe much more to them is counterproductive. Underpromise and overdeliver - that's the best defense against hype and backlash."

------

It's well applicable to nowadays' "patterns" too. SOA "pattern" was the one I thought of immediately after I read this.