Skip to content

Humility and Better Programming, Part 1

by Brian on May 29, 2013

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.

From → Programming

10 Comments Leave one →
  1. Every programmer should read Code Complete.

    And this little sentence beautifully portrays how I feel about programming too.

    “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.”

  2. Great post Brian, I envy you for having had the opportunity to work and learn from great minds. Thanks for sharing this and I am looking to reading the rest of the articles in this series.

  3. Reminds me of one of my favorite Brian Kernighan quotes about clever code and debugging:

    Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.

    • I use that Brian Kernighan quote often, the other related concept is the Software Peter Principle, where software becomes so complex even the developer doesn’t understand it.

Trackbacks and Pingbacks

  1. Humility and Better Programming, Part 2 | LabVIEW Field Journal
  2. Humility and Better Programming, Bibliography | LabVIEW Field Journal
  3. Humility and Better Programming, Bibliography | LabVIEW Field Journal
  4. Humility and Better Programming, Bibliography | LabVIEW Field Journal Archives
  5. Humility and Better Programming, Part 2 | LabVIEW Field Journal Archives
  6. Humility and Better Programming, Six Years Later - Stravaro, LLC

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.