phd thesis blog post updated

content/post/2023/07/identifying-and-amplifying-non-technical-skills-in-se-education.md

@@ -0,0 +1,125 @@
+---
+title: "Identifying & Amplifying Non-Technical Skills In Software Engineering Education"
+date: '2023-07-12T09:51:00+02:00'
+tags:
+  - writing
+  - phd
+categories:
+  - education
+---
+
+Identifying And Amplifying [Non-Technical Skills In Software Engineering Education](https://lirias.kuleuven.be/retrieve/718648), that's the full title of my accepted PhD which will be publicly defended in September. While the [previous blog post](/post/2023/07/a-tufte-style-thesis-using-pandoc) explained the technical details behind layouting and typesetting, in this post, I'd like to touch upon the contents itself. _What did you do these last five years, Wouter?_ I can hear you think. Let me answer that for you here! I promise I'll be brief. Full details can of course be found in the thesis itself. If you'd rather skim the separate papers, [go ahead](/works/papers/).
+
+![](../thesis.jpg "The cover page of my thesis.")
+
+IEEE defines software engineering as "the systematic appliance of engineering methods to software development". But what exactly are those methods? To most developers, they're technical: knowledge of programming languages, shortcuts in your favorite IDE or terminal, knowledge of the latest JS framework and how your CI/CD pipelines work, ... I tend to agree, but there's more to that: the difference between a good and a great software engineer is, to me, _non-technical_ knowledge---not just the technicalities. I'm talking about collaborative skills, empathy, knowing how to identify a problem, creative problem solving techniques, ... Admittedly, they're still hard to grasp. 
+
+In my thesis, I tried answering these three questions:
+
+1. What exactly are those non-technical industrial requirements of modern software engineers?
+2. How big is the gap between those requirements and current software engineering education?
+3. How can we improve education to reduce that gap?
+
+And thus the journey began...
+
+## Part I: Identifying Skills
+
+This part tried to answer the first question: what are those "non-technical" skills we keep talking about? Others call it soft skills, 21st century skills, professional skills, ... Semantics are discussed in the thesis, I won't go into that pickle here.
+
+### 1. Teaching Trends: Literature Analysis
+
+The first paper I ever published was a systematic literature analysis to try and identify which skills beyond the technical are currently being taught in computing academia. This overview presented some of the most common aspects to facilitate the teaching of these skills. We discussed each skill, aspect, and integration level individually to provide some context, highlighting the most and least common occurrences. By looking at the relationship between skill and teaching aspect, we discovered popular combinations and interesting trends in software engineering education.
+
+High-level skills we encountered in papers were communication, teamwork, self-reflection, conflict resolution, mentoring, leadership, motivation, career/role awareness, cultural intelligence, creativity, ethics, lifelong learning, empathy---in order of appearances.
+Browse an [interactive chord diagram or heatmap](https://people.cs.kuleuven.be/~wouter.groeneveld/slr/) of our findings to get a sense of which skills are overabundant and which are underrepresented. 
+
+### 2. Non-technical Industry Requirements
+
+Okay, so we know communication and teamwork is part of many curricula, but what do software developers think is needed to succeed? We enlisted many software engineering experts from different companies across the world to help us answer that question. Multiple rounds of surveys resulted in four skill groups: communication, collaboration, problem-solving, and personal skills. On top of that, we asked the experts to rank the skills according to relevance.
+
+You can browse the complete table of skills and categories on the [interactive website we created](https://people.cs.kuleuven.be/~wouter.groeneveld/delphi/), which also documents the survey questions and gathered metadata. I played around with amCharts, a JS-based graph generation framework. The end result was well-received, although are hard to marry with static figures of a paper:
+
+![](../delphioverview.jpg "A screenshot of the interactive website: the four skill categories.")
+
+## Part II: The Academia-Industry Skills Gap
+
+Part I provided a direction as to what "non-technical skills" exactly are, but we're still not sure how the skills identified by developers match the ones we found in the literature study. Furthermore, those skills are just terms found in papers---success stories which happened to get published. 
+
+### Teaching Trends: Program Syllabi
+
+In order to supplement the literature review data, we---painstakingly, I might add---analyzed learning outcomes of courses in European computing syllabi, and again tried to categorize these. We asked: what do CS programs reveal about non-technical expectations of undergraduate students? This gave us a more realistic view of what academia expects students to know at the end of a (non-technical) course. 
+
+Again, [an interactive website is available](https://people.cs.kuleuven.be/~wouter.groeneveld/courses/). I rather like this one, where you can zoom in on the map by clicking on a country to see the average skill category breakdown. I went a bit overboard while trying out VueJS. The page also contains a list of all courses in the database, and courses by skill, sortable on occurrence.
+
+### Identifying the Skill Gap
+
+The previous three studies yielded a lot of data that somehow has to be compared. But before we could do that, a translate step was needed: if something is called "career awareness" in a learning outcome, would this be the same as something called "role awareness" in a paper or by experts? By this point, juggling with these confusing terms became quite a challenge (and exhausting).
+
+In this publication/chapter, after translating and ranking skills according to most prevalent in academia but most needed in industry, we came to the conclusion that the academia-industry skill gap is the largest with these three skills: continuous or lifelong learning, creativity, and solution-oriented thinking. 
+
+The skill comparison chart [can be consulted online](https://people.cs.kuleuven.be/~wouter.groeneveld/gap/). The larger the colored bars, the more occurrences found in said previous works. Purple denotes the industry need while yellowish tints denote what's currently being taught---we were on the lookout for large purple bars with small yellow ones placed right next to them. 
+
+## Part III: Creativity as a Non-Technical Skill
+
+From hereon, I decided to zoom in on [creativity](/tags/creativity) and leave the high-level "non-technical skill" thing behind. 
+
+### Teaching Trends: Creativity
+
+Another teaching trend analysis was done, resulting in our second published systematic literature review, this time focusing on creativity in computing education. We found surprisingly little existing work in that area so there's your gap---and publication niche. We categorized the encountered papers as _passing_ (23; merely mentioning the term), _peripheral_ (17; added a bit of discussion but not used to support the methodology or results), or _depth_ papers (18; creativity used as a substantial theoretical basis). 
+
+In addition, we found major themes associated with these papers, such as teaching CS0/1/2, computational creativity, environment creation, intrinsic motivation, problem identification, collaboration, and curriculum (re)design. These, together with the notably absent theories from creativity research in the field of cognitive psychology, helped us further sharpen our own future work. 
+
+No fancy visualization this time, just a few Python-generated charts. Sorry. 
+
+### Professionals' Perceptions of Creativity
+
+Next, we were interested in what professional software developers think when they hear the term "creativity". What are their perceptions, how would they measure and activate or coach it? In a focus group study with four groups across different companies, we discussed creativity at length, and the end result are seven main themes that I've also used as a basis for the chapters of [The Creative Programmer](/works/the-creative-programmer): technical knowledge, communication, constraints, critical thinking, curiosity, creative state of mind, and creative techniques:
+
+![](/post/2021/01/creativity-mindmap.jpg "A mind map of the creativity themes.")
+
+In my blog post [What is Creativity in Software Engineering?](/post/2021/01/what-is-creativity-in-software-engineering/), I explain this work in more detail. 
+
+### Students' Perceptions of Creativity
+
+Do students perceive creativity the same as professional coders? The answer is of course a sound no. Our intention was to replicate the aforementioned focus group with another target group---undergraduate and graduate computing students---but organizational difficulties eventually morphed this study into semi-structured interviews with students. We did pose the same questions. 
+
+The most important takeaway here is that students have a very much fixed mindset when it comes to creativity: they either think they're creative, or they're not. But in reality, creative is a skill that can be learned and mastered, just like programming in Java. Also, students seem to put more emphasis on originality and technicality instead of programmers who more often mention the advantages of creative collaboration. Another mind map here which I'll skip.
+
+### Measuring Creativity
+
+Our intention was to do an intervention in class and somehow measure whether or not we were successful, but to do that, we first needed to find a way to measure creativity or its effects. There's lots of existing stuff out there but none neatly fit the above seven themes as identified by experts. In the end, we created---and successfully statistically validated---our own test. 
+
+The test is called the _Creative Programming Problem Solving Test_ or CPPST and you can take it yourself at https://brainbaking.com/cppst/ or just press the "I'm Feeling Lucky" button below the 56 questions if you're lazy to get an idea of how it works: results are laid out in a spider graph according to the 7 domains. The CPPST is context-sensitive so if you're doing another project your results will likely vary. 
+
+## Part IV: Amplifying Creative Skills
+
+Now that we have the CPPST in place, it's time for an interdisciplinary intervention. The work above was done in parallel with other smaller experiments I'll also briefly mention here. 
+
+### Creativity & Motivation
+
+In an attempt to motivate students for the _Software Design In C/C++_ course, I redesigned the course contents and introduced [programming on the GBA](/post/2019/04/teaching-oo-with-gba/). We administered a few surveys to see its effects and student really liked the assignments. We also wondered whether peer grading has an effect on study time but didn't find anything worthwhile. 
+
+At least we presented a poster and published a paper on developing for the 20 year old Game Boy Advance.
+
+### Creativity & Code Quality
+
+We were slightly more successful in finding a correlation between code quality and creativity of undergraduate CS1 student projects (in Java). We used the static code analysis tool PMD and correlated the reported errors with a creativity score as evaluated by a jury---the so-called "Consensual Assessment Technique" by Amabile. 
+
+Students' projects that were deemed more creative by the jury were also marked as a lot more messy by PMD! This could have a couple of reasons that need a bit more work to be able to pinpoint these, but the (medium) correlation an interesting find. Perhaps for graduate students this will no longer be the case. Perhaps if we redid this study in another academic year (or university), the results would have been totally different. 
+
+### Interdisciplinary Creativity
+
+In the last study, we paired graphic design students with our engineering students and let them have a go at a creative assignment using Processing or the online JS-based editor, p5.js. Three groups were created: design+design students, engineering+engineering students, and the mix. We expected the mix to perform the best, but the CPPST test and interviews proved otherwise: an initial collaboration hickup due to not really knowing each other prevented true creative flow.
+
+The test group was rather small so this could definitely be improved, but interviews yet again revealed the fixed mindset when it came to creativity: our engineering students thought the design students were creative just because they're following a design programme, and the design students thought the engineering students were good a programming because "it's like math". Interesting false baked-in beliefs!
+
+---
+
+That's more or less a summary of the thesis. A practical approach of creativity in programming can be found in [The Creative Programmer](/works/the-creative-programmer), where our research is also touched upon, together with the CPPST test. I hope programmers, students, and teachers will somehow find my work useful.
+
+There's ample of stuff left to do: the teachers' perceptions of creativity, a bigger interdisciplinary intervention, a longitudinal course analysis, ... If you're interested in reading more about it, feel free to check out the following links:
+
+- [My full thesis in PDF](https://lirias.kuleuven.be/retrieve/718648)
+- [My academic publications](/works/papers) (most of these represent chapters in the thesis)
+- [Blog posts tagged with 'PhD'](/tags/phd)
+- [Blog posts tagged with 'Creativity'](/tags/creativity)

content/post/2023/07/logo-convergence-design-mistakes.md

@@ -1,6 +1,6 @@
 ---
 title: Logo Convergence Design Mistakes
-date: 2023-07-12T11:00:00+02:00
+date: 2023-07-14T11:00:00+02:00
 categories:
     - braindump
 tags: