Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Learning to code vs. learning to automate

daedtech.com

Post reply on HN
Print view View original

181–190 of 190 posts

Re: Learning to code vs. learning to automate

#181

Post by kiddico »

nickjj wrote: post #119
sireat wrote: post #115

Earlier quoted context omitted.

AutoHotkey is an ugly language to write in, but oh boy is it useful for gluing disparate Windows actions together. Theoretically you can do the same thing that AHK does in a .net language or even Powershell but AHK is just easier to whip up something very quickly. Still I wish there were better Python wrappers for Windows automation.

> Theoretically you can do the same thing that AHK does in a .net language or even Powershell but AHK is just easier to whip up something very quickly. This is exactly how I see it too. 10+ years ago I would have written a C# app to do something that I can now do in AHK. Of course there's limitations (I wouldn't write a super intensive native app in AHK) but for little workflow optimizations it's so good. For example…

Your hex snippet produced my usual outcry when I read other's AHK scripts: "Wait, you can do THAT?!"

It's been added to my growing toolbox(which I lovingly call i3_emulator.exe), thanks!

Re: Learning to code vs. learning to automate

#182

Post by nickjj »

kiddico wrote: post #181
nickjj wrote: post #119

Earlier quoted context omitted.

> Theoretically you can do the same thing that AHK does in a .net language or even Powershell but AHK is just easier to whip up something very quickly. This is exactly how I see it too. 10+ years ago I would have written a C# app to do something that I can now do in AHK. Of course there's limitations (I wouldn't write a super intensive native app in AHK) but for little workflow optimizations it's so good. For example…

Your hex snippet produced my usual outcry when I read other's AHK scripts: "Wait, you can do THAT?!" It's been added to my growing toolbox(which I lovingly call i3_emulator.exe), thanks!

The fun thing about it is I wouldn't classify myself as an AHK developer. I just picked apart a couple of scripts that I found on Google.

You can kind of understand what's going on with general programming experience and double checking their documentation.

In the hex code example it almost reads like pseudo code. Get the mouse position and store it into X / Y variables, grab the color under the mouse position, make it all lower case, copy it to the clipboard but trim out a few extra characters that was returned by a previous step.

How is your i3 emulator going? I tried that one tiling window manager AHK script (bug.n) but found it to be a little too buggy to use.

Re: Learning to code vs. learning to automate

#183

Post by rfhjt »

JoeAltmaier wrote: post #163
beefield wrote: post #108

Earlier quoted context omitted.

If there is one thing that confuses me, that is productivity. You start doing the thing you were doing twice as fast earlier, thus your productivity doubles. Kind of, assuming that the price of your product does not change due to your increased productivity. If the price halves at the same time (e.g due to competitive pressure because you were not the only one to figure how to spend half the time doing same thing) yo…

Folks often assign the output of automated systems to the creator. This seems a fallacy. The output of an engineer creating an automated system is, the automated system. The output of the automated systems is the product of … the automated system. Who owns that? In a capitalist system, whomever paid for it. This is quickly becoming an issue. As industrial output is rapidly becoming exclusively the product of automate…

It's been like that since the Stone age. The reason it's like that is the fundamental forces that drive humans: greed, cruelty, ego and all that. Hard to expect someone in power to not get more power if he's blinded by greed. How many people do you know that voluntarily spend 25% of their income on those who are lower on the social ladder? I don't know anyone, myself included.

Re: Learning to code vs. learning to automate

#184

Post by iudqnolq »

JoeAltmaier wrote: post #163
beefield wrote: post #108

Earlier quoted context omitted.

If there is one thing that confuses me, that is productivity. You start doing the thing you were doing twice as fast earlier, thus your productivity doubles. Kind of, assuming that the price of your product does not change due to your increased productivity. If the price halves at the same time (e.g due to competitive pressure because you were not the only one to figure how to spend half the time doing same thing) yo…

Folks often assign the output of automated systems to the creator. This seems a fallacy. The output of an engineer creating an automated system is, the automated system. The output of the automated systems is the product of … the automated system. Who owns that? In a capitalist system, whomever paid for it. This is quickly becoming an issue. As industrial output is rapidly becoming exclusively the product of automate…

But isn't the value of the automated system the engineer produced to the business the sum of the value the system will create minus what has to be spent on it (compute power, maintenance).

(Emphasizing to the business to avoid a tired argument about value really being what the market will pay. In technical econ terms by value I mean the private benefit of the consumer of the automation)

Re: Learning to code vs. learning to automate

#185

Post by satokema_work »

BeetleB wrote: post #98
rurcliped wrote: post #68

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 hi…

"A slow sort of country!" said the Queen. "Now, here, you see, it takes all the running you can do, to keep in the same place. If you want to get somewhere else, you must run at least twice as fast as that!"

The cynical advice here is: automate your own tasks and keep the extra slack you gain from it - unless there's a compelling reason to do otherwise.

Re: Learning to code vs. learning to automate

#186

Post by luord »

Or maybe we should encourage users to be users and provide valuable feedback. As in, actually asking about the possibility of new features and reporting bugs.

It'd make engineering a bit easier without trying to encourage people who might not really be interested into wasting their time and everyone else's.

Re: Learning to code vs. learning to automate

#187

Post by JoeAltmaier »

iudqnolq wrote: post #184
JoeAltmaier wrote: post #163

Earlier quoted context omitted.

Folks often assign the output of automated systems to the creator. This seems a fallacy. The output of an engineer creating an automated system is, the automated system. The output of the automated systems is the product of … the automated system. Who owns that? In a capitalist system, whomever paid for it. This is quickly becoming an issue. As industrial output is rapidly becoming exclusively the product of automate…

But isn't the value of the automated system the engineer produced to the business the sum of the value the system will create minus what has to be spent on it (compute power, maintenance). (Emphasizing to the business to avoid a tired argument about value really being what the market will pay. In technical econ terms by value I mean the private benefit of the consumer of the automation)

That 'tired argument' is how capitalism works. So like it or not, an Engineer is paid the going rate.

The value of the automated system is clear. The value of the engineer is the automated system. Which might be quite expensive, but nothing like the value of its output.

Re: Learning to code vs. learning to automate

#188

Post by criddell »

surfsvammel wrote: post #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.

I'm reading Charles Petzold's book Code right now and I would highly recommend it if your kids are interested in computers. I'm about 1/3 of the way through it and even though I'm not learning a lot, it's a great read.

Actually, I learned how Braille works and that's something I always wondered about.

Re: Learning to code vs. learning to automate

#189

Post by iudqnolq »

JoeAltmaier wrote: post #187
iudqnolq wrote: post #184

Earlier quoted context omitted.

But isn't the value of the automated system the engineer produced to the business the sum of the value the system will create minus what has to be spent on it (compute power, maintenance). (Emphasizing to the business to avoid a tired argument about value really being what the market will pay. In technical econ terms by value I mean the private benefit of the consumer of the automation)

That 'tired argument' is how capitalism works. So like it or not, an Engineer is paid the going rate. The value of the automated system is clear. The value of the engineer is the automated system. Which might be quite expensive, but nothing like the value of its output.

I was trying to talk about the value the engineer produces from the perspective of their employer, which is separate from what that employer is willing to pay the engineer. In economics terms, I'm talking about the consumer surplus (the employer is the consumer of the labor the engineer produces, and has a surplus because they get more value than they are paying).

I called it a tired argument not because it definitely isn't true but because I'm tired of people shutting down unrelated conversations with it to look smart.

A simple scenario that shows these are separate concepts:

Suppose we have an extremely dumb firm that pays the engineer a trillion dollars to create an product that can make whoever owns it a billion dollars.

Suppose we have an extremely dumb engineer that charges a different firm $1 to produce the same product.

Suppose both firms are trying to sell the automation to a third firm. Their expenses are a sunk cost; this firm isn't going to pay the dumb firm that overspent any more. The value of the product is (generally) separate from your cost of making the product.

Re: Learning to code vs. learning to automate

#190

Post by Noumenon72 »

swozey wrote: post #77
Noumenon72 wrote: post #36

> Throughout human history, there’s been a sort of “pain is gain” approach to the repetitive. There was value in putting your head down, getting into a rhythm, and working hard at menial tasks. I was surprised when my sister told me, "I don't think everyone has that instinct to make things better all the time". That's like my fundamental drive! But she doesn't, and I guess I see why. Things didn't get better for hund…

Are you a perfectionist?

Sure, but I'm not surprised when people don't want to polish things the way I do. I'm surprised when they let things go to waste or spend their time doing boring and pointless things. Like, even Genghis Khan probably spent some time thinking about ways to take cities without having to fight so much, right?
Post reply on HN