• Ex-Consultant (unregistered)

    "You are running unauthorised software on company's computers? You are fired!"

  • Martin (unregistered)

    His coworkers didn't report his hacking activities? They could be fired for that!

    Their ERP system definitely needs some "I'm not a robot" checkboxes!

  • Greg (unregistered)

    kind of like me minus "the promotions". customers come to my general manager, then want to meet me just to tell me what a good job i do for them and how fast response time i have. i didn't do much programing, mostly i just used the tools they gave me and made them more productive. tasks that others spend 4-6 hours on, i finish in less than 10 minutes.

    this can present a problem when i am substituting a colleague. their customers are shocked at my fast response. instead of next day response or within 2 days, i deliver them full analysis within 30 mins. that's not my problem, though. >:-)

    hopefully there will be some real promotions in the near future. if not i will need to start looking outside the country. nothing much available arround here. i am not a developer, and there is plenty of sales people abroad... for now they sent me arround to a few customers. i was quite succesfully and increased sales by 30% and i sold with good margin. but my salary is still really bad. it's really the only major downside of this job i have.

    also previous snoofle article - exactly same issue at my company. IT takes up 3 or 4 years to deliver a project and even when it is done it is only 70% to specification, so we use other ehm tools (excel) and bend them to our liking. it's far from perfect but it is much better than various forms of typing and meaningless tasks.

  • A_L (unregistered)

    And they all lived happily ever after.

  • Appalled (unregistered)

    You're not a "Team Player". You're outshining everyone else and making them look incompetent. You're fired. Find yourself a one-man shop.

  • Quite (unregistered) in reply to Appalled

    Happens more often than you'd expect. Found myself in a refreshingly easy job once. Sailed through the work, treated it as therapy and a warm place to be all day. My mentor took me aside and complained that I was making the others look bad. But when I went for the promotion to the boffins' team I was passed over for someone else whose skills were inferior but he could talk football all day. Some time later after that team had been refactored through failure to deliver, I took the boss out for a drink of commiseration in which he agreed that yes, that was the worst management decision of his life.

  • bvs23bkv33 (unregistered)

    no budget for comment

  • MADC0D3R (unregistered)

    Pretty much the start of my career as a programmer.

  • ApoY2k (unregistered) in reply to Quite

    I could probably not supress my urge to answer "You're making the others look bad" with "Then tell them to git gud" in a situation like that. I mean, come on. So you're supposed to be worse on purpose just so everybody is on the same level? That's ridiculous.

  • JK (unregistered)

    Exactly what I was thinking! WTF?

  • Brian (unregistered) in reply to ApoY2k

    Tall Poppy Syndrome is a real thing.

  • Jerepp (unregistered)

    The first worm gets the bird...

  • JustSomeDudette (unregistered)

    Anyone who has seen Hot Fuzz will know exactly how well efficient performance is handled.

  • Zenith (unregistered) in reply to ApoY2k

    I briefly worked at a company that handed out a copy of "How to Win Friends and Influence People" to new hires. That was about all I got out of the book. Never ever perform better than somebody else because they'll feel sad. Or, as I read it over a decade earlier, Law 1: Never Outshine the Master.

    Every time I ask what "God" needs with a starship, I get the same answer that Kirk did...

  • Developer Dude (google)

    Like others, this is more or less how I got started, although I had done a little bit of programming in college, it was of extremely poor quality and it was not my forte.

    My first job after college was to run performance tests on a long distance wireless comms system. The system in place for collecting the data was reams of fanfold printouts collecting line by line printouts of transmit/receive performance data, and long rolls of paper strip charts of signal levels. This all had to be correlated by hand and analyzed. The collection and especially the correlation took months.

    I suggested we use a terminal emulator to collect the printouts, and an analog to digital card to capture the signal strength. "No budget for that". So I got my boss to buy the A/D card with some budget meant for something else, and setup the system while in the field testing. Then I wrote software to correlate the data and filter it.

    This saved months of manual work - what used to take weeks to months, was done in a day or two, and pretty soon we had must faster feedback on tests. It saved tens of thousands. My boss liked it (saved him a lot of work and made him look good), others did not.

  • LM (unregistered) in reply to JustSomeDudette

    ... and what lies waiting for us in the dark corners of a too-good-to-be-true fairy-tale land.

  • nb (unregistered)

    I've done similar... Two man week process of taking a (well defined) excel spreadsheet and manually transcribing into c structures of foo{ {bar,baz}, {bin,bash} }; variety. I created a perl script that took a CSV output of each worksheet in the workbook and created said tables, saved them into the source tree, and compiled each of 4 versions of the software based on said tables. 2 man weeks reduced to under 15 min... INCLUDING compile time.

    Showed my boss, he said "Great, whatever, just keep doing your job". So on the next project I told him I only needed a couple hours budgeted to the transcription task. He budgeted 2 weeks. I went on vacation for two weeks.

  • Joe (unregistered) in reply to Martin

    and get them self's automated out of a job at same time?

  • JustHere (unregistered)

    This also represents how changes get into organizations. Those who know better processes and methods, eventually obtain position of authority and can implement changes that should have occurred years or decades before.

  • Kashim (unregistered)

    To all of the: "You're doing your job too well, $x is sad." Any company that will fire you for doing your job too well isn't one you want to be at anyway. When I started work at my current job my boss said something similar about releases: I had written the tool to do them, so I could do them in under an hour where most people budgeted a full day. When my boss came to me complaining that I was making everyone else look bad, he actually had the gall to suggest that I make my releases take the "normal amount of time" a.k.a. pad my timesheet or just do it slower. He was not thrilled with my response of, "So, communism. Cool, I can do that." but thought he'd made his point and let it go. Next release I had a super tight schedule between projects and had to work an 18 hour day. I'd only spent 1/2 an hour of that on my release, but I made sure to just log the full 8 hours with the comment "Because Communism". My timesheet got rejected when I had a 25.5 hour day. We had a long discussion about padding timesheets. Eventually I convinced him to let it go with, "OK, so how about this: every time I do a release, you take the time I saved, convert it to a dollar amount, and make that amount be a bonus given out to everyone else in the department. There are <20 of us, so just take 7 hours of my pay, and divide it by 20. No one will complain if you give them all a small check every time I run a release faster, and the company isn't out any money." This is, of course, ridiculous, and he told me so. Then, I said, "If you can't reward everyone else for my hard work, then how can you do the opposite and chastise me for the fact that they work slow?" and I walked out of his office. He escalated it to upper management, and from my understanding, got shouted back down and told that people who are saving money for the company should not be disciplined. He came into my cube apologetically the next day and asked if I could write a procedure for how to use the tool that could cut down on other people's release times.

  • FormalWare (unregistered)

    Macros.

    What's the big WTF?

  • Gurth (nodebb)

    What's the big WTF?

    The big WTF is that he actually seems to have gotten away with it.

  • Chicken Little (unregistered) in reply to nb

    Vacation for 2 weeks? I have to be physically in the office to punch the clock in order to get paid. That is some crappie vacation.

  • Daniel (unregistered)

    Sounds like many of us have the same experience, minus the promotions.

    Nowadays I just spend the extra free time from automating most of my work to pick up new skills/technologies so I can hopefully find a better job next.

  • dkf (nodebb)

    ERP: an essential component of “HERP DERP!”

  • Trace (unregistered)

    I'll be damned, this story looks very familiar. I've submitted it long ago and thought it will never see the daylight. What a pleasant surprise :).

  • Hannes (unregistered)

    A somewhat related story: I once wrote a very small program for someone at my company so he could check transaction data in our database. He could type in card number, or amount, or purchase date and get a result based on those values. As I've said, it was a small program, just doing simple SQL queries in the background.

    A few days later I got a call from a different person, telling me that program was so great and that it saved all of them a great amount of time and why I didn't tell anyone about it earlier. And I was like... well, I didn't know you checked those transaction data MANUALLY!

  • Derp (unregistered)

    This is one female protagonist away from being a Gern fantasy.

  • Apeljohn (unregistered)

    I have a similar story. Ended up on a large life office's manual calcs team, due to my actual employer morphing into a body-hire shop. The role largely existed because a recent acquisition used a legacy system for calculating pensioners' key statistics, and because their new admin system didn't permit copy/pasting data "for security reasons".

    Our job was to switch to the old system, run the relevant transfer value / forward projection calcs, print the results, and scan them in for the benefit of NewAdminSystem's document repository. Then switch to the new system, take screenshots as documentation, manually transcribe the numbers in the screenshots (of which there were a lot), do some calcs combining the two sets of numbers, and finally send the results back to the administrator who'd requested it.

    This all changed when the Fire Nation attacked ^W^W^W^W I discovered that both systems used user-visible databases. I threw together a basic Excel/VBA tool that wrangled the relevant record-sets, and went to my line manager with my shiny new solution. And she gave me this look.

    The look is hard to describe. It's the look you'd give a pig that put on aviator goggles and requested clearance for take-off.

    What I hadn't realised is that, due to my status as "rental employee", the managers had mentally filed me as a contractor. And apparently in this company contractors to occupy the same ontological category as desks, keyboards, monitors, etc. Initiative from a contractor wasn't so much discouraged as it was a violation of the laws of God and man.

    A few months later, some business analysts were installed to figure out why the team was going so slow. They quickly went back to management with a basic Excel/VBA hybrid that could wrangle data from the back-end databases. Management loved it, and asked for an updated version.

    "Sure," the analysts said. "But can we have some of Apeljohn's time?"

    "Why?" asked the manager.

    "Well, this is the tool he developed months ago."

    Facepalm

  • Yazeran (unregistered) in reply to Developer Dude

    Yep.

    This is also more or less how I got to do programming in a professional way.

    When i joined, all our test setups were manually controlled (think manual valves and flow meters) and the only automation was data acquisition.

    I quickly got tired about having to do things manual (and writing things manually in old-school log-books which always disappeared because someone forgot to put them back).

    I then made the first clumsy web interface to at least log when people did change something so gas flows would be visible in a table as opposed to manually look back and seen when that particular flow meter was last changed (if the person changing the flow actually remembered to write it down assuming the log book was actually there).

    Then gradually others asked for more automation ("you know, could you not automatically set gas flows when we write the new flow in the system as opposed to having to also manually set the flow?", and management gradually approved purchases for computer control of things as well)

    Over the years that evolved to a fully fledged web based control system that we now publish as open source...

    Yazeran

    Plan: To go to mars one day with a hammer

  • Icon (unregistered)

    I was once told by a professor that you had to be lazy to be a computer programmer (or a mathematician for that matter), because it makes you want to figure out how to not do something the long way more than once.

  • Herr Otto Flick (unregistered)

    I'm guessing the WTF comes in part 2, where the self taught programmer's un-reviewed code makes everything broken. What a dick.

  • Developer Dude (google) in reply to Herr Otto Flick

    I work with a LOT of college educated "programmers" with degrees in CompSci/SW Engineering who can't write code worth a damn. I spend a LOT of time correcting their WTFs.

    Yes, I am self-taught - been "teaching myself" for over 30 years - always trying to improve, which is more than I can say for some other software engineers who stopped learning the day they got their degree.

  • The_Dark_Lord (nodebb)

    Go back 30 years ago, this was pretty much how most of us got into programming. You could still do that, before there were organized development teams, processes, QA and version control.

    I was an undergrad student in biochemistry in 1982. Every week we had a day-long experiment, during which we collected thousands of data points and wrote them in a notebook. We then spent 4 days doing manual computations (this was before spreadsheets) yielding final results, and then had only 2 days left for analysis and discussion, which is ehrn real biochemistry happens. The next semester I wrote an APL program on the mainframe and sold it for 750$ to the biochemistry department. You entered the data points and it printed the final result table, which students were allowed to (physically) cut and paste into their lab report. For about 10 years, each of the 120 students saved about 20 hours a week. As a bonus, my friends and I all over the country got a free BBS that I had hidden inside the program.

    After graduating I got a job in IT, actually I was the IT department in a high school. I obtained an APL interpreter for PC and wrote a dozen applications automating manual processes, some of which were in use for 15 years before being replaced by commercial apps. Nothing could beat the look on the principal's face when I demoed an app that did in 10 minutes the schedule assignments he normally did in 5 evenings. He was almost crying.

    Now I work as a consultant in government offices, and I discovered there is an official designation to this kind of work, we call it "User-context development". It usually takes the form of 10-years-old spreadsheets loaded with formulas, MS-Access databases residing on a workstation's C: drive. It usually fills a void left by functionnally-deprived official applications. It's become mission-critical, so we have to corral them into the corporate infrastructure and include them in backups and into disaster recovery plans.

  • The_Dark_Lord (nodebb)

    Go back 30 years ago, this was pretty much how most of us got into programming. You could still do that, before there were organized development teams, processes, QA and version control.

    I was an undergrad student in biochemistry in 1982. Every week we had a day-long experiment, during which we collected thousands of data points and wrote them in a notebook. We then spent 4 days doing manual computations (this was before spreadsheets) yielding final results, and then had only 2 days left for analysis and discussion, which is ehrn real biochemistry happens. The next semester I wrote an APL program on the mainframe and sold it for 750$ to the biochemistry department. You entered the data points and it printed the final result table, which students were allowed to (physically) cut and paste into their lab report. For about 10 years, each of the 120 students saved about 20 hours a week. As a bonus, my friends and I all over the country got a free BBS that I had hidden inside the program.

    After graduating I got a job in IT, actually I was the IT department in a high school. I obtained an APL interpreter for PC and wrote a dozen applications automating manual processes, some of which were in use for 15 years before being replaced by commercial apps. Nothing could beat the look on the principal's face when I demoed an app that did in 10 minutes the schedule assignments he normally did in 5 evenings. He was almost crying.

    Now I work as a consultant in government offices, and I discovered there is an official designation to this kind of work, we call it "User-context development". It usually takes the form of 10-years-old spreadsheets loaded with formulas, MS-Access databases residing on a workstation's C: drive. It usually fills a void left by functionnally-deprived official applications. It's become mission-critical, so we have to corral them into the corporate infrastructure and include them in backups and into disaster recovery plans.

  • Tim (unregistered) in reply to Apeljohn
    The look is hard to describe. It's the look you'd give a pig that put on aviator goggles and requested clearance for take-off.

    What do you have against Porco Rosso?

  • Cory Shanks (unregistered) in reply to Icon

    Larry Wall once said the three prime virtues of a programmer are Laziness, Impatience, and Hubris.

  • Herr Otto Flick (unregistered) in reply to Developer Dude

    Well sure, you can get shit programmers who are comp sci graduates, because comp sci is not programming, it is the science of computing. Programming is covered in comp sci like sharpening scissors is covered in hairdressing school; its a tool, its not the purpose. Software Engineering graduates are better, as some of their studying is spent studying the art.

    The problem with self taught people is that they don't know that they don't know things. It gets tedious explaining things like common OOP design patterns to someone who has been a "professional programmer" for > 3 years.

    However, this isn't the problem with the guy in the story; he's hacking away at an internal process, without telling people that he is doing it. He's not a programmer, he's learning how to do it on the job, without review, without feedback, without the full domain knowledge of what the system does and how it does it. He doesn't know enough to be doing this, and is risking his employer by doing it. If he wants to be a programmer, he should apply for a job as one.

  • NonnoBomba (unregistered) in reply to Ex-Consultant

    Ouch. This strikes really close to home.

  • VdP (unregistered)

    TRWTF is the happy ending.

  • Michael (unregistered)

    Ok... this article is obviously not about an ERP system, but about our Offer- and Order-Processing system. It has "copy some value from one form, and use this value to create the file names for at least two PDF files later in the process, then manually attach them to files, ..."

    There's one other thing:

    At one time in the process, it is possible to export an Excel sheet of an offer or order's raw data - all of the items with all of their article numbers, cost price, list price, customer price, ... All one huge wall of cells, no formatting, cryptic headers, no sums, nor formulae (think total price = n * single price). This is the only way to get to all of this data easily, and if properly formatted, can be of immense value to account managers when discussing pricing in the team or with the customer.

    Now, someone came up with a macro to add all the nice stuff once. Only, this thing required a load of user interaction, making you to click a bunch of Yes/No dialogs whenever it came to any place where some decision could be made. Also, the thing would run for minutes, but the dialogs interrupted it, so "start, go to grab coffee, return to result" wasn't possible.

    This can be done a lot better - whip up an options dialog, show that to the user when they run the macro (and have the default options set to cover 95% of the use cases, Excel thankfully keeps anything you change for the session). This finally enabled "start, check/change settings, continue, go grab coffee, return ...). The macro was in full control of our department, so we (a two person team) could change what we wanted - but we did so only after discreetly asking around if the current macro had been designed this way to make it look like people have to do "serious work" with their computers or prevent them from being perceived as "too fast", and thus get overburdened by additional workload.

    The looks we got were priceless. And reassuring, so we did the changes, and everyone used it happily ever after.

  • JBrickley (unregistered)

    Two problems with this. First one is these solutions inevitably are created using Microsoft Office VBA code and Word, Excel, Access. Then the system is implemented in a department without IT's knowledge. The original creator / maintainer moves on and one of the users calls the help desk when there is a problem. A technician is dispatched and then experiences a whole new kind of WTF moment with zero people being responsible for the business units home-brewed solution. It was so bad, that IT banned the practice and almost removed MS Access from workstations. DBA's really hate taking a novice solution and move it to real production.

    The second problem is a Six Sigma, LEAN, Continuous Improvement buy-in from management where the goal is efficiency. Once solutions are made and tested and metrics collected there will be layoffs of many staff. The same staff that were excited to help with the CI process.

  • Zenith (unregistered) in reply to Herr Otto Flick

    Having seen what passes for a senior developer in some organizations, the value of such a review to somebody who actually has some ambition would be below zero.

  • Trace (unregistered) in reply to JBrickley

    I always say that business critical solutions should be developed by professionals. A solution that improves efficiency, albeit with shitty code? Don't see big problem in that. Users can always go back to the old, inefficient ways if things stop working

  • Trace (unregistered) in reply to JBrickley

    I always say that business critical solutions should be developed by professionals. A solution that improves efficiency, albeit with shitty code? Don't see big problem in that. Users can always go back to the old, inefficient ways if things stop working

  • BushIDo (unregistered)

    Awww! He got promoted! He listens! That's such a sweet ending swoon

  • Disagree (unregistered) in reply to Trace

    I too learned some basic scripting from automating the repetitive aspects of my job. This is fine. I can do this for years. I can do this.

    Have you ever tried using the previously developed 'automation' shortcuts made by someone else who self-taught while making it? Its a nightmare. You can't easily go back. Often by the time people realise its a dependency to BAU functions, the team size has shrunk or taken on extra scope as a result of the efficiency the tool brought in. Now you're trying to tread water doing things manual while trying to fix or improve the broken cludge.

    I think this is a reason that dailywtf can't be taken seriously- So many articles detail the many agonies of taking over a 'legacy' piece of code, and then on the other side they're championing a guy who freed himself up for more work by automating his old stuff with unplanned/documented code.

  • Nagesh (nodebb)

    Where's the WTF? Old guard is scared of new tech. One American person already send me link for this https://en.wikipedia.org/wiki/John_Henry_(folklore)

  • smith (unregistered)

    On the off chance that you set out to make me think today; mission finished! I truly like you're composing style and how you express your thoughts. Much obliged to you. web site

Leave a comment on “The Automation Vigilante”

Log In or post as a guest

Replying to comment #:

« Return to Article