4 ms·

I replaced a person with a one line code change (performance tuning) - they got her another job though. Literally had a business call to see if they could run

by hobs 8y ago

I replaced a person with a one line code change (performance tuning) - they got her another job though. Literally had a business call to see if they could run another instance of $LOB_SOFTWARE because they had a person clicking a button for 40 hours a week.

kamaal 8y ago
That kind of work is easy to automate. Until you reach a situation when it has to be decided when a person has to click the button. And with what data they are supposed to click it. Often it's not easy to make those decisions through code. That is because the person making those click decisions, has a lot of tribal knowledge of the business situation at hand, which triggers only when the situation presents itself. But if human is basically a meat-robot doing programmable tasks that is not even a automation issue. Its really more management and planning problems. You are supposed to fire people running the business in those cases.
- passthefist 8y ago
  There's hybrid cases though, where you can use automation/business logic to lower the skill floor required for some work. That's pretty much the business model of the company I work for. We have what is essentially a call center using custom CRM/workflow software doing work that used to be done by many times more people with much more training. Instead of 5 licensed and well paid people we do the same work with one lower paid and less trained person assisted with software. Humans are still involved to make decisions when needed and for communication, but the simple and clear stuff is automated so we can hire pretty much anyone. It's good for our clients since we are cheaper and more efficient, but less good for the workers we're replacing who will need to find new marketable skills or fall down the ladder.
hadlock 8y ago
We replaced our entire overnight testing and on-call operations department with SSD and a little bit of SQL optimization. Jobs that used to kick off at 5pm would run until close to noon the next day. When I stopped interfacing with that unit those jobs completed by 9pm. Went from a department of 25 operators to a team of 15 or so. We weren't able to reduce further due to vacations, on call, sick time etc.
- hobs 8y ago
  Yeah, I see the biggest problem here when existing code which ran fine never got the maint it needed to scale up the team, so they throw more bodies at the issue instead of pay to fix the code. Good work.
jimbokun 8y ago
Reminds me of this: https://lostpedia.fandom.com/wiki/Pushing_the_button https://lostpedia.fandom.com/wiki/Pushing_the_button

by hobs 8y ago

kamaal 8y ago

That kind of work is easy to automate. Until you reach a situation when it has to be decided when a person has to click the button. And with what data they are supposed to click it. Often it's not easy to make those decisions through code. That is because the person making those click decisions, has a lot of tribal knowledge of the business situation at hand, which triggers only when the situation presents itself. But if human is basically a meat-robot doing programmable tasks that is not even a automation issue. Its really more management and planning problems. You are supposed to fire people running the business in those cases.

passthefist 8y ago
There's hybrid cases though, where you can use automation/business logic to lower the skill floor required for some work. That's pretty much the business model of the company I work for. We have what is essentially a call center using custom CRM/workflow software doing work that used to be done by many times more people with much more training. Instead of 5 licensed and well paid people we do the same work with one lower paid and less trained person assisted with software. Humans are still involved to make decisions when needed and for communication, but the simple and clear stuff is automated so we can hire pretty much anyone. It's good for our clients since we are cheaper and more efficient, but less good for the workers we're replacing who will need to find new marketable skills or fall down the ladder.

hadlock 8y ago

We replaced our entire overnight testing and on-call operations department with SSD and a little bit of SQL optimization. Jobs that used to kick off at 5pm would run until close to noon the next day. When I stopped interfacing with that unit those jobs completed by 9pm. Went from a department of 25 operators to a team of 15 or so. We weren't able to reduce further due to vacations, on call, sick time etc.

hobs 8y ago
Yeah, I see the biggest problem here when existing code which ran fine never got the maint it needed to scale up the team, so they throw more bodies at the issue instead of pay to fix the code. Good work.

jimbokun 8y ago

Reminds me of this: https://lostpedia.fandom.com/wiki/Pushing_the_button https://lostpedia.fandom.com/wiki/Pushing_the_button