Be a better employee, not a better programmer
André Staltz wrote an article making the rounds, entitled The single tip that made me a better programmer:
As a programmer, you must become one with the machine, thinking how the machine thinks, to a level that you will no longer be surprised by any behavior or corner case. There should be no dissonance between your mind and the computer’s activities. To become fully conscious of the runtime realm in the computer is, basically, programming utopia.
This is a good article, and has merit. But I don’t agree with it.
Most of my professional development revolves around two understandings:
- The job of a programmer (or developer, or software engineer, or whatever title you prefer) isn’t to program things. It’s to solve problems.
- I have a finite amount of time and mental energy which I can use.
If you commit to spending all (or even most) of your time focusing your mental energy and development time purely on things that are executable, you’re spending time improving as a tool rather than improving as someone who uses a tool.
You’re a programmer – you already have a fairly deep understanding, relative to non-programmers, of engineering systems. Focus on learning the other ones: focus on understanding social systems, commercial systems, experiential systems.
Watch how people use your product. Talk with customers. Talk with internal stakeholders. Ask people, what’s one thing you wish this did?. Shadow someone in your organization for three hours and figure out what you didn’t know and what they didn’t know. Put in the hard work – the unfamiliar work.
I know there are lots of bugs I could have solved if I knew how the JVM worked a little better; but there are even more bugs, features, and entire sprints I could have avoided if I knew how my company worked a little better.
André finishes his article by writing:
Programming is not about putting bricks together, it’s about persuading a beast.
My counterpoint would be: programming is not about persuading a beast, it’s about figuring out what beast to persuade.
(The persuasion itself is an implementation detail.)