I am always interested in noticing strategies for maximizing one's performance (alternately, minimizing one's effort) at work, and today I was thinking about two related strategies: error and change management. I wrote once before about parnas partitioning (writing code in such a way that it will be easy to change in the obvious ways later), and this is related, but not specific to computer science.One question to ask yourself when you have to choose a method to accomplish something at work is, "How easy will this be to fix
For instance, a coworker recently had to update 100 records in a program that has an Access database backend. Had it been my project, I would have gotten the identifiers for the 100 records, put them into Excel, put the new field values next to them, imported the spreadsheet into Access, and then run a query to update them. What she did instead was to open each record individually in the program, and do each update. This would make me crazy to begin with, but it also had the unfortunate result that, once she realized she had made a mistake, she had to do it all over again. If you make a mistake in my plan, you can easily just correct the Excel spreadsheet and reimport it, or fix the import query, or whatever is required. The data is entered once and it's stable.
This kind of technique is important to me because I make a lot of mistakes. I bet other people do too.
The second question to ask yourself is, "How easy will this be to change when they want me to change it?"
I try never to change something such that I can't pretty easily change it back, since "Put it back the way it was" is such a common request. I make new data rather than overwrite old data where appropriate. And I try to keep my changes somewhat modular, so that if they want to keep some changes and discard others, that too is possible. In your specific job, you probably know what types of changes are commonly desired, so you can set yourself up to make those as easy as possible in advance. It saves a lot of frustration and grumbling (on your part) later if you can treat changes as expected rather than aberrant.
Some common ways of making changes easier include making sure there are backups of old files, storing intermediate results, and using notes and/or naming conventions to keep things clear. You will definitely not remember, three months from now, how you generated this file or what you did to it, so make sure you give your future self a way to recover that information.
Here ends installment eleventy-seven in the Tam's Obvious Work Advice series.
3 comments:
The main problem like that which I have at work is when someone asks me something, I figure it out and tell them or do it, and then later they ask me again. I may or may not remember if I actually found an answer for them or not, but if the problem sounds familiar, I now have places where I can check for notes I may have taken.
It is amazing how people will ask you to do something in preparation for something they have to do, then not get around to it, then months later remember that they were waiting on you. Sometimes they do this many, many times. Sometimes even after they have done their part of the task, they are so used to have it hanging over their heads that they contact me again.
**
I also tend to spend part of my time looking for efficiencies. For example, in one program I use, you can press down-arrow, back-tab, back-tab to get the same effect as pressing tab 7 times or clicking with the mouse.
It really hurts me watching people hit tab repeatedly when they could get someplace much more quickly. So I usually tell them. Sometimes they even change their ways afterwards--it just never occurred to them to do it some other way.
**
I recommend the book _How Buildings Learn_. It's about how to plan buildings so that they are easy to update later. Actually, most of the book is just to convince you that buildings, do, in fact, change over time, so it shouldn't always be such a big surprise.
**
One of my obvious-work-advice topics is figuring out what's the worst thing you could accidentally do. For example as a math teacher, you could emotionally scar a kid for life. As a pizza parlour worker, I could have slammed the edge of the giant pizza spatula right into the neck of a co-worker, after which a fresh-out-of-the-oven pizza would hit them in the face, if they happened to walk up just as I was taking a pizza out of the head-level oven to put it on the counter behind me. Once I thought of this, it was very easy to train myself to check for co-workers before moving the pizza.
A few deficiencies I generally find bad in processes:
* People (usually individual contributors, since they can get away with it) not realizing that when they do something at work, it's part of a process, even if it only directly involves themselves.
* Processes not being robust to changes/revisions.
* Processes not being documented.
* Processes being opaque to quality-assurance methods.
* People not realizing that they need to QA their own work or have someone else do so, if possible.
* Processes not being done in a replicable manner, particularly when it involves data that will be compared to previous/later data and needs to be consistent (lack of documentation can cause this, of course).
* People being too prone to over-value the quickness/ immediate "efficiency" of getting something done right away, when it's something they'll need to do again and having a better process in place will save time/effort and minimize errors in the longer-run.
I'm going to have the joy of spending hours on Wed. trying to figure out what the person who put this datafile together was doing. And of course, there's no documentation!
One of the challenges of my job is that we do contract work for a bunch of companies, and some of what we do is scope out prospects they might want (and we do this for our own exploration division as well). Most of those types of projects are "one-offs" that you do once and never return to, and the quality control that they need is somewhat lessened. (For instance, we grab 200 wells in the area and do a quick and dirty analysis to figure out what we think the "average well" is worth. It's a very simple process where errors don't tend to compound.)
But then some of our work does come back and need to be redone, sometimes over and over, sometimes years apart, and then it becomes important that you used some kind of process and did things carefully. Carefully enough.
One of the techs I work with often tells me that she's worked on 30 or 40 projects in a month, and I've noticed that her work tends to be a bit slapdash. It's not that she necessarily makes mistakes, but that she treats every project as though it's a one-off, whether it is or not. I can understand this since she clearly does a lot of very small projects, but sometimes going in after she's worked on something is a bit annoying.
And we all swap work around like crazy so it does come up a fair bit, this problem of how to sort through what someone else has done.
Post a Comment