The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Psychology of working with nonprogrammers...

More and more, I'm starting to believe that having some grounding in *psychology* is important to being successful as a programmer (assuming you're a customer facing programmer).  After revisiting Joel's article about the Iceberg Secret, the more I understand that you have to at some level manipulate people's thinking, even though it may seem disengenuous (I know I screwed that up) on some level.  However, it really is for their own good because they just won't understand any other way.  Problem is, I always feel a little icky when I do this because *I* know that the UI is really just a small part of the much bigger project and I feel like some evil manipulative Hannibal Lector-like creature when I do this.  (However I'm coming to learn to control my guilt and in many cases am enjoying manipulating the customer ;) ).


Also, I like the part about sending out the self-congratulatory email with the schedule every week.  When my non-techie collegues seemed to get frustrated with my apparent lack of progress, I started doing exactly that (without having remembered this article, so I give myself a pat on the back :) ).  Once they saw the level of work written out in detailed unambiguous language, let's just say their attitudes changed pretty fast.  And they never forget it because this baby is going out EVERY week with updates and adjustments.

I've also taken to writing down meeting notes along with my schedule and sending those out because people ALWAYS forget what's discussed in meetings.  They'll niggle over  one minor thing that you didn't have time to get to because you were busy covering the 8,000 other suggestions they threw out, most of which they promptly forgot about anyway.  So now I do a little light analysis of the repucussions various suggestions (usually thrown out with no thought of actual impact) will have on the project and force them to see them all and explicity pick and choose in writing.  It helps cull down some of the more...exotic ideas pretty quickly.
Crimson Send private email
Saturday, February 05, 2005
 
 
"*psychology* is important to being successful as a programmer"

I would call these Project Managemer skills, but everything else you say is on the mark.
Anony Coward
Saturday, February 05, 2005
 
 
"I would call these Project Managemer skills, but everything else you say is on the mark."

Yeah, I'm assuming this person is talking to customers, be it the programmer, project manager or whomever.  However, managing expectations in this manner can be useful for communicating with other programmers too, especially those who are fundamentally bad at planning things.
Crimson Send private email
Monday, February 07, 2005
 
 
re: guilt over manipulation --

I really like the idea of blacking out those parts of the UI which aren't functional yet.  I don't see it as manipulation -- it's a readily understandable representation of your progress.  Saying "we're working on the frajm and the twiggle" isn't nearly as effective a means of communication as showing that the frajm and the twiggle are not available on the screen.  (Most) People understand what they see better than what they hear -- you're just making your status visible, which has to be a good thing.
Boofus McGoofus Send private email
Monday, February 07, 2005
 
 
"Saying "we're working on the frajm and the twiggle" isn't nearly as effective a means of communication as showing that the frajm and the twiggle are not available on the screen."

An example of : Dont' tell 'em. Show 'em.

Also, by blacking it out your'e conveying the information in at a level of abstraction that they understand. (.e.g,  to be completely accurate you'd say "commandbutton1.vislble=false") but it's actually much CLEARER (though less accurate) to SHOW them a blacked out control.

It's all about communicating in a language that they understand, rather than the most precise language that *you* know.
Mr. Analogy {ISV owner} Send private email
Monday, February 07, 2005
 
 
"I really like the idea of blacking out those parts of the UI which aren't functional yet.  I don't see it as manipulation -- it's a readily understandable representation of your progress. "

Yeah, you have a good point.  But have you ever run into giving presentations to people who may have dragged and dropped a couple of UI elements using VB 5 years ago and so are now gurus on UI design?  Or maybe they are people who on a fundamental level just don't understand that software engineering is complicated.  So when you tell these people that you haven't make it to some UI element, they act like they know exactly what's involved in building it (or you can see it in their eyes/body language).  For example, they may not realize that populating a table requires a call to a database sitting on another computer, which in turn requires some heavy duty debugging of SQL statements, setting of server parameters, etc, all stuff they'll never see.  They only see the UI element, which of course they are experts in and any explanation of the length of time it takes to build out the full functionality will be seen as a snow job or evasion.  Sometimes you just can't win no matter what.  I've come to accept this.  However, there is still a lot that you can do to control people's thinking...
Crimson Send private email
Tuesday, February 08, 2005
 
 
Well, since you're not trying to manipulate them anymore, you can tell the KnowItAlls exactly what you're doing -- we're not going to work on the GUI (which is they all know is easy) until we've handled the functionality behind it.

Of course, if they're KnowItAlls, they'll proceed to tell you about how easy the functionality behind the GUI is, and you'll just hum some Rolling Stones tunes to yourself until they stop talking.

(Or maybe that's just me.)
Boofus McGoofus Send private email
Tuesday, February 08, 2005
 
 
"Of course, if they're KnowItAlls, they'll proceed to tell you about how easy the functionality behind the GUI is, and you'll just hum some Rolling Stones tunes to yourself until they stop talking.

(Or maybe that's just me.)"


No, it's not just you. :)
Crimson Send private email
Tuesday, February 08, 2005
 
 
Psychology, communication, negotiation, trying to see where others are "coming from" and what pressures they are under .... all these are important in working with other people. Full stop. Doesn't matter whether they are programmers or not.
Freddie boy
Thursday, February 10, 2005
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz