At the start of this series of posts I was asking why I made so many mistakes. There's been a bit of a lull in this subject – partly because some of it turned up in a presentation at work. I understand now that I was wondering about a number of different things.
First, why was I letting the wrong people see working drafts?
Second, why wasn't I asking other people to help me remove the errors and oversights, which is a natural part of producing a document?
Third, why did / do so many errors and oversights slip by me?
Fourth, why can't I get it right first time?
Here are the answers. First, because I didn't understand that the receivers of a document are The Enemy, whose only intention in asking for anything is to gloat over the mistakes in it. Second, because there's no-one in my team I can ask. In an organisation where everyone is busy and there are few shared skills and knowledge (everyone's a single point of failure) your colleagues can't help you. Third, because I don't really know what answers to expect, so I can't see the wrong numbers. That and the fact that I'm not as sharp as I used to be – even if the grey hair is distinguished.
Fourth is not really about mistakes. It's really a way of asking, why am I so damn slow? The answer to that is, I'm not. Okay, so you can leave me in the dust, but you work for a serious technology company: six months in a retail bank with our lousy equipment and your brain will turn to mush as well. I give myself the impression of being slow because I dive right in and start cutting code – and I'm the only person who does that - Not. With spreadsheets, it's tempting to draft directly in the workbook: the average Excel-basher would think we were crazy if we suggested that what they are doing is the same as cutting Java or VBA raw. But it is – the spreadsheet is the code. Of course, I don't understand the problem when I start and only begin to as I try to solve it. Then it feels like I'm making mistakes or being slow – because it's code and code should compile. So I get side-tracked from the task of understanding the problem and how to solve it into writing first-draft code that compiles. Ooops. I'd be better off if I did some scribbling of ideas on a pad of paper first. That doesn't look like working to some people, and it also makes me feel like I should be able to talk about the task with someone else. Which I can't. It's easier to tap away at the keyboard and look as though I'm working – which I am, but not always effectively. Also, the open-plan office is not a great place to concentrate. (Wondering if you're going to lose your job always helps as well. We should be hearing sometime in the coming week.)
This isn't all of it, but it takes a lot of the emotion out of the subject for me. More to follow on it.
No comments:
Post a Comment