A huge amount of ideas and a quite a few months later, my original proposal, called "The disparity between industrial requirements and classic education of modern software engineering.", changed for the better. The approved abstract is called "Improving software engineering education by closing the gap with modern non-technical industrial requirements". After struggling to find any focus (and reference material to work with), I now settle with:

Mastering Lean Skills in Software Engineering Education

Defining what a skill is

These "lean skills" refer to the required skillset of modern software engineering practitioners. The skills themselves are not quite modern or new, but the ever evolving software development industry increasinly demands good noncognitive abilities next to conventional cognitive thinking - something that is on the rise for the last 10 years. Identifying non-technical requirements has been done plenty of times before and took on the form of the SWEBOK model and the like.

The problem with educational software engineering research in this area, is that either the papers are extremely vague, or they are too broad. Radermacher ¹ and Sedelmaier ² for instance identified missing soft skills in engineering education, but those skills do not speak for themselves: "project management", "personal skills", "ethics", "oral communication". I tried to create an overview of these papers as an introduction for myself into the topics and research world but ended up frustrated and confused. It also of course consumed some valuable months of my time...

Simply trying to pin down these terms by defining them seems to be a daunting task that will likely never receive a consensus³. For example, I tried to define the differences between "skill", "ability", "knowledge" and "competence". It took me more than a week and I gave up: every author gives his or hers own interpretation to these terms.

Since my background is with Computer Science and I've been a software engineer for 11 years, I'd like to incorporate this experience into my future work by concretizing these vague "skills" into something that people from the engineering industry understand and can work with. In the end, I'll have to define my own interpretation of the words "lean skills".

The word skill is arguably not ideal as it may exclude beliefs (mindset) and values, as opposed to a skill that can be learned.³ At least it is better than the much more rigid word trait. The word lean is also problematic: it may trigger people familiar with lean manufacturing to think only about those principles. While it's intentionally related, I don't want to limit identification to that particular kind of manufacturing or software development. Until I come up with something better, it will have to do.

Knowing what to work with

To be able to uniquely contribute to software engineering education research, the aim is to combine insights across multiple disciplines. I'm an avid philosophy and psychology reader and recognize the need for integration of certain key principles from these worlds into a more technical, engineering world.

Let's try to create an overview of important work in each area that would translate well into engineering education:

Philosophy

1. Self-cultivation (Bildung), Humboldt
2. Virtues and eudaimonia, Aristotle
3. Self-control, Seneca and Aurelius
4. How to live, Montaigne (and others)

Avoid emphasis on Metaphysics and (pure) Ethics.

Psychology

1. Grit, Duckworth
2. Flow, Csikszentmihalyi
3. Mindset, Dweck
4. Thinking, fast & Flow, Kahneman

Software Engineering

1. Software craftsmanship, McBreen
2. Lean software development, Toyota Manufacturing
3. Extreme Programming, Beck
4. PeopleWare, DeMarco
5. Pragmatic Thinking & Learning, Hunt

Almost all works suffer from a number of problems:

• Too theoretical (e.g. Metaphysics, theoretical Computer Science)
• Too superficial (e.g. "The passionate programmer")
• Too vague (e.g. 95% of all academic papers?)
• Too much usage of buzz-words (e.g. "Management 3.0")
• Too little research-based (e.g. "Drive")
• ...

It will be about finding the greatest common divisor and getting out of the way of vague or popular terms ("business"!). As you might have guessed, there are overlappings - the obvious one being PeopleWare as part of engineering and social psychology. Of course, grit and flow are natural evolutions of philosophical insights. There is plenty of techincal work released in the software engineering world based on these insights, although that is not immediately clear.

A Practical Philosphy for Engineering Education

To be able to effectively master these "lean skills", principles from all worlds could be extracted and reformulated into a practical philosophy (course), geared towards (software) engineering students.

This can be as technical as we want it to be. For example, take the excellent idea of studying 7 programmings languages in 7 weeks. To facilitate rapid learning that is required in a modern ever-changing software engineering world, requiring students to adapt to a new language every week would serve the purpose of building resilience to constant change. This exercise will be theoretically substantiated by drawing from philosophical and psychological research. Without this step, students would not have a firm understanding of why this resilience is needed, and they will not be able to translate what they have learned into the real world after graduating.

{{}} graph LR; A(Philosophy) B(Psychology) C(Software Engineering) A --> C A -.-> B B --> C {{< /mermaid >}}

I have yet to come across a good body of work emerged from within the Software Engineering world that successfully combines these ideas. Engineering research is typically very technical, and engineering education research as stated before either too vague or too pedagogical. Philosophy isn't exactly popular, especially among pragmatic engineers. University faculties do not usually work outside their own safe boundaries.

That said, I'm actually still struggling how to integrate what I want to do with what I have to do. Scientific (educational) research needs to contain well-defined questions, substantiated by references to more existing research. It's very easy to fall into the "vagueness" trap, especially if your thesis subject is too broad.

To remind myself of the constant dilemma between focus and exploration, I'll end with a quote from Maryam Mirzaei's research on PhD research⁴:

In fact, figuring out the scope is the prime challenge of completing a PhD. (...) The ambiguity of scope can also manifest itself in lack of positioning. Not having a clear overall argument is an important reason for PhD failure. The project 'thesis', the story and the new idea, spread too widely and too thinly can result in failure.

Figure src