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? Easy! Here is the recipe: Bring some time, find me when I have some to spare, too, then 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.
I’ve got service mentality. People generally find me supportive and helpful. 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.
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 limited entertainment, in particular if mutual respect remains assured. But for everyday communication, I consider “tug of war” a not-so-constructive mode of operation.
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. It’s good to have a “sparring partner” for creative processes. You need one? Ask me.
I like the sort of discussions where an objection isn’t misunderstood for 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.
For a bit of recursion: I find it valuable to decide on decision processes. Because I much prefer decisions that have been reached over those that only happened somehow.
I 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 (to be mitigated) 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 that perfect and complete solution likely to withstand all tests of time,
in the same meeting that does the deciding, agree when to review the decision.
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. The result: I had quite a lump of 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 area of expertise, and, through the code reviews, can contribute that special expertise to all work as it happens to go on.
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 find the review effort well-spent indeed.