Off-topic: Corrisponding Successfulness of Software Engineers with Communication Ability...

[Daniel Pitts]

I was just wondering what others experience was with this.
I've noticed that there is a population of "Engineers" who lack proper
communication skills. "can u hlp with my proj!"
Has anyone else noted if the success level of a programmer is related
to, and in what proportions, technical ability and communication
skills?

In my current position, I've found that I enjoy my work better once
I've improved my communication skills. I have always tried to use
proper-enough English, but I've recently discovered the ablity to
convey concepts to people whom I would otherwise confuse.

Anybody else have any comments?

 

[Lew]

I was just wondering what others experience was with this.
I've noticed that there is a population of "Engineers" who lack proper
communication skills. "can u hlp with my proj!"
Has anyone else noted if the success level of a programmer is related
to, and in what proportions, technical ability and communication
skills?

In my current position, I've found that I enjoy my work better once
I've improved my communication skills. I have always tried to use
proper-enough English, but I've recently discovered the ablity to
convey concepts to people whom I would otherwise confuse.

Anybody else have any comments?

I rate this question as fundamental and primary, in other words, at the core
of much of one's experience and of great importance.

Arguably the single most important aspect of human life is communication.
iPod, designed for music, became the home of the podcast. People talk.

More obviously, success in pretty much all human endeavor is tightly linked to
communication skills. Isn't communication foremost in cooperation? In turn,
isn't cooperation required for success?

Not only do your compatriots understand your explanations better now, but they
also feel more comfortable with you, and probably have an enhanced sense of
intimacy and empathy with you. Henceforth they are more likely to be patient
with you, to support you in difficult conversations and the like.

Likewise you will feel more intimacy and empathy, and the rest, where they are
concerned.

Even if that didn't materially contribute to your success, isn't life more
satisfying that way?

- Lew

 

[Alex Hunsley]

I was just wondering what others experience was with this.
I've noticed that there is a population of "Engineers" who lack proper
communication skills. "can u hlp with my proj!"

I'm with the other repliee on this one - communication is very important
- verbal, written, and other more abstract kinds.

Has anyone else noted if the success level of a programmer is related
to, and in what proportions, technical ability and communication
skills?

My (anecdotal) experience over ten years of professional engineering is
that pretty much everyone I've ever worked with in this line has had
decent communication skills. No txt speak, no sloppiness (and even a
willingness to read what they've just written to see that it makes sense!)

The one exception, interestingly, was at a company I worked where a guy
joined on the back of a strong CV which it soon transpired was a little,
er, counter-factual. I noticed he used txt speak in his emails at work -
which was a glaring exception to my usual experience. Purely anecdotal
however.

Using well formed language isn't just a matter of prissiness or pedantry
IMO.
Two points that come to mind:

a) the more you deviate from normal language, e.g. by using txt speak,
the more someone reading is noticing that (and potentially getting
annoyed by it). And the more they notice it, the less they are thinking
about the subject of the email - in effect, it increases cognitive load.

For the same reason, other distractions like politics should stay out of
code. By politics I mean things like writing M$ instead of MS. People
sometimes let off steam about a particular incomparability or issue in a
comment - and I think that's fair play - but stuff like writing M$ for
MS I find unprofessional (plus, you never know who might end up reading
your code!)

b) Sticking closely to well written English (or whatever language)
actually increases your potential audience. People who aren't very adept
at English, for example, quite possibly won't recognise abbreviations
like "hv" or "bcoz". Again, it can be seen as increasing cognitive load,
and possibly blocking understanding.

In my current position, I've found that I enjoy my work better once
I've improved my communication skills. I have always tried to use
proper-enough English, but I've recently discovered the ablity to
convey concepts to people whom I would otherwise confuse.

Good stuff.

I still manage to confuse non-engineers every now and then by using
words I completely take for granted. "Default" is one word that comes to
mind.

lex

 

[Chris Uppal]

Has anyone else noted if the success level of a programmer is related
to, and in what proportions, technical ability and communication
skills?

I think there are two parts to this. One is about communication skills in
general, the other is about a love of precision.

Programming is /all about/ communication -- I can't think of many professions
in which wide-ranging factual communication skills are more essential. (There
are certainly professions in which more focussed communication skills, or
non-factual ones, are even more essential -- think of salesmanship for
example). A good programmer has to be able to understand other people
regardless of whether (a) the other person knows what s/he is talking about
(they may be talking about their own subjects, or may be attempting to talk
about the programmer's subjects); and of whether (b) the programmer knows what
the other person is talking about; and of whether (c) the other person is a
good communicator themself (communication is part of /our/ job, it's not their
responsibility). Similarly, programmers (if they are to be any good) have to
be able to /explain/ things, again both to technical and non-technical people.

Of course, many programmers /aren't/ good communicators. They neither listen
well, nor speak with due empathy for their audience. Such people also tend, I
find, to write bad code -- specifically, /uncommunicative/ code. In a way
that's incidental to my point since I'm claiming that direct communication with
other people (which includes writing comments) is of central importance to the
programmer's work -- it depends on whether you think of "good" code primarily
as code which is likely to work as intended, or primarily as code which is
comprehensible (those are not conflicting requirements of course -- thankfully,
or we'd all be in deep shit).

Now good communication is not the only talent that's needed to be a good
programmer (having a good memory comes to mind, as does a talent for abstract
thought). One other... er... well, let's call it a talent, if only for
politeness sake, is a love of precision. A need for clarity. You can't be a
good programmer, or rather you can't write a good program, if you don't
understand the nature of the task, and the approach you are taking to solving
that task, and in precise detail. So, the chances are that any good programmer
is going to be the kind of person who /naturally/ works to attain that state --
call it an aversion to muddle. Such a personality trait likely to show up in
other activities -- for instance in use of language. So I think there's good
reason to expect that most good programmers are going to be precisionists in
all (or most) things, and thus to prefer using and hearing "well-formed"
language.

Going off at a slight tangent: my experience is that the best programmers are
extremely rigid in the little ways that they write code. For instance /always/
putting a space before a ; or /never, ever/ doing so. Or in how/whether they
place spaces around = or brackets. (And the great layout debate comes in here,
of course.) I think that inconstancy in such (let's be honest) inessentials is
a good sign that the program itself will be sub-standard. It isn't that care
in such matters makes someone into a better programmer, but that good
programmers tend (I have never met a counter-example, in fact) to take care
automatically. I think that the same effect will probably show up in the way
that good programmers use language.

There are probably other effects too. Programming is itself a rather
linguistic activity, so it may be that programming attracts people with a love
for using language. If so then being a good programmer would probably
correlate quite well with using very deliberate sentence construction and so on
("deliberate" as opposed to "careless" rather than to "informal"), even if my
main two claims should prove to be utter tosh.

tx 4 ur attntion.

-- chris

 

[Alex Hunsley]

Chris Uppal wrote:

[snip]

Now good communication is not the only talent that's needed to be a good
programmer (having a good memory comes to mind, as does a talent for abstract
thought). One other... er... well, let's call it a talent, if only for
politeness sake, is a love of precision. A need for clarity. You can't be a
good programmer, or rather you can't write a good program, if you don't
understand the nature of the task, and the approach you are taking to solving
that task, and in precise detail. So, the chances are that any good programmer
is going to be the kind of person who /naturally/ works to attain that state --
call it an aversion to muddle. Such a personality trait likely to show up in
other activities -- for instance in use of language. So I think there's good
reason to expect that most good programmers are going to be precisionists in
all (or most) things, and thus to prefer using and hearing "well-formed"
language.

You've sparked off an interesting line of thought for me: studying Comp
Sci at A level, we touched upon issues around formal languages, and in
particular the following question: "Would it make sense to have a
programming language that consisted of plain English?" And of course,
the answer was/is "No, since a lot of English constructions are open to
interpretation and inexact." Hence the use of formal languages. I just
found this curious to think about in light the above conversation...


This also reminds me of the idea of having code shared between people
via a process of automatic 'styling', which gives each person a view of
the code that they're used to. In other words, the 'static noise' (i.e.
whitespace and non-important formatting) looks different for different
people depending on what they're used to...

Could make diffs interesting though! (The tool would have to handle that
too.)
Wonder if such a thing will ever exist? Waste of time perhaps? I think
perhaps Roedy Green touched on such ideas on his website...

Thanks for the interesting post by the way! (And to the OP for the
interesting question.)

 

[Alex Hunsley]

Chris Uppal wrote:

[snip]

Now good communication is not the only talent that's needed to be a good
programmer (having a good memory comes to mind, as does a talent for abstract
thought). One other... er... well, let's call it a talent, if only for
politeness sake, is a love of precision. A need for clarity. You can't be a
good programmer, or rather you can't write a good program, if you don't
understand the nature of the task, and the approach you are taking to solving
that task, and in precise detail. So, the chances are that any good programmer
is going to be the kind of person who /naturally/ works to attain that state --
call it an aversion to muddle. Such a personality trait likely to show up in
other activities -- for instance in use of language. So I think there's good
reason to expect that most good programmers are going to be precisionists in
all (or most) things, and thus to prefer using and hearing "well-formed"
language.

You've sparked off an interesting line of thought for me: studying Comp
Sci at A level, we touched upon issues around formal languages, and in
particular the following question: "Would it make sense to have a
programming language that consisted of plain English?" And of course,
the answer was/is "No, since a lot of English constructions are open to
interpretation and inexact." Hence the use of formal languages. I just
found this curious to think about in light the above conversation...


This also reminds me of the idea of having code shared between people
via a process of automatic 'styling', which gives each person a view of
the code that they're used to. In other words, the 'static noise' (i.e.
whitespace and non-important formatting) looks different for different
people depending on what they're used to...

Could make diffs interesting though! (The tool would have to handle that
too.)
Wonder if such a thing will ever exist? Waste of time perhaps? I think
perhaps Roedy Green touched on such ideas on his website...

Thanks for the interesting post by the way! (And to the OP for the
interesting question.)

 

[Martin Gregorie]

Chris Uppal wrote:
..../...

Programming is /all about/ communication -- I can't think of many professions
in which wide-ranging factual communication skills are more essential.
>

A very good point and one that don't get nearly enough emphasis when
programming is being taught.

I think that a number of language designers have forgotten this too:
personally, I think that the use of generics may be a useful shorthand
but, like the badly thought out names for classes, methods and
variables, it tends to obscure the meaning of the code. Things weren't
like this in the past. To pick on an ancient example, the introduction
to the specification for Algol 60 explicitly says that the language was
designed to program computers and *to communicate algorithms between
people* (my emphasis). No doubt that one reason why the language, like
Pascal, uses BEGIN...END; rather than {...};

 

[Martin Gregorie]

Alex Hunsley wrote:
..../...

You've sparked off an interesting line of thought for me: studying Comp
Sci at A level, we touched upon issues around formal languages, and in
particular the following question: "Would it make sense to have a
programming language that consisted of plain English?" And of course,
the answer was/is "No, since a lot of English constructions are open to
interpretation and inexact." Hence the use of formal languages. I just
found this curious to think about in light the above conversation...

Its also somewhat proven by COBOL, which seems to have been designed on
the premise that there are people who can understand

MULTIPLE HOURLY-RATE BY HOURS-WORKED GIVING BASIC-WAGE.

but who would be totally confused by

basicWage = hourlyRate * hoursWorked;

 

[John W. Kennedy]

Alex Hunsley wrote:
..../...
Its also somewhat proven by COBOL, which seems to have been designed on
the premise that there are people who can understand

MULTIPLE HOURLY-RATE BY HOURS-WORKED GIVING BASIC-WAGE.

but who would be totally confused by

basicWage = hourlyRate * hoursWorked;

Partly, but it's also the case that COBOL was the first language to dive
into the pool of fixed-point noninteger arithmetic, with its concomitant
problem of intermediate-result precision. In fact, the original 1959
COBOL completely screwed the pooch on the COMPUTE statement, by
declaring the whole issue to be implementation-dependent, and the
problem wasn't fixed until COBOL 2002 -- in fact, the fix is still only
an optional extra. (PL/I did it better in 1965, but with a
one-size-fits-all solution that was not completely satisfactory; Ada
finally got it right in 1983.) As a result, for over 40 years, only the
ADD, SUBTRACT, MULTIPLY, and DIVIDE statements were safe to use in COBOL.

 

[Martin Gregorie]

Partly, but it's also the case that COBOL was the first language to dive
into the pool of fixed-point noninteger arithmetic, with its concomitant
problem of intermediate-result precision. In fact, the original 1959
COBOL completely screwed the pooch on the COMPUTE statement, by
declaring the whole issue to be implementation-dependent, and the
problem wasn't fixed until COBOL 2002 -- in fact, the fix is still only
an optional extra. (PL/I did it better in 1965, but with a
one-size-fits-all solution that was not completely satisfactory; Ada
finally got it right in 1983.) As a result, for over 40 years, only the
ADD, SUBTRACT, MULTIPLY, and DIVIDE statements were safe to use in COBOL.

Fair point, though all the implementations I've used: ICL mainframe
(1900 and 2900), Tandem NonStop, MicroFocus haven't suffered from that
problem AFAICT.

The best example of the fallacious theory that "some folks can't
understand mathematical notation but can read pseudo-English without
problem" is provided by comparing the MOVE statement with simple
assignment. Assignments are simple copies but a MOVE has huge
ramifications when you consider all the type conversion and editing that
can happen within it.

 

[John W. Kennedy]

Fair point, though all the implementations I've used: ICL mainframe
(1900 and 2900), Tandem NonStop, MicroFocus haven't suffered from that
problem AFAICT.

As long as you stuck with one machine architecture and one compiler,
you'd generally be OK, but in cross-system use, the COMPUTE statement
might as well be a random-number generator. They left the semantics of
COMPUTE A = B / C + D for the compiler writers to decide, and one of the
reasons that it took over 40 years to fix, and that the fix is still
optional, is because compiler writers took different choices. (It is my
understanding that the fix follows, at least approximately, the rules
used by IBM, which are also approximate the rules that IBM designed into
PL/I.)

The best example of the fallacious theory that "some folks can't
understand mathematical notation but can read pseudo-English without
problem" is provided by comparing the MOVE statement with simple
assignment. Assignments are simple copies but a MOVE has huge
ramifications when you consider all the type conversion and editing that
can happen within it.

I'm afraid you've lost me completely on this. A COBOL MOVE on elementary
items does pretty much what you would expect an assignment statement to
do. The ugly thing is that the MOVE statement on groups (without the BY
NAME option) does a straight bit copy, even if it's nonsense.

 

[Martin Gregorie]

I'm afraid you've lost me completely on this. A COBOL MOVE on elementary
items does pretty much what you would expect an assignment statement to
do.

....provided that the elementary items are unedited and of the same type,
e.g. character string to character string, numeric to numeric, but MOVE
will also convert numeric to character (right justified, zero filled on
the left IIRC). Its affected by JUSTIFIED LEFT/RIGHT qualifiers and will
attempt to convert character to numeric, usually with unexpected
results. If the fields are edited (e.g. character pictures containing B
or literals or edited display numeric fields) the effects of the MOVE
can get quite complex. Consider the fun and games you can have with
something like PIC "$$,$$$,$$9.99DB" BLANK WHEN ZERO and its more
complex bretheren. Now consider what happens if the unwary coder MOVEs
such a display edited numeric field to, say a PIC 9(6) COMP SYNC field.

The ugly thing is that the MOVE statement on groups (without the BY
NAME option) does a straight bit copy, even if it's nonsense.

Sure, but its useful: you often want to copy an entire group field
without conversion or editing. In fact I've seen people get in more
trouble with MOVE CORRESPONDING, which has been banned in most places
I've used COBOL because its such a nightmare to maintain in the face of
change requests.

As I said, at the top of this discussion, MOVE looks simple but almost
never is in reality: assignment statements are *much* simpler.

 

[Chris Uppal]

This also reminds me of the idea of having code shared between people
via a process of automatic 'styling', which gives each person a view of
the code that they're used to. In other words, the 'static noise' (i.e.
whitespace and non-important formatting) looks different for different
people depending on what they're used to...

Yes, it's an idea that gets proposed from time to time (often by people who are
sick of hearing debates about "optimal" code layout). It's pretty trivial to
do if the IDE has the right architecture, and if anyone wants to add it (for
instance the Smalltalk IDE I use has an option to do it).

Could make diffs interesting though! (The tool would have to handle that
too.)

Simplest way would be to [re]format the code into "project default style"
before diffing (and also before entry into source management systems). A
better idea would be to make all those systems aware of the grammar of the
language(s) they were dealing with (semantics too, would help -- but for
different reasons).


But, personally, I think its a horrible idea. The point is that people (if
they have any sensitivity to code at all) /don't/ lay code out according to
some totally mechanical algorithm -- without thought for the /meaning/ of the
code. It is normal to have variations from the default (especially in vertical
space) which indicate the /phrasing/ of the code (to borrow a musical metaphor
suggested over on comp.lang.smalltalk.dolphin). Another example would be to
keep operations on X and Y coordinates paired together in a way which would
violate the default rules (this attempt to do precise code layout in OE will
probably fail miserably -- you'll just have to imagine what it /should/ look
like...):

float x, y;
float x2; y2;

x = somewhere(); y = somewhereElse();
xM = x * 2; yM = y * 2;
x += increment; y += increment;

System.out.println(
"Original: (%d,%d)\tDoubled: (%d,%d)"),
x, y,
x2, y2);

And automatic layout (unless done by an AI -- which is beyond the current state
of the art ;-) just discards that information. Throwing information away,
especially information about something as sensitive as code, is only justified
if there wasn't any information there in the first place. But that's (sort of)
my point from the earlier post -- if the programmer's any good then s/he /will/
be sensitive to meaning and communication, and will have used layout (etc) to
help the reader see the structures in the code.

-- chris

 

[John W. Kennedy]

....provided that the elementary items are unedited and of the same
type, e.g. character string to character string, numeric to numeric, but
MOVE will also convert numeric to character (right justified, zero
filled on the left IIRC). Its affected by JUSTIFIED LEFT/RIGHT
qualifiers and will attempt to convert character to numeric, usually
with unexpected results. If the fields are edited (e.g. character
pictures containing B or literals or edited display numeric fields) the
effects of the MOVE can get quite complex. Consider the fun and games
you can have with something like PIC "$$,$$$,$$9.99DB" BLANK WHEN ZERO
and its more complex bretheren. Now consider what happens if the unwary
coder MOVEs such a display edited numeric field to, say a PIC 9(6) COMP
SYNC field.

And how does this differ in concept from the interesting things that can
happen when converting between floating-point and integer in, say, Fortray?

 

[Martin Gregorie]

And how does this differ in concept from the interesting things that can
happen when converting between floating-point and integer in, say, Fortray?

Pass - I don't speak Fortran.

As I was attempting to point out, there seems to have been an odd
mindset when COBOL was designed. It assumed that, while mathematicians
and engineers could understand pseudo-mathematical notation, there was a
whole bunch of business-oriented people who couldn't make sense of an
algorithm unless it was written in pseudo-English.

As an illustration I pointed out all the stuff that's potentially
concealed in a simple-looking MOVE that makes a MOVE not so simple to
understand. That was all: I had no other motive..

 

[John W. Kennedy]

Pass - I don't speak Fortran.

Then consider:

int i = 123;
double d = i;

in Java; the same principle applies. There is no particular oddity in
the concept of an assignment from a variable of one type to a variable
of another type doing so by type-to-type conversion of the value.

As I was attempting to point out, there seems to have been an odd
mindset when COBOL was designed. It assumed that, while mathematicians
and engineers could understand pseudo-mathematical notation, there was a
whole bunch of business-oriented people who couldn't make sense of an
algorithm unless it was written in pseudo-English.

Well, seeing that the original COBOL designers completely botched the
design when it came to pseudo-mathematical notation (which they did
include, in the form of the COMPUTE statement, but with undefined
semantics), maybe that's just as well.

(Interestingly enough, IBM's early COBOL rival, Commercial Translator
[sometimes known as COMMTRAN] did computations with formulae, with a SET
statement similar to the COBOL COMPUTE statement, but also had a
separate ADD statement, on the assumption, I suppose that += is a much
more common operator than -=. *=, or /=. Like COBOL, Commercial
Translator, judging from the limited material available at
bitsavers.org, did not undertake to solve the intermediate-results
problem. Perhaps it actually did everything under the covers in binary.)

 

[Martin Gregorie]

Then consider:

int i = 123;
double d = i;

But that's just numeric->numeric. Don't forget that MOVE can copy almost
any elementary field to any other elementary field without getting a
compilation error. Whether the results are useful is quite another
matter, of course, but IIRC the Fortran compiler would be just as
allergic as Java to assigning a double to a string.

 

[John W. Kennedy]

But that's just numeric->numeric. Don't forget that MOVE can copy almost
any elementary field to any other elementary field without getting a
compilation error. Whether the results are useful is quite another
matter, of course, but IIRC the Fortran compiler would be just as
allergic as Java to assigning a double to a string.

COBOL needed a more general form, what with the requirement for PICTURE,
etc. But it's not as free-and-easy as you seem to think, although the
PL/I assignment statement is.

 

[Andrew Thompson]

I was just wondering what others experience was with this.
I've noticed that there is a population of "Engineers" who lack propercommunicationskills. "can u hlp with my proj!"
Has anyone else noted if the success level of a programmer is related
to, and in what proportions, technical ability andcommunication
skills?

This thread has produced some interesting replies,
but I would now like to take it over to discussing
an aspect that I do not believe has been mentioned.

"Non-english speakers communicate better with
an international audience."

By "Non-english speakers", I am referring to
people who are fluent in English, yet still
think in another language.

Why?

The point is perhaps demonstrated on the thread
'Java Programmer'
<http://groups.google.com/group/comp.lang.java.programmer/browse_frm/
thread/533a41314519d962/5d136be6c0307670#5d136be6c0307670>

I made a comment re. Google groups that I did
not think much about, "Which, as an aside,
and a groups user, I have never noticed.",
or rather, I was thinking of my minor
point about GG, rather than how to express it.

Someone who thinks in a language that is not
English, but then has to translate thoughts
to English, might take more time to think about
*how* to express that thought in a way that
can be understood by others.

Thoughts? (Especially from people willing to
identify their primary language. My one and
only language is English - in case anybody is
unclear.)

BTW - Daniel..
<http://www.google.com/search?q=Corrisponding>
;-)

Andrew T.

 

[Michael Rauscher]

Someone who thinks in a language that is not
English, but then has to translate thoughts
to English, might take more time to think about
*how* to express that thought in a way that
can be understood by others.

Maybe. My native language is German and - you're right - it takes me
(much) more time to write in English.

I *try* to make as less errors as possible but I think that my English
writings are full of (grammatical) errors.

On the other hand I try to write as simple as possible. This results in
writings that use simple words and simple sentences (complex sentences
increase the risk of making errors *g*). They aren't stylish, of course
but perhaps (I hope) they can be understood by others.

Since there's no feedback on my writing that tells me where I used
incorrect English, I can't rate them.

Bye
Michael