

Non-technical mistakes made by programmers - wtfdeveloper
http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/

======
wglb
I am less a fan of "top N _whatevers_ done by _whomever_" lists--seems like an
outline looking for content.

But he does link to the "egoless programming". I remember when that kind of
chatter came out--probably concurrent with "The Psychology of Computer
Programming". I remember thinking then, and still wondering, why there aren't
similar essays about "egoless management" or "Becoming an Egoless Executive".

Just wondering.

And on that topic, I think that separating criticism of the work from the
criticism of the programmer/author/poet is a dicey thing indeed. I wonder if
doing so is just pretending.

------
blhack
On communication...

I'm not so sure that programmers are _bad_ communicators, as much as they just
don't communicate in the same way those they're communicating with do.

I know that I have absolutely NO problem whatsoever communicating abstract
and/or complex technical concepts to and with my my peer group; I also have a
hell of a time trying to figure out what some of my users are trying to tell
me.

I think too many people are quick to jump on the

"Programmers (or just tech people in general) are JERKS! They're unhelpful and
they always push back! They're arrogant!"

While these traits might describe _some_ programmers. They also describe some
accountants, and some architects, and some mechanics, and some janitors, and
some widget makers.

It's frustrating sometimes that the burden falls on the programmer (or tech)
to try and find a metaphor that the user understands, rather than the user
trying to have a _basic_ understanding of their computer.

I'm currently working on a project that involves processing some really big
datasets (okay, probably not that big for some people around here...but bear
with me..). It starts as some text files with ~260 million rows of data. We're
just in the beginning/test/planning phase, and this will eventually grow to >1
billion. People (non-tech) people in our group keep INSISTING that we use
_this_ database engine, or THIS hardware configuration (raid 0...which as
already failed). They refuse to listen to those of us that know what we're
doing. They insist that all of this data should live in one huge table (rather
than our suggestion of either scaling it our horizontally, or using a
directory tree and supplementing it with an index that lives in a database).

Does this mean that we're bad communicators? I think not. I think that there
is SOME burden to make sure that everyone understands everything that falls on
us, but certainly not all of it. We need to be met halfway.

The same goes for the ego. Do I have a huge ego? No, but I know for 100%
certain that I'm more knowledgeable about these things than some of my
colleagues. I also know that I am no expert on it. I'm open to suggestions,
just not those that aren't based in any sort of basic understanding.

~~~
roc
The lay crowd doesn't have time/experience/inclination to understand the
minutia, that's why they defer to the specialist.

Therefore it is always the responsibility of the specialist to communicate
necessary information in a way that's generally understandable. Since their
definition of 'basic understanding' will never match yours, you should be
prepared to explain each necessary component from the ground up until they
_can_ understand the issue at hand.

And the lay are perfectly justified in asking questions/making suggestions
_even if they don't have the first clue what the implications of their
suggestions are_.

Because suggestions should be treated purely on merit, not source. If the
receptionist asks "Raid 0?" your answer should be as tactful, careful and
considered as if the smartest geek you know had said it.

Much of the rest of your comment deals more with 'playing well with others',
rather than communication itself.

Lay people dictating technical solutions despite warnings from their
specialists isn't miscommunication; it's someone being a shortsighted,
micromanaging dick.

~~~
blhack
I think my delivery here might have been a bit..bad.

I'm not talking about specialists giving abstract data to non-specialists. I'm
talking about users that refuse to learn how to use outlook because they can
just ask somebody else. This mentality of "I don't want to learn" usually
leads to the belief that the person doing it for you is bad at communicating.

------
idlewords
I would put "wasting time following content-free links" near the top of that
list.

~~~
zzkt
Just under "Assuming the demo won't end up in production"

------
edw519
Nice to see someone talk about all the "other stuff" once in a while.

"#1-Lack of discipline" and "#2-Big egos" are not non-technical skills. They
are personality traits and apply to everyone.

"#3-Being a bad communicator" - absolutely! In business situations, sometimes
it's half the battle.

"#4-Forgetting about the customer". If you're in business this should always
be #1.

"#5-Not prioritizing the work properly", another bad habit that applies to
almost everyone.

I think OP missed the #1 (closely related to the Customer) non-technical
mistake made by programmers: systems analysis. Determining _what_ to do before
determining _how_ to do it.

I've seen plenty of bad software, but I've seen just as many projects fail
with good software written to do the wrong thing. When we learn to spend more
time on the "what", the "how" invariably gets easier.

~~~
abyssknight
Understanding a customer's needs is perhaps the greatest skill a developer can
learn. I once met a colleague who refused to work on a project until they
explained to him what it was for, why they needed it, and how they intended on
using it. It took me a year or two to really understand how wise that was. Of
course, we're assuming the customer knows what they want. (PT: They don't.)

~~~
DougWebb
I find one of the biggest challenges, and best skills to develop, is getting
the customer to describe the problem they're trying to solve rather than the
solution they think they need. My job, as a Software Engineer, is to figure
out the best solution for the customer's problem, not just to implement the
solution the customer requested.

------
peregrine
3.- Being a bad communicator. Focus. They just talk about what is need to be
understand.

Perhaps this person needs to reflect on this themselves.

~~~
codemonkey
The writer is spanish. Presumably, english is not his first language.

