Live data from Hacker News

Coders Automating Their Own Job

theatlantic.com

461–470 of 499 posts

Re: Coders Automating Their Own Job

#461

Earlier quoted context omitted.

With the way things are going, I’m not sure learning a little bit of programming will help. Digitization has really begun rolling with RPA, because we now automate system processes for systems with no apis and no direct data manipulation. But even though RPA is mostly screengrapping and macros, we’ve found it impossible to teach to people who aren’t developers. Similar with better BI tools it’s become possible for sq…

As a disclaimer, my name is George ( https://george.nychis.com ) and I helped found a software automation company based out of Boston, MA that is "related" to this space called Soroco ( https://www.soroco.com ). Our focus is around solving the kinds of problems you talk about. Building automation to replace repetitive and deterministic work across software systems in the enterprise. As you have learned, RPA is mostly…

Are you familiar with Automa? I tried to get my organization to purchase it for automated testing, but approval for that ran aground on the fact that Automa doesn't have a US distributor. (As you may infer, I'm a gov't contractor.)

I was hoping that your company offerred a product similar to Automa, but it looks like your business model is different to that.

Anyway I ended up having to re-implement my Automa-using Python scripts using a different technology (TestStack.White and C#) and I 100% concur with your analogy about TCP over IP and building on unreliable foundation. It's also analogous to the sensor fusion problem of AI: picking out what to do when different methods of interacting with the automation layer report conflicting results. (And you have multiple ways because you need the redundancy to detect and deal with problem #1 - automation interfaces are incredibly unreliable.)

For example between IT-mandated invasive antivirus software injecting shims in the OS and/or screwy win32 code in the program-under-test, or bugs in TestStack.White, (I've found indications of all three causes) there is some kind of randomness or ambiguity in the Window handles you get when you ask for certain controls on a dialog. You might ask for the OK button and get the button 50% of the time and 50% of the time get a handle which turns out to be the textbox above it.

So I've taken a belt-and-suspenders approach and built a database of all of the controls I expect to find and their screen positions, a folder full of screenshot snippets which I intend to make my test automation program compare, and use that to augment what Windows UIA is telling me is on-screen. Due to the problem of receiving the wrong window handle (on this app) when I ask TestStack.White to find a control at a certain position or by name, I resort to just cross-collating the entire list of controls on the window with the best match from the database. However even this is 4x harder than it should be, because for some reason the positions and sizes in the database (obtained by a previous attempt with a different automation tool) differ by small pixel amounts from what TestStack.White reports. So I had to implement a fuzzy match.

And then the entire object-oriented architecture of my automation utility program collapsed on itself like a house of cards, because now I have 2 or 3 different derived classes to represent "the same" conceptual object: if you code "button.Click()" should it click the button with the handle found by TestStack.White? Or click the coordinate from the database? Or click where the screenshot matched? Or do nothing because this is a mock object? Worse, I now have a constellation of 1..N OOP instances associated with each conceptual object: maybe the database says I should have a button, but I can't find a handle for it thus I cannot create a ButtonFromHandle but no matter I can still click on the center coord of ButtonFromData. But if I have both I really want to default to one (which?) that is most reliable. Object-oriented programming design methodologies are completely inadequate to deal with the case of "some number between 1 and N instances actually represent one conceptual object and should be treated like a sheaf of overlaid transparencies". Yes, it can be done, but the design turns into something that makes sense from that aspect but makes no sense from the API-user's point of view: you just want to click "the" button you don't want to do "button.Implementations.First().Click()" or some such. Then add in multiple layers of mocks for unit testing the automation tool and you get N*M combinations...

Not sure where I was going with this, I guess I'm just excited to find someone who's worked on the same (or similar) problem.

Re: Coders Automating Their Own Job

#462
post #164

Earlier quoted context omitted.

No business would be willing to pay that. Once you've shown them that the job can be done easier/faster/cheaper, they will insist on that as the new standard. Rinse and repeat until you are penniless and they have all the money.

But they were just paying that, in the form of paying you. If they don't think the task is worth paying that much to get done, they would have just been not-doing-the-task. Also, note that I never suggested mentioning that the SaaS service you create should make any mention of its service being automated. Consider an entry in the "cloud bookkeeping SaaS" genre: they sell you on having real accountants looking at your…

Congratulations, you have discovered information asymmetry!

Re: Coders Automating Their Own Job

#463
post #251

This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns. This article is actually touching on a deeper level of dysfunction in how we do things li…

> This article really highlights how odd our methods of valuing output are. Ultimately if someone is idling for 6 years because they've written a program to do their job for them, who cares? They are delivering the same output which hopefully the company deemed was valued at X amount BECAUSE it delivers Y amount of profit/returns.

This is why, in 19th century, they've used to call wage labor, as opposed to self-employment, "wage slavery".

You are selling your time, not the goods you produce.

https://en.wikipedia.org/wiki/Wage_slavery

Re: Coders Automating Their Own Job

#464

Earlier quoted context omitted.

What do you base that on?

I base that on 40 years of life experience and travel and living in a variety of communities. But there's overwhelming evidence of it, an BTW I'm not saying 'religious' per say, but 'church attendance' which is a much stronger overlap with conscientious behaviours. [1] [2] [3] People who doubt that regular church attenders are more likely to 'return wallets' I think have little exposure to classical religious communi…

That's a bit of a romantic view, those kind of communities ain't all roses either in my experience.

They breed a lot of narrow minded small thinking bigots, even if they do return wallets.

The idea we should as a society somehow return to a romantic past that never actually existed isn't a good one in my opinion. And we can't do that anyway because our understanding has changed.

Not that there aren't a lot of good things from the past that somehow got dropped by the wayside, there are.

Re: Coders Automating Their Own Job

#465

You know how sometimes you love an article so much that you are annoyed you didn't write it? This does a better job than I could have of tieing together a dozen threads of conversation that I've had with various friends for years. I actually believe that there's a culture war implied in this debate; the question of who deserves to reap the gains of automation is more than just philosophy or ethics. The question "is t…

With the way things are going, I’m not sure learning a little bit of programming will help. Digitization has really begun rolling with RPA, because we now automate system processes for systems with no apis and no direct data manipulation. But even though RPA is mostly screengrapping and macros, we’ve found it impossible to teach to people who aren’t developers. Similar with better BI tools it’s become possible for sq…

I've been mucking around with RPA a bit, and was wondering if you have any suggestions on writing tests?

Re: Coders Automating Their Own Job

#466
post #202

Earlier quoted context omitted.

"is there inherent nobility in work itself?" Nietzsche would hate this question: https://en.wikipedia.org/wiki/Master%E2%80%93slave_morality Working is the opposite of noble in the traditional sense of the word.

Depends on what you mean by "traditional". Even in the New Testament, you'll find passages like 2 Thessalonians 3:10: 'For even when we were with you, we gave you this rule: "The one who is unwilling to work shall not eat.' There are probably examples from the Old Testament as well. Perhaps Nietzsche, with his critique of traditional Christian values, can be seen as a reaction against Christianity.

True, but as Nietzsche points out, Christianity was primarily responsible for the inversion of what is "good" and "noble".

Re: Coders Automating Their Own Job

#467

Earlier quoted context omitted.

I base that on 40 years of life experience and travel and living in a variety of communities. But there's overwhelming evidence of it, an BTW I'm not saying 'religious' per say, but 'church attendance' which is a much stronger overlap with conscientious behaviours. [1] [2] [3] People who doubt that regular church attenders are more likely to 'return wallets' I think have little exposure to classical religious communi…

That's a bit of a romantic view, those kind of communities ain't all roses either in my experience. They breed a lot of narrow minded small thinking bigots, even if they do return wallets. The idea we should as a society somehow return to a romantic past that never actually existed isn't a good one in my opinion. And we can't do that anyway because our understanding has changed. Not that there aren't a lot of good th…

"somehow return to a romantic past"

Contentiousness is not a 'romantic past', it's a perennial ideal.

Re: Coders Automating Their Own Job

#468

Earlier quoted context omitted.

That's a bit of a romantic view, those kind of communities ain't all roses either in my experience. They breed a lot of narrow minded small thinking bigots, even if they do return wallets. The idea we should as a society somehow return to a romantic past that never actually existed isn't a good one in my opinion. And we can't do that anyway because our understanding has changed. Not that there aren't a lot of good th…

"somehow return to a romantic past" Contentiousness is not a 'romantic past', it's a perennial ideal.

And one I'm entirely in favor of.

But these communities do tend to have a dark side along with the positive attributes you correctly mention.

Additionally, if the basis is faith, and people no longer have that, what then?

Re: Coders Automating Their Own Job

#469

Earlier quoted context omitted.

One thing I find fascinating about the article is that it's assumed the cleverness was the code written to automate. This is incorrect; the cleverness is in noticing when a task can be automated. Typically, the code itself is trivial. I have told my work more than once that if they wanted to get the most out of me they should put me on the "front line" for a month or two, and let me decide what needs to be automated.…

Our most recent stocktake I took the day off from programming, grabbed a handheld and went around doing the same job as anyone else doing stocktake, I have about half a dozen small-medium sized changes I can make that will vastly reduce time for next stock take. I've also spent time in our sandblast units and our loading docks and sales team. How can I architect and build good software if I don't have a good understa…

The proudest bug I've ever fixed came from working with the team using our software. They had a task that should take 5 minutes that the have to do several times a day but it was taking 30 minutes, 25 of those minutes was spent finding the right item in a massive list in a combo box (think medical codes). The only fix required was to an an order by clause so they could find what they were looking for, but they couldn't get approval for it. I took up the cause for them but couldn't get approval either, I couldn't get this two second task to be deemed a business priority and had to sneak the change in, risking my own ass.

The woman who had been wasting this time for years came up and hugged me in tears. No one was getting fired but I'd just freed up enough time that she didn't have to work overtime everyday. It was such a simple change and lifted such a weight off the users shoulders that went undone for years because nobody actually watched them using our software.

Unfortunately someones authority was undermined and I was let go a few weeks later.

Re: Coders Automating Their Own Job

#470
I work for a financial software company in QA and I have no qualms admitting right after arriving I wrote a program to test the new release code for me. Each release all I have to do is change some variables load and run. I see nothing wrong with using my grey matter to its fullest potential.
Post reply on HN