Today I came across an article by Erik Dietrich called “Learning in a World Where Programming Skills Aren’t That Important”. I haven’t found the time to read Erik’s book Developer Hegemony yet, but I’ve read and enjoyed a lot of the writing on his blog.

Early in the article, he recounts his definition of an efficiencer. The difference between an efficiencer and a programmer is this: the programmer writes code while the efficiencer solves a problem.

A while ago, I wrote a post about a contract I did in which I built API-driven automation on top of Airtable, instead of continuing the custom-built CRM that the previous developer had started to create. While writing that post, I also described that I believe a developer’s job shouldn’t be writing code but solving problems. Erik’s writing partly inspired my reasoning, but at the time, I didn’t have a fancy term for it. Now, however, I believe that the project I mentioned is an excellent example for an efficiencer’s work.

I enjoy coding, and I love writing code that does something smart. I even tend to grow attached to the lines I wrote. But the value I can provide doesn’t necessarily lie in that code but in understanding requirements and solving them in the best way.