The programming industry is very much about what's new---the hottest language, technique, or framework. But, the best programmers---the ones that are going to stick around for the long haul---rely on a few timeless principles. These are the ones that take years of practicing the craft to truly master. Even further, they are relevant regardless of where you work on the technology stack.
Here are the four traits that I find live in every long-term programmer I've had the privilege to work with.
So much of good programming comes down to good organization. Think about these concepts scattered all over the various layers of a typical piece of software: OOP, encapsulation, interfaces, information architecture, the DRY principle, CSS preprocessors, HTML, relational data modeling, normalization, design patterns---I could go on and on. But at a point, it may just sound like I'm naming any generic concept that relates to programming.
Consider that all of these ideas, languages, and approaches to building software are driven primarily by the same concept: organization. Encapsulation is about what (and what not) to group together into a single component. The DRY principle is about extracting out common functionality into a single place---that is to say, re-organizing your code more tightly. CSS preprocessors enable the developer to organize common visual styles together. HTML is the language of organizing content. Relational data modeling is, at its core, all about deciding how to best organize a bunch of data.
Great programmers spend years learning how to organize well. They consider why they've chosen a specific way to organize something (because there are infinite ways to organize anything). And, they frequently re-evaluate how their work is organized as features grow.
"There are only two hard things in Computer Science: cache invalidation and naming things." -Phil Karlton.
While we don't all have to work on invalidating stale caches, every programmer has to name things. Say too much and you could paint yourself into a corner. Say too little and you're left with the technical debt of ambiguity. Naming can turn otherwise hairy code into something much more manageable, as much as it can turn well-architected code into a maintenance nightmare. Sometimes a naming pattern works best, other times it's too restrictive.
Good naming is hard. And, just like organization, it requires constant re-evaluation.
At the end, programming decisions are always about trade-offs. There are no silver bullets. A distinctive characteristic of a seasoned programmer is their ability to judge the worth of one option versus another.
Every new feature addition, by its nature, will add technical debt. A new feature means there's something new to maintain. The long-term programmer thinks carefully about whether the pros outweigh the cons. And, the best ones aren't just thinking about what's best for the codebase---they're considering the customer and the stakeholders. They use new tools not because they're new, but because there's a legitimate benefit to them.
The last trait I see common amongst long-term programmers is, perhaps, the most nebulous one.When we learn to program through textbooks or tutorials, the paths have already been paved for us. The examples are hygienic. When we're working in real code, the paths are not only off the beaten ones, but we sometimes don't realize they exist until we're right in front of it. This is particularly true of legacy code.
And so, the long-term programmer always faces the challenge of getting something from Point A to Point B. After all, most crufty codebases can't be polished in an overnight refactoring. The diligent programmer carefully considers what multitude of steps are needed to get to the ultimate landing point, and how to accommodate the needs of the users and stakeholders while the journey is in mid-flight. Through a combination of foresight, empathy, and pragmatic problem solving techniques, they find a way to get from Point A to Point B successfully.
