In my quest to better understand how software engineers in the trenches intuitively solve problems, I stumbled upon a book from an MIT sociologist published two years before I was born (1983). Donald Schön's The Reflective Practitioner contains an arguably important message, somewhere deep down hidden within the dark caverns of confusing academic prose. In sum, Donald categorizes modern knowledge workers into two big categories: (1) the professional, and (2) the (reflective) practitioner.

A professional, according to Schön, is a specialist concerned with knowledge. The unknown scares the professional, as he or she has no knowledge about that. The pure sciences, and the applied sciences to a certain extend, are the places the professional calls home. Etymologically speaking, to profess means to avow, to declare. The One Truth to rule them all. An example of a professional is a medical doctor or an engineer. These professions solve problems by applying general knowledge and patterns to the situations presented to them. Upon consulting your doctor, he or she will usually ask you a few questions, after which a decision tree in their head will spew out the diagnose. Hooray for science!

In that sense, a software engineer could easily be a profession: we apply design patterns---abstract ready-to-use solution sets---to situational problems, and then call it a day.

In the seventies and eighties, everyone wanted to be a "professional" and have a "profession" instead of a mere "occupation". New "pure" sciences started appearing out of thin air to give the librarian the much needed scientific background by mixing history, psychology, sociology and language. Everyone wants to "profess". Trust me, I'm a professional.

The biggest problem with professionals, again according to Schön, is that:

1. They can only apply their scientific knowledge if the problem is identified in the first place. In the real world, problems are complex, not merely complicated: see the Cynefin framework.
2. Applying general rules to real-world problems usually does not end well. Your doctor's decision tree does not take into account that you might be suffering from multiple inconveniences that influence each other.

Our design pattern is just that: it's a design pattern, a best practice rule that can be learned but never simply applied in its learned form. It's a jungle out there in (legacy) source code land! One does not simply apply a pattern in code. In the Cynefin framework, a problem where a best practice can be blindly applied exactly as you have learned it is called an obvious problem: it's tightly constrained and there are zero degrees of freedom.

If science does not save you in practice, what does? Something called reflection-in-action. The reflective practitioner learns to adapt as he approaches uncertainty, regularly changing course while steering towards a solution. I can almost taste the word "agile" as I type this, but I promise I won't. The prototype of such a practitioner would be the architect who designs rather than engineers. Strange, then, that architecture is also taught in the faculty of engineering. But what is designing?

Designing is changing existing situations into preferred ones.

I quite like that definition, even if it might have abstracted away too much context. In later chapters, things start to get a bit hazy as both knowledge working labels suddenly get entangled by calling architects design professions.

The reflective practitioner---such as an architectural designer, so it seems---embraces the unknown rather than fears it. It is his working ground. These practitioners are concerned with the knowing, not necessarily with (theoretical) knowledge. There's a thin line between both concepts, one I am still trying to bring into focus, but the gist is that many reflective practitioners don't even know how to explain their problem identification and solving methods. "It's a gut feeling" and the like are common answers. It reminds me of the Dreyfus model of skill acquisition. Novices approach problems by decomposing and decide analytical (knowledge-based). Experts approach problems holistically and decide intuitively. Many experts are unable to teach novices: they simply can't explain their intuitive workflow.

Where am I going with all this?

Good software engineers know how to apply generic concepts called patterns to day-to-day problems. Great software engineers know most patterns are just that: generic---inapplicable without adapting to the given situation. They might merge two or more concepts and make up a new pattern on-the-fly. I think that is what Schön refers to when he talks about reflection-in-action. Maybe it is time to stop making ourselves ridiculous and drop the fancy schmancy "engineer" part. I mean, really, "requirements engineering"? Don't get me started on that. It's not as bad as a sales engineer, though.

Knowledge-in-action is more important than scientific knowledge. That is what I take away from the book, and that is also what my gut tells me! However, there's one little predicament we're still stuck with: if students have to struggle through higher education---ruled by professors who on average have seen very little practice and put too much emphasis on technical knowledge---who's going to learn them to reflect-in-action?

My limited experience with teaching is that closed environments such as campus buildings do not help here. We as educators come up with little and big projects as part of a course or curriculum, but this can hardly be called a real-life problem. Furthermore, the problem is usually well-defined: we're like "hey kids, here is an assignment. You know what to do". We're never like "hey kids, this is weird code! I have no idea what the problem is, let alone how to solve it. Do you?" We might flatter (or fool) ourselves into thinking that we as academic educators learn students how to reflect-in-action using x or y or z, but in reality, it hardly matters.

It's not in the trenches. You need to be in the trenches.

In the last chapter, the conclusion called "implications for the professions and their place in society", Schön signs off with practical advice to professionals. What stings though is that (1) nobody I know in the industry has knowledge of this academic book since (2) it's written by an academic in their typical off-putting prose... Of course a successor exists on how to take action in higher education, but I haven't gotten to it yet. It's perhaps too smartly entitled " Educating the Reflective Practitioner: Toward a New Design for Teaching and Learning in the Professions". I hate the usage of the word toward in publications...

It's sometimes sad to see so many interesting ideas to be constrained within the academic environment where it was conceived, precisely because it is academic material. Luckily, suckers like me slog through these dark caverns and write a thousand words on an obscure blog for others to discover. I dropped my torch on many occasions, frightened of the dangers ahead.