jump to navigation

Friday Philosophy – Do Average to Be a Success March 6, 2015

Posted by mwidlake in Friday Philosophy, humour, Perceptions.
Tags: , , ,
trackback

A few days ago a friend of mine, helifromfinland, tweeted something that exactly matched the topic that I was thinking of doing my next Friday Philosophy on. Heli said:

I am learning to do things well enough, not always perfect. Even writing that sentence feels so wrong but #babysteps 😀

That made me smile – I know the feeling myself and I know some people for whom it is all-consuming. It is something that I suspect many people who are active in the oracle community struggle with. We all try and do the best we can at all we do.

In our jobs in I.T what is needed most often is not the perfect solution – or even the best solution we can come up with. It is:

The best solution that achieves the requirement within the timeframe allowed.

I think I was lucky in that the principle of “good enough” was explained to me fairly early on – and in an environment where “good enough” is not usually the prescribed wisdom.

I was at college doing my degree. In academia or school you are usually encouraged to strive for perfection, in the aim of doing the best you can. It seems to me that they don’t teach you what the real world wants. I can’t remember the exact details (it’s almost 3 decades ago!) but I was trying to finish a written assignment in genetics and it was deadline day. I hunted down the professor who had assigned the task and asked if I could have a few more days as I wanted to check up some of the latest papers on it in the library {I know, what a terrible swot {definition – see item two here!} I was}. He did not say no, he did not say yes. Instead he took me into his office and asked me a few questions about the topic and what I had written so far. I think he was checking I had done something rather than was just covering up being lazy. He then asked me what the purpose of the assignment was.

???

I started explaining the topic again but he cut me short. It took him a few attempts I think to get to where he was directing me, which was that it was a task to be completed in a time frame, to show I understood the topic. I was not doing original research, I was not trying to prove anything. It was Just A Task. The Prof then explained to me that his wife was not an academic but worked in industry. She had tasks to do in set time frames and others relied on her doing those tasks on time. She had more work to do than she could easily cope with. The Prof asked me “Should she keep asking for more time do them? Should she only do a few tasks to the best of her ability or most of her tasks to a level that everyone was happy with?” I got his point, but surely in academia the aim is always “as good as you can?”. He felt not and I think he was vexed {meaning, “really pissed off”} that many academics see it that way. There are times you need to do the very best you can; to spend the time to prove your theory; to cover off all the alternatives or caveats to your point; to get the lab result that clearly corroborates your point. But most of the time, you are doing tasks. Stop dithering and do them. It’s more pointed in the commercial world but the academic world is fundamentally the same.

I think he left it to me to decide if I was going to hand the assignment in late or not but I can’t remember what I did (I’ve got my notes from back then, I can probably find out! But I’ve decided this post does not need that level of perfection… 🙂 ).

I think we can all agree that, especially in a work environment where others are dependent on us doing our bit in a timely manner, it is better to do an acceptable job on time than constantly overrun. It is also better to get most {aiming unrealistically for “all”} of your work done rather than failing to do tasks that then impact on others. Of course, what is acceptable is all relative and there is a time/achievement cost-benefit-analysis in moving up the poor-acceptable-good-excellent-perfect spectrum.

Maybe what defines your skill in a role is how far up the poor-acceptable-good-excellent-perfect spectrum you hit on a regular basis.

The problem is that, for some of us, we are like Heli and we absolutely, totally and utterly want to do a very good job on everything we do. This is an idea that our parents, teachers and society do press upon us in our formative years, after all.

Of course, your employer will want you to do six impossible things this morning but most are happy with 4 good things this morning and would prefer that over 2 excellent things by the end of the day and 4 undone.

I can’t say I’ve always stuck to the principal of limiting a task to the effort or time it deserves – I have a natural tendency to try and do too good{no, complete is a better way to put it} a job or else I go the opposite and don’t do the task justice {or even at all!}, so I really empathise with Heli’s tweet. When I first became a contractor I struggled with doing enough average work to keep the client happy, I was just spending too much time on doing the best I could at one or two tasks. In reality, they just wanted lots of stuff done competently. So my Prof had failed to instill the right attitude in me!

One of the nuances of “good enough”, and my point about getting {nearly} all your work done, is that it is almost an impossible thing to achieve. If you get all your tasks done, what happens? Yes, more work comes your way. Especially as our working society has gone in exactly the opposite direction to both what many predicted in the 50’s, 60’s & 70’s and also against what we, the workers, would want. The plan was we would all be working, but working fewer hours and days for similar pay. But as most of us can testify, we seem to be asked to do more and more. It’s a topic for a different day but, basically, we are all screwed by the desire by our employers to get more out of each one of us to maximise profit – more work done by the same number or less people is reducing staff pay in relation to output. The reward for getting all your work done on time is more work will be allocated to you.

Another nuance is one I know I have gone on about before. If you do a job, especially an unpleasant or hard job, very well – what is your reward? You get to do the job for ever. Or you get the next horrible, hard job to do. The reward for exceeding expectations is to set the bar that people will want you to hit ever higher and higher and higher

But you do want some recognition and some promotions.

So, for goodness sake, do just an acceptable-good job of a slightly-more-than-is-reasonable number of tasks and don’t do the next horrible job you are handed beyond expectation. And if you forget yourself and go and do the horrible task well, remember to make an utter mess of the next one – you must stop that expectation bar rising!

The final nuance is perhaps the hardest one, and the one I still struggle with despite someone explaining it to me almost 30 years ago. Some tasks really do need to be at the brilliant end of the spectrum and some are fine at being at the average or even poor end. If your role is as a DBA, your backup/recovery protocols need to be towards the brilliant. You may hope to never need to do disaster recovery but one day you will and if it goes wrong, expect to be fired. However, tuning a batch report to run in under an hour? Usually, you are asked for an ideal run time that the business does not need. Under 2 hours is enough and you have a SHED load of other tasks. No one needs the report in under a minute. You should do an average job, even if your soul dies a little in doing so.

As I mentioned above, as a contractor I initially struggled at times to do lots-of-average-work. As a consultant the requirements and expectations are a little different. You are expected to do excellent, come up with something the regular team has not. It’s nice if it is achieved quickly but heck, hard takes time :-). Average (ie what the regular team would come up with) is NOT acceptable (*NB Not always true). I personally find that the consultant paradigm suits me more, my character and working method is more suited to a slower, more considered approach. I really need to get to be a proper consultant…

So the take home message on how to get on in the working world is:

Be just above average at tasks.

Do 80% of your work but back pedal if you hit 90%.

If you accidentally do a magnificent job, mess up the next one.

Occasionally, only occasionally, let rip and blow them all away with your brilliance.

And please let me know how the above works out for you 🙂

***

Quick update – a recent xkcd panel that makes the point well 🙂

Advertisements

Comments»

1. Neil Chandler - March 6, 2015

In the land of the blind the one eyed man is king. Walk around with one eye shut, but occasionally demonstrate binocular vision. Don’t sweat the petty stuff, don’t pet the sweaty stuff.

my word, it’s Friday.

2. lotharflatz - March 6, 2015

Martin, I always like the texts you are writing. It is good that somebody thinks about the basic stuff. Makes me feel I am not alone.

mwidlake - March 6, 2015

Thank you Lothar

3. Carol Dacko - March 6, 2015

Martin, thanks for the reminder!

4. Long suffering wife - March 6, 2015

For someone who measures the angles of their shortbread to ensure uniformity, and really can’t conceive doing just 80% of tasks, this is a definite area of difference in the Widlake household. I am slowly getting to appreciate Martin’s perspective, but definitely not comfortable with it, but am trying to improve.

I seem to recall last week that It was mentioned that this week’s Friday Philosphy was going to be a message to ‘long suffering wife’ for baked goodies.. Perhaps in a strange way it is….

So you’ll accept a ‘just above average’ pavlova?

mwidlake - March 6, 2015

That will do just fine – as your “just above average” pavlova would be James Martin’s at his best 🙂

5. Brian Tkatch - March 6, 2015

Reminds me:

Lt. Commander Geordi La Forge: Look, Mr. Scott, I’d love to explain everything to you, but the Captain wants this spectrographic analysis done by 1300 hours.

[La Forge goes back to work; Scotty follows slowly]

Scotty: Do you mind a little advice? Starfleet captains are like children. They want everything right now and they want it their way. But the secret is to give them only what they need, not what they want.

Lt. Commander Geordi La Forge: Yeah, well, I told the Captain I’d have this analysis done in an hour.

Scotty: How long will it really take?

Lt. Commander Geordi La Forge: An hour!

Scotty: Oh, you didn’t tell him how long it would *really* take, did ya?

Lt. Commander Geordi La Forge: Well, of course I did.

Scotty: Oh, laddie. You’ve got a lot to learn if you want people to think of you as a miracle worker.

From: http://www.imdb.com/title/tt0708764/trivia?tab=qt&ref_=tt_trv_qu

mwidlake - March 6, 2015

So the moral is, do we want to be Geordi or do we want to be Scotty?

I’ll plump for scotty as I love to shout “she’ll nay take the strain, Cap’n!” (which, don’t think, he ever actually said!)

6. jgarry - March 6, 2015

The thing about programming, it magnifies things. So the difference between utter fail and above average is less than above average to near perfection.

This is somewhat mediated by requirements definition – you don’t want autopilot software to start playing roller coaster, or land in the exact same spot wearing out a runway (both of which have been published risks), and you might not care so much in an inventory system for bottles that have some percentage of breakage or defects, so need to be manually counted anyways. But you definitely don’t want to order 100,000 lids, er, tins of lizard meat, either. Of course, we all have seen bad requirements definitions; the agile philosophy, for example, seeks to ameliorate this with cyclical incremental improvement, or some such thing.

The real problem in This Modern World is: not evaluating the risks properly at all. You get a whole ecosystem of apps programmed in a rapid continuous delivery system, where some are just thrown together, others are micro-QC’d and suffer from no integration testing, entire infrastructures are thrown together to beat the other guy, political considerations and economic bias make for strange decisions, and on and on. Serious bugs can exist for years before anyone notices. The situation is worsening as the workforce doesn’t learn from the mistakes of the past. Where once it was hoped that software engineering could be transformed into an actual profession, now it seems everyone can and will recapitulate negative ontogeny.

None of this is new; the risks enumerated in Peter Neumann’s book vary only by mix and degree from when it was first published 20 years ago.

The flaw in your view is this: it assumes management is smart about allocating resources, and can, um, competently evaluate competency. Since they can’t, there will always be tension between those for whom perfectionism is a good thing, and reality.

Meanwhile, my wife was just stopped and questioned by police while trying to get from her university gig to a patient. Because the middle school next to the university was one of four in the county where anonymous threats placed them on lockdown this morning. Technology bad.

mwidlake - March 6, 2015

You are right Joel – it’s hard to get the business (I don’t like to blame “management” as your direct manager or even the next layer up may not be responsible for any of this) to understand the correct method to approach each individual system requirement (and the wrong usage of methodology has become rife – you use methods, methodology is the study of methods). I also agree with you that there is often a poor understanding of how good a solution is needed.

But getting back to the original post, how many of us add instrumentation to one-of jobs where it is not needed or build in complex re-run logic where in fact the most pragmatic solution is to keep the application simple and just wipe-and-rerun if there is a failure? The irony of this is that those of us who believe in these such things and occasionally put them in where they are not needed spend most of our lives fighting major systems where they would be a massive boon and were never built in.

Let’s all chuck it in and become street cleaners.

jgarry - March 6, 2015

The usage of “methodology” these days applies both to a set of working methods and the study.

Just don’t get me started on “actionable.” 😉

mwidlake - March 7, 2015

Just because it has become a common mistake, accepted by the proletariet, does not make it correct English. And don’t get me started on the abuse of the word “Unique”!

Grumble, grumble, grumble…

🙂

mwidlake - March 8, 2015

Joel, just for your amusement – this is from a very recent oaktable email from Cary Millsap (Apologies to Cary that I have not checked with him first, but he’s such a nice chap…)

“The American Heritage Dictionary of the English Language (2003) usage note on this, which I quoted in Optimizing Oracle Performance (p358), is brilliant:

In recent years, however, the word “methodology” has been used as a pretentious substitute for “method” in scientific and technical contexts… The misuse of “methodology” obscures an important conceptual distinction between the tools of scientific investigation (properly “methods”) and the principles that determine how such tools are deployed and interpreted—a distinction that the scientific and scholarly communities, if not the wider public, should be expected to maintain.

#amen

American Heritage seem to be holding fast to this definition (https://www.ahdictionary.com/word/search.html?q=methodology), although I don’t see the usage note in the online edition.

I like the rule of thumb, if you are tempted to use the article “a” or “the,” then you’re talking about a method. There is no “a methodology”; methodology doesn’t take an article, just like sociology, or geology, …or mathematics, or astronomy.

Cary”

You see, I am not the only bitter, angry language nerd on the planet. I am not unique in that respect.

7. Narendra - March 6, 2015

The reward for exceeding expectations is to set the bar people will want you to hit ever higher and higher and higher
You touched a nerve there. My newly promoted “manager” was telling me that I could have done one more task that was sitting with one of my collegues for almost a year now. I was wondering if his next demand would be to walk on water or convert water to wine.

mwidlake - March 6, 2015

As Joel commented, there are issues where management (or, at least, the business) have a poor ability to quantify what is an easy or hard task. There is an excellent XKCD cartoon that covers it. There is also the little issue that when things go wrong with an IT project, with one part of it, and the project falls behind, they want the thing that failed to be fixed – but it less time than the original thing took to be messed up. So if you propose a solution, there is an immediate pressure for you to deliver the better solution in a ridiculously short timescale. If you question this, you get treated as though it is now not only your problem but your are failing by not promising to meet the stupid timescale. Is this what you just had?

The only solution, I feel, is to refuse the silly timescale, point out the illogic behind it and stick to your guns. But that is very, very hard thing to do in reality. *sigh*.

Narendra - March 8, 2015

Martin,

I wish it was that simple. The irony is this “new manager” was a “technicle lead” till a few days back. So he understands everything about technical challanges. The fact that he was making those unreasonable demands, makes things even worse. It is like newly convert trying too hard to belong…It was quite evident that he was trying to protect his inefficient buddies and over-expensive buddies.
I guess one can never expect to have a logical and reasonable argument with somebody having unethical and immoral work culture.

mwidlake - March 8, 2015

I’m sorry Narendra, it looks like you’ve just come up against one of those people. I am not a “all managers are idiots” person but sometimes when someone has just stepped from the coal face to management they turn into the type of manager they were complaining about as a technician. I have no real idea why, except maybe they are very, very unsure of themselves and desperate to be seen to be “succeeding” to the management gang who are his new peers.

I would suggest a direct but firm chat with them, but if they are scared and feeling vulnerable then you are not likely to get a good response. Maybe time to bite your tongue and watch from the sides…

8. Noons - March 9, 2015

80% is not acceptable for me. 100% is always needed/expected.
But 100% of my work output is not necessarily 100% of the ideal solution.
It may need a bit more, a bit less. It’s all about setting – and agreeing – expectations.
If there is one thing I’ve learned in uni – and life as an IT engineer – it is that the rule of 80-20 for time split in a project is only applicable under perfect conditions and to the whole project. Good old “you spend 80% of a project’s time doing the last 20%” is only applicable if striving for a perfect overall result.
Real life is far from perfect.
Almost always we have to compromise on what would be 100% perfect and settle for only 50%, or even less.
Depending on a host of other things, mostly budgets but also timelines, resource availability, and so on.
Under those conditions I expect my work output to hit 100%. Otherwise I’ll be reducing the total project output to even less than 50%! And so does my boss.

9. Jeffrey Kemp - March 9, 2015

My tolerance for imperfection varies depending on what stage the project is in.

In the design stage, I strive for “100%” perfection; if the design is a little off, fix it straight away. In the early build stage, strive for “95%” perfection or better. Too often I’ve seen a quick-and-dirty fix only causes the project to be delayed even more, because the hack requires other hacks in order to work, whereas taking the time to get it right in the first place results in efficiencies and saved work down the track. However, in the late stages when we’re getting ready to deploy, the aim is for “80%” – i.e. err on the side of stability rather than perfection (make small tactical changes rather than broad architectural chnages) – but note down areas where technical debt needs to be paid down later.

As I tell my clients: “early changes are cheap; late changes are expensive” – referring mainly to the cost of regression testing.

mwidlake - March 9, 2015

I agree Jeff – the design part of an IT project should be a lot closer to 100% due to the escalating cost of changes later on. Sadly, in my experience, design is more and more being side-lined as it is seen as time spent when nothing is being “produced”. I *know* agile and similar methods do not ignore design if done properly, but in my experience few places do it properly. Also, I tend to get involved once the design has been shown to be flawed!
What is annoying about getting the design right is that the project then tends to go very well – so there is no imminent disaster where you get to save the day! Everyone says they understand and appreciate what a great job was done on the design, but you know they are lying. They actually think the design part must have been easy 🙂

10. Jeffrey Kemp - March 9, 2015

I meant to say, “tolerance for imperfection” 🙂

mwidlake - March 9, 2015

I corrected your imperfection 🙂


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: