liralen: Finch Painting (Default)
Liralen Li ([personal profile] liralen) wrote2002-04-29 10:26 am

A Difficult Book

So our CEO gave everyone this book called, Difficult Conversations last week and there have been all kinds of jokes about the book going on around the office. No one likes being told what to read or what can help them, I guess.

But everyone got a copy in their mail, and I, wordaholic that I am, started reading it just 'cause it was in front of me.

It was hard to read.

Mostly because the examples they had in the book probably reflected every difficult, argumentative and hard conversation I've had in my life. It was oddly a relief to know that everyone has these kinds of conversations and has them blow up so completely, and also oddly stressful and terrifying, in some ways, to read these things because of all the hooks they had into old conversations that I never felt that good about. The first third of the book was incredibly hard for me to read.

Until I hit the 'know your tendency' bit about some folks tend to blame others and other folks tend to soak up blame. I suddenly tied in the fact that I really, truly soak up blame partially because I believe that if I know that I was at fault then I can do something about it in the future. But I realize, now, that I nearly always go too far in that, especially when I'm talking with someone who really tends to want to blame others. I knew it in vague ways before it was stated so plainly, but now it's pretty damned clear.

It was odd to realize that and realize that a lot of my discomfort in reading this stuff was because I was going back to all those old conversations and thinking, "Damn... I fucked that up..." and at the same time I was also thinking, "Why do *I* have to do all the work all the time?" add to that all the old emotions of "But I can't care so much when I get hurt so badly." With the additional information, it was clear that while I have made mistakes, it isn't up to me to fix them *all* and I can't go back in time and I can do better with the people that really do care to listen to me and that lifted the worst of the reaction. Whew.

I've always thought arguments were pointless, and I've realized in the past that on the most part, whenever I've been in a strenuous argument with anyone all it does is harden each person in their position. I always thought it was just human nature and always felt kind of sick and guilty about fighting, but never really figured out *why*. This book finally gave me the key as to *why*. There are far more important and interesting things to figure out in a conversation with someone than who is 'right' or 'wrong' or 'to blame'... and it was really cool to get a concrete feeling as to why and exactly what those more useful, constructive things are and why there are so many people I really enjoy talking with. Whew.

I also realized why I actually have no problems even talking about sometimes delicate stuff with most people, but there have been three or four people that have made me feel like it was all my fault that we couldn't seem to talk about anything without a fight. While I did do stuff to escalate what was happening, it isn't just me, and it was especially important to me to figure out to really look at the fact that there are many other people that I am comfortable talking with and whom are very, very comfortable talking with me about stuff they never could talk about with anyone else. Balancing the reality of my relationships and interactions against how a few people decide to see me. But now I can see why they decided some of that, too. That was very cool to learn.

So I'd recommend this book to anyone that is terrified of talking to *someone* about something they don't want to hear.

[identity profile] liralen.livejournal.com 2002-04-30 10:33 am (UTC)(link)
Hm. I thought more about this...

The axioms I run across are far more like one guy who believes "Software should be complete and should gracefully handle error conditions." versus a guy who really believes that 'Software should be written on time and should be clean and efficient code.'

Which axiom is 'right'? For me they both are, but to varying degrees at different times in the design process. And they come into conflict some of the time, but not all the time. Sometimes the decisions they make are the same. Sometimes they're wildly different because of the emphasis they have. That's when I hear one guy muttering about 'slack bastard' and the other muttering about 'turn a perfectly elegant solution that *works* from one page to twenty of illegible code.' Which is right? It may not matter when the real problem is 'what did will take care of the problems the user sees?'

Again, your 'if' makes for a particular kind of context. If it were in the medical equipment shop I once interviewed at the question of databases would never have come up because they only had one that was tested enough for FDA approval. If it were in another software shop I was working at, the real question would have been 'Process, WHAT process?' At yet another, where engineering was told, point-blank, "you do NOT figure out requirements or specifications you code what we tell you", then implementation is where they always started.

Sure. Given a context, there is usually a more efficient and better way to do anything, plus an answer that can be obviously correct to all involved. Given any group of engineers, we usually find something that satisfies the requirements and is sweet to build, that, for us, is 'right' and true. But to assume that it'll work everywhere leads to the engineer that tries using one technique on every problem they face.

[identity profile] zamiel.livejournal.com 2002-04-30 04:00 pm (UTC)(link)
I may have the hammer-solution methodology, but I have a lot of hammers. This generally keeps me from obsessing on one particular solution, whether that be a detriment or advantage (and there are advantages to the obsessive solutioner; if nothing else, he gets good at implimenting that solution).

Now, as for what to do with the two programmers above, is get the first one solving the P=NP problem, and while he's doing that, put a bullet into the back of his head. With that as a warning, teach the other guy to include more frequent error trapping as a second-pass implimentation refactoring, and you'll end up with one trained programmer with the right mix of habits. No one that believes that software can be complete can be allowed to live; its bad for the gene-pool. Mainly because I'd rather manage five programmers who believe that code should be in on time than ten of which five aren't hitting the implimentation deadlines. Retasking two of the five on refactoring for error trapping as the final set of deadlines nears assures that I'll get efficient, clean error-trapping on time and thus is a net win.

(This is why I have so much fun in management courses. Of course, I've been refered to as Torquemada, too.)

[identity profile] agrimony.livejournal.com 2002-05-01 10:28 am (UTC)(link)
I subscribe to the axiom that software should be complete and should gracefully handle error conditions while being written on time and should be clean and efficient code. :) A dream world, I know. And I'm not a programmer. And there are trade offs necessary in any process to hit a deadline and and and...

But from the view point of an ideal world where, more often than not, I end up supporting this stuff brilliant programmers write... I like all those things. :)

This is apropos of nothing.