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 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 heard, and 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 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 find “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 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 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 somehow happened.
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 many 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 endlessly attempting to find that perfect complete solution likely to withstand all tests of time,
in the same meeting that does the deciding, agree when to review that 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 branches claiming completion. One received liberal amounts of qualified code reviews. That meant one initially had to swallow quite a lump of pride.
But soon, I noticed our code in that project was in good overall shape. At least as good as any I’ve seen elsewhere (and I’ve seen plenty). This resulted in new pride, of a better variety.
Also, these 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 that happens to go on.
Ever since that experience, 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.
I’ve also collected good initial experience with “code review 2.0”, namely, pair programming. We even did that remotely, in one distributed team, for a while. Unfortunately, after we had solved some of the initial technical problems, but before pair programming had become truly habitual, the team happened to be re-organized and that put an end to pair programming in that project.