• (cs)

    Go Figure, Stuff like that happens all the time. good thing I compile my scripts into programs

  • Jethris (unregistered)

    Luckily, I never had to be a "third-class" programmer, but rather, mostly a "second-class" kinda guy.

    I'm also too stupid to keep my mouth shut. I would have said: 1: I met all my deadlines, right? 2: I, using iniative and adaptivity, didn't listen to the powers that be and went ahead with what I thought was right. (Just because the IT dept says the world is flat, doesn't mean it's true) 3: Just because you guys are too busy or arrogant to do what I did, doesn't mean I'm the one in the wrong. 4: Doesn't the company and it's integrity come before your little group? 5: I hear the PHB has a new opening, you applying?

    CAPTCHA: Tastey, Nobody bakes a cake as tastey as a Tastey-Kake.

  • The cow says.... (unregistered)

    Just leave. The moment you find that the programming job you got is actually mind-numbing data entry that will one day be a cancer on your resume, just turn around and go. How hard is that? Once you find that all control and authority is vested in a cadre of self-congratulatory elites with their heads so far up their own asses that they smell duodenum, just walk away. No matter how much you need the money, this job will end up costing you more, in frustration, in lost opportunity, in time and brain cells wasted. Just go.

  • (cs)

    Aaaaaand ... that's why automated stuff, if it works OK (as in "no weird stuff happening"), must be kept a secret.

    That way, you do everything quick, slack off the rest of your allotted time slot and save yourself from stoopid management reprimands.

    We did some automating stuff at my former job, and most of the middle and upper management didn't even know about it. People who spent days doing weird matches (similar to this WTF) had their work reduced to simple copy-pasting data, process, fetch whatever the program spits out.

    Too bad the IT department was ... um... 3 people, of which 2 of us knew how to apply changes ... and both of us are in greener pasture. WTF indeed.

  • (cs)

    I love the "programming jobs" that are actually data entry, because so often they can be simplified with some scripts and you can spend all your time goofing off, like by reading sites like this...

  • Ahoapap (unregistered)

    Oh god, these are one of our vendors..........

    We've got to get a new one.

  • evilghost (unregistered)

    Did he ever consider that he was writing to the code/script that was going to make his entire department unnecessary? Why keep all those data-entry folks on the payroll when the script does it.

  • Rich (unregistered) in reply to bstorer
    I love the "programming jobs" that are actually data entry, because so often they can be simplified with some scripts and you can spend all your time goofing off, like by reading sites like this...

    I was thinking the same, though then i'd worry about having my and 3 other positions made redundant by a script. At least the author showed some intelligence by making the script; I'd be more worried if i was one of the other guys.

    CAPTCHA: cognac what you need to drink to survive a job like that.

  • htg (unregistered)

    Always keep automation systems that make your job redundant (or rock the boat the 'superiors' are in) secret.

    3am working is a fine compromise for doing 1 hour of work a week but getting paid for ~40.

    However the 'No' culture at the company should have been obvious early on, so create the script, give it to your fellow 'third grade programmers', and leave when you get bored of Solitaire / the job market is heating up. You could even say in your leaving interview that you could write a script to automate the majority of the department's work, and you're willing to do it as a contractor. Do this if you hate the fellow third grade programmers, because you can sell the wage savings to the company to aid your pitch.

  • (cs)

    ...but not to the degree of this story. This is pretty good, writing a script to automate your entire job.

    I would share it, but if I had a clue about the corp. culture at a place like this, I'd write the script, use it for a while, find a new job, and then release the script. ;)

  • (cs) in reply to Jethris
    Jethris:
    Luckily, I never had to be a "third-class" programmer, but rather, mostly a "second-class" kinda guy.

    I'm also too stupid to keep my mouth shut. I would have said: 1: I met all my deadlines, right? 2: I, using iniative and adaptivity, didn't listen to the powers that be and went ahead with what I thought was right. (Just because the IT dept says the world is flat, doesn't mean it's true) 3: Just because you guys are too busy or arrogant to do what I did, doesn't mean I'm the one in the wrong. 4: Doesn't the company and it's integrity come before your little group? 5: I hear the PHB has a new opening, you applying?

    CAPTCHA: Tastey, Nobody bakes a cake as tastey as a Tastey-Kake.

    I was once in a fairly similar situation. I too had automated something that took 2 people over 8 hours each day (combined). The resulting script ran via cron at 6AM and reduced 8 man hours of work each day to a 16 character bitmask page (before BlackBerry's). I too was reamed for writing an unauthorized script to correct the daily batch job errors each day (dump transaction logs, run fix-it scripts, etc).

    Unfortunately for them, they didn't trace the script to me until the problems were magically being fixed for about a month. I told them that I had saved them the equivalent of an entire person each day, that could then be used for more productive work.

    They bitched, so I shut down the cron job (it was running on my local host), shut down Unix on my box and took 2 weeks vacation. It took a couple of days before they started calling me at home asking what the hell I had done to sabotage everything. I did not return the calls.

    After two weeks, I went back to work. All the senior managers were at my desk waiting for me - presumably to kill me after I showed them what sabotage I had committed.

    I told them I had simply stopped running my cron job. They didn't believe me. I told them to power up my box, log in as me, and run a 1 line script that re-populated cron with the job. In 5 minutes, pretty much all of the daily nonsense had been fixed by the script.

    Since they had seen how everything was fixed, and no sign of sabotage, they sort of had to eat crow. From then on, they never messed with me again.

    Sometimes, the best thing you can do when a-holes spout off is to stop doing your job.

  • Anita Tinkle (unregistered) in reply to Ahoapap

    Is "Herald Media Services" a Pennsylvania-based concern? If they are, I know exactly who these people are. :-)

  • RON (unregistered)

    I did this at my current job. Our old toolsets were ancient and no one knew how they worked internally, and noone wanted to update them to be more user-friendly (or even workable).

    So I made a new uber-tool to take care of everything. People freaked out at first because it was an "unauthorized project". Then some management saw how much more productive it made everyone, and increased our workload by 50%.

    Bottom line: If you streamline your work process and people know about it, they'll just give you more work to do.

    Oh, and now I have to fix the damn tool every time someone does something retarded with it (despite the fact that I clearly documented the entire thing and made it known that anyone can modify it if they want!). Eesh, initiative is not worth it in a corporate environment.

  • Frymaster (unregistered) in reply to Anita Tinkle

    stupid people, well, the world's full of them, innit?

    It's the "stealing other people's work" bit that's so malicious...

  • Jeff (unregistered) in reply to jrwr00

    When I was in college I took summer internship for a big international company located close by. The job gave me course credit + wouldn't look bad on my resume (as internships go). Plus it paid $15/hr, not bad for a college student.

    So I get there and realize my entire job could be automated with a simple program. So I take the file format home, write a program, and then bring it in the next morning. I show it to my supervisor who then lets me give it a whirl and the thing works flawlessly. The other intern and I blow through two months worth of work in a week and the company sent us to training and misc. other stuff for the rest of our duration. I still got paid and got SAP training (wheeee!).

    I tried to get a real programming job with them after I graduated, but apparently they god rid of that entire group after my internship was done and the third grade programming success didn't translate into anything the first graders wanted.

    At least MY story worked out pretty well for me. I would have thrown myself out a window if I had to do all that work by hand.

  • (cs) in reply to The cow says....
    The cow says....:
    Just leave. The moment you find that the programming job you got is actually mind-numbing data entry that will one day be a cancer on your resume, just turn around and go. How hard is that? Once you find that all control and authority is vested in a cadre of self-congratulatory elites with their heads so far up their own asses that they smell duodenum, just walk away. No matter how much you need the money, this job will end up costing you more, in frustration, in lost opportunity, in time and brain cells wasted. Just go.

    No, you look for work while you're still getting paid.

    1. An employed person always looks more attractive than an unemployed person. It's just simple envy. "We want want they have." vs. "Nobody wants this guy."

    2. You keep getting paid.

    As for making scripts like this, at one place I wrote a HEX editor that changed several parameters on a device. My supervisor wanted to write 10,000 versions of the code. I pared it down to 2 with the editor. Total savings: About 40 man-hours a week.

    That editor, and the code I wrote to match it, are now the lifeblood of that company.

    And no, I don't work there anymore.

  • ringbark (unregistered)

    At a previous post, I wrote a lot of automated scripts to do stuff. Real scripts were in a proper /bin directory, mine were in a /u/myname directory and all the programmers had my directory in their $PATH. After I left (acrimoniously), all was well until the DP manager had a spring clean and got rid of "all this crap". All hell broke loose because my ex-colleagues suddenly found that half the stuff they used wasn't there any more. I believe eventually they persuaded him to restore the scripts, but I don't know how long "eventually" was.

    waffles: what the DP manager does

  • (cs)

    Just bring up the fact that you wrote it at a large staff meeting and ask if management will give you a raise for your brilliance and/or punish the guy who stole your script.

    Chances are you'll just get fired (instead of quitting) but you'll feel better about it and have a funnier story.

  • Billy Bob The Sad Programmer (unregistered) in reply to The cow says....
    The cow says....:
    Just leave. The moment you find that the programming job you got is actually mind-numbing data entry that will one day be a cancer on your resume, just turn around and go. How hard is that? Once you find that all control and authority is vested in a cadre of self-congratulatory elites with their heads so far up their own asses that they smell duodenum, just walk away. No matter how much you need the money, this job will end up costing you more, in frustration, in lost opportunity, in time and brain cells wasted. Just go.

    Wish I'd followed that advice. Instead I spent the bulk of my career at mind-numbing soul-destroying employers.

    I second this entirely. Anyone new to the industry, keep this in mind, because it is 100% true.

  • Tim (unregistered)

    Ah, now I know why there were problems with the Tribune data for my Tivo so many times (sorry to spoil the mystery for anyone).

    Anyway, the rookie mistake was to let people know about the script. If anything, you use the script for a few months on your own, then you've got evidence that it worked (although it sounds like the idiots in charge wouldn't even have cared about that).

    Reminds me of a job I had when I joined a large company that didn't seem to know what to get me to do. Eventually I was sent to a department downstairs to do a job for them. It was some simple data munging, and took about 3 hours (including the time it took me to learn awk/sed so I could use them to do the munging). I came back at lunch to report to my boss and he said "Oh, you've finished? They said that job would take two weeks."

    Luckily the company didn't do anything important, like write the software for half the world's flight simulators that are used to train civil and military pilots...

  • AdventureTime (unregistered)

    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up?

    Point is, script cowboys cause problems because their shit:

    • Is developed in isolation, not as part of the development process in use at the organization. So, folks who should be consulted on impact are NOT.

    • Documentation? We're cool script cowboys, we're too busy saving the world to write up any documentation.

    • Testing? Nah. Why test it when it obviously smirk wink smack sink WORKS?

    • Doesn't take maintenance cycles into consideration. "The Script" becomes an item of mystery that is discovered when it breaks.

    • VIOLATES ENCAPSULATION (of departments!) WHICH IS FATE WORSE THAN etc. Scripts can contain hard-coded assumptions which are equivalent to Business Practices . It isn't the technician's (== code cowboy's) job to formalize business practices. Aren't we all (as smug readers of The Daily WhateFer) in agreement that it SuX0Rs when management make technical decisions? So... physician, heal thyself?

    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

  • Chaz (unregistered)

    Ah, this story is dear to my heart.

    I automated my last job. I developed some scripts to watch my Outlook inbox; parse incoming email requests; fill out intranet web forms; submit my work; and respond to the emails. The scripts would pause for random amounts of time between operations, so that incoming requests wouldn't receive "All done!" replies in 10 seconds.

    A few months went by; naturally, no one noticed anything. I grew more bored and frustrated with the job each day. So I showed my boss, expecting to be fired for insubordination, but -- lo and behold -- he was indifferent to what I'd created. That's when I knew it was time to leave.

  • ChiefCrazyTalk (unregistered)

    The Real WTF is that this is no longer the Daily WTF! Why the name change? The new one is lamer than an iPod with no wireless and less space than a Nomad.

  • (cs) in reply to AdventureTime

    This reminds me of something a friend of mine did. He worked for a certain now-hot company, which would have devices put into debug mode for troubleshooting, but never taken out. The problem is that on startup and during usage, the devices would spew data into a central debugging server while in debug mode. This is the correct behavior, except that whenever the troubleshooting was finished, devices may not have been removed from debugging mode. So, he took it upon himself to write a perl script that would determine how long devices had been in debugging mode (by looking at creation times, etc), and deactivate debugging on devices that had been active for over two weeks.

    Turns out that, like quantum physics, he had changed the state of these logs simply by observing them. So, the last access times were changed from 2 weeks in the past to the date at which he ran the script. That would be ok, except it also turns out that real, developed by IT scripts were also viewing those logs, and were parsing the access time. Which was now "5 minutes ago" for every single log.

    Shortly thereafter, a nastygram circulated the staff, chiding whoever had caused this problem and suggesting that they may not want to do it again. My friend quickly removed his script from the server and dropped the idea completely.

    Moral of the story: sometimes there's a reason to not write that script.

  • AGould (unregistered)

    A lot of this depends on your corporate environment. I'm fortunate enough to work for a company who sees the value of spending eight hours today to save half an hour for every day in perpetuity (generally automating stuff previously done by hand). There's always something else to do after (six years and counting.)

    If my company didn't encourage that sort of thing, I'd still do it - I just wouldn't do it for anyone else. I'm responsible for my work - if I can do it in five minutes by automation instead of two hours by hand, just makes me look better.

  • SomeCoder (unregistered) in reply to AdventureTime
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up?

    Point is, script cowboys cause problems because their shit:

    • Is developed in isolation, not as part of the development process in use at the organization. So, folks who should be consulted on impact are NOT.

    • Documentation? We're cool script cowboys, we're too busy saving the world to write up any documentation.

    • Testing? Nah. Why test it when it obviously smirk wink smack sink WORKS?

    • Doesn't take maintenance cycles into consideration. "The Script" becomes an item of mystery that is discovered when it breaks.

    • VIOLATES ENCAPSULATION (of departments!) WHICH IS FATE WORSE THAN etc. Scripts can contain hard-coded assumptions which are equivalent to Business Practices . It isn't the technician's (== code cowboy's) job to formalize business practices. Aren't we all (as smug readers of The Daily WhateFer) in agreement that it SuX0Rs when management make technical decisions? So... physician, heal thyself?

    So, no, the WTF is not really the corporation. So what if they don't want to streamline the process by which work is done? It's their dollar.

    I agree to a point. I've been a script cowboy myself. I took a task that used to take hours and got it down to 10 minutes. I took an entire process that used to be handled by documenting things in Excel spreadsheets, moved it to a SQL database and streamlined the entire thing, improving efficiency by more than 100%. For my efforts, I was given a raise and promotion. My process became official and now I'm part of the development team that maintains and improves it.

    That said, I've seen the fruits of some script cowboys in other departments that try to add things to the process without telling us. They write code, then go on vacation. When it breaks, I'm blamed for it but have no idea where the code is, or what it even does. It's a huge WTF and impossible to trouble shoot.

    So there are both sides to the story. Improving process = good. Being a script cowboy that can barely code = bad.

    PS For the record, The Daily What The Fuck was way better.

  • velvetJ (unregistered)

    ha, ha, ha...

    love the comment and the timing :)

  • nobody (unregistered)

    I had a position wehre I had work that involved some mind-numbing tasks. The problem was, they wouldn't buy software to speed it up (for me, anyway). I'd have to wait for someone else to make the minor change (like insert a column in a text file that was too big for Excel) because he had the editor that could do it. And I was told NOT to write a program; wait for this other person and then fill in the data. I wrote the program anyway; it took under an hour and was fairly flexible. They didn't have to know. Fancy office space (expensive) but too cheap to spend under $100 for software for me. (Actually, they were probably trying to get rid of me)

    Too bad I had to take that job; I was unemployed and needed the money. At least the next two have been better; it is easier to get a new job when either employed or with a fresh work history. I think giving an address of "3rd cardboard box from the right in the second alley" would make potential employers avoid me.

  • Jon (unregistered)

    At a previous job, there was an automated process to which people could upload MS Word documents and have them converted to XML. The conversion process was very slow -- it created a Word DOM object, enumerated the styles, then calculated which sections of text belonged to which styles and finally generated the XML. It took around 5 minutes per document (!). (I believe the code was copied from an obscure page on microsoft.com.)

    I looked over the code and, on a hunch, replaced a linear search with a binary one. That cut it down to slightly less than 2 minutes per document. On another occasion, I replaced the entire routine by using the Word DOM object's "save as HTML" function and post-processing the HTML file. Now it took 1 second per file.

    I'm happy to say that management praised my efforts. Didn't get anything from it, though. :(

  • Sammy (unregistered) in reply to The cow says....
    The cow says....:
    Just leave. The moment you find that the programming job you got is actually mind-numbing data entry that will one day be a cancer on your resume, just turn around and go... No matter how much you need the money, this job will end up costing you more, in frustration, in lost opportunity, in time and brain cells wasted. Just go.

    And how.

    There's a company I've worked with in the past. The owner has been, for years, utterly convinced of the cutting-edge nature of his site. When I first met him, he was using college students to hand-update the prices of items on his web pages. As in, they were all static HTML, no database access whatsoever. When someone wanted to order, they had to re-input the price and item number on the order page, exactly as if it were a mail-order catalog. (And to be fair, that's what he used to have, so I'm sure it didn't seem odd to him.)

    Occasionally, I'd bump into the students who worked for him. Every time, I'd tell them: get out. Get out, now, because even as a college job this is going to rot your brain beyond comprehension. Better you find work as a waiter than kill whatever love of your profession you have at this place. And sure enough, the people who left quickly managed to do fairly well, but those who didn't either dropped out of the field entirely, or are still there.

    (For reference: this is the same guy who had his chief web dude call me up to ask if some hacker had replaced all his color images with black & white ones. Seriously.)

  • plizak (unregistered)

    Reminds me of my first co-op work term.

    One of the other co-op workers was asked to stop writing macros in excel. He was replacing several of the engineers jobs with macros, and the boss was worried what to do with his engineers that had no more work to do.

    Would you believe that stock fell from a high of over $124 to under $1.

  • ElQuberto (unregistered) in reply to AdventureTime
    AdventureTime:
    Point is, script cowboys cause problems because their shit:

    You're still angry about being automated out of that job?

  • Vlad Patryshev (unregistered)

    Oh, this looks so familiar. I was framed and kicked out of Fireclick for converting a Manual Test Plan from MS Word format to dynamic html page, and for suggesting using unittests in our daily programming practice.

  • Gabriel (unregistered) in reply to RON
    RON:
    I made a new uber-tool to take care of everything. People freaked out at first because it was an "unauthorized project". Then some management saw how much more productive it made everyone, and increased our workload by 50%.

    Bottom line: If you streamline your work process and people know about it, they'll just give you more work to do.

    If you have good managers, they will give you BETTER work to do (more interesting/challenging/etc), not just more, if you automate a major part of your workflow.

  • Mark (unregistered)

    So, the work he did was on his free time, not authorized, and rejected by the company...

    Should have hit them with a six figure licensing bill on the way out the door for using his intellectual property (ie - the script, and his since the company abandoned it and disavowed it). Even though he wouldn't have had a chance at getting the money, just on principal of it (and to, in a not so veiled way, call the "professional IT department" a group of CYA, no-talent plagiarists. )

    Captcha: sanitarium (ironic, isn't it)

  • (cs)

    I remember a similar story, hopefully I get most of the facts right (but I'm anonymizing anyway). A friend of a friend was working in the physics group for a medical device. Let's call him Bob. The user interface was pretty shoddy, and he was getting tired of it. The programming team seemed like they were essentially writing the UI framework from scratch. This was a terminal based interface, with Unix as the front-end system. So of course the obvious solution would have been to start with the "curses" terminal windowing library that came with Unix. The programmers didn't like this idea apparently.

    So Bob goes in one weekend, and writes up a terminal based UI, built on top of curses, that does exactly what most of the company wants, and is easy to use and easy to modify. But as soon as he showed it off to people, the programming team were upset. He wasn't one of the software team, so he wasn't supposed to have been doing that sort of programming. Although they didn't come out and say so, it was implicit that the software team had been insulted by this. After all, they were supposed to be the best programmers. Management essentially told him to stop working on this stuff in his free time.

    Fast forward a couple decades. Bob is now CEO of a computer related corporation, and his picture has been on the cover of a PC oriented magazine. I'm also working with someone who used to be on the software team at that company, who says he doesn't remember the incident...

  • G Money (unregistered) in reply to plizak
    plizak:
    Reminds me of my first co-op work term.

    One of the other co-op workers was asked to stop writing macros in excel. He was replacing several of the engineers jobs with macros, and the boss was worried what to do with his engineers that had no more work to do.

    Would you believe that stock fell from a high of over $124 to under $1.

    Do they happen to have a fancy office space at the intersection of Carling & Moodie?

    Captcha: vern. know what I mean?

  • JohnB (unregistered) in reply to SomeCoder
    SomeCoder:
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up? <snip>
    <snip> I took an entire process that used to be handled by documenting things in Excel spreadsheets, moved it to a SQL database and streamlined the entire thing, improving efficiency by more than 100%. For my efforts, I was given a raise and promotion. My process became official and now I'm part of the development team that maintains and improves it. <snip>
    Let's assume that the old Excel process took 1 day. Therefore, 100% of the time is 1 day. If you improved it by more than 100% then the work is now finished before it started. Trust me on this one: you are not as good as you think you are.
  • A. Thompson (unregistered)

    Hey, we're published! Oh, the Big Rookie Mistakes. I was young, foolish, and naive. I stepped on toes trying to prove I was good enough to get a job in the first-class programmers department. I did get offered to join the 'real' IT before I left.

    As for being a code cowboy there are certainly some valid points there. My script wasn't peer reviewed. It ran on development servers. I had the access level to do a lot of damage.

    But why did I have that access level? Did I go against policy, or was policy not in place to prevent an idiot 20 year old from wiping out an entire server with a couple well placed shell commands?

    I was given all the tools I needed to write scripts. Other people wrote scripts to help the daily grind. I didn't know our utility scripts needed to be reviewed or tested on dev servers. I wasn't in the IT department so I didn't have that IT training. They left us to our own devices to Get It Done.

    My device made others look bad. It was a couple lines of AWK, some FTP GET commands, and a join -t that generated a text file. Not exactly server killing technology.

    Is the moral of this story "Do the bare minimum and never try to fix problems that aren't yours?"

  • Tom Woolf (unregistered)
    jman:
    Talk about a WHAT THE FUCK

    No, you mean "Talk about a Worse Than Failure"

    My god, that's so Failure-ing lame.

    (jk webmaster - I just figured I'd say it before anybody else does)

  • Tom Woolf (unregistered)

    A coworker of mine from when I worked at a Giant Enterprise changed from one Accounting department to another. When we were in the same department, we put together many spreadsheets, macros, and programs streamlining the quarterly reconciliation process - saving the department hundreds of man-hours per quarter.

    So, when she saw data input used to transfer information from reports in Word to Excel, she went to work. Saved 9 man-hours per day for the department. Her reward? $100, and being ostracized by her coworkers. Shoot, it got so bad that when I tried to shift to the same group (we both wanted out of the first department to an incompetent, unstable, and malicious boss), that department's leader said no - the two of us would be too strong and throw off the fragile interpersonal balance within the group.

    I guess they were afraid some additional efficiencies might be accomplished.

  • Aescnt (unregistered) in reply to JohnB

    Well,

    efficiency = work/time

    ...which follows a 100% increase in efficiency either means getting twice as much work done for the same amount of time, or half the amount of time for the same work, or some sort of middleground between the two.

  • Aescnt (unregistered) in reply to JohnB
    JohnB:
    SomeCoder:
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up? <snip>
    <snip> I took an entire process that used to be handled by documenting things in Excel spreadsheets, moved it to a SQL database and streamlined the entire thing, improving efficiency by more than 100%. For my efforts, I was given a raise and promotion. My process became official and now I'm part of the development team that maintains and improves it. <snip>
    Let's assume that the old Excel process took 1 day. Therefore, 100% of the time is 1 day. If you improved it by more than 100% then the work is now finished before it started. Trust me on this one: you are not as good as you think you are.

    Well,

    efficiency = work/time

    ...which follows a 100% increase in efficiency either means getting twice as much work done for the same amount of time, or half the amount of time for the same work, or some sort of middleground between the two.

    (sorry, this comment was supposed to be in reply to that quote above, I just happened to click "reply" instead of "quote")

  • (cs)

    Been there, done that. In my case, it was hand-coded XML files from templates that where merged by a huge Java app to create static HTML files. When I asked why they didn't use a CMS, they said it would put the contractors out of work.

    I did manage to speed up one process that involved cutting and pasting from an Excel spreadsheet into one of the XML files. I had Excel output its data as XML, and merge it with the template. A one day job now took 30 seconds, and was error-proof.

    Eventually, I quit, blowing my stack at the stupidity of the entire department in the process.

  • SomeCoder (unregistered) in reply to JohnB
    JohnB:
    SomeCoder:
    AdventureTime:
    Am I the only one who, reading this, thinks of the other posts wherein our hero takes a job only to find "...a veritable Italian restaurant worth of spaghetti scripts," which do everything from correcting Payroll's errors to modifying local weather phenomena, only to run screaming from the job because it was too fuc...err, feathered up? <snip>
    <snip> I took an entire process that used to be handled by documenting things in Excel spreadsheets, moved it to a SQL database and streamlined the entire thing, improving efficiency by more than 100%. For my efforts, I was given a raise and promotion. My process became official and now I'm part of the development team that maintains and improves it. <snip>
    Let's assume that the old Excel process took 1 day. Therefore, 100% of the time is 1 day. If you improved it by more than 100% then the work is now finished before it started. Trust me on this one: you are not as good as you think you are.

    I'll let you make whatever assumptions you want without knowing anything about any of the process at all.

  • Rich (unregistered)

    As a college student, my wife had a work study in the College's HR dept. They had a large Excel spreadsheet of job applicants. She was told to manually count how many of them were M and F.

    My wife is by no means an IT person, but she knew that was a WTF. Her solution was to sort on gender, and see what row number the last F was, and subtract that fron total rows to get M.

    They had been doing the manual count for years, and may be back to it now that she's gone.

  • BINARE (unregistered) in reply to Vlad Patryshev
    Vlad Patryshev:
    Oh, this looks so familiar. I was framed and kicked out of Fireclick for converting a Manual Test Plan from MS Word format to dynamic html page, and for suggesting using unittests in our daily programming practice.

    Canned for exporting a Word doc to html?

    Looks like you clicked on "Save As" instead of "Save Ass" :)

  • Steve (unregistered)

    My goodness.

    Stories like this one and many of the others I see here make me oh, so, glad that I'm in academia and not in the "real world".

  • waffles (unregistered) in reply to Steve
    Steve:
    My goodness.

    Stories like this one and many of the others I see here make me oh, so, glad that I'm in academia and not in the "real world".

    Only because most academia-based stories seem to be banned, but the few that make it through should make you rethink that statement.

  • Mark (unregistered)

    Wow I would be really angry if that had happened to me. If I had come up with the script and then had someone else take credit, I would quit in an instant, while making sure as many people as possible knew why I was leaving.

Leave a comment on “Impossible, Impractical, and Too Expensive”

Log In or post as a guest

Replying to comment #122941:

« Return to Article