Motivation of software professionals
in [Java Programming]
|
From: Seebs on 15 Feb 2010 22:40 On 2010-02-16, James Kanze <james.kanze(a)gmail.com> wrote: > On Feb 14, 4:56 pm, Seebs <usenet-nos...(a)seebs.net> wrote: >> On 2010-02-14, James Kanze <james.ka...(a)gmail.com> wrote: >> > To be really effective, design and code review requires a >> > physical meeting. Depending on the organization of the project, >> > such physical meetings are more or less difficult. >> Nonsense. > The more channels you have available, the better communication > works. Not so. Some channels can swamp others. If you're busy picking up facial expressions, instead of properly processing the raw data, the extra channel has HARMED your quality of communication. > There are probably some special exceptions, but other peoples > expressions and gestes are a vital part of communications. They may well be -- but my experience has been that you can communicate some things much better without them. > Not to mention the informal communications which occur when you > meet at the coffee pot. I've worked from home, and in the end, > I was frustrated by it because I was missing so much of the > informal communications which make things go. I would miss that, except that in my workplace (which spans several continents), the "coffee pot" is IRC. > That sort of thing is essential for any review. You do it > before the face-to-face meeting. But the reviewer isn't God, > either; the purpose of the meeting is to discuss the issues, not > to say that the coder did it wrong. If you do it well enough, I don't think the face-to-face meeting does anything but cater to superstition. > Almost universally. Ask any psychologist. We communicate > through many different channels. I do, in fact, have a psych degree. And what I can tell you is that, while there are many channels, sometimes you get better or more reliable communication by *suppressing* the non-analytic channels. Say, if you were trying to obtain accurate data about a thing subject to pure analysis, rather than trying to develop a feel for someone else's emotional state. The goal is not to have the largest possible total number of bits communicated, no matter what those bits are or what they communicate about; it's to communicate a narrowly-defined specific class of things, and for that plain text can have advantages. Most people I know have had the experience of discovering that a particular communication worked much better in writing than it did in speech. Real-time mechanisms can be a very bad choice for some communications. You get more data per second if you are watching ten televisions than if you're watching only one. That doesn't mean that, if you want to learn a lot, the best way to do it is to watch multiple televisions at once. For that matter, while a picture may be worth a thousand words, sometimes it's only worth the exact thousand words it would take to describe the picture. Why would we read code when we could watch a movie of someone reading it, complete with facial expressions, tone, and guestures? Because facial expressions, tone, and guestures swamp our capacity to process input, and leave us feeling like we've really connected but with a very high probability of having completely missed something because we were too busy being connected to think carefully. It's like the way that people *feel* more productive when they multitask, but they actually get less done and don't do it as well. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Seebs on 15 Feb 2010 22:28 On 2010-02-16, James Kanze <james.kanze(a)gmail.com> wrote: > I am. If only because such projects require a larger degree of > accountability than free software can offer. I can't see anyone > providing free software with contractual penalties for downtime; > most of the software I worked on in the 1990's had such > penalties. I think it may be done occasionally. Certainly, if I had contractual penalties for downtime, and my choices were Windows or Linux, I'd run free software. :P -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Alf P. Steinbach on 15 Feb 2010 23:01 * Seebs: [snippety] > Why would we read code when we could watch a movie of someone reading it, > complete with facial expressions, tone, and guestures? You might notice the person picking his/her nose all the time, and goodbye. Or, you might notice that hey, that's [insert name of Really Attractive Lady here], and and that's who I'll be working with via the net? Hah. Better invite her to a working lunch, or something. Otherwise, if learning about the code is your interest, skip the video. Cheers & hth., - Alf
From: Richard on 15 Feb 2010 23:07 Seebs <usenet-nospam(a)seebs.net> writes: > On 2010-02-16, James Kanze <james.kanze(a)gmail.com> wrote: >> I am. If only because such projects require a larger degree of >> accountability than free software can offer. I can't see anyone >> providing free software with contractual penalties for downtime; >> most of the software I worked on in the 1990's had such >> penalties. > > I think it may be done occasionally. Certainly, if I had contractual > penalties for downtime, and my choices were Windows or Linux, I'd > run free software. :P > > -s Why? -- "Avoid hyperbole at all costs, its the most destructive argument on the planet" - Mark McIntyre in comp.lang.c
From: Nick Keighley on 16 Feb 2010 05:09
On 16 Feb, 03:40, Seebs <usenet-nos...(a)seebs.net> wrote: > On 2010-02-16, James Kanze <james.ka...(a)gmail.com> wrote: > > On Feb 14, 4:56 pm, Seebs <usenet-nos...(a)seebs.net> wrote: > >> On 2010-02-14, James Kanze <james.ka...(a)gmail.com> wrote: > >> > To be really effective, design and code review requires a > >> > physical meeting. Depending on the organization of the project, > >> > such physical meetings are more or less difficult. I've got mixed opinions on this. The real review takes place off line. Explanation and discussion of possible solutions (I know, a code walthru isn't supposed to consider solutions- a daft idea if you ask me [1]) at a meeting. Design meeetings can work. [1] my review comments would then read "I know a much better way to do this! Can you guess what it is {he! he!}?" <snip> > > That sort of thing is essential for any review. You do it > > before the face-to-face meeting. But the reviewer isn't God, > > either; the purpose of the meeting is to discuss the issues, not > > to say that the coder did it wrong. sometimes he *is* wrong! Some things get discussed/argued to death. There is nothing more tedious than going through everey written comment on a long list. I'd rather skip along. "Ok you accept items 1-9 but you don't understand what 10 is about- lets discuss item 10" > If you do it well enough, I don't think the face-to-face meeting does > anything but cater to superstition. I find it easier to communicate with someone if I've met him in layer 1 at least once. I like a mental picture of who I'm talking to. Um except here... > Most people I know have had the experience of discovering that a particular > communication worked much better in writing than it did in speech. Real-time > mechanisms can be a very bad choice for some communications. try dictating hex patches down a phone line. Or unix commands. You rapidly discover Italian vowels aren't the same as ours. "ee? do you e or i?" Imagine if all programming specifications had to delivered in a speech. Or chanted in iambic pentameter (no, spinoza, that's not a challenge) > You get more data per second if you are watching ten televisions than if > you're watching only one. That doesn't mean that, if you want to learn a > lot, the best way to do it is to watch multiple televisions at once. For > that matter, while a picture may be worth a thousand words, sometimes it's > only worth the exact thousand words it would take to describe the picture.. > Why would we read code when we could watch a movie of someone reading it, > complete with facial expressions, tone, and guestures? > > Because facial expressions, tone, and guestures swamp our capacity to > process input, and leave us feeling like we've really connected but with > a very high probability of having completely missed something because > we were too busy being connected to think carefully. It's like the way > that people *feel* more productive when they multitask, but they actually > get less done and don't do it as well. |