"The Best Programming Advice I Ever Got" with Andrei Alexandrescu
See more advice from other programmers here.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Read The D Programming Language or more than 24,000 other books and videos on Safari Books Online. Start a free trial today.
Name:
Andrei Alexandrescu
Job Experience:
I worked as a software engineer in banking and Web companies, and later as a research scientist (which entails staring at numbers in addition to programming).
Most Notable Achievement:
Wrote a couple of books; got a doctorate from a university that, to paraphrase Mark Twain, is too good to have me as a professor; contributed to the D programming language; invented an algorithm (DynTrie) that only I and possibly my adviser know about.
Most Frequently Used Programming Language:
The D programming language.
Advice:
This is a bit meta, so it needs some context. I'd developed this huge passion for analog electronics since I was a kid. Whenever something was wrong with our TV set, my father would call this neighbor in our apartment building, Mr. Ghitzescu. He was a jovial man who arrived with his multimeter and a few other tools, and invariably found a way to fix our TV set after a few magic passes at its vacuum tubes (I'm not that old, mind you; this was Communist Romania, where the technological clock was a couple of decades back) and later integrated circuits. Then Mr. Ghitzescu would leave as gleeful as ever, not before giving me some good advice such as "See, I never put both hands in the TV when fixing it, lest I'd get a heart attack if I got electrocuted by some capacitor". I was left in awe at how so much knowledge and insight could reside in one man. I dreamed of doing electronics for a living, so when the time came I applied to the Electrical Engineering (EE) department at the university.
But this story isn't about Mr. Ghitzescu; it's about my Mom. I had started attending the EE department. The CS department was just across the street from it, and inevitably there was talk about this computer programming thing - it was getting quite trendy. I gradually realized software and analog electronics were getting ready for an all-out war for occupying my mind. At that point I had a chat about it with Mom.
Now, Mom was a gymnasium music teacher of some notice, but knew next to nothing about EE, Computer Science (CS), and such. Many distinctions between analog and digital electronics were lost on her. She does have, however, a sharp mind and an insight that never ceases to surprise me.
So here's what she told me: "You're weighing EE versus CS. You see, EE was hot when Mr. Ghitzescu was a student. Now it's all tamed, standardized. There's a lot still happening in EE, of course, but I think CS will be much bigger and you'll find it more rewarding to invest your creativity in it." I have no idea how she ever figured that out; the year was 1990, and even though the computer revolution was well underway in the USA, it only arrived as muffled echoes to an Eastern Bloc country just after the Cold War.
This has touched the fabric of my life in more ways than I'd realized at first. First, it put the paradigm embodied to me by Mr. Ghitzescu in a whole new light - analog electronics was only enjoying a trailing momentum, digital was to take over, and moreover programming digital systems was to become big. Second, and here's where it gets interesting, I got to see the ever-changing nature of the whole thing: something hot today will inevitably become be a paradigm past tomorrow, and may as well already be on the way there.
That sounds obvious, but has non-obvious consequences (and here we get to the gist of the "programming advice"). Most notably, learning how to learn is more important than learning anything else. If you know how to learn, you'll reduce inertia and emotional investment in any particular niche, so you're likely to make better decisions when choosing what to best work on. Another consequence is that it's best to be continuously introspective with regard to what you're doing versus what you should be doing. Often that gives you unexpected insights. If you're a good calligrapher and grok the emergence of the printing press, the smart move is to be the first font designer.
I'm happy I harbored that attitude. For example, back in 2001, I wrote this book, Modern C++ Design, that was quite successful and vaulted me in a position within the C++ community that surprised me quite a bit. I could have comfortably spent my entire career as a top C++ dog. Instead I veered into a doctorate in Machine Learning (a field I initially knew nothing about, but had an intuition about its emergence), followed by a related line of work at Facebook. My interest in programming languages migrated to a different outlet - the D programming language. Both endeavors were extremely risky propositions at the time, both career-wise and financially; a few friends tried to talk me out of each.
Did it work out? My accomplishments are hardly world-changing, but that's beside the point, as many other factors would enter into such a judgment (innate capability, context, and more). The point is that attitude has improved my utilization of whatever resources I've had, and it has made me a happy and fulfilled person. If I could go back and change one thing, I'd do it all over again, just more radically.
But just in case you do care about changing the world, you're in good company. Consider Donald Knuth (the consummate computer scientist) and the late Steve Jobs (the consummate computer entrepreneur) - both renowned for moving full-force into fields that were complete unknowns to them beforehand, and for dramatically changing their course. Knuth mentioned in an interview: "I guess I'm a quick study; I can become an instant expert in something...I can absorb a subject locally and get good at it for a little while... but then don't ask me to do the thing I was doing a few months ago!" And Jobs, in his famous commencement address: "I have looked in the mirror every morning and asked myself: 'If today were the last day of my life, would I want to do what I am about to do today?' And whenever the answer has been 'No' for too many days in a row, I know I need to change something."
This pattern is common to all great programmers I know: they're not experts in something as much as experts in becoming experts in something.
The best programming advice I ever got was to spend my entire career becoming educable. And I suggest you do the same.