Motivation of software professionals
in [Dot Net]
|
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.
From: Arved Sandstrom on 16 Feb 2010 05:26 James Kanze wrote: > On Feb 14, 4:54 pm, Lew <no...(a)lewscanon.com> wrote: >> James Kanze wrote: >>>> Did you actually try using any free software back in the early >>>> 1990's [sic]? >> Seebs wrote: >>> I did. > >> Same here. > >>> NetBSD was for the most part reliable and bulletproof during >>> that time; it ran rings around several commercial Unixes. I >>> had no interest in g++; so far as I could tell, at that >>> time, "a C++ compiler" was intrinsically unusable. But gcc >>> was stable enough to build systems that worked reliably, and >>> the BSD kernel and userspace were pretty livable. >> James Kanze wrote: >>>> Neither Linux nor g++ were even usable, and emacs (by > >> That's pure fantasy. > >> I used a couple of Linux distributions in the early nineties, >> and they worked better than commercial UNIX variants. > > And I tried to use them, and they just didn't stop crashing. > Even today, Linux is only gradually approaching the level of the > Unixes back then. [ SNIP ] I have to agree with you here. My earliest use of Linux was 1993, side by side with IRIX and SunOS. I don't remember frequent crashing of Linux but there was no question but that the UNIX systems were more stable, more polished and had more capability. Granted, everyone back then was throwing Linux on old PCs, which probably didn't help, but still... AHS
From: Arved Sandstrom on 16 Feb 2010 05:47 Seebs wrote: > 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. [ SNIP ] There is absolutely no question but that some things - many things - work better in written form than in speech. Requirements specifications, design documents, test plans and code itself are good examples. As for code reviews I believe those can go either way. It depends on skill levels overall, skill level differences, personalities, and problems (or lack thereof) with prerequisite artifacts like design and requirements. A code review that involves dysfunctional prerequisites, dubious skill levels amongst the coders, and lots of ego - sort of a common situation actually - is probably best handled f2f. IMHO. But I've certainly seen code reviews that were handled nicely with no personal interaction other than email or chat. This usually happened when good requirements and design informed the whole discussion, all the programmers were skilled, and the egos weren't too large. A lot of times in a real code review you most definitely are managing emotional state. That requires developing a feel for it, which you can't do over chat. Seeing those blank expressions, or looks of anger, is quite helpful in steering the review towards a somewhat productive conclusion. AHS
From: Richard Heathfield on 16 Feb 2010 09:18 Nick Keighley wrote: <snip> > try dictating hex patches down a phone line. Done that. Well, kind of. I once had to dictate assembly language instructions down a phone line to a non-techie (broker), for him to type into DEBUG, and then assemble and run. Fortunately, the program was very short. (Although email and the Web both existed at the time, neither of us had access to either of them, and the broker needed an instant solution, so I couldn't just snail him a diskette.) It wasn't easy! -- Richard Heathfield <http://www.cpax.org.uk> Email: -http://www. +rjh@ "Usenet is a strange place" - dmr 29 July 1999 Sig line vacant - apply within
From: Seebs on 16 Feb 2010 12:21
On 2010-02-16, Arved Sandstrom <dcest61(a)hotmail.com> wrote: > A lot of times in a real code review you most definitely are managing > emotional state. That requires developing a feel for it, which you can't > do over chat. Seeing those blank expressions, or looks of anger, is > quite helpful in steering the review towards a somewhat productive > conclusion. You make a good point here. With some experience, you can learn to preempt a lot of that by attention to wording. At $dayjob, we have a couple of techniques applying to this: 1. Code review is done on a list everyone sees. (We're still small enough to get away with that, for now.) 2. Everyone's code is reviewed, even the "senior" people. 3. Over time, anyone watching the list will see enough people, some of them quite senior, caught in mistakes or oversights, that they'll develop a good feel for how to handle that. It works surprisingly well. When you've seen a couple of the senior staff say "whoops, yeah, I totally missed that, nevermind, I'll submit a V2 in a day or two", it becomes much less worrisome to be asked to fix something. -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! |