Non-technical mistakes made by programmers(makinggoodsoftware.com)
makinggoodsoftware.com
Non-technical mistakes made by programmers
http://www.makinggoodsoftware.com/2009/07/07/5-top-non-technical-mistakes-made-by-programmers/
5 comments
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.
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.
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.
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.
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.
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.
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.
"#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.
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.)
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.
I find #1 and #2 curious, given that martial arts are all about training for the opposite of these, and:
"The popularity of martial arts in the hacker culture deserves special mention. Many observers have noted it, and the connection has grown noticeably stronger over time. In the 1970s, many hackers admired martial arts disciplines from a distance, sensing a compatible ideal in their exaltation of skill through rigorous self-discipline and concentration. As martial arts became increasingly mainstreamed in the U.S. and other western countries, hackers moved from admiring to doing in large numbers." (Jargon file, 2000)
Are 'hackers' a negligible minority of 'programmers'? Or have martial arts ceased to be the "hacker exercise of choice"? (Then again, most other hacker hobbies also seem to "involv[e] concentration, stamina, and micromotor skills".)
"The popularity of martial arts in the hacker culture deserves special mention. Many observers have noted it, and the connection has grown noticeably stronger over time. In the 1970s, many hackers admired martial arts disciplines from a distance, sensing a compatible ideal in their exaltation of skill through rigorous self-discipline and concentration. As martial arts became increasingly mainstreamed in the U.S. and other western countries, hackers moved from admiring to doing in large numbers." (Jargon file, 2000)
Are 'hackers' a negligible minority of 'programmers'? Or have martial arts ceased to be the "hacker exercise of choice"? (Then again, most other hacker hobbies also seem to "involv[e] concentration, stamina, and micromotor skills".)
ESR was never representative of the hacker community.
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.
Perhaps this person needs to reflect on this themselves.
The writer is spanish. Presumably, english is not his first language.
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.