Motivation of software professionals
in [Java Programming]
|
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!
From: Branimir Maksimovic on 16 Feb 2010 15:25
Richard Heathfield wrote: > 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! > That guy was pretty techie, because it contradicts my experience. For example one guy was not capable to just find and change parameter in config file, and I mailed him that. Problem was that config file had about 1000 lines and he didn;t knew how to apply case insensitive search. In my experince lot of them don;t even know what is text editor let alone debugger. So that guy was techie for, sure.... Greets |