by Philip Greenspun (philg@mit.edu)
ArsDigita : ArsDigita Systems Journal : One article
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:
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.
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.
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):
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.
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.
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.
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 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. 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?
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.
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.
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. ;-)
Here is an email message regarding the
ArsDigita Oracle Driver:
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?
... 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?
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.
Professionalism in Medicine
Consider three doctors:
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?
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.
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.
The new definition
We define software engineering professionalism with the following
objectives:
How we do it at ArsDigita
At ArsDigita, we encourage programmers to become better professionals.
We assist them by
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.
-- tom pickering, August 15, 2000
I have to disagree with Mr. Pickering about what constitutes offensive language that crosses the line of professionalism.
-- Cameron Watters, September 4, 2000
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');
}*/
-- 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.
-- 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?)
-- 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.
-- 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.
-- Squirrel Eiserloh, March 4, 2001Related Links