A Programmer's Three Identities

One of the reasons I enjoy programming so much is that it asks you to to simultaneously take on three unique identities. Each identity requires you to think differently and the identities may be called upon to different levels depending on the programming task. And it is absolutely possible to program with only one or two of these identities. But, to be a truly great programmer you must be able to assume all three identities.

The Scientist

The first identity is the scientist. This is typically the first identity acquired by students in the traditional university pipeline. In academia the scientist’s role is essential; in industry the scientist takes a backseat while occasionally being critically important.

Unsurprisingly, the scientist is concerned with the field of computer science: algorithms, complexity theory, parsing techniques, statistical methods and other things of this ilk. The most important aspect of a program to the scientist is whether it provably achieves something. How the code looks or is deployed are irrelevant details. Above all the scientist focuses on the possibilities of computing.

The Craftsmen

The second identity is the craftsmen¹. Commonly this identity is discovered after one has spent sufficient time honing their identity as a scientist. Those who were introduced to programming at a young age often pick this up as their first identity.

The craftsmen recognizes that programming is not just a science but also an art. They take immense pride in the clarity, consistency, and conciseness of their code. A great craftsmen is concerned with the smallest minutia like ensuring their is always a space after a comma in a list of items. Refactoring is a delightful opportunity for a craftsmen – not a dreaded chore. It is a pleasure to live in the codebase of a craftsmen. Above all the craftsmen focuses on the joy of programming.

The Engineer

The third and final identity is the engineer. This identity is developed when you first come in contact with code operating in production. Production is where the rubber hits the road as your program is used to solve real-world problems.

The engineer’s primary concern is how a program can be delivered and managed to reliably solve these real-world problems. Tools are an engineers best friend: monitoring/alerting systems, CI/CD, performance instrumentation, distributed tracing, etc. When tasks are repetitive and important the engineer automates them. An engineer isn’t afraid to get dirty solving a weird bug in production and they aren’t afraid to jerry-rig a not-so-pretty but effective solution. Above all the engineer focuses on the practical issues that arise when a program enters the real-world.

The Programmer

The programmer contains the multitudes of all these identities. They know when it is time to develop the perfectly optimal solution and when the O(n) solution is good enough; when it is time to fix that one obscure linting rule and when it is time to just hit save and move on cause it works; when it is time to build a well tuned deployment pipeline and when a Jupyter notebook will do just fine.

This is an incredibly difficult balancing act and one of the reasons why I love programming. I’m just at the beginning of my journey with each of these identities and I can’t wait to go deeper into each one of them.