Eric Sink is nothing short of a programming evangelist. From his early work at Spyglass where he worked on the original versions of the browser now known as Internet Explorer, to designing the AbiWord project, the free word processing program, through to his founding of SourceGear (one of the fastest growing companies in the US), he continues to develop solutions to problems that lie outside obvious commercial software.

If he isn’t known through SourceGear’s products such as Vault, a control tool which uses SQL Server 2000 for all repository storage, and Fortress which is built on the version control features of Vault but features bug-tracking, he is certainly known for his blog which became the best-selling book Eric Sink on the Business of Software. The book is a collection of essays which originally appeared on the MSDN website from October 2003 to April 2005 – looking at anything from software development, marketing for geeks, to an article on small studios which introduced the term micro-ISV. Eric is also known for his spoof of a Microsoft ad campaign featuring “software legends”, which is embedded in the site.

A software programmer by profession, he has a B.S. in Computer Science from the University of Illinois and lives not far from the campus in Champaign.

RM:

How did you become a programmer?

ES:

My first computer was a Commodore Vic-20. It had 5K of RAM. Back then, you couldn’t do much with a computer besides write programs for it. Nowadays kids want computers so they can access Facebook. I used my computer to learn 6502 assembly. A little bit later I scrounged up enough money to upgrade to a Commodore 64. So then in addition to programming I could also play Zork – one of the first interactive fiction computer games and an early descendant of Colossal Cave Adventure.

RM:

Do you remember the first interesting program that you wrote?

ES:

I suppose that depends on how you define “interesting”. I’d have to say my first interesting program was an implementation of sprites for that Vic-20. I actually sold it to a magazine in the form of an article. I think I got a couple hundred bucks for it, which was a lot of money for somebody not yet old enough to get a driver’s license. The first really substantial piece of software I wrote was a C compiler. It was just a hobby project I wrote in my early twenties, and I never earned a dime from it. But it was great experience. I got it to the point where it could self-compile.

RM:

You were at Spyglass for five years where you led the group that developed the Web browser later to become known as Internet Explorer. Was it all new code when you began? Did you start with an empty desk and start typing? Did you spend a lot of time talking about what features the browser would have?

ES:

Yeah, it was all new code. We had a license for the Mosaic code from NCSA, but we considered it a prototype. We needed an implementation that was faster, more robust, and more cross-platform. Initially, the project was a sprint. I was given just a few weeks to come up with something we could demonstrate to a prospective customer, so we didn’t do much planning or talking up front. As the project team grew, stuff got a bit more organized.

RM:

If you were doing something on that scale again, would you start with a few paragraphs of text and a list of features? Is that the finest granularity you would get to before you start writing code?

ES:

I prefer some amount of Big Design Up Front (BDUF). I’m not the type that wants to spend months getting every detail worked out so I only have to code it once. Thinking carefully about the architecture before I start gives me a lot of information about the problem. The rest of the information I get from my first implementation, which I usually throw away and replace with The Good One.

RM:

What about length and intensity? I’m sure you’ve done the 80, 100 and 120 hour weeks. Under what circumstances is that really necessary or is it just a macho thing to do?

ES:

I worked some very long hours in the early days of the Spyglass browser. I’m not sure I would describe these situations as necessary or macho. They just sometimes happen. Every once in a while, the conditions are right for both programmer and employer to really get immersed in a project. Trying to force those conditions is an exercise in futility. And trying to work that way constantly is absurd, like trying to sprint an entire marathon.

RM:

Other than having millions of people using your software what is it about programming that you most enjoy?

ES:

I think one of my favourite parts of programming is taking a piece of code and finding ways to make it faster.

RM:

What languages would you say you’ve really lived and breathed with enough to claim as your own?

ES:

I suppose C is the language closest to my heart. Writing a C compiler in C will do that to a person. I’ve spent quite a lot of time writing C#, and I really like it. In the realm of scripting languages, I am quite fond of Python and Javascript. There are other languages that are interesting and nice, but those four have been the critical part of my toolbox. That said, I see a lot of language and compiler innovation happening, and that makes me happy. New ideas in those areas have always held great interest for me. What Google is doing with Go is certainly very cool, for example. I’m excited about Clang. I’d be even more excited if they would implement some extensions for supporting function contracts in C.

RM:

Does it matter much to you what language you use?

ES:

Definitely. The tradeoffs between different languages are enormous. For example, my pace of development is 2-3 times faster with C# than with C, but I’m using C for my current project because the CLR runtime limits our deployment options. Coding in C is tedious, but the results offer some advantages that just aren’t available with higher level languages.

RM:

Do you like C++?

ES:

No. My feelings toward C++ are something closer to hatred. I wasn’t always this way. I actually kind of liked C++ back before it had templates and exceptions and references and copy constructors. The original concept of a better C was a great idea. I think the language just lost its way, and now it’s a complete mess.

RM:

Do you find code beautiful? Is there an aesthetic beyond maintainability?

ES:

Code can be beautiful, but beyond the basic professional standards like readability, efficiency, and quality, I don’t think aesthetics are a big priority for me. In fact, I observe that some of the most successful pieces of code in the world are not noted for their beauty. This is to be expected. By the same a body of code gets all the bug fixes and special situations handled, it’s not likely to be pretty enough to get asked out much on the weekends.

RM:

You’re well known as the author of Eric Sink on the Business of Software. Do you find that programming and writing are similar intellectual processes?

ES:

Not really. Programming is an exercise in manipulating complex abstractions to solve a problem. Writing is a form of communication aimed at other human beings. I can get immersed in the challenges of either one, but they definitely feel different.

RM:

SourceGear has received a lot of plaudits since it was formed in 1997, including being listed as one of the 500 fastest-growing private companies in America. Next year will be the firm’s 15th birthday; what keeps the business interesting for you and did you have a plan when you started to be leading the company this number of years later? Are there many more things to do? What would you like to achieve?

ES:

When I started this company, all I really wanted was to create a place where I liked to work. It sort of grew from there. I don’t really have specific aspirations at this point, except to continue building software that people like to use. I’ve found that if users like my software and my co-workers like their jobs, then everything else works out.

RM:

What do you think the impact will be now that Vault users can easily source control their SQL Server?

ES:

It could be very significant. These features have been requested by Vault users for a long time. Red Gate is right partner for us on this issue, and I’m glad it’s happening.

RM:

Just out of curiosity, what makes Red Gate better than any other partner?

ES:

In our market segments, Red Gate is the dominant player in tools for SQL developers. We’ve had a number of interactions with the company and its principals over the years, all positive. It’s a good company.

RM:

At SourceGear do you divide things up so people own different parts of the software? Some people say that’s important. Others say it’s better for a team to collectively own all the data. Do you have an opinion on that?

ES:

I think having collective ownership of the code is a good ideal, and worth some effort to pursue. But it’s much easier to just have a primary owner for each major piece of the code. We resist this as much as we can, but true collective ownership would be a huge change in the way we do things. Pursuing this ideal would probably force us to give up on other things we believe are also very important. Just like economics, software development is an optimization problem.

RM:

Are there particular computer-science or programming books that everyone should read? Have you read Don Knuth’s The Art of Computer Programming? Lots of computer-science theory is based on maths of course, how much maths or that kind of problem solving is necessary to be a good programmer?

ES:

Have I read Knuth? Yes, but certainly not all of it. I am a great admirer of the man and his work. I haven’t found real math to be all that useful. When I was in college the engineering majors had to take 3 semesters of calculus and then a thing or two beyond that. The math majors used to say that real math doesn’t start until you finish calculus and start differential equations. In my experience as a software developer, I’ve never found much need to apply anything beyond first semester calculus and linear algebra. Perhaps that’s just the nature of the problem domain in which I have been working.

RM:

Do you think the kind of people who can be good at programming has changed?

ES:

Yes. Programming has always been something that is very hard to learn for those who lack a natural aptitude or a passion for it. It’s not like some other careers like law. I’m not saying just anybody can be a lawyer, but the process of becoming an attorney does look different to me. Many programmers were software hobbyists before they were professionals. Nobody practices law as a hobby. The real change that has happened is around the notion of software development as a hobby, especially with young people. It’s so different from when I was their age, writing spreadsheets in BASIC and graphics code in 6502 assembler.

RM:

A few of the people I’ve interviewed such as L Peter Duetsch and Don Knuth compose and play music and you’re something of a musician. Is there a link between music and technology do you think such as source code versus music notation?

ES:

I think any linkage between music and programming is rather subtle. I love to make music specifically because it is different from making software. It uses different parts of my brain. It is an activity in which my emotions are fully engaged, whereas coding is not. An awful lot of programmers are also musicians. People have observed this and proceeded to wonder if music and code are similar. Maybe they are, but I tend to think all those programmers are looking for balance.