Fog Creek – Interview with Eric Lippert

In, we chat with developers about their passion for programming: how they got into it, what they like to work on and how.

Today’s guest is Eric Lippert, Software Architect at Coverity. He was previously Principal Developer at Microsoft on the C# compiler team, on the C# language design team as well was on the ECMA committee, standardizing JavaScript.

He’s the author of several programming books, including ‘Essential C#‘ and the ‘Visual Basic .NET Code Security Handbook‘. He writes about programming on his blog and often helps out developers on StackOverflow.

Eric Lippert
Location: Seattle, US
Current Role: Software Architect at Coverity

How did you get into software development?

When I was six or seven years old my school library got a couple of Commodore PETs. There was a special school edition of the PET that came with a Waterloo BASIC chip, and we had some stock PETs as well.

At first I just stayed late after school playing Dam Buster, but soon I realized that I could write programs for this thing myself. I got a book, which I still own, Practice Your BASIC. I keep it in my office just in case I need to practice my BASIC. I would write programs at home on graph paper, and then type them in after school and see if they worked. Mostly it was making rocket ships fly around the screen. My elementary school librarian was very supportive in letting me stay late and getting me books about programming and mathematics; I contacted her on LinkedIn recently and we had a lovely conversation about the old days.

When I was ten I found my first bug in someone else’s program; my sixth grade teacher had a math flash card program that would sometimes give the wrong answers and he asked me if I could have a look at it. I was not a very sophisticated programmer at this point, and I didn’t understand the program, but I realized that I did not need to understand it, I just needed to find the mistake, so I read every line of the program and thought about whether it made sense in isolation. I don’t remember the exact text of the bug, but it was something akin to:

  • 1230 IF X > 10 THEN PRINT (X – 10) * Z
  • 1240 IF Y > 10 THEN PRINT (X – 10) * Z

And that second line struck me as being wrong. As someone who spots bugs for a living now, I would note that the consequence following the THEN seems to be uncorrelated with the condition following the IF. In a more modern programming environment I would put this down to a copy-paste error where someone copied the first line, pasted it, intended to change all the X’s to Y’s, but got distracted after the first one. (Of course it is unlikely that the author of this program was using an editor that had copy-paste in 1982. They were just distracted when writing the code.)

Incidentally, Coverity’s static analyzer finds copy-paste bugs like this and some of them that we’ve seen in real, live customer code have been quite severe. When you copy-paste a line like this where it is dollars and euros instead of x and y and then inconsistently change some of the dollars to euros, you can create an extremely expensive bug!

But I digress. The Commodore 64 was released that year and I think I got one in 1983 or thereabouts — thanks, Mom, that investment paid off — and started hacking away at it. The program I was most proud of was a database to keep track of my book collection, which tells you something about my priorities when I was eleven. The part that I thought was super slick was that I wrote a little window manager using the box-drawing characters that would animate expanding and contracting the windows when a new screen was opened or closed.

We would occasionally go on field trips to a building that the school board had set up with a computer lab, and learn about LOGO, but I did not have any other formal training in programming until I was in high school, so I was mostly self-taught. While in high school I did a summer internship program at WATCOM, then justly famous for their compilers and databases, where they taught me C programming, how to use a debugger, how to build a finite state machine, and so on. I later worked at WATCOM while I was taking my degree as well, which was very convenient as they were across the street from the University of Waterloo. (And still are, though the company is now part of Sybase.)

I took my degree in both Applied Mathematics and Computer Science at Waterloo, though of course Computer Science and Computer Programming are rather different.

damBuster (1)

Tell us a little about your current role

I am a software architect specializing in the analysis of C# code at Coverity, which is now a division of Synopsys.

Coverity makes software which analyzes its customers’ software looking for critical bugs, missing test cases, that sort of thing. We have analyzers that look for defects in C, C++, Java and C# code; right now I’m working on getting the “checkers” — the analysis algorithms — that look for things like Cross-Site Scripting and Cross-Site Request Forgery and such in Java web applications working in ASP.NET web applications. This is probably the most frequent request we get from our customers who use a lot of C#, so I’m excited to get it up and running.

A typical day involves a lot of different things. There are all the project management tasks — reviewing bug reports and test cases and code, making sure we’re on schedule, that sort of thing. There are technical tasks — I don’t write a lot of code in my day-to-day work, but I still try to take some of the coding tasks on myself. There’s a lot of mentoring; most of my coworkers are experts in writing C++ for Unix, not writing C# for Windows, and so I often have to explain how ‘The Microsoft Way Of Thinking’ differs from what they’re used to. And there’s a lot of just straight up research; I haven’t actually worked on ASP.NET directly since before it was ASP.NET, and a lot has changed since then! My knowledge of C# has historically been narrow, and so I am learning a lot every day.

My extracurricular technical activities right now are first, Mark and I are getting the C# 6.0 edition of Essential C# ready for publication, and second, I am working on a series of educational videos for O’Reilly. We’ve just posted the first set on the web and I’m hard at work on the next course now.

When are you at your happiest whilst coding?

There’s a quote that’s sometimes attributed to Dijkstra to the effect that many developers derive pleasure from removing bugs that they should not have created in the first place. I’ve never really understood this as a source of pleasure. I am least happy while debugging, and therefore I try to structure my code to first, make it correct the first time, and second, to make it as easy as possible to debug on the reasonable assumption that I did not actually make it bug-free. I assume that it is going to be at least twice as hard to understand the code in the debugger as it was to write it, so I try to write it using half my available cleverness.

The kinds of problems that I really enjoy coding-up are those where first, I have a clear specification of the problem, and second, I can solve the problem by creating subsystems that solve simpler problems and then fortifying the heck out of those subsystems. Working on the Roslyn project — where we re-wrote the C# and VB compilers from scratch in C# and VB — was my dream job. The specification was excellent, and we started with a blank page, so we had to come up with all the subsystems that were robust enough to compose to solve our big problems.

procMon (1)

What is your dev environment?

Coverity comes from a Unix background, so it’s a very UNIX-like development environment by default. I am unusual here in that I use my Windows machine for most of my development; I use Cygwin to interface with the UNIX-based development environment. Most of my coworkers just use Ubuntu for the day-to-day development and only use Windows for testing.

Of course, when I am working on the C#-based portions of the product, I use Visual Studio 2013 like a sensible person.

A tool that I use surprisingly often that I think is maybe not in too many developer toolboxes is ProcMon. All the time I want to know “where exactly is that temporary file?” or “did we get that key out of the 32 bit registry hive or the 64 bit hive?” and so on.

If I am “in the zone” coding I like to listen to music; my tastes are pretty eclectic. I’ve got Stacey Kent on right now; on a given day I might listen to everything from the Glenn Gould recording of the Goldberg Variations (the first one of course), to Diana Krall, Philip Glass, Daft Punk, Pink Floyd, Sondheim musicals, whatever, depending on my mood.

Probably my biggest quirk as far as coding goes is that if I am not using Visual Studio, I use a copy of WATCOM VI from the early 1990s as my editor. It is so thoroughly in my fingers now that, even though, there are better versions of VI out there, I’m stuck with it.

What are your favorite books about development?

I see that you interviewed Jared already — in fact, he now basically has the job that I had when I was at Microsoft — so it is not surprising that he already mentioned two of my favourite books. Leaving those aside, the book that I consult most often is, of course, The C# Programming Language, which I encourage everyone to get for the entertaining annotations that we’ve added to the specification.

I edit technical books as a hobby, so my take on “favorite books” includes those I’ve edited. Jon Skeet‘s book, ‘C# In Depth‘ is probably my favorite of all the books I’ve edited, mostly because Jon makes it so difficult to find his mistakes by virtue of not making any. People often ask me for book recommendations and I always tell them that “C# In Depth” and “Essential C#” are my favorites because they are so well-named; “C# In Depth” really does go into depth, and “Essential C#” gives you all the essentials you need.

programmingLanguage (1)

What technologies are you currently trying out?

I actually had dinner with Jon yesterday and we were chatting quite a bit about Docker, which I have no experience with. I love the idea of having some way of doing isolation of large software components without all the overhead of a full-on virtual machine, so hopefully I’ll find some time to learn more about it.

I’ve also been totally avoiding the entire world of “all-in-the-cloud” service-oriented architectures while I’ve been heads-down in the world of semantic analysis of code; this really is the future and I know shockingly little about it.

When not coding, what do you like to do?

Ricky Jay has a line in The Spanish Prisoner where he says that when your hobbies interfere with your work, that’s great, but when they interfere with each other, you’ve got a big problem. Boy, do I know all about that.

Amongst my many hobbies are:

  • writing and editing books and videos about C#
  • blogging; I have taken a break from my blog due to too many other projects interfering with each other, but I’ll get back into it soon
  • sailing tiny high-performance sailboats at high speed; I recently acquired a 1976 Hobie 16 at my father’s place in Canada and I have a Bieker 2 International 14 here in Seattle.
  • fixing up my 108-year-old house
  • woodworking; I’m interested in learning how to build cabinetry and other furniture
  • I’ve built myself a backyard foundry so that I can cast metal; I’d like to learn how to make tools
  • playing the piano, mostly jazz and show tunes
  • teaching ukulele
  • answering questions on StackOverflow

And there’s probably a few more in there that I’ve missed. I like to keep busy.

sailing (1)

What advice would you give to a younger version of yourself starting out in development?

If I could go back in time and give my younger self advice, it would be to buckle down and learn Commodore 64 assembler. I was always intimidated by assembly language, and to this day my ability to read machine code is weak.

If asked to give advice to young people starting in computer programming today, it would be to learn how to write non-code documents clearly. Good developers will quickly reach a point where just writing correct code is not enough; they’ve got to teach others how to use it, or convince them that the change is correct. Communication is key.

I’ve often said that among the best advice I got when I was a young programmer is to pick a relatively narrow topic, find as many real-world user questions about it as possible, and write clear, accurate, cogent answers to those questions. Soon you will be a recognized expert on that topic, you’ll learn a lot, and you’ll be able to communicate clearly with your co-workers.

Thanks to Eric for taking the time to speak with us. Have someone you’d like to be a guest? Let us know @FogCreek.

Recent Interviews

Hakim El Hattab
Phil Sturgeon
Leah Culver
Peteris Krumins
Peteris Krumins