Live data from Hacker News

Coders Automating Their Own Job

theatlantic.com

391–400 of 499 posts

Re: Coders Automating Their Own Job

#391
post #135

Earlier quoted context omitted.

As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important? Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies. (P.S. I understand the best developers probably don't…

I’d hope they all do. If you get an experienced developer they should want to automate all of this. My former boss took the model of improving processes and revenue, then taking a cut of the difference ongoing. He had financial freedom already, so this was the best use of his time. With some companies you aren’t given all of the information to make the right decision for efficiencies sake, or they write such a rigid…

That's a great idea, will definitely try this out.

Seems to be a good idea to separate out the architecting from the actual implementation. Makes sense, because if someone knows they'll have to be implementing, it could cloud their plan for the ideal solution. Similar to separating out design, UX, and development roles.

Re: Coders Automating Their Own Job

#392
post #336
post #268

Earlier quoted context omitted.

> 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. Their boss cares. This is capitalism, and capitalist ethics say you should be fired if…

I think it means that your job should then become automating aspects of the business, then maintaining these automations. Your labour becomes automating.

> I think it means that your job should then become automating aspects of the business, then maintaining these automations. Your labour becomes automating.

More realistically: as a laborer, you shouldn't put in extra effort to automate your job away, because the benefits will likely be kept from you, for the most part. They might throw you a bone as a reward, but a bones are leftovers. They'll keep the meat for themselves. This kind of automation is properly understood as a kind of charity for the people who need it least.

The appeal of automating away your job is the freedom it seems to bring to the automator, but that's an illusion. You'll remain a laborer until you're put in a position to go live under a bridge, which is a freedom you've always had.

If you want to openly automate away your job, you want to be a software engineer. At a minimum, negotiate a software engineer's salary from you employer before you start that work. However, if you can manage it, it's better for you to start a company to license the automation back in perpetuity.

Re: Coders Automating Their Own Job

#393

Earlier quoted context omitted.

As a non-developer, how can I hire someone (or a team) like OP that focuses on automating menial stuff and focuses on the most important? Does a development agency that focuses on this model exist? Of course they should be paid more per hour (or other unit) than your average, less optimized agency, but the sum total should be less than hiring inefficient agencies. (P.S. I understand the best developers probably don't…

Part of the problem is that to effectively automate a task or series of tasks you need to fully understand what is being done. The person currently doing this knows what they are doing (you would hope), and may understand why they are doing it (this is not guaranteed). In many cases, what somebody does (and why) is not documented, or if it is the documentation is most likely out of date and inaccurate. To effectively…

So it sounds like two things:

1) As person with business knowledge, vision, plan, etc, I should fully document the business goal and why we're doing it and what we're trying to achieve at the highest level, then work with the developer to figure out what should be developed to achieve that and where to automate.

2) Don't hire outside person or agency, but bring someone in full-time or as a part-time partner for the long term and incentivize them to get better and better?

Re: Coders Automating Their Own Job

#394
post #340
post #316

A question for the people that have a positive attitude towards keeping time savings for yourself instead of passing them on to your employer. Would you be also okay with the following situation: You have someone remodell your garden. He comes up with an estimate of 1 week worth of full-time work for two people. Based on your experience this seems reasonable and you agree on a fixed price of 10000$. Two scenarios of…

One important distinction that you omit is the robot gardener costs exactly the same as other people doing the work manually. If I had to choose between two options that cost the same, but one is ultra fast and has consistently high quality, it's a no-brainer for me.

Why would the robot cost the same? If it costs the same, then there is no incentive to introduce robots in the first place. I think the wide-spread automation is a testament to the much lower price of robots compared to human labour, no?

Re: Coders Automating Their Own Job

#395
This is a common situation that I've been in several times before, even up to the point of automating the automating.

I had one particularly nasty supervisor who gave me a project, then asked me how long it would take to program, then without fail tell me that was unacceptably slow, then tell me that my predecessor could have done it in half the time, and finally question my competence.

So one day he brings me a short programming project that previously took anywhere from say 2-3 hours, asks me how long it will take to program, and I respond with, "30 seconds". He then replies, "That's too long. So and so could have done it in 15... wait, what did you say?"

I've mostly or completely automated several of my own jobs, and when done with that, proceeded to reduce my co-workers' work load. Usually it does not end well. Either someone higher up in the organization will perceive the automation as wasting time (still can't wrap my head around that), think of you as now redundant, or see little reason to offer additional compensation while moving you into a new position that does nothing but automate. After all, if you were willing to automate in the previous position at the previous level of compensation, why should they have to pay you more now?

Re: Coders Automating Their Own Job

#396

This is a common situation that I've been in several times before, even up to the point of automating the automating. I had one particularly nasty supervisor who gave me a project, then asked me how long it would take to program, then without fail tell me that was unacceptably slow, then tell me that my predecessor could have done it in half the time, and finally question my competence. So one day he brings me a shor…

“30 seconds”. You should have told him 6 hours. If he needs it done quicker hire someone else. Enjoy your day.

Re: Coders Automating Their Own Job

#397

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…

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

The first programming job I had I was actually promoted from being a "front-line" worker answering calls and processing forms all day, and I was pretty much able to write the software with no requirements explanation at all. So there is some value there.

Re: Coders Automating Their Own Job

#398

Earlier quoted context omitted.

Funny, I've always seen it the opposite way. The employer earns my work by giving me a salary. My work has a value and the employer pays for it. The minute they stop paying me, my offer cease and they lose any future value I might have brought them. Maybe it's because I did a lot of freelance and agency work before working a full time contract.

Unless they got you on that non-compete for 2-3+ years on that 6 month contract, at that point you are their value and everything you brought was theirs, nevermind they might not have had the value if you hadn't brought/created it.

You shouldn't sign something like this.

Over here (Montréal) there's right to work laws and precedents that makes it so that those clauses are pretty much null if they keep you from working.

Non-compete pretty much only protects the employers from having a direct competitor recruiting their employees.

Re: Coders Automating Their Own Job

#399
post #394
post #340

Earlier quoted context omitted.

One important distinction that you omit is the robot gardener costs exactly the same as other people doing the work manually. If I had to choose between two options that cost the same, but one is ultra fast and has consistently high quality, it's a no-brainer for me.

Why would the robot cost the same? If it costs the same, then there is no incentive to introduce robots in the first place. I think the wide-spread automation is a testament to the much lower price of robots compared to human labour, no?

I mean the guy using robot gardener takes the same pay for the services, not the robot, sorry for confusion.

Re: Coders Automating Their Own Job

#400

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…

I had to Google RPA. Never heard of any of those tools. What I have heard of - and directly witnessed - is MS Access and MS Excel being used by non-developers to build surprisingly powerful tools to solve their most acute problems. They often don't even realize that they are programming.

Yes, that's true, but there are also plenty of cases of them making mistakes (the amount of money lost per year to mistakes in Excel spreadsheets is something obscene) and getting in way over their heads.
Post reply on HN