"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]
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.
While a I agree with you up to the point, the word "professionalism" is often used to construct social convention around a rule that did not existed previously or is not strong. I am talking about a situation where the society do not care much, but the person using the word "professionalism" does and wants us to force it on others.
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.
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.
I do not agree with gnopgnip, but I think the way you are dressed might have a priming effect. There were quite a few studies conducted on this topic. But I don't think its effect is significant, and if you associate being dressed for the office with something stressful, then it might have negative effect on you.
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.
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.
Only if they are bad communicators. And then you either lose any record of what was discussed or you have to write notes, which will have to be clear without human interaction anyway, so why not just write that email and draw those diagrams and save everyone the trouble from the start?
OK, I agree with your points that having written notes is good, and I would say that 90% or more of meetings that I attend are a waste of time, but then occasionally something useful does come out that can't be conveyed clearly via email.
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.
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.
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.
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.
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.
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.
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.
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.
"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.
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 helped me a lot but I don't know of any other good books for programmers on UI/UX
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.
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... . (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.
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.
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.
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.
Safety critical software projects do have levels of completeness and rigor comparable to civil engineering. An example is the space shuttle control software, which ran for decades without a single serious failure - by contrast, the shuttle hardware in the same time period suffered two lethal failures.
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.
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.
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.
> Software failure is costly and impactful. Why not aspire to levels of completeness and rigor comparable to civil engineering?
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 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.
> Why everyone tries to attribute something to software professional and redefine the meaning of professional.
(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.
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
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.
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.
Remeber Bobak Ferdowsi? The NASA guy with a mohawk?
[0] http://www.smh.com.au/small-business/blogs/work-in-progress/...