Continuous improvement

Toyota are famous for continuous improvement and lean manufacturing. The process never ending. Thanks to Spooky action for the link.

Writing a short blog about this article is useful in a couple of ways

1. It means I have this link saved on an external server. So when I reread this stuff in the future I can go and reread that article, revisit the sites which are linked.
2. Reinforces the article just read, writing (or typing in this case) and expresses some part of my opinion or view or take on the subject.

When I read about the bloke who goes home and looks at his home and domestic chores differently I am like that, and I thought and can almost hear people's sharp intake of breath that you could seek to continuously improve not just your job but your own life. I know the words "How anal!"
Sad isn't it, that I feel some form of cultural bias exists against self improvement, even enjoying your job, let alone the drudgery of domestic chores like mowing the lawn, or knowing how long your morning routine takes to get you from bed to office.

I joked when I started work with Paul Vallee and his mates at Pythian that I would have paging reduced to a minimum, that a role which started out as a tough role for one person to handle would end up being a minor issue. Ironically in fact that the only issues which will remain will be the most serious emergencies or disasters. I should have taken a bet on that. I now have days where I do not receive a single page. This is bliss as there is nothing worse than a page to break your concentration and focus.

If you feel like skipping the article here are the 4 processes which the author identified within Toyota each feeding of each other

1. Making cars
2. Making cars better
3. Teaching everyone how to make cars better
4. Making the process of making cars, making cars better, and teaching how to make cars better, better.

Have Fun

Paul

10,000 hours to expertise or why senior DBAs normally have 6 years experience

Watching this video presentation by Malcolm Gladwell at New Yorker 2012 conference.

Interesting. As a contractor you normally work on a 220 day working year.

220 x 8 hours = 1760 hours per year.

If you use the 10,000 hours to expertise that is 5.68 years. This is interesting given that most jobs roles advertised as "Senior DBAs" want at least 5 more like 6 years.

Now I would argue that no DBA does studied DBA work for 8 hours, 220 days per year, unless you are working at places like Pythian, which provide more exposure to DBA work, should mean you are going to become an expert sooner.
The other way to get exposure to different work is to change jobs every couple of years. Normally when the job gets boring as you have been proactive and solved all the hard (and easy) problems.

I was listening to another version of this loosely based on the idea of compounding interest. Essentially if you spend some amount of extra time your area of focus compared to another in your field for example:

if you spend 1 hour extra per week per year, your calculation looks like this:
(220 x 8) + (52 x 1) = 1812 hours per year, reaching expertise in 5.5 years.

if you spend 2 hours extra per week per year, your calculation looks like this:
(220 x 8) + (52 x 2) = 1864 hours per year, reaching expertise in 5.3 years.

This might not seem like much, but as you become better at your focus, your training should remain challenging, pushing the envelope. So the expert level you are handling more complex problems and solutions quicker and more easily.

This raises some interesting questions,

1. Is the burnout, churn in senior DBAs leaving to become landscape designers related to the Alexander factor "no more worlds to conquer"?
2. Do some people realize what it takes to be an expert and jump between roles because they won't invest the time for whatever reason?
   
3. Once you reach the level of being an expert, in most occupations that means you are normally very well paid, in the top x% of salaries for the profession. Are you there yet?

The other interesting point made by Gladwell in his presentation was the underlining factor of stubbornness. Maybe stubbornness is a trait which we should interview for, in tandem with the ability to make jumps when we reach a dead end.

Are you stubborn?

Have Fun

Paul

p.s. this means that I have a long way to go as a writer, given my blog production is one article per month.

Australian postcode T-shirts

Here is a mate's website which sells T-shirts with Australian postcodes, equivalent to zipcodes in North America.

I had a chat to him on gtalk and told him he should extend it to include a image of google maps mashup.

Go and have a look http://shop.qpzm.com.au/

Have Fun

MySQL summary posts

I have Frank's blog on my RSS feed.

Here are a couple of posts discussing some recent presentations at the MySQL conference.

Google and MySQL
Innodb performance optimization

If you are looking for the MySQL conference presentation materials they can be found here

Unfortunately given the push for sparse presentations (in terms of words). Having the audio and
any screendumps/movies would help as well. There is nothing worse than listening to a podcast or audio from a presentation when the speaker is constantly referring to slides or something on the screen which you can't see.

But I guess you can't have everything, before you tell me I should have gone, I live 17 hours by plane away and my kids hate me leaving for any length of time as they wonder if I am ever coming back (remember the passing of time is different for young kids) .

I am still learning MySQL, probably faster as I come from a database background.
The mantra of recording what HAD happened rang true, sometimes being more important than what IS happening. Measuring everything and having a historical record to use to reconstruct is something clearly missing currently from MySQL and until recently SQLserver.

Have Fun

Paul