
Professionalism for Software Engineers (2000) - cottonseed
http://philip.greenspun.com/ancient-history/professionalism-for-software-engineers
======
forgottenpass
"Professionalism" gets used as a rhetorical tool to lump aesthetics into the
same category as qualities that effect job performance. Once they're in the
same category, the irrelevant things steal creditability from the important
ones. (And because society doesn't exist in a vacuum, they might even become
self-fulfilling prophecies)

Remeber Bobak Ferdowsi? The NASA guy with a mohawk?

    
    
        [...] you know, too unprofessional to be selling tickets at a railway 
        station but reliable enough for landing robots on Mars. [0]
    

[0] [http://www.smh.com.au/small-business/blogs/work-in-
progress/...](http://www.smh.com.au/small-business/blogs/work-in-
progress/unshaven-unprofessional-mohawk-no-worries-20120809-23xjk.html)

~~~
fennecfoxen
Eh. Different professions have different needs. If you're in a profession
where you need to interact with a broad variety of human beings in a positive
way, then having a haircut which is designed to draw attention to yourself by
boldly and deliberately flouting social conventions, it may be a problem.
You're being paid to make the customers happy and their interactions
straightforward, not to challenge their conventions and ways of thinking.

If you're in a position where you need to work closely with your fellow
employees and a computer, that's different. Approaching things
unconventionally and thinking outside the box could very well be a NASA
scientist's chief virtue.

~~~
enraged_camel
And yet we have hordes of white collar workers who never interact with
customers face-to-face, but are still expected to come into the office in
business or business casual clothing.

After a certain period, you start to understand that "proper business attire"
has nothing to do with customer interactions and everything to do with
providing yet another avenue for bosses to exert control over their workers.

~~~
gnopgnip
How you present yourself has a very real effect on how you perform. When you
stay in pajamas and a t shirt all day you are holding yourself back.

~~~
enraged_camel
If how you present yourself has a "very real" effect on how you perform, maybe
you can provide some citations.

Every now and then, articles pop up that talk about how people who work at
home perform better when they actually wear work clothes. My suspicion is that
this is simply the PR industry at work, hired by companies that sell work
attire.

[http://paulgraham.com/submarine.html](http://paulgraham.com/submarine.html)

~~~
krschultz
I think that the statement "My suspicion is that this is simply the PR
industry at work, hired by companies that sell work attire." is complete
unfounded bullshit.

There are many studies that show habits are an integral part of being human. I
like the 'elephant and rider' metaphor. You have a finite amount of rider time
each day to control your elephant. Every time you make a decision or exercise
a bit of self control, you use up some rider. Habits drive the elephant too,
but don't cost any rider time. If you are working with your habits, you get
the elephant to do what you want for free. If you are working against your
habits, it costs even more rider time just to do the basics.

So if you are someone that has a habit of wearing sweatpants and a tshirt all
day, forcing yourself into business casual clothes costs rider and reduces
your potential productivity for that day.

On the other hand, if your habit _is to wear work clothes_ , then getting up
in the morning and dressing as if you are going to an office isn't costing you
anything. In fact it's probably putting you in the state of mind that you are
'now at work'.

For me personally, 'getting dressed for work' generally means jeans,
comfortable shoes, and a button down shirt. Some days a tshirt. If I'm working
from home - even on a Saturday for my own sideprojects (as I did today), I get
'dressed for work'. I wake up, take a shower, shave, have breakfast, make the
same coffee as a work day, wear the same clothes as a work day, and then go
get shit done. Arguably I would expend less physical energy rolling out of bed
and sitting in front of my computer, but I would never ever be in the right
state of mind.

~~~
sqrt17
So if someone told you that jeans were not proper working clothes and that you
are being unprofessional, would you agree with them?

What you're describing is just sticking a "I'm working" label onto yourself,
which could be done with a button-down shirt just as well as with wearing a
black t-shirt as long as it is, in your mind, "dressed for work". The part
where the PR industry comes in is where people in a customer-facing position -
people used to call those "suits" in the 90s for the exact reason of being
inappropriately dressed for someone doing production, as opposed to management
or sales, work - expect others to conform to their standards instead of the
other way around.

In other words, standards of dress tell a lot about whether your organization
is engineering-driven or sales/marketing driven, and startup culture -
traditionally driven at least in part by technical people - definitely has
other standards than banking or consulting.

------
Pxtl
I think there's still something to be said for professionalism. I curse like a
sailor when frustrated (which, as a coder, is about 95% of the day) so I
constantly have to rein it in. This is because avoiding offending people
_does_ matter.

If you want to have an open and inclusive environment, you have to keep in
mind the terrible things you say. You want to attract a group of top and
diverse people? Some of those folks are going to have thin skin, or they're
going to have sensitive buttons that you don't have.

They can't avoid hearing it, but you can avoid saying it.

And as for rude code? I've got a team under me now and I've seen it happen
already a few times: somebody _will_ see it. I don't care where you wrote it,
it _will_ be seen. Murphy's law just works that way. Your IDE will be open
when you remote in to fix something during a rough alpha-stage demo, or a
variable name will become a database column will become a column of a report.

Somebody _will_ see it, and they _will_ be offended, and it's _your_ ass.

~~~
lloeki
If they're offended, they're performing ego driven development. Aim cursing at
the code, not the person: "This code is complete horseshit" means exactly that
and one's got room for improvement, _not_ that one is worth complete
horseshit.

I'd rather have people around me that have the courage to say "WTF is this
shit" rather than the politically correct talk about how this code "will not
work" and could be "improved". In my current situation the latter only leads
to wishful thinking ("in an _ideal_ world we'd fix that... _later_ ") and
handwaving of my "academic" thought process. Yes it's _my_ ass, the one ass
that's sick of making up for people mistakes all the time, and the only thing
that has a semblance of snap them out of their numbness is to shock them.

There is nothing less professional than shipping non-functional code to
customers, nor imposing undue amount of work to your teammates by writing an
unmaintainable mess, either of which being more equivalent to a giant implicit
"fuck you" than colourful words.

------
jtheory
This caught my eye, from the "How we do it at ArsDigita" list:

> 6\. 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. >

Communication (and writing in particular) skills are crucial -- programmers
who are articulate and concise are so much more valuable then others with
equivalent coding skills, but whose grammar & spelling leaves you wondering
what they meant to say, who can't jump to the meat of an issue (or consider
their audience) when discussing it, or worse.

I consider it strongly when we're hiring; it's a neat idea to actively improve
writing skills for the programmers already on board.

~~~
mgkimsal
Worked with a guy recently who emailed me with "I don't understand arrays". I
immediately called him and said "we've got some big problems - this is scaring
me, that you'd write that - you need to understand arrays."

I got back "oh, I understand arrays - I don't understand why what they're used
for."

Me: "Holy cow - how can you understand array but not know what they're used
for? That doesn't make sense."

Him: "No, I mean I don't know why this framework uses them in these 2
libraries."

Me: "Please learn to communicate your full thought before emailing me. This
seriously makes me question your ability to get any of this done - you're not
able to get your thoughts across properly - how can I assume you can
understand what I'm saying, what the requirements are, or translate to code
correctly? You might be able to, but you lose credibility when you write and
talk this loosely - words have meaning."

"I don't understand why the framework uses arrays in supporting library X" is
miles different from "I don't understand arrays". But in his mind, he was
saying the same thing.

~~~
gedrap
Yup. And the opposite of it when a person starts with some random abstract
(supposed to be background) things and takes 5min to get to his point although
I lost him within the first minute.

Some people may be amazing programmers but if they struggle to share their
ideas, the impression they make will be 'meh'. And impression, even an
irrational one, caries a great weight.

------
droopyEyelids
I really enjoyed the article. Defining your aspirations has a subtle yet
profound effect on your trajectory of life.

Sometimes our aspirations are chosen for us by accidents of our culture or
circumstances. I think thats what the article described when the author wrote
about how professionalism (the kind of career we aspire to) can come to mean
'getting more money' or something equally beside-the-point of a life well
lived.

Money is great, but after your needs are met it's a senseless goal. Politeness
is good, but it doesn't necessarily improve the world- just keeps it from
getting worse.

Innovation and teaching go well beyond inoffensiveness— they directly help
improve the lives of others. And they even surpass the good that wealth can
provide- because no matter how much money there is, someone actually has to do
the work, and when that work is the result of your individual lifetime's
efforts and experiences, you're the only one that can do it.

------
nswanberg
Here is Philip giving this wonderful talk:
[https://www.youtube.com/watch?v=JsPFdVrbGeE](https://www.youtube.com/watch?v=JsPFdVrbGeE)

The lone youtube comment is priceless.

Cotton: Do you know if Philip still has the wimpypoint presentation posted
anywhere?

~~~
cottonseed
I don't. Looks like might have been using a wimpypoint server that didn't
survive the closing of aD/aDUni.

------
StronglyTyped
I see this every time I install StartExplorer in Eclipse. And I love it.
[http://www.wtfpl.net/txt/copying/](http://www.wtfpl.net/txt/copying/)

------
PhasmaFelis
My favorite bit from the reader comments at the time:

 _" 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._

Man, did that ever not last.

------
nsx147
I tend to communicate in a way my peers can effectively relate and understand.
This applies to comments in source code. I feel it would otherwise be a
disservice to everyone involved.

------
abalone
One thing jumped out at me:

 _" we encourage programmers to become better professionals [by] staying lean
on the... user interface, and user experience specialists"_

That's a major difference between now and then. In the past 14 years there's
been a huge shift towards better respecting UI design as a professional
speciality. It definitely used to be a thing that programmers didn't respect
as much, like sales & marketing. And software has gotten a lot better as a
result.

~~~
arthurjj
As someone who wasn't a huge fan of working with UI I have to say over the
past decade it's become arguably the _most_ important part of most apps. It's
a bit outdated but reading "Don't Make Me Think"
[http://amzn.to/1o3XMYy](http://amzn.to/1o3XMYy) helped me a lot but I don't
know of any other good books for programmers on UI/UX

------
Havoc
That strikes me as a good definition for an FOSS environment.

Personally I don't think there should be as much emphasis on teaching. Those
that are "natural teachers" will do it anyway and should be rewarded as such
but I'd be wary of formalizing it.

I like the mentor system. e.g. At my employer informal peer knowledge transfer
is the primary teaching method, but everyone has a powerful individual
assigned that is responsible for watching over each of us - guardian angel of
sorts.

------
lifeisstillgood
>>> practiced at the state of the art, improved the state of the art, and
taught others how to improve their skills.

Succinct and elegant - a wonderful definition.

------
michaelochurch
The distinguishing trait of a _profession_ is that it involves ethical
obligations that supersede managerial authority. Here's a blog post I wrote on
it:
[http://michaelochurch.wordpress.com/2012/11/18/programmers-d...](http://michaelochurch.wordpress.com/2012/11/18/programmers-
dont-need-a-union-we-need-a-profession/) . (However, I've become convinced,
later in my career, in the value of having some representation, like a
Hollywood writer's union.) If you're a professional, "I was following orders"
is no excuse.

The flip side of that, which professionals tend to enjoy, is that your boss's
power over you must be limited. Thus, the profession gives credibility to all
members. If you get fired because your boss doesn't like you, you're still a
doctor. The AMA wants it to be this way, because if the boss held as much
power as in most jobs, professionals wouldn't have the autonomy under which
that responsibility (don't harm patients, even if ordered to do so) makes
sense.

The professional organization also, at least in theory, looks out for its
membership. If doctors are autonomous (i.e. can always find jobs) and wealthy
enough that they have the resources to keep up with lifelong duties (e.g.
keeping abreast of medical advances) then the risk that they are compromised
against their obligations is low.

A doctor can say, "I won't do this, because I believe it will harm the
patient." A software engineer can't. That's the difference.

~~~
geebee
I'm on the fence about the notion of a profession for software "engineers".
One thing that worries me is the uncertainty around who would establish
credentialing (For instance, I was a math major - would a degree in computer
science be required to sit for the exam?)

I do see more than a few benefits to it as well, though. For starters, we'd be
able to start treating each other as professionals. I've been on both sides of
the interview, and I personally don't enjoy asking an experience programmer
how to do programming exercises that clearly (there's no way to spin this)
just amount to testing whether the person has minimum competence. I'm not
questioning the value of knowing how to print a binary tree in order, but I
actually think it becomes an almost degrading ritual after a while, and we all
participate in it. Do physicians have to re-study organic chemistry every time
the interview for a new job, the way programmers wonder if they are going to
need to explain how the JVM works, or explain in detail how a random forest
works, or how to find long term probabilities in a markov chain, or answer
questions about operating systems? Personally, I would enjoy not having to re-
load all that knowledge into "exam ready" memory in the weeks leading up to an
interview (and having to be strategic about it, because I can't afford to drop
everything at my job and study for nothing but an interview for several
weeks).

A genuine _professional_ exam might cover the core, and it would (if done
well) actually cover the issues that we, as a profession, have decided are
critical. Again, I'm not sure if this would work, or if it wouldn't do more
harm than good, it's something that I find intriguing. Suppose there really
were a good, rigorous, highly regarded, professional exam (perhaps including
an in-person component, as with nursing and medicine). This might take the
exam away from the whim of the employer and return it to the practitioners in
the field. Employers are still free to ask what questions they like, but
they'd acknowledge that they're re-examining a candidate on subject matter
knowledge that was already validated by a group of professionals, _or_ that
they've decided to quiz heavily on subject matter that is outside that realm
(in essence, acknowledging that they're looking for niche expertise, and that
this isn't about verifying that someone isn't a fraud).

I think we should acknowledge in our field just how grueling these "exams" are
every time we apply for a new job. People talk about how tough the bar exam is
in California - it's 18 total hours of exam over 3 days. I've had periods of
interviewing (at more than one company) that were about that long. It takes a
while to prepare for the bar, of course, but here were some of the topics I
was asked about over 3 8+ hour day of interviews (total interview time for two
different math oriented programming jobs…)

build a binary tree

traverse a binary tree

add a node

remove a node (describe how, answer questions, write a bit of code)

how to keep it balanced (some code, probing questions, but not obliged to
write full code for red-black)

how to find the dual of the primal in linear programming, and explain the
relationship

code up a singleton

identify the lack the strategy and factory patterns in a long if-then bit of
code, show how to do it with patterns convert a database table to a bunch of
indicators (T/F)… is this strange?

find long term state of markov chain

model a shipping system as a graph and suggest how to optimize it
mathematically

detect a cycle in a linked list

convert a linear program into something that can be solved with dynamic
programming (i.e., it didn't need to be an optimization, it could be solved
with a greedy algorithm)

print all permutations of a string, using recursion

swap two integers without creating a third variable (asked over lunch)

There were also interviews with management, and so forth. I can't possibly
tell you if this was worse than the bar, but it took years of preparation, and
I failed to get an offer from either company. I'm not sure why, but I didn't
rock the tech interview. I was busy at the time and also had a full time job
to do (and a young child to take care of at home). I've taken exams on
everything listed above at one point or another. People talk about the "low
barriers to entry" for programming, as if legal licensing barriers are the
only kind. Barriers to entering programming are pretty heavy, and they can be
capricious.

------
kurtle
This is an old article from 2000.

~~~
michaelcampbell
Yes, thus the "(2000)" in the title. (Or was that not there originally?

------
rwmj
The Linux kernel seems like a poor example of professionalism. It's written in
C, released with barely any testing (and thus has major regressions, such as
the dup system call being broken a while back), and the community around it is
very unfriendly (sometimes with reason).

The development model is interesting, and was basically bound to happen once
you had the license, the internet and eventually the tools (git). It's a step
forward from proprietary software but we're not at the level of discipline
required to build bridges, skyscrapers and nuclear power plants.

~~~
tommi
Would you say that discipline required to build nuclear power plants is
desirable in building Linux kernel?

~~~
Codhisattva
Software failure is costly and impactful. Why not aspire to levels of
completeness and rigor comparable to civil engineering?

As a software craftsman and a professional, I recognize the necessity to
impose a practice on younger, less experienced programmers to guide them
towards high quality work. Civil engineering is a good example for all coders
to learn from.

~~~
IvyMike
> Why not aspire to levels of completeness and rigor comparable to civil
> engineering?

Because it takes 11 years to upgrade one feature.
[https://en.wikipedia.org/wiki/Eastern_span_replacement_of_th...](https://en.wikipedia.org/wiki/Eastern_span_replacement_of_the_San_Francisco%E2%80%93Oakland_Bay_Bridge)

In all seriousness, you could have any level of 'rigor' you want, but you
probably don't want to pay for it. I used to work at a hardware company that
used custom ASICs. Each new hardware platform used a handful of new ASICs and
took around five years to develop. And if you made a mistake in an ASIC it was
costly to fix--sometimes you could modify a metal mask, but a full respin was
approaching $1M. In that environment, you do everything you can to not make a
mistake.

I was always glad I was in software. I used to joke that if I made a mistake,
it cost around one cent of electricity to recompile.

But over time, they started to treat software development like they did ASIC
development. It took _forever_ to get a feature implemented, Seriously, even
tiny things that were like "I've got an UI idea that I can code it in a couple
of days and see how it works out, if it sucks no harm no foul" were turned
into six month orgies of spec writing, endless meetings, multiple layers of
buyoff, and just overall inefficiencies.

~~~
TheOtherHobbes
It's interesting - to me, anyway - that there's endless talk about patterns
and methodologies and various heavily promoted (but often questionable)
project management traditions in software.

But there's no formal, explicit and established pattern/process which guides a
project through the stages of invention, innovation, refinement (debugging and
user feedback), deployment and promotion, and preparation for maintenance with
documentation.

If you're lucky and/or experienced and/or have good project management some of
these things will be done well.

If not - nope.

In your case I can see why ASIC culture crept over to software. But if
software had an existing culture, you - and everyone else - would be able to
try out new ideas without management terror that you were going to break
something.

------
levosmetalo
Why everyone tries to attribute something to software professional and
redefine the meaning of professional. The term is well understood [1][2] and
means just someone that do some work for a living, get paid for it.

That's all there is, no further requirement to be "professional". The whole
discussion about professionalism in the context of software reminds me of FSF
attempts to convince us that "free" means something else which is not actually
the same as "free" in every other context.

[1]
[http://www.oxforddictionaries.com/definition/english/profess...](http://www.oxforddictionaries.com/definition/english/professional)
[2]
[https://en.wiktionary.org/wiki/professional](https://en.wiktionary.org/wiki/professional)

~~~
chillacy
Yes, but the word 'professional' technically describes a job that goes beyond
doing work and getting paid. Some milestones of a profession:

1\. an occupation becomes a full-time occupation 2\. the establishment of a
training school 3\. the establishment of a university school 4\. the
establishment of a local association 5\. the establishment of a national
association 6\. the introduction of codes of professional ethics 7\. the
establishment of state licensing laws

Wiki:
[http://en.wikipedia.org/wiki/Profession](http://en.wikipedia.org/wiki/Profession)

Software dev has yet to come up with official ethics and state licensing for
the most part, verses civil engineering for instance, which you have to be
licensed to do.

~~~
huherto
pretty interesting.

What scares me about licensing is having all the non coding CMM professionals
that evolved into Agile that may end up defining the licensing requirements.

~~~
watwut
Just because there are higher organizational levels of "professionalism" does
not mean that it is reasonable to go there for our profession. Those higher
organizational levels should be taken when there is a clear need for them.
They should not be taken just because we feel we exist long enough.

