Welcome to our continuing series of Code Project interviews in which we talk to developers about their backgrounds, projects, interests and pet peeves. In this installment we talk to Michael Dunn, longtime Code Project member, and four-time Code Project MVP.
Who are you?
I'm Michael Dunn. I live in Mountain View, in the famous Silicon Valley, just a few miles from the headquarters
of various companies like Google and Facebook. I work at VMware as a senior
engineer on the team that makes VMware Workstation,
Player, and Fusion.
If you've used full screen, multi-monitor, or unity modes in Workstation, then you're running my code.
What do you do?
I started in the industry in 1995 as a QA engineer at Symantec on the Norton AntiVirus team. I had learned C++ in college, but I didn't know
anything about Windows, so as part of the job, I got the chance to learn Win32 programming while writing automated
testing tools. After two years on the QA team, I was promoted to the dev team. The highest-profile work I did there
was to redesign the main UI for NAV 2000.
The other company I've worked for whose name you'd recognize is Napster.
The legal version. I actually joined the company a few months before the company was called Napster. When the company
was sold and renamed, we redesigned the UI of our standalone client app and our Windows Player plug-in, and I led
the redesign work. I also wrote the code that talked to portable devices (MP3 players, phones, etc.).
What is your development environment?
At work, I have a beefy Dell box with three monitors, though normally I only use two of them. I own some features
that are made for multiple-monitor situations, so that's why I have so many. Our dev machines tend to have a lot
of RAM, since we need the ability to run several VMs at once. Mine has 12 GB and runs 64-bit Windows 7.
Since my team has Windows, Linux, and Mac developers, there isn't a standard environment. A few of us, including
me, use Visual Studio. I use version 2008, for a few reasons: We don't use C++11, 2010 doesn't really look that
nice, and 2010 couldn't handle our large code base when I tried it few months ago. VMware uses Perforce
for source control, and some of the people who like git use a git mirror. For
code reviews, we use the most awesome Review Board.
My hardware at home isn't nearly as advanced. The amount of free-time "fun" programming I do has dropped
off lately, so I haven't felt a pressing need to upgrade. I'm using a 5-year-old Alienware laptop that's still
chugging along, though the battery is shot. I also use a Drobo
for backing up my photos, source code, and other important stuff.
It should be no surprise that my favorite framework is WTL. It's just a perfect fit for me. It's enough of a
framework to hide the grunt work, but not so abstract that it's completely different from the underlying Win32
layer. I've gotten more exposure to STL at VMware and through Stephan T. Lavavej's great
series
of videos, and the more I see of it, the more I appreciate how much work went into its design.
Almost all of my work has been in C++. I've dabbled a bit in JavaScript when necessary, and I picked up Perl
on my own since it's great for text processing when I need to do that. But most of the time, I like doing geeky
UI stuff in C++.
What new tools, languages or frameworks interest you?
C++11 looks really nice, though I won't get to use it for
real work in the near future. Having to share one code base among three platforms, each with their own compilers,
makes major upgrades a bit of a pain.
I've been writing lately about the
Ribbon, and I've even played around a bit with the animation
engine. I really like how Microsoft has designed its COM-based features recently. I remember having to integrate
the Task Scheduler into NAV when I was
on that team, and it seemed super-complicated and hard to use. But the Ribbon, the animation engine, and the Windows
7 Taskbar features have really good samples, and they're straightforward enough that I was able to grasp the basics
of each feature after a day of reading the docs and sample code.
What is your coding pet peeve?
You don't know how true the saying "You should code like the maintenance programmer is an axe murderer who
knows where you live" is until you've had to make changes to code written by someone who's never heard it.
Sensible variable names, well-written comments, and clear logic make life so much easier. The lack of any of those
things makes my job harder and makes me want to buy an axe.
I'm an ardent supporter of Hungarian, and it's a shame that people dismiss it without understanding how to use
it to gain the benefit that it was designed to give. See "What's
Up With Hungarian Notation?" by Eric Lippert and "Making
Wrong Code Look Wrong" by Joel Spolsky for longer, better-written arguments in favor of Hungarian.
As for indenting style, the only thing that really irks me is when matching elements don't line up. The "if
(xyz) {" style makes me very sad. Not only does that make it harder to scan through code and find a
matching brace, it reduces the whitespace under the if (or while, or whatever), and ends
up squishing code together, which also hurts readability.
How did you get started programming?
I had some exposure to computers from an early age, thanks to my uncle who let me use some of his old hardware
when he upgraded his. I wasn't doing any programming on them, though I would occasionally type in a program from
a book or magazine.
The first computer I truly programmed on was an Apple //e when I was in 4th or 5th grade. The school
library had a few computers, and the librarian taught an after-school class on BASIC. The first program I can recall
writing, aside from class assignments, was a simple "welcome to Open
House" animation using the line-drawing commands in Apple BASIC.
The first computer of my own that I used extensively was a Commodore
64. I read a ton of books back then, and I regularly got magazines like Compute!,
Compute!'s Gazette, and Run.
But the 64's BASIC was pretty limited, so I did a lot more reading that writing. Plus, the 64 was so good at games
that I got a bit distracted. :) Later on, I got a 128,
and its BASIC was good enough that I started writing serious programs. The most complicated program I wrote was
an equation grapher, which used a self-modifying trick to let me enter an equation at runtime.
I took a class on C and C++ in college, and that's when it finally clicked that hey, this is something I like
enough, and I'm good enough at, that I could make a career out of it.
What do you love / hate about the developer community?
I love being able to help other folks who are just starting out. That's one of the reasons I started writing articles,
actually. There were no online resources when I was learning Windows, so when I was stuck on something, I had to
either figure it out on my own, or hope that someone on my team could help. It's great that CodeProject's authors,
as well as other Q&A sites, have built up such a huge amount of knowledge. I ran into an old colleague at the
Build conference who said that he knew several developers who used WTL,
and that they all got started by reading my series of articles. (Yay ego boost!)
There are some awesome bloggers out there, mostly notably Raymond
Chen, who also have a ton of knowledge, and take the time to share it. They nicely counter the rah-rah talk
that I usually hear out of Microsoft whenever they announce something new, which is of course 100 times
better than the thing they released two years ago and are now dumping.
I don't really hate anything about the community. I've only had a couple of bad experiences on the CodeProject
boards. Then again, I don't get wrapped up in trolls and flames to begin with.
Where do you see yourself in 10 years?
I honestly have no idea. I will likely be one of these three things: a programmer, a photographer, or a pro pinball
player. The probability of each one happening changes over time.
If you had one piece of advice for an up-and-coming programmer?
I'm going to blatantly ignore the "one piece" part. :)
- See above about not crossing axe murderers.
- Programming, and the mental skills that go with it, take practice. Write code to improve your understanding
of a certain area. Write code to solve a problem and improve your problem-solving skills.
- I highly recommend the book Writing Solid Code, which contains a ton of info and good practices on ways
to write code so that bugs are found as soon as possible.
- Develop your written language skills, say, by writing articles for CodeProject. When you're working with people
far away from you, or writing comments that future programmers will rely on, good, clear writing is essential.
- If you're a native English speaker, you absolutely must study another language. While people often say
that English is hard, its grammar is actually far less complex than Romance or other Germanic languages. Studying
other languages teaches you about rules that don't exist in English, but are quite common in other languages, such
as noun-adjective agreement. If you don't know about things that other languages do, that can be a big hurdle when
it comes to writing code that will run correctly in other locales. It's too easy to write code that assumes English
grammar rules, without realizing that your output will be totally wrong in other languages.
