Hello Alex, and thank you for accepting this interview. First of all, can you tell us a bit about your career path?
I got my Master degree in EE in 1980, started designing chips and systems for Texas Instruments, then IBM Research, where gradually I drifted towards software development; as a developer and technical manager, I then worked for Cad.Lab/think3 (an Italian CAD company), then some years as a freelance, and in the last few years for Google, Inc, in Mountain View, CA.
What exactly lead you to a sudden change from electronics to building software?
It wasn't sudden, but gradual: I wrote more and more software to make my hardware more useful, and one day I realized I was basically doing only software, not hardware any more.
Do you think there is such thing as Software Engineering? Will computer programming ever become an engineering discipline in the traditional sense of the term?
It already is: I'm an engineer — the overall differences between hardware engineering practices and software ones are vanishingly small, smaller than differences between sub-fields within each discipline (designing transformers vs microprocessors, or consumer web apps vs software for real-time control of industrial machinery, say). The main issue may be that most practitioners in software development don't have actual engineering training (but rather, for example, computer science, which, as Djikstra said, "is no more about computers than astronomy is about telescopes").
In the constantly evolving world of the IT industry, how does a programmer keep up the pace and sort useful technologies from useless ones? Have you ever found yourself investing time in something that later revealed to be useless for your purposes, or do the dots always connect eventually?
Yes, like everybody else, over the years I did repeatedly fall for the lure of elegant technologies that later turned out not to work well in the real world; learning, per se, is never a waste of time, but it's important to avoid investing too much time and energy in such endeavors (it would be a disaster if one developed and deployed a large, costly, important system and then discovered that the technology's not adequate).
Always look at new technologies with a critical, indeed somewhat cynical eye: in particular, look for simplicity — a technology that's intrinsically simple (like, say, HTTP) is much more likely to get good, robust, interoperable implementations, than "elegant" but complex technologies. Don't look for perfection: just as "no battle plan survives contact with the enemy", so "no perfection survives contact with real-world deployment" — look for the simplicity and robustness that allow a technology to SURVIVE the inevitable imperfections and quirks.
Once a yet-unproven technology you've picked this way remains interesting and promising after preliminary analysis, always start with a pilot project — large enough to put the technology through its paces, but not so large or crucial that utter failure of that project would doom your career, your company, or your client.
In your own opinion, what areas are more likely to face the greatest development in the next 10 years?
I predict (a rather easy prediction!) that the boom in software related to and relying on networking (including the Web and other distributed systems) will keep growing; the server-side of such systems will be more and more likely to be "in the cloud" (large, virtualized, distributed clusters of servers); on the client-side, desktops and laptops), while remaining part of the mix, will play a relatively diminishing role, in favor of an ever more varied mix of devices — smart phones, of course, but also game consoles, set-top boxes, e-book readers, tablets, intelligent tables and other furniture, "wearable computers", and no doubt some other new device that nobody's heard of yet.
Any advice for young IT students and graduates taking their first career steps?
There's always a difficult strategic decision to make in most professional careers (in IT or otherwise): go for "depth", becoming a super-expert in a tiny niche (with the risk that said niche may disappear from under you...), or go for "breadth", trying to reach useful but not super-specialized understanding of a variety of related technologies and fields (with the risk of being "jack of all trades, master of none"). The dilemma has been humorously summarized as: the super-specialist knows everything about "nothing" (meaning, an exceedingly narrow niche), the super-generalist knows "nothing" (a too shallow, superficial understanding) about everything.
I don't have a magic wand to guide such difficult career decisions, but my advice would be to try and strike an intermediate stance, with some bias in favor of being a generalist rather than a specialist, but with enough in-depth understanding to deal with Spolsky's "Law of Leaky Abstractions": "all abstractions leak", so if you only understand the surface abstraction, not any of the depth of the underlying implementation, you're doomed to disaster as soon as such a leak happens. E.g., if you develop web apps, it's fine to use high-level abstract tools and approaches, but make sure you understand in detail HTTP, DNS, TCP/IP, etc — all the layers on which your chosen "high-level" abstraction/technology rests... one day, the abstraction will leak, and your solid understanding of its implementation will stand you in good stead!
