While speaking at a conference in Minneapolis earlier this week, I had the opportunity to sit on a speaker panel. Normally, from the panelist's point of view, these are fascinating things, but after having done literally hundreds of them, I admit I'm a little bit jaded. They tend to be the same questions over and over again, to which offering up the same answers over and over again just… well, it tends to grate after a while.
However, this past panel was a bit different, largely because an attendee came up with a question that, while it shouldn't have been new in any way, was. Or maybe it was that this was a question that hadn't been asked in a while. Or perhaps it was simply that he asked it with a different inflection than I had heard before. Regardless, it threw me into a few moments of deep contemplation before I could respond.
That question, as you may have already inferred from the title of this column, was thus: “I'm a new programmer, having moved over after 20 years as a systems guy. What do you wish somebody had taught you back when you were new?”
While I was thinking about my answer, several of the other panelists responded with some very good answers, which deserve repetition for that reason.
Testing
Within the last decade, ever since Erich Gamma and Kent Beck wrote the seminal article on the subject, “Test Infected”, testing by programmers has become not only fashionable, but considered to be a core responsibility. Wrapped up at first as part of the “Agile” movement, unit-testing has now moved squarely into the collection of “mainstream” developer topics-much like object-oriented was two decades ago, whether developers are using it or not, they've at least heard about it. More importantly, developers increasingly find themselves required to justify not using it, instead of the other way around.
Dynamic Languages
The “rise” of dynamic languages-languages like Python, Ruby, or ECMAScript/JavaScript, often disparagingly and colloquially referred to as “scripting” languages-marked an important realization to the mainstream development community: that not all code really “fits” into the traditional statically typed, compiled-ahead-of-time language mindset. In fact, the productivity enhancements seen by Ruby-on-Rails in turn led to some shifts in how .NET developers looked at building web applications, moving from their traditional drag-and-drop WebForms-based style into a more testable and (to many) understandable format.
In fact, the dynamic language meme created directly observable change at Microsoft, including the creation of a new shell environment (PowerShell), the development of not one but two dynamic language environments on top of the CLR (IronPython and IronRuby), as well as a framework/engine for a variety of different dynamic languages (the DLR) that later got folded into the C# programming language as part of Visual Studio 2010.
Pairing
As a mechanism for brainstorming and producing creative ideas, authors, musicians, and artists have long known that pairing-or any other form of small-group collective collaboration-works phenomenally well. But for years, programming resisted the idea of “two programmers, one machine” on the grounds that it meant that code emerges half as fast as having each programmer hacking away on a machine of their own. Couple that with the inevitable arguments that: “I need my own machine to handle certain things” (like email and the inevitable browsing of web pages that have nothing to do with work), or: "You can't really expect me to sit next to somebody else all day, can you?", and pair programming seemed dead in the water.
And yet, when programmers actually practice pairing for a non-trivial amount of time, they quickly discover that pairing is nothing like they imagined it to be. In fact, when I talk to developers who initially resist pairing, and then give it a shot, the reactions that emerge are overwhelmingly positive-as Ward Cunningham once put it during an interview I had the opportunity to do with him, “Having somebody listen to you, as a programmer, is huge.”
Quality Is Fast
It's at the heart of the Agile Manifesto, and at the heart of several other approaches beyond that, but it seems to be a lesson that developers have to learn individually and only over time: building applications “the right way” (whatever way that is) to produce a quality application is actually faster than producing an application quickly, then spending just as much time (or more) fixing the inevitable bugs and architectural changes that appear.
This, of course, has fascinating implications about building prototypes or proofs-of-concept kinds of applications, since the whole point of those clearly differs from that of a “production” application, yet too often developers are asked (by which I really mean “ordered”) to put those into production. But even allowing for those clearly mismanaged situations, it becomes fairly clear after studying the analyses and statistics that “building it right” trumps “building it fast” in almost every situation.
One Rule to Program By
For me, however, all of these answers paled in comparison to a lesson I'd had the privilege to learn the easy way. At my first professional programming job working for a startup company named Tangible Vision, I met Hussein Dalmouti, VP of Development, who taught me what I think is the most important lesson a programmer can learn-that of “egoless programming”.
Wikipedia defines “egoless programming” as “a style of computer programming in which personal factors are minimized so that quality may be improved.” A popular topic among programming classes during the 80s, it more or less completely disappeared as a topic of discussion by the 90s, and today lies all but forgotten. In fact, several people came up to me after the panel asking about, even as several “grizzled veteran” programmers remarked that they were shocked the topic even needed to be mentioned. Clearly, a nerve had been struck.
Egoless programming's roots lie in the book, “The Psychology of Computer Programming” by Jerry Weinburg, 1971. Weinburg describes a style of development environment relying heavily on peer reviews. He coined the phrase to describe programmers who had worked within this environment for some significant period of time. And at its heart, his philosophy-that code improved when multiple pairs of eyeballs are looking at it and either implicitly or explicitly judging it-sounds eerily familiar to developers familiar with Agile principles and specifically that of pairing.
But egoless programming means more than just putting your code in front of somebody else's eyeballs for judgment. Over 30 years later, Lamont Adams wrote an article for techrepublic.com in which he laid out “Ten Commandments for Egoless Programming”:
Understand and accept that you will make mistakes. The point is to find them early, before they make it into production. Fortunately, except for the few of us developing rocket guidance software at JPL, mistakes are rarely fatal in our industry, so we can, and should, learn, laugh, and move on.
You are not your code. Remember that the entire point of a review is to find problems, and problems will be found. Don't take it personally when one is uncovered.
No matter how much “karate” you know, someone else will always know more. Such an individual can teach you some new moves if you ask. Seek and accept input from others, especially when you think it's not needed.
Don't rewrite code without consultation. There's a fine line between “fixing code” and “rewriting code.” Know the difference, and pursue stylistic changes within the framework of a code review, not as a lone enforcer.
Treat people who know less than you with respect, deference, and patience. Nontechnical people who deal with developers on a regular basis almost universally hold the opinion that we are prima donnas at best and crybabies at worst. Don't reinforce this stereotype with anger and impatience.
The only constant in the world is change. Be open to it and accept it with a smile. Look at each change to your requirements, platform, or tool as a new challenge, not as some serious inconvenience to be fought.
The only true authority stems from knowledge, not from position. Knowledge engenders authority, and authority engenders respect-so if you want respect in an egoless environment, cultivate knowledge.
Fight for what you believe, but gracefully accept defeat. Understand that sometimes your ideas will be overruled. Even if you do turn out to be right, don't take revenge or say, “I told you so” more than a few times at most, and don't make your dearly departed idea a martyr or rallying cry.
Don't be "the guy in the room." Don't be the guy coding in the dark office emerging only to buy cola. The guy in the room is out of touch, out of sight, and out of control and has no place in an open, collaborative environment.
Critique code instead of people-be kind to the coder, not to the code. As much as possible, make all of your comments positive and oriented to improving the code. Relate comments to local standards, program specs, increased performance, etc.
Even more important than just writing code, adherents to these 10 commandments will find themselves not only learning more, but gathering the respect and admiration of their peers at a shockingly accelerated rate. In fact, just about every programming career sin I can rattle off is a violation of one of the above dictates.
Think about it-of all the “jerkwad” developers you've ever known over time, how did they get that reputation? What did they do to earn it? The architect who insists that the only way to obtain any sort of effective interoperability between platforms is WS-* clearly stands accused of violating #7. The consultant who stands in front of management and says “I don't know what idiot wrote this code, but he should be fired” pretty obviously doesn't get #10. The 30-year-employee who refuses to learn any new programming language because “COBOL works” egregiously sins against #6. And who hasn't been on a project where working code suddenly becomes less working because one of the developers “didn't like the way the code looked” and rewrote it all overnight, without asking anybody else's opinion, on the grounds that “now it's more understandable”?
Be Egoless
However, of all of these, by far the most important principle to understand is that of the first: “You are not your code.” This is a lesson I wish every developer would be forced to learn before ever being allowed to launch a compiler or interpreter, because everything else stems from that basic realization.
Let's be honest: many developers got started writing code because they found social interaction painful and uncomfortable. Not uncommonly, these teenagers found solace in the quiet and solitude of writing code: they could feel good about themselves, and express themselves, through technology.
Then, as they moved out into the workplace, they discovered that knowledge of that technology translated into direct value to customers or employers-and suddenly, they were valued. Not necessarily because of themselves, but because of what they could do. Though unintentional, the young programmer receives confirmation that they are only valued for the code that they write: their code is an extension of themselves, logically at the core of their sense of self-worth.
It sounds ridiculous to say it. And yet, anecdotally, how many developers do you know who get unreasonably angry when “their” code is criticized?
This was what Hussein taught me: that when somebody turns to you and says, “I think I've found a bug in your code,” that the right response is to say, “Oh, that's wonderful. Where is it?” That when somebody says, “I think I have a better way of handling this particular situation,” the right response is to say, “Excellent! Show me your ideas.” And that when somebody says, “I still don't understand how this thing works,” the right response should be, “OK, tell me what part doesn't make sense and let's go over it again.” Even when that developer is a not-yet-graduated barely-21-year-old with zero years of professional experience under their belt. Even when you're a seasoned professional with over a dozen years' programming on your resume.
Wrap-up
My term of employment with Tangible Vision didn't last long-my wife and child were still in California, and I grew depressed and my work suffered. They cut me loose after a few months. Tangible Vision as a company no longer exists-I lost contact with them shortly after moving back to California and finishing up school. But the lessons I learned there, even for the short time I was there, stuck with me.
Not everybody gets the chance to work with a Hussein Dalmouti. I wish they could-it made all the difference in the world to me. But if you take those 10 Commandments to heart, you can make a difference not only to the other developers around you, but to yourself, as you become the kind of programmer that others want to work with.
Thank you, Hussein.
