Talking the Talk and Walking the Walk

Lately, I’ve been reflecting on my software engineering career as a software engineer. I’ve had the privilege of working with some truly exceptional developers, and while most of them weren’t great teachers{{1}}, they nonetheless impart lessons through action and behavior.
Engineering talent is hard to find, and – to be completely honest – the vast majority of us will never reach that level of greatness. We will get better over time with experience, practice, and our intense curiosities, but I feel like there’s a ceiling to the impression a developer leaves, just on technical ability alone.
I’m often most impressed with people who are:
Autonomous. I think of autonomy as the ability to work sans supervision, sans constant extrinsic motivation. Self-motivation is an oft-cited factor in work satisfaction{{2}}, and common sense tells us that happy workers will be more productive. It’s a good sign when an engineer is restless when they don’t have an active project, even if the inactivity lasts for a few hours.
The trait implies a natural attunement in technical problems and a strong tendency to solve said problems. These developers really just enjoy the act of building: new techniques, new languages and practices, and creating systems to be used by others. Unsurprisingly, this maps well with the open source movement, and is one of the reasons why contributions to OSS is such a strong hiring signal.
Communicative. Our time was spent writing instructions for machines, but the code we produce will be read, reused, and refactored by other living, breathing engineers. More often than not, the work we produce is a small part of a much larger, much more complex system. Communication, then, is the skill that differentiates a solo rockstar armed with his or her pet project{{3}} from an engineering team building ambitious products.
Pretty much every developer I know intuitively acknowledges the importance of communication, but few have the time, energy, or direction to improve. It manifests in so many different forms, technically or otherwise: design documents, architecture diagrams, collaboration with non-engineering teams, and core tasks like pair programming and knowledge transfers are all about getting others to gain perspective and understanding.
Turns out, people who are technically competent and can be self-sufficient while enabling collaboration are highly sought after{{4}}. How surprising.
[[1]]How does that idiom go? Those who can’t, teach.[[1]]
[[2]]Though on the other side, it has perhaps an adverse effect on work-life balance.[[2]]
[[3]]Mad props, though, to the one-man army behind the Visopsys operating system.[[3]]
[[4]]On barely-related tangent, I feel like these two qualities are sorely lacking in most outsourced software development and are the root cause of the frustrations and money spent.[[4]]