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]

"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?"