Humility and Better Programming, Part 1

I am not a particularly clever programmer.  Or at least, I try not to be.  I like simple code because frankly, I’m not really smart enough to understand code that looks like spaghetti.

A little over 25 years ago, I started working at National Instruments as an entry-level software engineer.  I received an outstanding education as a computer scientist from the University of Texas at Austin, where I was able to interact with some of the greatest minds of the Computer Sciences… Woody Bledsoe, Edsger W. Dijkstra, C.A.R. Hoare, to name a few.  Besides learning from great teachers, I learned how to become a better teacher.  Teaching a really difficult subject (assembly language, in my case) for several semesters to college sophomores will make you a better teacher, and will make you a master of the subject as you explain concepts a dozen different ways to try to get it across.

Soon after starting at NI, it became clear to me that one of the shortcomings of my formal university education was that I didn’t have much experience writing code.

Wait.  What?  You got a degree in computer science and don’t know how to program?

I didn’t quite say that.  Sure, I knew algorithms, data structures, operating system concepts, and I was immersed in the field of artificial intelligence, especially automated theorem proving.  I could write small- to medium-sized programs in a variety of different programming languages.  What I didn’t learn in the classroom was how to be a professional programmer who could write large, robust, maintainable programs.  It just wasn’t needed in our assignments—the lifetime of a class programming project was at most a semester, and group programming projects were pretty rare.

I learned to program outside the classroom.  I was active in the open source community before we called it the open source community.  I collaborated on several projects, mostly irrelevant now, but which were important to the greater community at the time.  I was collaborating with people I would never meet, but who shared a common goal of writing useful programs for problems we all shared.  And guess what?  It encouraged us to write robust, maintainable code.  If you didn’t, you were (nicely) called out on it—often by having someone else document your code for you, or sometimes rewrite it in a better way.  The better the code, the more likely someone would add to it—new features, better performance—whatever was needed.

The other place I learned to program was on the job in the LabVIEW R&D team.  I had the best mentors.  Steve Rogers and Rob Dye really stand out.  They are both software architects still on the development team.  Part of the culture in LabVIEW R&D is to have some humility when it comes to the code.  While you might be responsible for a section of code, you don’t “own” it.  Steve says that the only person who can rightfully “own” code in LabVIEW is Jeff K.

The LabVIEW source code is communal—anybody (on the team) can touch any part they need to.  If I need to change how a function is called, then it’s my responsibility to update every place that it’s called, wherever that code is.  (Or come up with a way for callers to be fixed automatically.)  Territorialism (“stay out of my code”) is not tolerated.

This turns out to be a really good approach to software engineering, and I want to use a couple of blog posts to explain why.

My team is a fan of the book Code Complete, by Steve McConnell.  I first read this back in the mid-1990’s, as we were growing our development team and growing our processes to match.  I was recently rereading part of it, and ran across a chapter on “Personal Character”.  One of the key points of this chapter…

“Your personal character directly affects your ability to write computer programs.”

In part 2, I’ll dive a bit deeper on why I think this is true, and share some ideas from my experience that will help you become a stronger programmer.