I may not be a grizzled gray-beard, but I’ve been helping to professionally ship software since 1994, including both shrink-wrapped “software-in-a-box” and web-delivered services. I have proven experience at designing solutions correctly from the beginning to ensure that they will be ready by the time the deadline arrives. For all of the standard details, take a look at my résumé.
What may not jump out from my résumé is how often I have had to delve into a new or foreign codebase, whether from working on a feature or tracking down a pernicious bug, and come out with a deep understanding of another team’s code. This has resulted in “patch-and-go” fixes delivered to other teams, and to refactored and redesigned code that performs more reliably and with better performance characteristics.
I’m certainly not a designer*, but I’m obnoxiously good at noticing designs and user experiences that aren’t aesthetically pleasing. Have you ever noticed a restaurant menu or sign that uses a 0 (zero) instead of O (capital-oh), or vice-versa? How about publications that are layed out using spaces instead of tabs or other vertical guides? These things jump out at me all the time, often before I even have a chance to actually focus on the item in question.
I bring that same level of attention to the software I design and implement; in truth, I can’t really avoid it. Seeing code duplication or overly-convoluted if/else expressions results in an almost physical, visceral response. It must be fixed!
* This site is okay, but believe me, I know it’s no masterpiece of web design. There are a ton of considerations that go into good design, and I know enough to know that I’m only consciously aware of a small number of them. That said, it’s like Associate Justice Potter Stewart wrote: “I know it when I see it.”
As important as the details are, I also know how critical it is to step back and look at the entire picture. Have we asked “why?” enough to ensure we’re solving the user’s actual needs, rather than just what they say they want? Are we spending too much time on a feature that will only be used occasionally? Yes, the perfectionist in me wants to fix every last bug... but I also know that every change introduces risk, and there’s a delicate balance to maintain.
Okay, maybe not The Great Communicator, but at least a great communicator, whether it’s disucussing technical details among programmers, making trade-offs across functional teams, or talking to “regular folks”. You’d never know I was a typical introverted programmer in these contexts (unless you were one as well, and understood how much easier it is when you’re talkng about something you know well).
I also spent the 2012–2013 school year teaching high-school AP Computer Science, which taught me as much about communicating and presenting as I taught the students about programming.
You can also take a look at my StackOverflow answers, to see more examples of my communication style.