teaching software engineering is still done wrong: more thoughts

content/post/2022/05/teaching-software-engineering-is-still-done-wrong.md

@@ -35,7 +35,9 @@ Within my own courses, I try to relate the small examples to the work field by d
 
 Barr explains that academia overly focuses on what he calls "individual problem solving": small subsets of algorithmic problems, that have little to nothing to do with real-life software _engineering_ problems. Another classic example would be teaching and proving complexities of various sorting algorithms. Sure, they have their use, but mastering those problems by hacking away individually has little to do with team-based software _engineering_.
 
-I used to think that the difference between the titles "programmer" and "software engineer" is just a matter of vanity, but in Barr's context, a programmer will struggle to pick up the role of a software engineer, and in university, we're teaching students to become programmers, while we actually need software engineers. Stop focusing on performance and algorithms. Focus on readability and code. The same is true for research, according to Barr: where is all the empiric software engineering research that focuses on how writing code in practice works? Instead, we're publishing heaps and heaps of... individual program analysis results?
+I used to think that the difference between the titles "programmer" and "software engineer" is just a matter of vanity, but in Barr's context, a programmer will struggle to pick up the role of a software engineer, and in university, we're teaching students to become programmers, while we actually need software engineers. Stop focusing on performance and algorithms. Focus on readability and code. The same is true for research, according to Barr: where is all the empiric software engineering research[^emp] that focuses on how writing code in practice works? Instead, we're publishing heaps and heaps of... individual program analysis results?
+
+[^emp]: I'm not saying there isn't anything like that: there's among others the ICSE (_International Conference on Software Engineering_), where I also published. However, consider this: at our university, KU Leuven, one of the oldest and internationally well-respected Belgian universities with a huge Computer Science department, there isn't a single research group with primary focus on software engineering. Some, like [DISTRINET](https://wms.cs.kuleuven.be/cs/english/research), say they research "software engineering", but judging from [their publications](https://distrinet.cs.kuleuven.be/research/publications/), it's not the SE Adam Barr and I are talking about. Compare this to University of Stuttgart's [Empirical Software Engineering](https://www.iste.uni-stuttgart.de/ese/) group, where exciting and genuinely interesting things on the subject are being put out. That proves it's not impossible to get funded.
 
 Isn't it telling that in the seventies, both academics and industry experts like Dijkstra and Mills warned us that this ain't the way to teach computing? Fifty years later, the situation hasn't changed much. This isn't just according to Barr, or according to my personal experience with teaching, but also according to the research I've encountered en conducted myself by [analyzing learning outcomes](https://people.cs.kuleuven.be/~wouter.groeneveld/courses/) of computing-related course material across European universities.
 
@@ -48,9 +50,9 @@ Adam Barr warns academics that code bootcamps might take over---and perhaps righ
 - The structure in academia is much too rigid. Its culture facilitates slow reactions, individualism, and focus on research instead of education, with little incentive to change.
 - There is surprisingly little real-world experience within academia. Most professors never really faced Dijkstra's "a program a thousand times as large", so how are they supposed to teach how to handle that?
 
-Barr ended his talk with a few recommendations: let students taste real-world code by exploring open source projects, give them bigger open assignments, etc. These conclusions can be read in pretty much every single paper on computing education, and as good as this practical advice is, I wonder why it's almost never taken to heart. Even if it is, will it be enough?
+Barr ended his talk with a few recommendations: let students taste real-world code by exploring open source projects, give them bigger open assignments, etc. These conclusions can be read in pretty much every single paper on computing education, and as good as this practical advice is, I wonder why it's almost never taken to heart. Even if it is, will it be enough? I wonder whether other universities might be more progressive than the ones I have experience with.
 
-All things considered, in my opinion, the future is looking bleak. I'm still convinced students really start learning as soon as they graduate and start working. Hopefully they end up in a company that cares about life-long learning, assigns them an amicable coach, and employs pair programming to quickly bring their knowledge above the minimum level. The more I think about this, the less I think academia---at least in its current state---will be able to rectify this. 
+All things considered, in my opinion, the future is looking bleak. I'm still convinced students only _really_ start learning as soon as they graduate and start working (and by "work", I mean in industry, not staying around and doing a PhD!). Hopefully they end up in a company that cares about life-long learning, assigns them an amicable coach, and employs pair programming to quickly bring their knowledge above the minimum level. The more I think about this, the less I think academia---at least in its current state---will be able to rectify this. 
 
 And without a critical mass, there's little I can do besides getting even more frustrated.