4 ms·

> If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt

> If you're not being challenged in your job (i.e. doing grunt work), you either need to find a harder job within the company (it might be automating away grunt work), or failing that, a different company. Honestly, the only serious challenge I have in my job is getting people to do stuff in a maintainable, reliable way despite the fact it costs a little more in QA of the automation (or manual change control processes that IT frequently resists). Automation is not the right solution when human QA and manual intervention is an order of magnitude less expensive than the potential problems created by a non-technical user. You have to realize the only person who _really_ understands most heavily integrated systems are technical folks and automating abstractions to allow non-technical users to make sweeping system-wide changes is a bad idea (even if it is easier on IT). > Top performers have usually crept towards the high end of the salary available to them, and they're aware that grunt work isn't necessarily a good cost / value tradeoff for the company they're working for, nor a good tradeoff for their human capital vs income earned. The problem is, you can't always automate grunt work. For instance, matrix rate shipping is something that is (effectively) a business rule that is maintained manually across multiple systems. Someone, somewhere is going to have manually determine that business rule and apply it. Now, lets say you are crafty and you automate the f out of this process so they just have to type some values into a spreadsheet and upload it. Or a form. Or whatever. What happens if your validation is not 100% correct and you are relying on non-IT people to QA this update that impacts multiple systems? You lose $50k before the defect is fixed because instead of having someone who understood the impact from end to end dealing with it, you gave it to a business person who found a novel way to work around your validation to "make it work". The cost of annual, manual updates by a 6 figure salaried programmer would have been less than $5k a year. So the wise, automation oriented programmer fixes the defects in validation, writes some more unit tests, and so forth. Then, lo and behold, it happens a second time on Black Friday and you end up giving out 6 figures in $$ due to a "software error" that was due to a business person setting everything to $0.01 because they misunderstood something.). Now, you might blame the business person but given this has happened for the Nth time before this person automated it...they should have known better and required some sort of manual validation step by QA/IT/whatever. Some things you really, really must have a manual sanity check on because of how critical they are and the business risk involved and automating it to the point you hand it off to someone else for minimal manual work is not the right decision. I've seen this with controlled substances, regulated products moving across borders, shipping, and a dozen other things. Non-technical people being handed powerful automated tools they don't 100% understand is not always the correct solution.

barrkel 9y ago
That's a fine rant on the trade-offs of automation vs manual intervention. It's one reason I used the word "might". Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.
- AFNobody 9y ago
  > Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more. Yes. Its a situation where the individual's interests (focusing on being visible on high impact projects that hit deadlines and then moving on before the maintenance and/or technical debt issues crop up) are diametrically opposed to the business's interests (building maintainable systems that do not have 5-6 figure bugs that likely exceed the development cost of something as simple as executing on a critical path combo box). I've never worked for a business correctly values the impact of the former on the latter.

barrkel 9y ago

That's a fine rant on the trade-offs of automation vs manual intervention. It's one reason I used the word "might". Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more.

AFNobody 9y ago
> Perhaps another way to put what I was trying to say is that top performers are constantly looking to maximize the amount of value they're adding, and a day filled with grunt work is seldom that; while a job filled with grunt work and little else is actively damaging to your career, if you're capable of more. Yes. Its a situation where the individual's interests (focusing on being visible on high impact projects that hit deadlines and then moving on before the maintenance and/or technical debt issues crop up) are diametrically opposed to the business's interests (building maintainable systems that do not have 5-6 figure bugs that likely exceed the development cost of something as simple as executing on a critical path combo box). I've never worked for a business correctly values the impact of the former on the latter.