Redefining Professionalism for Software Engineers (ArsDigita Systems Journal)

Redefining Professionalism for Software Engineers

by Philip Greenspun (philg@mit.edu)

ArsDigita : ArsDigita Systems Journal : One article

Here is an email message regarding the ArsDigita Oracle Driver:
... the following highly unprofessional comment in the original
source code: 
   /* how the fuck were we supposed to know it was a dml?
      Anyway, it is a DML statement, so we retry with 1 iteration */

Should public domain source have this kind of language in it?  Is it
a good reflection on AD?
Should one judge the author of this code, Cotton Seed, unprofessional because of his colorful source code (never visible to an end-user)? Or does he get credit for having made an honest effort to write a high-quality, useful piece of software and then giving it away for free, with source code so that others can build on his work?" And then further credit for calling attention to a potentially important issue with words that are unlikely to be overlooked?
In another ArsDigita example, when the company was young, we decided to let readers self-select the most appropriate content right from our home page:

Everyone: RemindMe will send you email before your friends' birthdays; TowZone will alert you before your car gets towed for street cleaning; Scorecard will tell you whether your neighborhood is polluted. Our free evening and one-day courses (at MIT) will teach you how to make the best use of the Internet.
Kids: The ArsDigita Foundation will give you $10,000 for developing and maintaining a tasteful non-commercial Web service.
Nerds: Learn how to use our open-source toolkits for community sites and ecommerce. The software is free and we wrote a whole book (also free) explaining how to use it. If you want to build collaborative Web-based applications for the Fortune 500 and well-financed .coms, come work at ArsDigita!
Poor Web Publishers: Our free services will add collaboration to your Web site without you having to install or maintain a relational database management system.
Rich Web Publishers: Challenge us with your innovative Web service idea.

A MIT computer science senior with whom we were working objected "You can't say 'rich and poor' when you mean to say 'rich and poor'!" Why not? "It is unprofessional."
Curious to know what his definition of software engineering professionalism was after four years of MIT education, we probed a bit deeper and established that the way that he thought about professionalism did not differ from the thinking of a Mary Kay cosmetics saleswoman: wear nice clothes, drive a clean car, and don't say anything that might offend anyone.
Professionalism in Medicine
Consider three doctors:

Surgeon 1 does the same operation over and over in his Beverly Hills clinic and makes a lot of money
Surgeon 2 is competent in all the standard operations but in addition has developed an innovative procedure and, because of the time devoted to innovation, makes less money than Surgeon 1.
Surgeon 3 has developed an innovative procedure and practices it regularly, but also makes time for occasional travel to France, China, Japan, and Argentina to teach other doctors how to practice the innovation.
Most of their fellow physicians would agree that Surgeon 3 is the "most professional" doctor of the group. Surgeon 3 has practiced at the state of the art, improved the state of the art, and taught others how to improve their skills.
Professionalism in the Software Industry (circa 1985)
As the packaged software industry reached its middle age around 1985, it was difficult for an individual programmer to have an impact. Software had to be marketed via traditional media, burned onto a physical medium, put into a fancy package, and shipped to a retailer. Consequently, 50 or more people were involved in any piece of code reaching an end-user. It would have been tough for a software engineer to aspire to the same standards of professionalism that put Surgeon 3 over the top. How can the software engineer ensure that his or her innovation will ever reach an end-user if shipping it out the door requires 50 other people to be paid on an ongoing basis? How can the software engineer teach other programmers how to practice the innovation if the software is closed-source and his or her organization's employment agreements mandate secrecy?
The industrial programmer circa 1985 was a factory employee, pure and simple. He or she might aspire to achieve high standards of craftsmanship but never professionalism.
What were a programmer's options, then, if in fact craftsmanship proved to be an unsatisfying career goal? The only escape from the strictures of closed-source and secrecy was the university. A programmer could join a computer science research lab at a university where, very likely, he or she would be permitted to teach others via publication, source code release, and face-to-face instruction of students. However, by going into a university, where the required team of 50 would never be assembled to deliver a software product to market, the programmer was giving up the opportunity to work at the state of the art as well as innovate and teach.
Professionalism in the Software Industry (circa 2000)
Like the MIT senior mentioned above, most industrial programmers have not changed their opinion of what it means to be a successful professional. The closer a programmer gets to Bill Gates in terms of wealth, the more successful a professional he is considered to be. Engineers in Silicon Valley worship John Doerr, a venture capitalist at Kleiner Perkins, Larry Ellison, and Bill Gates.
There is some evidence that standards are shifting. Richard Stallman and Linus Torvalds draw large crowds of admirers worldwide. These pioneers in the open-source software movement are beginning to exhibit some of the elements of Surgeon 3 (above):

they practice at the state of the art, writing computer programs that are used by millions of people worldwide (the GNU set of Unix tools and the Linux kernel)
they have innovated, Stallman having developed the Emacs text editor (one of the first multi-window systems) and Torvalds having developed a new method for coordinating development worldwide
they have taught others how to practice their innovation by releasing their work as open-source software and by writing documentation
The Internet makes it easier for an individual programmer to distribute work to a large audience, thus making it easier to practice at the state of the art. The open-source movement makes it easier for an individual programmer to find a job where it will be practical to release his or her creations to other programmers who might build on that work.
It is thus now within a programmer's power to improve his or her practice as a software engineering professional, where the definition of professional is similar to that used in medicine.
The new definition
We define software engineering professionalism with the following objectives:

a professional programmer picks a worthwhile problem to attack; we are engineers, not scientists, and therefore should attempt solutions that will solve real user problems
a professional programmer has a dedication to the end-user experience; most computer applications built these days are Web applications built by small teams and hence it is now possible for an individual programmer to ensure that end users aren't confused or frustrated (in the case of a programmer working on a tool for other programmers, the goal is defined to be "dedication to ease of use by the recipient programmer")
a professional programmer does high quality work; we preserve the dedication to good system design, maintainability, and documentation, that constituted pride of craftsmanship
a professional programmer innovates; information systems are not good enough, the users are entitled to better, and it is our job to build better systems
a professional programmer teaches by example; open-source is the one true path for a professional software engineer
a professional programmer teaches by documentation; writing is hard but the best software documentation has always been written by programmers who were willing to make an extra effort
a professional programmer teaches face-to-face; we've not found a substitute for face-to-face interaction so a software engineering professional should teach fellow workers via code review, teach short overview lectures to large audiences, and help teach multi-week courses

How we do it at ArsDigita
At ArsDigita, we encourage programmers to become better professionals. We assist them by
committing to attack the hardest problems for a wide range of computer users; niche software products are easy and profitable to build but most of the programmers on such a product are putting in the 10,000th feature. At ArsDigita, we simultaneously attack the problems of public online community, B2B ecommerce, B2C ecommerce, cooperative work inside an organization, cooperative work across organizations, running a university, accounting and HR for a services company, etc. This gives our programmers plenty of room to grow.
staying lean on the sales, account management, user interface, and user experience specialists; a programming team is in direct contact with the Web service operator and oftentimes with end-users. The programmers have a lot of control over and responsiblity for the end-user experience.
hiring good people and paying them well; it is only possible to build a high-quality system if one has high-quality colleagues. Thus at ArsDigita we don't hire people unless they've demonstrated an ability to produce high-quality code on a set of problem sets (originally developed for a course at MIT).
giving little respect to our old code and not striving for compatibility with too many substrate systems; we let our programmers build their professional reputation for innovation rather than become embroiled in worrying about whether a new thing will inconvenience legacy users (we have support contracts for them) or how to make sure that new code works on every brand of RDBMS
having a strict open-source software policy; reusable code is documented and open-sourced in the hope that it will aid other programmers worldwide
dragging people out to writing retreats; most programmers say that they can't write but experience shows that peoples' writing skills improve dramatically if they will only practice writing. At ArsDigita, we have beach and ski houses near our larger offices and drag people out for long weekends to finish writing projects with help from other programmers who are completing writing projects.
establishing our own university, TAing at existing universities, and mentoring within our offices; a lot of PhD computer scientists are reluctant to leave academia because they won't be able to teach. But we have our own ArsDigita University teaching the normal undergrad computer science curriculum and we are happy to pay a developer to spend a month there teaching a course. We encourage our developers to volunteer as TAs or lecturers at universities near our offices (e.g., Caltech, MIT, Stanford, UC Berkeley, University of Pennsylvania). We insist that senior developers review junior developers' code internally.
Epilogue
How well has this new definition of professionalism succeeded within ArsDigita's staff of nearly 100 programmers (April 2000)? The release of our main product, the ArsDigita Community System, is handled by a group of Caltech PhDs and former Caltech faculty in Pasadena, California. Here is the first line, a comment, of the first file in the release:
# ACS 3.2 (MIT Sucks!)

asj-editors@arsdigita.com

Reader's Comments

In the past few months I have made an effort to adopt the arsdigita guidelines for programming in my current job by following the Job Description for Programmers. I have begun documenting my projects, and trying to help my co-workers learn better practices as often as possible. My co-workers have all noticed the change in my behavior and professionalism. I still wear jeans and sneakers most days, but on the whole, I am more respected by the MBA's of the company and I am a more credible employee. I think professionalism is very important and having the community talk about issues like this is a good thing. Kudos to arsdigita for publishing this document.

-- Phillip Harrington, June 8, 2000

I would add another:
A professional programmer plays well with others. Being a hotshot coder is enough when it's you and your PC in the basement, but if you want to be a useful member of a programming team you need to be able to collaborate and get along with your peers in a social environment. I've met good programmers who simply could not get along with their co-workers due to arrogance or lack of social skills. They were ultimately less useful to have on a team than their less skilled but more friendly counterparts.
As an interesting sidenote about professionalism on code comments, there's a document that shows some comments by Linus Torvalds from a very early Linux kernel. The thing I like about these is that they communicate an air of humility, good humor, and friendliness which set the right tone for successful collaboration.

-- Perrin Harkins, June 10, 2000

I think somewhere in the list of what constitutes a professional should be a line that mentions a professional programmer keeps an eye on the future. I've seen far too much code that, for the same amount of design effort, could have been generalized to enhance reusability and improve maintenance, but wasn't. "Penny wise and pound foolish"

-- Terry Grossman, July 14, 2000

The only down side I see about using the work "fuck" in your comments is if it will offend your co workers. Team work is definitely a part of being a professional programmer. If the word fuck offends (or is likely to) other people who will have to read your code then perhaps discretion should be used in placing it in a comment.
Would people be happy with "/* we have to be this carefull with memory because our boss was too jewish to buy more */" or "/* dont change this or you'll have to work like a nigger to fix it */"? Both of these expressions were current when I was a child - and considered less offensive than any four letter word. Thankfully we have now decided that this is not appropriate language to use.
I personally would give very negative feedback to anyone using either of these expressions in their code - open source, high quality or not.
Respect for your fellow man should DEFINITELY be part of any definition of professionalism.

-- tom pickering, August 15, 2000

I have to disagree with Mr. Pickering about what constitutes offensive language that crosses the line of professionalism.
I do agree that the fact that an offensive phrase may be commonplace does not alone excuse its use; but I find that the racial slurs he uses as examples are hardly analogous to the example of a four-letter used initially for discussion. The word f**k (while not in my personal vocabulary of appropriate language) in the initial example does not seek to discredit or offend a group of persons based solely on a physical characteristic. In fact, usage in this context is completely objective to any particular person. One must choose to be offended by it, no offense is necessarily intended.
In other cases, however, phraseology must be excused based on the basis of context. When Tom was a kid, the use of those phrases in code comments MAY have been appropriate IF they accurately communicated the commentor's point in a manor familiar to the reader. *GASP* Racism & Bigotry !!! No, not necessarily. I believe that when everyday speech is analyzed to death, you'll find that many phrases/songs/addages are rooted in offense even though they are not often used with such offense in mind. We use words like 'gyp' to mean cheated, whereas it was originally an offensive comment about the business practices of Gypsies. 'Indian giver' and 'Eenie-Meenie-Mynie-Mo', both rooted in racism, are also increadibly commonplace in today's American culture.
I think that we have become far to reactionary as a culture to these issues of late. Let us remember to examine issues in the context of the situation: would it really be worth it to contest the use of the word nigger with your dying grandfather, hours from death? If so, to what end? I think that the same applies here. If you're concerned about comments in open source code, change it to reflect a magazine publishible version and submit a patch. It may not be accepted, but who cares. If the goal is usable code, remember not to be tripped up on the minor details. A truly professional programmer would be able to overlook the racism and bigotry of a fool and make valuable contrabutions in spite of it.

-- Cameron Watters, September 4, 2000

I am a professional programmer. I have been since 1982, when I first got paid to write a GC-mass spec data collection system for a research laboratory. I have worked for companies such as IBM, Sybase, Microsoft, etc.

I found nothing particularly untoward about the comment that starts this thread -- the comment that uses 'the F word'. To confirm that it's ok, I went searching through some production source from years past. I was unable to find any time that I used it, but did find the following comment in a library written by one of my colleagues. He is definitely a professional programmer. Here is the comment:
"/* SDK 1.1 DualBoot fucks up the Extended_sig
if( !s0.NumOfSectors ){
// The beta version of os/2 1.1 used 0x28, dos 4.00 uses 0x29
if( !(s0.Extended_sig == 0x28 || s0.Extended_sig == 0x29))
_abort("drive %c: Boot record screwed up.\n", args->drive+'A');
}*/

Note that the message never appears except in code. The entire block is from unit testing and was never released. I participated in developing other parts of this system. Believe me, the comment really communicates to me (another programmer) loud and clear.

Programmers work very long hours trying to meet often impossible goals. They are constantly let down by their tools, vendors, bosses (or clients) and the public at large. They are still expected to get the job done. I think they can be forgiven communicating in their native tongue from time to time n'est pas?

Having said all that, I confess that I would not likely turn over code with such comments to a major client if I expected their people to be working on it. However, that's more a political-weasel-ism on my part than it is professionalism per-se. I applaud my programming peers for having the balls to say what they mean directly without mincing words. As for the nay-sayers: Fuck 'em.

-- Bob Trower, September 11, 2000

They way it looks to me is that there isn't much difference between a comment with an offensive word in it and code with an offensive (read inefficient or error-inducing or inelegant) implementation of a design. In fact, since the comment can't possibly cause the software to fail, offensive code is in many senses worse than offensive comments.
In the non-code world offensive language is defined by the customs of the group in which the conversation happens. Over time the members of a group agree on language that is appropriate and stick with it, ostracizing or at least glaring at those who offend.
The same process happens in open source code. If a line of code offends, change it and check the changes back in to the revision control system. If a comment offends, rewrite it and check the changes back into the rcs. The group of active programmers will converge on appropriate language for comments, just as they will converge on an acceptable documentation level and an acceptable level of bugs in the code.
And readers of code should bear in mind the group that wrote the code, and have a reasonable sense of what can be considered offensive igven that group. Most code is written by logical people who are offended by meaningless exceptions to otherwise elegant rules and are very likely to write "fuck" when they have to implement such an exception.
Isn't the exception just as offensive as the comment?

-- Bart Addis, September 12, 2000

I just wanted to share that comments such as the one above not only fail to offend me, they make my day a whole lot easier. True, well commented code is helpful for any programmer, but add a little humor and the world seems like a much better place. The use of foul language is not funny in itself, but its juxtoposition in source code does strike me as humorous. Maybe I am a nerd: more than once I have been caught chuckling at my desktop. My co-workers have turned to my screen expecting to see 'the joke of the day' website they roll there eyes and shrug their shoulders when they see a screen full of code which they don't understand. Still, I appreciate the little break: the reminder that there is room for humor in the midst of serious work. I might be concerned if this language was broadcast on prime-time TV where children might get confused, but how many 5 year olds are into driver development?
Image: vending.jpg

-- Mark Donchek, October 2, 2000

Regarding the code example a few posts up: it is somewhat ironic that this fragment is held out as an example of what professional code should look like. This code contains an example of one of the worst programming practices that I can imagine: an error message that doesn't really tell you what the problem is. It should say "drive %c: boot record signature was 0x%x, wanted to see 0x28 (OS/2) or 0x29 (DOS)". As it is, the first time somebody sees the existing message, they're probably going to go back into the code and print out what exactly the signature was, so as to get an idea of where it came from. (Is it zero? Is it some other partition type?)
Why is this important? Because it's highly professional to attempt to save time for programmers who are going to have to fix bugs in your code. Most likely the bugs are going to have been detected by somebody running the code, and hence looking at its output, rather than by reading the comments in the source code. An accurate error message is accurate documentation in that it conveys expectations that were not met and is also useful for debugging, because it tells somebody what went wrong at runtime. To this extent it's more important to get the error messages right than to get the comments right.

-- Gideon Glass, October 4, 2000

What constitutes professionalism is highly subjective, since there appears to be a lack of well-defined criteria, though the Arsdigita values seem a nice step forward. (Clearly we mean the term to be something more than the dictionary characterization of "making a livlihood".) As a continuation of this thread, philosophical inquiry into the concept of professionalism within a given domain might include consideration of some questions such as the following. (You, the reader, are invited to weigh them and to think of examples that affirm or deny their associated premises.) By .domain. I mean a complex set of interrelated elements that likely includes: a) technical field (tools, processes, protocols) b) social and cultural environment (people such as co-workers, clients, and stakeholders) c) actual work performed and quality of products produced.
Thought questions:
1.To what degree can one be proficient/expert in a domain without being professional in that domain?
2.To what degree can one be professional in a domain without being proficient or expert?
3. To what degree could one be professional in a domain if one exhibits poor etiquette by the prevailing standards of social behavior?
4. What if the surgeon in Phil.s example dresses slovenly, smells bad, curses like a sailor, or engages in sexual harassment, but is the best in the world with respect to Phil's three postulated principles of professional behavior (i.e., practices state of the art, improved the state of the art, and teaches others how to improve state of the art)?
5. What if the surgeon in Phil.s example dresses immaculately, has great bedside manner, communicates well, is genuinely respectful and caring, and in most ways meets the three state of the art criteria, but is less effective in healing patients with those state of the art skills compared to most of his/her peers? (perhaps not helping those patients upon which the evolving state of art skills are being developed)
6. Could/should a software engineer be labeled professional if he rarely, or sporadically, writes quality documentation?
7. Can documentation be considered as much of an esthetic as the functional code itself?
A list of such questions could be expanded indefinitely. Their consideration might illuminate how we subjectively differ on what constitutes professionalism in a given domain.
One of the approaches to narrowing the range of subjective views of professionalism might be to build consensus on specific sets of measurable domain criteria for professionalism. In addition to Phil's proposal of innovation and mentoring, others might consider and improve upon: a. further identification of .best practice. techniques and methodology, tailored to meet specific circumstances.left as a reader exercise to specify particulars, but vulgar language in commented code does seems unprofessional to some, even in instances where it might be "effective" b. Courtesy towards domain co-workers, clients, and stakeholders c. Ethical (at least in the domain environment) behavior (e.g., gives due credit to others and does not make false claims)
Providing clean, well-documented, understandable, well-tested (and largely correct) code is but one mark of software engineering professionalism; as suggested above, among several other factors we might consider is personal behavior/ethics. These factors and their relative weighting are currently ill-defined and rather protean, but with more collaboration, who knows?
Abstract generalizations, such as "professionalism", can be a double-edged sword. They can be useful to cut the clutter of detail and complexity, but in so doing they may distort our perception, and worse, be misused, if we are not vigilant. Realworld domain behavior is not a clear dualism between professional and unprofessional, but rather characterized by infinitely many degrees of shading. A further caveat: the preceding sampling of questions is NOT intended to suggest that people who are .unprofessional. by one set of criteria are necessarily of lesser value by other criteria.

-- Terry Alford, November 12, 2000

Many, if not most, of the programmers with whom I've worked (in a variety of contexts) throughout the past 10 years or so have been rather lax when it comes to (a) documentation & commenting of code and (b) overall Quality of code. Their philosophies have been "hey, if it works, it works", or "this code is self-explanatory; it doesn't need comments", or even "I don't have time to put in comments." Often times, the comments that are present are written "from me to me", rather than "from me to you", and aren't very helpful six months down the line when someone else comes along to modify that section of code and ends up tearing their hair out over what should have been a trivial modification.
And so, time and again, I've learned and re-learned the following lesson:
The practice of programming does not stop with the writing of functional code. It includes, equally important: good code design, documentation, code structure, commenting, and communication with one's peers. Though someone may be a brilliant code-writer, he may still be a lousy software engineer due to the lack of these other attributes (which all ultimately boil down to an ability and desire to communicate). These people are much better suited to projects in which they are the sole custodian of their own mess.
When one says "a truly great programmer is worth 10 good programmers", it is these factors (and not simply code-invention) that govern the titles "great" and "good".
As far as Swearing vs. Professionalism, I agree with Bart; badly-written code should offend a good programmer more than a little four-letter word. In most cases, a swear word helps by emphasizing the seriousness of a concern.
Then again, I'm coming from the perspective of Game Development, an industry in which both swearing and bad coding practices are grossly overrepresented. ;-)

-- Squirrel Eiserloh, March 4, 2001

Redefining Professionalism for Software Engineers

Professionalism in Medicine

Professionalism in the Software Industry (circa 1985)

Professionalism in the Software Industry (circa 2000)

The new definition

How we do it at ArsDigita

Epilogue

Reader's Comments

Related Links