Live data from Hacker News

Learning to code vs. learning to automate

daedtech.com

91–100 of 190 posts

Re: Learning to code vs. learning to automate

#92
post #83

Earlier quoted context omitted.

Why is that a failure? I didn't know every job had to last a lifetime.

it's a failure because that condition was one of the reasons that he did not automate his job. A success of capitalism would be if it provided some incentive to automate the job.

Heh, good point. But still I wouldn't call it a failure, just a defect, or not optimal. The company as a whole probably works just fine.

Re: Learning to code vs. learning to automate

#93
I agree. But I am still going to tell my kids to learn to code. Programming is more than automating stuff. It’s even more than solving problems.

Programming is a process, a way of thinking about things, it is entertaining, it’s creative, it’s beautiful in many ways, in and of itself.

Learning to program sharpens so many parts of once mind, I want everyone to get a glimpse of that.

Re: Learning to code vs. learning to automate

#94
post #85
post #71

Earlier quoted context omitted.

>4. If I successfully automate it, all of my coworkers lose their jobs. A failure of capitalism when less work and more productivity is a bad thing.

Very true. My brother lost his job at Blockbuster when they closed down. Since then he hasn't been able to find a job. When I mentioned to him that unemployment is at a 50 year low and maybe now would be a good time to try again to find a job he was dismissive. He went on to explain to me how due to capitalism he will never work again. Now I can't stop worrying that I'll lose my job and never be able to work again.

Blaming an economic system for one's lack of motivation to search for work sounds like a cheap deflection.

Moreover, it's not like Blockbuster was known for hiring skilled workers.

Re: Learning to code vs. learning to automate

#95
post #71

The problem often isn't ability to automate. It's that the workers closest to the problem have an overwhelming disincentive to automate. Suppose I have a low-level job in Peloton operations. Our Phalange Team must ensure that, before a bike's in-home delivery date is confirmed, the delivery technician has placed an internal order for a left phalange. Each of us spends all day navigating between the Sales app and the…

>4. If I successfully automate it, all of my coworkers lose their jobs. A failure of capitalism when less work and more productivity is a bad thing.

> A failure of capitalism when less work and more productivity is a bad thing.

Do you believe buggy whip manufacturers should be entitled to their old job even today?

Re: Learning to code vs. learning to automate

#96
post #2

To paraphrase a famous quote on regular expressions: "Some people, when confronted with a problem, think 'I know, I'll automate.' Now they have two problems."

What would you prefer? Manual is hardly an option.

Manual is always an option, but that's not my point. I've automated plenty of things in my life and know only too well that the task of automating a task is often a major task in its own right.

Re: Learning to code vs. learning to automate

#97
post #21

Obligatory RPA: GUI-based automation to mimic user interactions, leveraging existing application and web GUIs as an API to automate against. Not something I'd recommend to backend developers / data crews. But it's pretty awesome stuff for non-developer, front-line business users. What is RPA? - https://www.uipath.com/rpa/robotic-process-automation UiPath free, "unlimited time for non commercial use" trial - https://w…

So, this looks to me like a marketing layer ("Robots!") over a macro-recorder on steroids. I'm not complaining, I bet you can make a lot of money doing this, and it's arguably helpful to the clients, but am I missing something? Like, there are no actual robots involved, yeah?

"Macro-recorder on steroids" is a surprisingly tricky thing to do well.

Think supporting 30+ years of different UI frameworks, over process variants that may be dissimilar (e.g. when code = 5, the "OK" button is actually a different class).

All while hiding enough of the underlying complexity that a business user ignorant of all the above can write 95%+ of the automation.

So yes, I'd say it's one of those things that seems easy, but is difficult to actually get working for compatibility reasons.

There are no physical robots involved. ;)

Re: Learning to code vs. learning to automate

#98

The problem often isn't ability to automate. It's that the workers closest to the problem have an overwhelming disincentive to automate. Suppose I have a low-level job in Peloton operations. Our Phalange Team must ensure that, before a bike's in-home delivery date is confirmed, the delivery technician has placed an internal order for a left phalange. Each of us spends all day navigating between the Sales app and the…

There's also:

Management will be pleased and then ask the team to achieve 20-50% more per day because your automation sped things up and now you have more free time to do stuff. This adds stress to the team because the script isn't 100% reliable, and when it fails the team is still expected to maintain the 20-50% more benchmark. Your ass is being burnt to fix the script ASAP, and everyone has to work long hours to hit the "new normal" benchmark.

Oh, and of course, you don't get any real reward for improving the team's productivity because "It's awesome you did this but writing scripts isn't what we hired you to do".

I've lived this guy's life:

https://news.ycombinator.com/item?id=21737666

And after a bunch of similar experiences there I decided that I'd never work again in a team where management exhibited such behavior. If improving the team's performance adds stress to everyone in the team, I'm not going to automate. But I became an engineer to solve problems and not to pointlessly spin wheels. The only good option: Leave and find another job (which I thankfully did).

Re: Learning to code vs. learning to automate

#99

I totally agree that learning "just coding" per se should not be a goal. It should also help to solve some of your real problems and automation is one of the topic that is very likely you need to solve. When you do something that you like and at the same time need it pays off twice. In fact I got most of my programming skills by implementing simple automation task that I needed. I highly recommend AutoHotkey ( https:…

I just changed jobs from developing on Windows to developing on a Linux virtual machine in Windows. I miss AutoHotkey so much. There are so many things that the command line can't do -- GUI commands, window switchers, and so on. It's a great example of how "learn to automate" can beat "learn to code". When you know how to do something by hand, learning enough about a program's API to do the same thing is a separate l…

> There are so many things that the command line can't do -- GUI commands, window switchers, and so on.

Check out "xdotool": https://www.semicomplete.com/projects/xdotool/

Re: Learning to code vs. learning to automate

#100
post #76

Earlier quoted context omitted.

To put what you've said more succinctly, even though reductionism is valid for a computer, there is no reason for us to reduce everyone to transistors. My mother is an accountant for example, and she could easily pick up SQL or a programming language, but the issue with teaching her one is that it doesn't solve any of her immediate problems. Excel already automates most of that work away, so for her that's all she ne…

Excel is the world's most popular IDE ;)

One of my weed out questions in programming interviews is to ask their opinion on Excel. Specifically, strengths and weaknesses.

If they don't come up with at least one strength or spend the whole answer bashing it, that's an instant reject for any position touching UX.

Post reply on HN