11 ms·

I had a low paid data entry job one summer at university well over a decade ago that involved a tortuous process for digitising gas mains installation informati

I had a low paid data entry job one summer at university well over a decade ago that involved a tortuous process for digitising gas mains installation information. I discovered ahk and found I was able to install it, so I began to script the repetitive entry screens spread between multiple different programs. It allowed you to write a simple GUI form to collect various data up front. There was a lot of window picking and timers and sending of mouse clicks. It was really quite depraved but it worked. I could finish an hour's work in about 10 minutes and spent most of my time listening to Tom Stoppard plays. I showed it to my immediate manager who I liked; they had a huge backlog and issues with the health and safety executive. She was interested and I thought I might get a slightly better low paid job maintaining my script, but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk of getting in trouble for using it. So a hundred or so people went back to doing things 6 times as slowly and much more error prone-edly. It's stayed with me as some kind of lesson about inefficient use of human capital. It was the first time I can remember really solving a problem I had with software. Thanks ahk. You beautiful ugly thing.

WaxProlix 6y ago
> It was really quite depraved but it worked > but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk this seems like a reasonable call to me.
- BeetleB 6y ago
  Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
  - WaxProlix 6y ago
    It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. The IT guy might have on some level recognized this and judged the possible loss to be way more than the "guaranteed loss" of the not-broken current process. If I were an IT guy with low level skills, I'd be proud of myself for making that hard call.
    - jimmaswell 6y ago
      You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.
      - WaxProlix 6y ago
        Spoken like someone who's never caused a prod outage at a real company, I guess. I'd say that - outside of some startup or small company that has few (or no?) users - the cautious approach is right. The IT guy knew that he was a podunk pissant warden of a very, very small portion of very, very large organization (an org of a few hundred people is basically nothing compared to the vastness of many oil companies) and that the value that his org provided was compromised by this automated approach, without knowing how to mitigate that compromise. He made the right call, assuming he was just there as a bulwark against exactly this.
        6y ago
  - WaxProlix 6y ago
    I don't think AHK or python or whatever is the issue here, it's automating the consumption of a ton of data without consulting the consumers or vendors of that data, or enacting correctness guarantees. It seems like you're hung up on AHK vs not-AHk and that's not something I care about. I've seen and been involved in a lot of naive automation of human processes just to see all of the edge cases destroy a business for weeks or more on end.
  - silasdavis 6y ago
    So actually he didn't want to be responsible for deploying more widely. I kept on using it. I was probably not meant to.
- silasdavis 6y ago
  Perhaps. It certainly wouldn't have been me that had to live with it. It might have been hard to stop using it. To give some context this was a utility company. The gas pipes were consumer and commercial supply lines. You need to know where they are buried so people don't blow themselves up digging them up. It was safety critical. >> It was really quite depraved but it worked The baseline context for this, though, is a very error prone process. It was common for me to register a pipe in the technical specification (size depth etc) system and map that (by rekeying the handwritten ID) and accidentally pick a different location in the system for indicating connection of service to main pipes. You could have a service pipe (to someone's house) registered to a main in a completely different area. My script eliminated these types of errors. The other thing to note is it didn't change the underlying process. You could, and I did, check the underlying form fills (something I wouldn't bother doing when it took 6 times as long). I'm not trying to denigrate the individual here, he might have been doing his best given his knowledge and level of autonomy (he might also have been chickenshit) but as an organisation they let some value fall on the floor from an employee because they had no mechanism to capture and integrate it.
  - Reelin 6y ago
    If it really reduced the required time six fold, the obvious safety-productivity win-win would be to independently (ie different workers) enter everything twice. You would enjoy a three fold improvement in time requirements, should nearly eliminate all basic data entry errors, and significantly improve the employee experience. Or you could just decide to pass on all that, that's always an option I suppose.
njharman 6y ago
Its experiences like this that make me sad for people who can't code. Not full blown dev, just enough to automate the mundane. I can't imagine being at the mercy of computer tech in areas of being the master of it.
- stormdennis 6y ago
  What advantage is it to the grunts if you automate stuff such that what took them an hour takes ten minutes? All that will happen is that either some will be laid off or the boss will find other ways of filling the time with other work.
  - pletnes 6y ago
    Less mouse arm pain. And you can listen to podcasts, or something, in the 50 minutes.
  - nicbou 6y ago
    Tedious work is very unpleasant. It's not just about how much time things take, but about how dreadfully boring the work can be.
mulmen 6y ago
Awesome. And gross. And awesome. I did something similar around the same time parsing out some archaic TSV format. I forget the details of it all but we were copy-pasting from Notepad to Excel which I think involved changing some Notepad word wrap preference with every file? I think the objective was to get a CSV file and then FTP it somewhere? Anyway, I wrote a powershell script I think it was, maybe I managed to install python? Whatever it was I basically replaced myself with a shell script and spent my spare time posting on somethingawful. Which actually did lead to a better job interview. Overall a good use of my time. I hadn't thought about this for years. Thanks for reminding me, I think.
koheripbal 6y ago
Your mistake here was not pitching the idea to someone more senior.

WaxProlix 6y ago

> It was really quite depraved but it worked > but alas the overworked, underskilled, and somewhat frightened IT person couldn't stomach the risk this seems like a reasonable call to me.

BeetleB 6y ago
Not at all. He could have written his own program and just used it, and IT would never have gotten involved. Because it was using a 3rd party tool, IT got lazy. My company, BTW, not only explicitly allows AHK, they actually encourage it. I mean, if you're going to give people compilers to write arbitrary code, this is not worse.
- WaxProlix 6y ago
  It seems weird to expect someone with no programming training (an IT guy) to either build or sign off on something they have no understanding of. In large/high stakes settings, being risk averse and knowing the limits of your understanding are very good traits. Imho, this IT guy did his job, more or less. What was the testing plan for this AHK script? What edge cases were considered? Unit tests, integ tests.... was there a preprod environment for it? A trial run? Can you safely roll back if / when bad data shows up? What's the retry strategy for network or up/downstream fault tolerance? Is there alarm or monitor coverage for bad scenarios? I'm not saying a bunch of people typing are error prone, if that's your take on my post. I just think that there's a VERY different set of risks (and therefore mitigations) between a distributed manual process and a large scale automated one. The IT guy might have on some level recognized this and judged the possible loss to be way more than the "guaranteed loss" of the not-broken current process. If I were an IT guy with low level skills, I'd be proud of myself for making that hard call.
  - jimmaswell 6y ago
    You absolutely do not need all that red tape to use a script written for a well-known program. The IT guy just didn't care to spend the teensiest mental energy to save people an enormous amount of work. "No" is the easiest, safest call possible, not a hard call at all. People like him should be shamed.
    - WaxProlix 6y ago
      Spoken like someone who's never caused a prod outage at a real company, I guess. I'd say that - outside of some startup or small company that has few (or no?) users - the cautious approach is right. The IT guy knew that he was a podunk pissant warden of a very, very small portion of very, very large organization (an org of a few hundred people is basically nothing compared to the vastness of many oil companies) and that the value that his org provided was compromised by this automated approach, without knowing how to mitigate that compromise. He made the right call, assuming he was just there as a bulwark against exactly this.
      - 6y ago
- WaxProlix 6y ago
  I don't think AHK or python or whatever is the issue here, it's automating the consumption of a ton of data without consulting the consumers or vendors of that data, or enacting correctness guarantees. It seems like you're hung up on AHK vs not-AHk and that's not something I care about. I've seen and been involved in a lot of naive automation of human processes just to see all of the edge cases destroy a business for weeks or more on end.
- silasdavis 6y ago
  So actually he didn't want to be responsible for deploying more widely. I kept on using it. I was probably not meant to.
silasdavis 6y ago
Perhaps. It certainly wouldn't have been me that had to live with it. It might have been hard to stop using it. To give some context this was a utility company. The gas pipes were consumer and commercial supply lines. You need to know where they are buried so people don't blow themselves up digging them up. It was safety critical. >> It was really quite depraved but it worked The baseline context for this, though, is a very error prone process. It was common for me to register a pipe in the technical specification (size depth etc) system and map that (by rekeying the handwritten ID) and accidentally pick a different location in the system for indicating connection of service to main pipes. You could have a service pipe (to someone's house) registered to a main in a completely different area. My script eliminated these types of errors. The other thing to note is it didn't change the underlying process. You could, and I did, check the underlying form fills (something I wouldn't bother doing when it took 6 times as long). I'm not trying to denigrate the individual here, he might have been doing his best given his knowledge and level of autonomy (he might also have been chickenshit) but as an organisation they let some value fall on the floor from an employee because they had no mechanism to capture and integrate it.
- Reelin 6y ago
  If it really reduced the required time six fold, the obvious safety-productivity win-win would be to independently (ie different workers) enter everything twice. You would enjoy a three fold improvement in time requirements, should nearly eliminate all basic data entry errors, and significantly improve the employee experience. Or you could just decide to pass on all that, that's always an option I suppose.

njharman 6y ago

Its experiences like this that make me sad for people who can't code. Not full blown dev, just enough to automate the mundane. I can't imagine being at the mercy of computer tech in areas of being the master of it.

stormdennis 6y ago
What advantage is it to the grunts if you automate stuff such that what took them an hour takes ten minutes? All that will happen is that either some will be laid off or the boss will find other ways of filling the time with other work.
- pletnes 6y ago
  Less mouse arm pain. And you can listen to podcasts, or something, in the 50 minutes.
- nicbou 6y ago
  Tedious work is very unpleasant. It's not just about how much time things take, but about how dreadfully boring the work can be.

mulmen 6y ago

Awesome. And gross. And awesome. I did something similar around the same time parsing out some archaic TSV format. I forget the details of it all but we were copy-pasting from Notepad to Excel which I think involved changing some Notepad word wrap preference with every file? I think the objective was to get a CSV file and then FTP it somewhere? Anyway, I wrote a powershell script I think it was, maybe I managed to install python? Whatever it was I basically replaced myself with a shell script and spent my spare time posting on somethingawful. Which actually did lead to a better job interview. Overall a good use of my time. I hadn't thought about this for years. Thanks for reminding me, I think.

koheripbal 6y ago

Your mistake here was not pitching the idea to someone more senior.