The Power of Knowing "Why?" in Software Engineering

I am currently reading “How Life Imitates Chess” by Garry Kasparov, after I saw a great review of the book by Baron Schwartz. Great book and I highly recommend it.

It’s got many lessons for software engineers as well. For example, in chapter 9 “Phases of the game” Kasparov talks about inexperienced players blindly following openings by famous grandmasters and how this can carry one only so far and ultimately is a trap.

Players, even club amateurs, dedicate hours to studying and memorizing the lines of the preferred opening. This knowledge is invaluable, but it can also be a trap. Many make the mistake of believing that if they know what a famous Grandmaster played in this exact position back in 1962, they don't have to think for themselves. [...] Without knowing why all the moves are made, he'll have little idea of how to continue when play inevitably advances beyond the moves he was able to store in his memory.

In software engineering, we have many conferences and online tutorials and blogs where our own Grandmasters talk about how they tackled a particular problem or resolved a particular outage. Sharing experiences is invaluable, but like Kasparov says, it can only carry you so far. Many people will blindly follow solutions described during conference talks, without understanding why it was done this way and not the other. Some people base their selection of a certain technology on opinion of a guru. Again - without fully understanding the context and reasons behind the decision.

What I am trying to say is Learn from other people's experiences, but don't forget to understand their context and their reasons. Your ability as a software engineer is based on your ability to adapt the solution to your needs, not simply copy it. Or if you copy, you need to know exactly why it will work for you.

Categories: software-engineering |

Comments (1)

Anton Antonov // 09 Jul 2009

Hi, you are right ! :D I just want to mention that Why is strategic question also like What so with this question you want to foresee you future in some way. But many software engineers think in how, where, when which are tactics questions. I'll give an example with software product.Thinking with question like how, where and when give us a short term results but It doesn't survive more than a year as a decision or a part of product. So we can say that the process of design is to have a future stable product or to have a demo product for the customer now which product doesn't have the necessary qualities and we have to insert a lot of effort for every new feature.