A Difficult Book

[liralen]

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.

Comments

[zamiel.livejournal.com]

If the inbound axiomatic assumptions are wrong, the argument is wrong. Period. You just proved my point for me, thank you.

If I'm designing software for a hospital management system, and insist on the process being about what database we use during the specification phase, I'm wrong. There's no way around that fact and no amount of trying to convey sympathy and understanding will change that fact. If I don't know what's important to a user on a project (and you usually don't until you actually sit down with them and see what it is they want to do, and how), then if I proceed under that false asumption, I'm wrong. If I'm letting my past experiences blind me to present facts, I'm wrong. Conversely, if someone else is doing these things, they're wrong. This isn't really rocket science, honestly. Its simple logic and science.

Its a terrifyingly easy trap to fall into to say "Well, its all just a matter of perspective." But its really not. Its either sensical, or not. Logical, or not. Defensible, or not. Of two things are equally defensible, then one considers efficiency. If axioms differ so far on whether or not something is defensible or not, the only solution is the death of one of the conflictants.

Really, its simple.

[liralen.livejournal.com]

Sure. For that particular argument, yes.

It's cool to know the context of that argument, and that case is very clear cut for you. So knowing your context and knowing exactly what kind of argument you're talking about, yes, it isn't applicable.

In the context of 'should the GUI have a menu item labeled 'Delete Implementation Data' or 'Reset Project Status'. Or 'Should we put in a Source Control System'? It *is* entirely a matter of perspective.

Your conversation and my conversations are different conversations about different things.

Also, from what you originally wrote, it seems that I did misrepresent the book, as it's actually about the fact that 95% of all conversation do end up about being what's wrong or right, and the question simply is, "Is that where you really want it to be?" Sometimes the answer is yes. I just fine that, usually, it isn't nearly as useful as other conversations I could be having.

And in your case, it clearly is yes. But 95% of my conversations aren't about things that are that clear

[zamiel.livejournal.com]

"Should we put in a source control system?" is easy. Its "yes." The first time ten days worth of coding are lost because someone futzed an entire strand of updates will teach you that, tout suite.

Interface issues are always fairly clear; you can argue about exact phrasing, but let's be honest: just labeling the thing with what it is solves 95% of those issues. Now, if the question is whether or not you should give the user the ability to do that, well, that's not your call. Ask the client. If they don't know, add the feature and an option to toggle it off, and be done with it. That's not an issue for discussion, its a way for people to dick-off actual working in preference for "discussing soft issues." Ie. be slack.

When it comes down to it, there are only two kinds of meaningful decisions:

Is this true?

and ...

Which is more efficient?

If it can't be boiled down to one of those two, especially in the accomplishment of a task, its wasted time.

You'd never know I do high-end corporate technical support; 99% of my co-workers seem to have bought in to the whole "give them warm fuzzies and ignore the problem" clap-trap. This may be why they get yelled at by clients, and I get respected.

[liralen.livejournal.com]

You didn't ask context, so you didn't get the actual problem for 'Should we put in a source control system?' And you came up, exactly, with the same answer all the other software engineers came up with, which doesn't take into account either efficiency or truth about what's really needed.

We do hardware tools for hardware engineers to design chips. Do hardware engineers need a source control system? Do they need it now? What parts to they need? Can we actually do it better for them than the tools they already have? Do we have the time to include it when we have to trade off twenty other features for it?

Sure, the simple answer, without asking question or questioning ones initial assumptions. Then it's easy. You can say it's true because of what you believe to be the problem. It's more about figuring out what more *is* there than your intial assumption.

[zamiel.livejournal.com]

You know, even with increased context, I still have to say "Yes, they need some kind of source control system," on this one. Now, whether they already have one as part of their already extant practices is a whole other issue, and might not be immediately recognizable to someone outside the process, which is why one actually studies these things for the spec before writing them. Odds are not only do they need it, but they probably do need it now (and, in fact, it probably is already embedded in current practice; having engineers walking all over each other's traces would make things too difficult to believe they don't have one).

Now, the only real question here with a question on the scale is "Do we have the time to include it when we have to trade off twenty other features for it?" And that one comes down to examining the position of where the software you're writing is intended by the customer to fit into their work flow. If all the ap is intended to do is edit flow control block diagrams, and said diagrams are kept on disks in a cabinet that have to be fetched and replaced with changes logged to a seperate piece of groupware, then the SCS isn't part of the ap, but it definitely has to be in place. If, on the other hand, the customer wants the ap to replace the whole fetch-the-disk/log-the-changes/replace-the-disk cycle, then the SCS has to be built into the software.

Maybe I'm unique, but I'm aware that processes extend beyond aps into how the ap is used, and if you're not part of the design process for that too, you're pretty much going to be implimenting useless shit (like Compaq's upcoming call-tracking system, Pulse, designed by useless yard-apes and management-munchers who haven't taken a call in their lives). There is no question hardware engineers need an SCS. There might be a question about whether or not its in a given ap or not. Maybe. In general, it'll be pretty bloody obvious from looking at the customer's spec and processes.

[marypcb.livejournal.com]

you subscribe to programming as a skill rather than an art? It would be nice if all the interface problems were that solved, but I don't think they are.

[zamiel.livejournal.com]

I subscribe to life as a skill rather than an art. Programming is just a large subset thereof.

Art, on the other hand, generally involves the phrase, "Do you want fries with that?"

[liralen.livejournal.com]

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.

[zamiel.livejournal.com]

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.)

[agrimony.livejournal.com]

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.