Some soft skills

Explain

I’m a good communicator. I’m good at explaining stuff to all kinds of people, tech nerds or beginners or managerial folks, whoever.

And I positively love doing it. You want to do me a favor? Here is one recipe that will work each time: Bring some time, find me when I have some to spare, too, ask me any question about any topic dear to my heart; finally, be genuinely curious about what I have to say.

I like explaining so much, I don’t mind doing it in writing, either. Developers hate writing documentation? Not this developer…

I even enjoy presenting something in front of a crowd. As my time permits and opportunity arises, you can find me giving presentations at INNOQ-internal events, sometimes even at public IT conferences, helping out at Berlin Rail’s Girls beginners’ workshops or “Code and Cake”, or giving presentations for radio amateurs.

At your service!

I’ve often been in charge of infrastructure that developers and others had need to use. I’ve also been a contact point between development teams and customers, or between development teams and development teams. People generally find me supportive and helpful.

I’ve got service mentality. If my service is broken from your point of view, I’ll listen. I’ll try to fix it, if I can. People know that. They come to me for help.

From my point of view, it feels good to be helpful to people.

Discuss

I enjoy open discourse and juicy discussions.

First, a disclaimer: This is not meant to refer to intellectual “tug of war”. Who is right and who is wrong? Who is smarter? Such games can provide entertainment, in particular if mutual respect remains assured. But for everyday communication, and also from a “results” point of view, I consider “tug of war” a not-so-constructive mode of operation.

That said, it’s often good to have a “sparring partner” for creative processes. You need one? Ask me. But the key phrase here is “partner”. The end should be common understanding. Let’s together arrive at something that’s smarter, even wiser, than what any of us could have done alone.

I like the sort of discussions where an objection isn’t misunderstood as an attack. Where issues are considered, not positions defended. Where fears are allowed to appear at the surface and need not hide behind rational-sounding arguments. Where “good question!” is meant and received as a compliment. Where it is normal to need a moment, or even a day, to think something through. Where ideas are to be experimented with. In such an open discussion, what you propose now, you yourself may find at fault only a little later. A discussion of this sort can become a thrilling intellectual adventure.

Discussions are for learning, for solving problems, and for reaching decisions.

I much prefer decisions that have been reached over those that only happened somehow. Therefore, I generally find it valuable to decide on decision processes.

I also prefer organizational structures where members get to voice concerns before decisions, over those where the usual mode of operation results in complaints being muttered afterwards.

I find ideas from sociocracy appealing, including:

• During decision-taking, distinguish between concerns (which can mitigated without major change of course) and objections (regarding serious show-stopping dangers),

• reach a reasonable partial decision now, that is “safe enough to try” now – instead of forever attempting to find a perfect and complete solution likely to withstand all tests of time,

• in the same meeting that does the deciding, set a date when to review the decision reached.

I’ve never actually been part of a team that tried sociocracy, but I would love to.

More earth-bound, let me mention code reviews. A while ago, I was with a project where a whole gang of developers would jump at any feature branch claiming completion. One received liberal amounts of code reviews. Good, qualified code reviews. One result: I had quite a lump of personal pride to swallow.

The other result: Our code in that project was in extraordinary good overall shape, probably better than any I’ve seen elsewhere (and I’ve seen plenty). This resulted in new pride, of a better variety.

Also, those extensive code reviews provided quite some learning experience for everybody. Each developer has their particular areas of expertise, and, through the code reviews, can contribute that special expertise to all work being done.

Ever since that experience, some years ago, I’m sold for code reviews. I recommend them, give them, and try to obtain them, where I can. Code quality problems being as expensive as they are, I generally find review effort well-spent indeed.