Professionalism for Software Engineers (2000)
philip.greenspun.com
philip.greenspun.com
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]
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.
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.
I firmly believe meetings are a waste of time.
And a lot of people are bad communicators.
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.
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.
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.
How comfortable you are has a real effect on how you perform.
How you present yourself is someone else's problem. If it is a problem for someone else then they are affecting how you perform.
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.
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.
> 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.
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.
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.
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.
The lone youtube comment is priceless.
Cotton: Do you know if Philip still has the wimpypoint presentation posted anywhere?
"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.
"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.
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.
Succinct and elegant - a wonderful definition.
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.
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.
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.
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.
The price paid for that, of course, is levels of cost and bureaucracy comparable to civil engineering. Try to build a website for a startup that way and you'll be out of business long before you ship anything. The correct level of rigor depends on what you're doing.
Because it takes 11 years to upgrade one feature. https://en.wikipedia.org/wiki/Eastern_span_replacement_of_th...
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.
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.
Completeness and rigor is also costly and impactful. There's a tradeoff to be made there. Additionally, it's easier to be complete and rigorous in civil engineering when the inputs are easier to model and predict.
Why do you think that doesn't happen?
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... [2] https://en.wiktionary.org/wiki/professional
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
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.
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.
(1) There are several definitions of "professional", one of which (from your own linkedsource, wiktionary) is "Of, pertaining to, or in accordance with the (usually high) standards of a profession." -- which requires the existence of such standards within the profession. (2) The actual word at issue in the title of the linked article is "professionalism" which is specifically, in its primary definition, about standards/expectations within a community [1].
> 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.
"Free", too, has many meanings, but being a reference to freedom (i.e., liberty) rather than absence of cost isn't a particularly obscure one. For instance, the common phrase "free country" does not mean "a country available at no cost". The idea that there is one thing that "free" means "in every other context" besides Free Software is, well, completely wrong itself.