Ned vs. NED.EXE
I caught a snippet of an NPR interview this morning. An economist spoke of CEOs confiding in him about the new technologies they had coming that would put a lot of their employees out of work. In the past, I’ve noted that programmers like me write that code, and are the last to get whacked. Not so fast...
A few years back, my friend Ned worked for me. He was a new programmer, so I had him building admin screens and coding objects mapped to database tables. Basic, repetitive work that the coder has to pay attention to the context of the work, but is a lot of following a pattern. After a while, he left for greener pastures, which was the point of hiring him.
Meanwhile, back in my shop, I had a stack of work was piling up. One day, I had seventeen objects to code up. Each takes about a day, maybe less to code and test. I had a distinct pattern to coding these, and when something has a distinct repetitive pattern, it is a candidate for automating. Enter NED.EXE
I whipped up NED.EXE in a week and a half. It then cranked out C# class files for seventeen tables in about 2 minutes. I had worked out quirks in the process during that time, so this was hundreds of lines of code that ran perfectly. In later years, Microsoft came out with Entity Framework, and since I like to brag, NED.EXE still does some things better. So much so, I retooled NED.EXE to crank out add-ons to Entity Framework’s generated code. That might be too technical for some folks, the gist is, I replaced a human with less effort than Microsoft spent on the same problem.
My little morning drive reminded me that what can be automated will surprise us. Jobs we assumed are future-proof may not be. Cashiers, truck and taxi drivers are on the chopping block in the next decade. Having a job will be like musical chairs. Dismissing those who don’t have a seat on the assumption they did something wrong is a faulty assumption. We as a society ought to think about that.