I write this blog to be genuinely helpful and to add value to others. Every case of writing software is different because of business specifics and involved people. Your situation as a software engineer differs from mine.

We don’t outgrow our challenges or get promoted past them. The best workplaces and most effective organizations have them. In fact, engaging well in difficulties in projects is a sign of health in the code base, team, and organization. People that deal productively with the inevitable stresses emerge with a stronger sense of trust in the code, each other and the company.

So one explanation for the interest in this blog is discovering productivity hints. Another is the delight of individuals happy to find a way through software or people related dilemmas. Long-term success and even survival of many organizations may depend on their ability to engineer software and lead projects. If even slightly I support you in solving your problems, then I reached my goal.


This blog draws from many wells.

The ideas and stories I share throughout the blog come from my life and from my work with a diverse group of colleagues and clients. For variety and to protect their confidentiality, many of these stories are amalgams of different people’s experiences. As a rule I change all identifying facts.

I’m deeply grateful to those I’ve worked with. It is for their generosity, openness, courage, and truthfulness I learned the most.

My training is in software engineering and economics. Besides my reflections, this blog incorporates and builds on ideas from many authors of blogs and books on writing great software. Their insight have proven invaluable to my work in the context of business and team dynamics.

My family offered unconditional support for spending my time learning and writing, for which I love them all the more and I am deeply grateful.

As usual, the good things about this blog owe a great deal to others while errors and omissions are my responsibility.