How to motivate someone to learn a programming language. 1. Assign a repeatable task. 2. Incentivize to complete higher number of tasks. This can be a flat ra

How to motivate someone to learn a programming language. 1. Assign a repeatable task. 2. Incentivize to complete higher number of tasks. This can be a flat rate per task or flat number of tasks per day or something similar. 3. Let them work for a while to understand the process. 4. Now the idea to automate gradually appears in their head. 5. First automation appears. I usually start with command line loops and encoding strings into barcodes. 6. GUI automation appears and the user starts running into limitations of easy tools. 7. User makes the decision to invest time into learning a programming language. 8. User automates their entire job. Smarter companies would offer to assign her the role of an internal software tool maker to identify processes and automate them. Some of these toolmakers might be like me and perfectly happy to simply do a lot less and get paid the same or more. Other companies will make her realize she might be valued higher elsewhere. Learning a programming language without a concrete goal to solve is not as being able to completely automate your job. I once identified a great opportunity as a field service engineer. The company unknowingly offered me an incentive. After arriving on-site, I can identify additional broken equipment that’s not in my original scope and add it to my scope. I negotiated flat rate compensation per unit fixed rather than per location or per hour. My marginal cost to fix additional equipment is a few extra minutes. The company sending me that work creates additional scope on their end after I am finished and so we all get paid more money. The service call gets closed in a single visit. I call that a textbook example of all incentives aligned. So, after identifying this opportunity, I explored all bottlenecks inhibiting me from working faster. A single additional service call per day results in significant extra money. Bottlenecks: 1. Talking to dispatch to verbally relay serial numbers, shipping numbers, and other phonetically spelled data. Solution: start transmitting data as structured text dispatch can copy/paste. Result: most loved vendor, no more waste of time. ;) 2. Verify equipment is properly configured. Solution: if it can be pinged, it will work, else redo the previous task. Result: knowing the arp and ping commands lets me test equipment without walking to it. 3. Verify output integrity. Solution: (currently implementing this) use a personal IP KVM with a WiFi AP to remotely operate the on-premises server while standing next to equipment. Motivation: running upstairs at least 30 times at one troublesome location not long ago. 4. Repetitive entry of text strings into multiple contexts. Solution: encode those strings, like passwords, into barcodes on my iPad and scan them while also scanning serial numbers and such. Result: this saved a ton of time. My first automation was to write a script to ping all devices as part of a health check. Now that I reached the limit of easy automation, we enter software engineering. I am working on a tool to automatically generate my paperwork based on OCR-ed screenshots. I am also working on a tool for the dispatch to have better visibility into what their techs are doing. At the same time, I have a huge incentive not to share my shortcuts with other techs. By the way, the next generation of our control equipment runs Linux. I was constrained by archaic tools running on Windows, but we all know to which extent we can automate Linux. ;)