#161 - The 7 Dimensions of Highly Creative Programmers - Wouter Groeneveld

[00:01:06] Episode Introduction

Henry Suryawirawan: Hello again to all of you, my listeners! Welcome to the Tech Lead Journal podcast, a podcast on technical leadership and excellence. If you haven’t, please subscribe on your favorite podcast app to get notified for new episodes. Tech Lead Journal also provides bite-sized contents on LinkedIn, X, Instagram, YouTube, and TikTok.

My guest for today’s episode is Wouter Groeneveld. He is a software engineer, computer science education researcher, and the author of “The Creative Programmer”. In this episode, Wouter dives deep into what makes good engineers truly exceptional. And that is creativity! He describes his definition of creativity and shares the 7 key dimensions of a creative programmer - from technical mastery to embracing constraints and being curious. Learn how you can take your coding to the next level and unleash your inner creativity as a software engineer.

I hope you enjoy listening to this episode and learning a lot. Please share it with your colleagues, friends, and communities, and leave a five star rating and review on Apple Podcasts and Spotify. Let’s go to my conversation with Wouter after some quick words from our sponsor.

[00:03:05] Introduction

Henry Suryawirawan: Hello, guys. Welcome back to another new episode of the Tech Lead Journal podcast. Today, I have with me, Wouter Groeneveld.

Wouter Groeneveld: Hi.

Henry Suryawirawan: He’s the author of a book titled “The Creative Programmer”. I think the title of the book sounds really interesting, programmer and creativity, right? I think we are gonna learn about creativity as a programmer from Wouter, and what aspects are really, really needed when we wanna become a creative programmer. I think he even have like a trademark or even a term for this creative programmer. So welcome to the show, Wouter.

Wouter Groeneveld: Thanks for having me. Welcome. Hi.

[00:03:35] Career Journey

Henry Suryawirawan: Wouter, I always love in the beginning to ask my guests to maybe first introduce yourself by telling about your highlights or turning points that we all can learn from.

Wouter Groeneveld: Sure, sure. So, I am a software engineer. I’ve been developing software for 11 years in the industry. I’ve had plenty of experience. And after a few years, I’ve also picked up various roles like coaching and dev lead roles. And we started doing interviews trying to get new people to join. People from colleges and universities and also other more experienced developers. And while doing those interviews, I noticed that technicality or technical knowledge is usually not the kind of thing that’s a big problem. Most software engineers know how to keep their stuff up to date. But somehow, . most projects I’ve been working on still failed. And of course, there are various reasons for that, including management, no pun intended. But also beside the technical knowledge something else was important, but I wasn’t really sure what, so we’ll call these non-technical requirements for now. Uh, I know the term is a bit fake, but it’ll get more concrete later on.

And well, after 11 years of being in industry, I’ve had the opportunity to teach halftime at the university, at my local faculty I’m currently working for. And after like a semester of teaching, I really like doing that. And I was asking myself, perhaps, I can really dig into the question I have, which is what makes a software engineer a really great software engineer besides programming experience and besides knowing how to develop in Java or Kotlin or whatever.

So for the past five years, I’ve been researching non-technical requirements in software engineering. So I’ve been a researcher now. I’m now an academic, so I’m what you would might call a multi-class, a software engineer slash academic. And the combination of both is really interesting. And, uh, after a few years, I noticed that creativity is an important aspect of problem solving and software development. So we’ve focused and zoomed in on that. And the result is The Creative Programmer, I guess. And lots of other academic publications that are a little bit less fluent to read. So I guess we won’t be doing that today.

Henry Suryawirawan: Thank you for sharing your story. I always love reading this kind of book, right? A book that came from academia or you know, with a well-backed research, right? I think I have few episodes, it’s something like this. And it’s always interesting and fascinating to actually understand maybe the human brain or the cognitive aspect of programming, right? And I’m sure today, we’ll learn a lot as well.

[00:06:10] Reasons Software Projects Fail

Henry Suryawirawan: So you mentioned about, you know, even though software programmers don’t have any kind of technical problems, generally, but software projects still fail, which you call the non-technical requirements. Maybe if you can tell us a little bit more, in your view, what are some of the common challenges why software projects still fail?

Wouter Groeneveld: Yeah, of course. Well, one of the most common issues, of course, is team-based human-based problems when working in teams when collaborating, and there’s lots of research based on that. This is one of the, let’s say, challenges for me as a researcher myself, because I shouldn’t let myself be biased by my prior experience. So I know what the major problems, but as a researcher, I, of course, can’t just say, okay, it’s going to be this. That’s anecdotal evidence. So we took that question and we went to the industry, to multiple companies from multiple countries. And we asked them, what do you think is the reason for that? Why are some software developers average and others great?

And the result was a huge list of non-technical requirements. People were saying, okay, uh, lots of communication based skills are really important. A lot of people were saying, you gotta really be good at constraint based thinking. A lot of people were saying, no, no, it’s gotta be creativity. If you have a problem, you need to think in a creative way to overcome the roadblock to be able to solve that problem better. So that’s a, it’s a really huge list of competencies people think is important. And then we started ranking them. So that’s another study that we executed. And within the top three was always, someone always mentioned creativity, always.

So that kept us thinking. Hmm, that’s interesting. Then we tried to see if there’s already a lot of academic research within computing education regarding creativity. And the answer is no. So there’s a lot of research in cognitive psychology related to creativity, but most of those results are really general. So it’s not really programming, not concrete enough for a software engineer or developer to make use of, for instance, uh, let’s call it that way. So what I try to do is to bridge the gap between cognitive psychology and the research within the creative field and try to map it to computing education and see whether or not we can learn from that.

[00:08:29] The Creative Programmer

Henry Suryawirawan: Sounds fascinating, so let’s just dive deep into it, right? So you mentioned the creative programmer. So maybe tell us your definition first. What do you think is a creative programmer? I know this is probably a little bit generic as well for some people. Maybe we can clarify it.

Wouter Groeneveld: Yeah, sure. So one of the, let’s call it, classic definitions of creativity is something is creative when it’s of a high quality standard, when it’s applicable to the context, and of course, when it’s original. So if someone else already made it, then it’s not going to be creative, because, well, it’s already there. But this definition doesn’t really take context into account. It’s a classic one from the field of psychology. And we thought we could do better.

So we asked people in the industry, what do you think is a creative programmer? Do you have any insights for us? And we basically summarized everyone’s opinions. And we noticed lots of recurring themes. Let’s call it themes. And the result is actually creativity is something within, within the context of programming, of course, is something multi-dimensional, which means that there’s lots of different aspects involved in being a creative programmer. And each of those aspects is one chapter in the book of the creative programmer.

So one of the most obvious domains or aspects of being a creative programmer is having technical knowledge. In essence, it means… imagine you are a Java developer and you’ve never developed something in Java before, then chances are you’re not going to be very creative at the reflective API because you simply don’t know how to use it. So there’s gotta be a minimum, bare minimum level of technical knowledge to be able to approach problems in a creative way. So that’s an obvious one. So that’s technical knowledge.

The next one is communication or collaboration, which is related to working together. It’s more interesting, for instance, to work together in a heterogenous group than in a homogenous group, because you have different opinions. And based on that, you can cross pollinate ideas and get a much better, more interesting idea. But of course, you need to be open to those ideas. Most people are not and, and end up fighting. So that’s not going to work. So that’s the second one.

The third one is an interesting one is constraint-based thinking. For instance, you have your typical time and money constraints. Something has to be done within two weeks or three weeks or whatever. But within programming, of course, you also have hardware constraints. The stuff has to work on an older CPU, because it’s still deployed somewhere, or the banking industry says it’s gotta work in Pascal or in VB, VB6, uh, older, older software technologies that you have to work with. Of course, you wanna use modern software development techniques, but it’s an old tool. How do you do that? You also have to be creative to apply those new techniques to old technology. So that’s the third one.

Then we have a critical thinking and a creative state of mind. So what does that mean? A creative programmer is a critical thinker. That means you have different ideas, but you still need to critically evaluate each of these ideas to see whether or not they’re applicable to what you’re doing right now. For instance, which is really relevant today, if you ask Chat GPT for a question, it usually comes up with answer that more or less works or get a Copilot. Most of my students, well, I’m, I’m speaking of course about students right now, but most junior or some senior colleagues also do this, they just copy paste the result because it’s working and then move on. Sometimes that’s good, but sometimes that’s not. You first have to think about what am I doing? Perhaps these tools gave an answer that connects to something else in your brain that if you think about it makes an even better solution. But you can’t just skip that step.

And then you have the creative state of mind, which is like the classic a-ha moments when you’re showering. Uh, and you’re not really thinking about a big problem you have a lot of difficulty with. Suddenly, the ideas occur to you in a flash of insight. But before that flash, a lot of work has been done already. So most people think that it’s some genius insight way that not everyone can achieve, but that’s simply not the case. You’ve been chipping away at the problem for hours and hours and hours before you’ve got that insight. And there are a few practicalities that are explained in the book that can help you get more of those.

And then the sixth is curiosity, getting out of your comfort zone. If you’re not curious and you don’t want to experience new things, you don’t want to explore new technologies then you’re not going to make the link between the new thing and the old thing. Which means that you’re not going to have enough ideas to be creative as a developer. It’s really simple.

And last but not least, there are a few practical creative techniques that we can employ during programming to become a more creative programmer. One of those, of course, is a technique everyone uses and knows, is zooming out. If you’re really focused on a few methods you are writing and you don’t know how to implement something, then perhaps it’s a good idea to just zoom out for a few minutes and see what am I doing? Is this relevant? And some people do that. Too often some people don’t do that at all. We have a few interesting techniques derived from, for instance, writers or artists that we can map to the world of software engineering to help become a more creative programmer.

So that’s in essence what it’s all about. I know it’s a lot. Perhaps we can pick out a few and discuss these to help the listener make a sense of all this.

Henry Suryawirawan: Thank you for the high level overview of the seven different themes to become a creative programmer.

[00:14:06] Social Approval & Seniority

Henry Suryawirawan: So one thing before we go into probably diving each of the themes when we have the time, but one thing that I also want to call out in your book. You mentioned something is creative when the social peers actually approve it. When I read it, I think it’s also kind of like insightful, right? Because doesn’t mean we always have to come up with something unique, I mean like original, novel and things like that. But something is creative is when our peers actually say, hey, that is a creative way of doing things. Maybe this social verdict part you can touch on a little bit.

Wouter Groeneveld: Yeah, sure. Creativity is a systemic, which means it’s linked to other things, like the seven domains I just talked about. Creativity is not something, like for instance, I wrote a simple program in Java and I’m not creative because someone else has already written “hello world”. And of course, millions of people have already done that, so I’m probably not going to be very creative at doing that. But that’s not really the case, because if it was the first time for me, and I’ve had a lot of difficulties coming up with that simple solution, perhaps it’s for me, personally, it can be creative.

So creativity, when you think about trying to define the concept, it’s really difficult because you have individual levels of creativity. You have team-based levels of creativity. You have corporate based, like company-based levels of creativity. And on the other hand, you have the context that’s involved. Psychologists are moving from the classic definition that I mentioned earlier, and are adopting a more systemic approach. Which means, it’s something as creative when someone else says it is, and that that person who says it is, is the experts.

For instance, if you’re in a gallery and if you’re looking at a painting, and if you don’t know a lot about paintings like I do, but I still like looking at them. Sometimes I wonder, should I be amazed? Should I say, oh, wow! Because with modern art, you don’t really know. But if someone explains lots of things about the painting in the background and you see that they think it’s really creative, then you nod along and you’re, you’re like, okay, yeah, yeah, I, I’m, this is going, this has gotta be creative. And that same principle also applies to the world of software engineering. But we shouldn’t ignore the context. Of course, context is always relevant.

Henry Suryawirawan: Right. Another thing that I just want you to also explain, right. People as they go senior in the industry, maybe they learn a lot of programming languages. Maybe they have done a lot of projects. Maybe they went into different companies, right? That doesn’t necessarily mean that they are more creative than the junior. So this is also another important aspects that maybe we can learn as well.

Wouter Groeneveld: Yeah, indeed. That’s the difference between having 10 years of experience doing exactly the same thing, which means actually, yeah, you only have one year of experience, because you just did the same thing over and over again. And someone else who did 10 years of different things, trying out different things, failing a lot, of course, because being a creative programmer inherently also means, uh, you’re gonna fail multiple times. But that doesn’t mean that you’re not learning anything. I think that’s a really important takeaway. If you wanna be a creative programmer, you have to experiment. Like one of the concept is, of course, also being curious. So that’s indeed an important aspect of it.

Henry Suryawirawan: Right. So let’s go into the themes, right? So maybe we start from technical knowledge. Also, I just wanna also give to listeners, right, how Wouter explained this theme in the book, right? You have a mix of, you know, games, you also have a mix of philosophy or ancient history. I think that’s always interesting for those of you who love these kind of topics, right? Because you can easily see what kind of problem that Wouter is explaining for each of the theme.

[00:17:39] Technical Knowledge: Getting More Inputs

Henry Suryawirawan: So let’s start with the technical knowledge, right? I think you mentioned that, of course, if you wanna be creative in Java kind of software, you need to know Java. But maybe I wanna touch on not on that aspect, because that is kind of like given most people should by now know about that.

Wouter Groeneveld: I hope so.

Henry Suryawirawan: Uh I wanna start maybe from getting inputs, right, because in your book for technical knowledge, you advise us to actually get more inputs, which means like learning more things, you know, reading more stuffs or maybe watching more tutorials or videos. So tell us more about the importance of this getting input.

Wouter Groeneveld: Yeah. Or for instance, listening to the Tech Lead Journal podcast. Well, that’s really interesting because during one of our interviews, our participants said something like, creativity is the blue of different inputs. And that kept me thinking for a while. I was thinking like, okay, that’s a really good way to summarize a part of creativity, of course, because there are multiple parts involved. If you’re only going to get input from one source or a few sources and you stick to those, then chances are that cross-pollination of ideas is going to occur a lot less than if you have multiple ways to learn new different things.

So it’s really important to be open not only to the world of programming, but also read a few pieces on psychology, on philosophy. That’s one of the things that I try to do with the book itself is not approach it simply from the mind of a programmer, but also like you mentioned from different domains, and then you can see the ideas and the ways that people do stuff in those domains are not really that different compared to me as a programmer. And that’s really interesting. But of course, there’s also a big danger of having too much input, unable to process them, being paralyzed with too much stuff going on, uh, especially with, nowadays, the internet, like social media, doom scrolling, keeping up to date. The conclusion is you gotta have a system.

So one of my systems, but not necessarily the best one, or the one you should employ, of course, is like having a created RSS feed reader where you can paste in stuff that interests you. Not having too much, but not having too little. So if you read those things combined with, of course, also offline books or eBooks or other things that you hear. Even hear on the streets passing by like, hmm, this is something interesting. Then you can start, subconsciously of course, cross-pollinate those things. It’s not something you do actively, at least, not something I do actively.

Henry Suryawirawan: Right. So I think when you mentioned RSS feeder and trying to constrain the input, I still have the problem. I subscribe to too many RSS feeders, I guess, and also newsletters. So I, I wonder how, how much time I have to actually consume all of them.

[00:20:22] Personal Knowledge Management

Henry Suryawirawan: So when you mention about this system, right? I think some people love this topic, personal knowledge management, right? Or maybe other people also call it second brain and notes taking, and things like that. And you have this, uh, loop, gather, internalized, act loop, right? So which is very, very important when we want to actually use the knowledge, not just hoarding the information in the notes. But actually use that for something useful, right? So tell us about this personal knowledge management. I think because many, many creative programmers actually do this kind of stuff quite disciplined.

Wouter Groeneveld: Yeah. I noticed indeed a few ex-colleagues of me having things like personal wikis where they store technical information or how to do a grep or how to do regular expressions in Java or in Kotlin or whatever for their next project. When they have to do it again, they can quickly reach for it and just apply the knowledge that they already have explored before. So that’s an important part. But if you’ve gotta store stuff, then you have to think, what am I going to do with it in the near future? So it’s not just reading or consuming and then doing nothing with it. A creative programmer, of course, wants to be creative, wants to solve problems creatively, which means you have to do something with that input. Because like you mentioned, there’s just too much inputs. There’s too many things to do and to read. Um, you have to curate it and also add context. So summarize it in your own way.

That’s a really, really important part, not just saving URLs or links to articles and then calling it a day. No, you have to summarize it yourself in your own words. When you’re doing that, then during that process, you are probably linking it to something else. If that linking doesn’t occur, then the cross pollination and the new ideas are not going to come. And of course, the ultimate goal of having a personal knowledge management system is having new ideas, capturing the new ideas, and doing something with it.

Like Niklas Luhmann, a really well-known German academic, used a principle called Zettelkasten technique. It’s really popular lately. Uh, you can search for it on the internet or read about it in the book. One of the reasons why he did the thing that he did is to publish more. So I think Luhmann published like 60 or 70 books in his entire lifetime. That’s not articles, that’s books, which is huge. So that’s the output. That’s something, of course, as a programmer, you don’t want to write books, you want to write codes, but the same principles apply.

Henry Suryawirawan: Yeah, I think many programmers like myself or maybe just let’s call it technical or knowledge worker, right, actually consume a lot of things, right? So we read blogs. And these days there are so many resources, and not just in texts, but also in audio, like this podcast, and also video on YouTube, and maybe even like short clips, you know, like YouTube Shorts and TikTok.

Wouter Groeneveld: It’s crazy.

Henry Suryawirawan: There’s just so, so many, uh, information. I think the tendency for all of us still is like consume, consume, consume, but we never actually take action on it. And in fact, for me, I also learned from, you know, one of the podcasts before. I made it such a framework, like it’s called 4Cs. So you, you first, you Consume, consume a lot, but you have to create the second C. And then you Connect with people, maybe create some kind of a network or maybe groups to actually share the creativity that you have. And the fourth one is actually to do it Consistently. I think that is also probably one thing that listeners can learn from.

[00:23:37] Creativity Begets Creativity

Henry Suryawirawan: And you mentioned also creativity begets creativity, right? So once you create something creative, there might be a chance for you to create something more creative as well. So tell us more about this part, because I think it’s also important to encourage people to start.

Wouter Groeneveld: Yeah, sure. Well, it’s a simple concept. It just means the process of writing this book has been exactly that. It’s been a process of, let’s call it fermenting of ideas for years and years. And I didn’t really do anything with those ideas. So I’ve read a lot of different books. I’ve collected a lot of different articles. I’ve done a lot of studies myself and somehow after reading book after book, you start having these thoughts like I’ve seen this before. Perhaps I should link this to something I’ve done before. Then if you can hark back to the system that you have, you can quickly look up that information that has been contextualized by your own notes. Then you can link them together.

And after doing that, writing the book itself is actually the easiest part. Well, in theory, let’s say, uh, writing the outline of the book is the, is the simplest part, because that’s just getting those notes out of your system, collecting them, rearranging them, and then some way or another, you already have a template of what you want to do, and then it’s a matter of, of filling it in.

And of course, I can work based on this book. I still have open ideas or questions I didn’t have before writing them. Some of the chapters, I can write some more fledged out examples for or I’ve had ideas for future research based on what I’ve been writing. And if I wouldn’t have written this, then I wouldn’t have those ideas. So it’s just a continuation of what you’ve been doing before.

Henry Suryawirawan: Right. So I think the summary is like take notes, you know, like gather this information, internalize that by doing summary for yourself, linking ideas, cross pollinate. I think you mentioned this word, like so, so many times, right? Cross-pollinate different ideas.

Wouter Groeneveld: It’s really important.

Henry Suryawirawan: Yeah. And then the last one is take action, right? So you can’t be creative if you don’t produce, or you know, do something about it, right? So I think that is like a good summary.

[00:25:37] Collaboration & Communication

Henry Suryawirawan: So let’s move on to the next theme, which is the communication and collaboration. I think for many software engineers this can become a challenge, because, you know, some are like more introvert. Some prefer to speak to the machine rather than people. Some also don’t like working in teams. They just want to go solo. So tell us more about this importance of collaboration.

Wouter Groeneveld: Yeah, I think it’s really obvious once you start looking beyond the boundaries of software engineering. If you look at really productive or really creative teams in the past, for instance, in arts, uh, like the gatherings in cafes in Paris, the extreme Tuesday sessions in London, you always see the same pattern emerging, which is a heterogeneous group of like-minded people who want to push a domain forward. They’re fed up with, for instance, the Camerata in the 16th century. They were fed up with the current level of music and they wanted to create something new. So there has to be a common interest, and there has to be people from different backgrounds, because that’s what makes it interesting. If you have an idea and you share it and someone else looks at it with different eyes from a different background, they can add value to it and that makes the idea even better. But of course, you need to be open to do something like that. That’s what I also mentioned earlier.

And one of the most interesting parts perhaps of this chapter is that the idea of the community smells in the later part of the chapter, which means, you have this concept called technical debt, which I guess everyone knows as a programmer, uh, which is code that’s been left alone that you should have refactored some way or another, which is going to cost money, which is the result of code smells, different code smells. And in community based teams, which are of course all teams, you can have something similar. Instead of technical debt, you have social debt concept called social debt. And instead of code smells, you have community smells.

And why is that so important for a creative programmer? Because those community smells, they actually impede creativity. Not only at an individual level, because if you’re unhappy in a team, you’re not going to be that creative. I’ve read studies that claim that a happy programmer is a creative programmer, which is, well, I guess more or less true. But also team-based. If there’s lots of fights going on, or, you know what I’m talking about. Then at team-based level, um, it’s not going to to be that creative. So it, I think it’s really important to try and identify those different community smells.

For instance, we’ve all seen the lone wolf, which is a typical community smell. There’s one guy in a corner typing away, uh, ignoring everyone and just pushing Git commit and it’s done completely ignoring the team-based rules. And of course, when that guy goes to home, the team is angry and has to revert a few things or has to modify a few things. That’s not really a great way to form a real community. It’s a team but it’s not a community and it’s not going to be really creative as a community that way. And there are different examples of community smells like that in the book. That’s not a concept that I invented, but something that I encountered by the work of Damian Tamburri, uh, professor in the Netherlands, who has been working on empirical software engineering and also behavioral software engineering.

Henry Suryawirawan: The moment that I read this part, right, the community smells, and also the social debt, right? I think it’s really, really insightful. Many people these days call out software engineering as a sociotechnical problem, right? It’s not only technical, but are social aspects that you also need to take care of.

[00:29:05] Collective Creativity

Henry Suryawirawan: Just like what you mentioned, right? There are some antipatterns in terms of behaviors or maybe teamwork, communications, right? You can also see if the team doesn’t talk to each other. I think that’s also another community smells right. And I think the most important thing that you mentioned about this part is that you cannot be creative if you’re doing it in isolation, right? Like you are doing it yourself. So tell us how can a team actually do something more together such that we can create more creative output? Maybe there are some things that you can advise us here.

Wouter Groeneveld: Well, for teams, I think it’s obvious that everyone should be open to the ideas of others, should be respectful to one another, even if you do not agree with the ideas or the implementation that someone else is trying to cram in But one of the most important things perhaps for engineering managers to take away is to try to create a creative culture within the company, which means that sharing knowledge is also as important as getting the stuff done.

Because if you don’t share knowledge, not even within the team, but across different teams. And, I’m not just talking about sharing the corporate knowledge or the functional knowledge of the software itself, but also more silly things like the personal office management. For instance, if someone set up a wiki and they’re having a blast, why not share that. So someone else can perhaps also pick up that. If you somehow manage to combine different ideas or publish something, why not share that? It shouldn’t always be work related. And I’ve seen in the past that that’s a bit frowned upon. Most of the efforts for sharing knowledge are still safely within the context of the corporate software itself, and it shouldn’t be.

Henry Suryawirawan: Thanks for some of the tips. I think some techniques like, you know, pair programming, mob programming, it’s also quite useful. Cross-pollinate ideas, learning maybe from seniors and juniors, right? And I think it’s always a two-way thing. It’s not just one way, right? I think that’s also another key thing.

[00:30:55] Constraints

Henry Suryawirawan: Let’s move on to the third theme, which is constraints. I think this is for some people who know they, they can see it, but for most people who doesn’t understand that constraints actually can also create more creativity. So tell us more about this concept that constraints can actually make us more creative.

Wouter Groeneveld: Right. So most programmers usually get angry when they’re given constraints. Let’s just be honest. If someone says it’s gotta be done by the end of the week, then you’re starting to sweat and you don’t really want to continue at all. So there are different ways of applying constraints. Most of the constraints are just given to us, right? Like budget constraints, time constraints, hardware constraints, software constraints. If you end up in a team who’s working in Go, then you gotta right software in Go, unless you manage to convince someone to write a microservices in another language. But that’s just a constraint that’s inherited to the program itself.

But on the other hand, we have something called self-imposed constraints, and that’s perhaps the most interesting one. It can be viewed as follows. Instead of having given constraints, you give yourself additional constraints. For instance, if you’re stuck on a method or on a class or on a particular programming problem, you can say to your pair, why not try to write this in five lines or less? Or why not try to not use any loops? But try to use recursion instead. Or the other way around. It forces us to view the problem from a different angle and it forces us to rethink what we’re actually doing. So, these constraints that you impose yourself are really powerful. And in the beginning, you have to play around and try to see, um, am I pushing my luck? Am I doing it wrong? Am I adding too much constraints, because that’s also going to be a problem.

There’s something called a sweet spot of constraint, which means if you have too little constraints, for instance, barely one or two, then the project is not going to be done. If there’s no deadline and there’s no money, you have an endless amount of money. Imagine. Then you are probably not really going to bother having anything done today, or tomorrow or the week, the week after that, you’re just going to take a few years of vacation before getting started. But on the other hand, if someone says it’s gotta be done by tomorrow and you only have like a few hundred euros of budget, then that’s next to impossible. So if you have too little constraints, you can add a few yourself. If you have too many constraints, you can try to imagine that you have less constraints. For instance, take some away. But of course, sometimes that’s just impossible. So you have to imagine that.

And by imagining that, you can also approach a problem in a different way. So that’s really an interesting one. A silly one, a silly example that we did in the past was, for instance, let’s try to fix this without consulting the internet, without trying to look up anything. Some of the solutions then are probably not going to be very optimal. But then of course, you look it up afterwards and you compare and you’ve learned something. The goal is always to learn something.

Henry Suryawirawan: Yeah, I wish that we all can have this unlimited money, unlimited time.

Wouter Groeneveld: Yeah, I do too.

Henry Suryawirawan: Just cruise along, yeah. And don’t create anything. But I think what you mentioned, right, time and money are like the common, most common things that become a constraint, right? Because we work in a software projects or maybe, you know, like a competition with the industry. So we have to produce something fast and also cheap, right? And I think the other thing is scope, right? So sometimes we can tweak the, you know, the kind of features that we have to build so that we can be more creative, you know, like a focused kind of effort to solve the problem. And for me as well, uh, doing this podcast, the time-based constraint really works for me, because every week I have to produce something. And that kind of like creates a lot more output for me.

Wouter Groeneveld: Yeah, that’s, that’s true. I do something similar actually for my blog at brainbaking.com. A bit of people lurking there. I say to myself, I wanna have something online every four or five days. And it doesn’t really matter what. And most of the ideas are just plug for my personal knowledge management system. So I take notes, whatever I see or whatever I’m reading. And if I wouldn’t have said that myself, there would be a lot less interesting articles I think. Yeah.

Henry Suryawirawan: Yeah. And sometimes it’s not about the high quality of the content, right? It’s the act of just producing that think can improve the quality over the time. And yeah, just, uh an intermezzo as well, so Wouter here is a professional baker as well. So if you’re interested in learning how to bake, I think you can learn from Wouter’s blog.

So the most important thing about this constraints theme for me is that don’t forget there is another constraint, the self-imposed constraint apart from the inherent constraint of the problem that you’re working.

[00:35:33] Critical Thinking

Henry Suryawirawan: So let’s move on to the next one, which is critical thinking, right? So I think many people understand, yeah, we have to be critical, but what does it mean to be critical?

Wouter Groeneveld: Well, you have different phases of the typical creative, inventive way of thinking. And most of the time, I think everyone is familiar with, for instance, brainstorming, right? When you’re trying to brainstorm, you’re trying to ideate to generate different ideas of approaching a problem in a different way. There are, for example, 10 different ideas. And sometimes I’ve seen just people pick the idea that they have been implemented before, because it’s the easiest one because they know it, because they’ve used the software or the technology before. Because of the constraints, if money or budget is tight, you, of course, do something that you’ve been doing before because then progress is faster. That’s really simple. But perhaps it’s not really the best way of picking the idea. Or perhaps if you chose the second idea, did you evaluate the other eight after that? Did you talk about those? Sometimes things like that get easily forgotten.

Henry Suryawirawan: Yeah. So I think another thing that you can do in the team that I learned, right? You can do this thing called spike, right? Maybe in your sprint, you allocate time to do spikes, you know, learning new technologies, doing POCs, and, you know, sharing the findings, right? In a timeboxed manner. The key is the timeboxed manner.

So I think critical thinking. Some people also in the design thinking world, you have this, you know, diverging thoughts and then converging thoughts. I think that’s also probably one of the techniques that is commonly used to be more critical, right? I think another important part is that sometimes you can do it in a team and sometimes you can do it individually, right. So maybe there are some techniques that you also have learned in the research that you did. How can we, you know, improve our critical thinking mindset?

Wouter Groeneveld: That’s a really interesting one. It’s kind of difficult to answer. I think the obvious answer is going to be that you have to try to be more critical each and every day. And something, something difficult you encounter, try to stand still for a moment and think, what am I doing right now? Should I be approaching this problem at all? Sometimes it’s not problem solving or using creativity to overcome the problem. But sometimes, it’s problem defining. Is this problem the problem I’m trying to solve? Sometimes the answer is no. And not a lot of software developers ask these questions.

Of course, again, under pressure, I completely understand you’re not really going to do that at all. But it’s not only on a low level like when you are programming different functions, but also on a high level when you are approaching a client or when you’re discussing something with a functional analyst. You’ve always have to take these things into account. And it’s a bit like putting on different hats, like the critical thinking hat, and then you have to ideate hats and coming up with different ideas. You can’t do both at once because if you try to do that, then you would have a lot less ideas, because you are shooting down the ideas as soon as they come into your mind, because you’re saying, no, that’s not going to be possible. No, this is costing too much.

First, you have to ideate and not really evaluate whatever idea comes to mind, and then you critically evaluate the ideas. And because of that brainstorming, the typical way that we do is not really the best way to approach it. It’s more interesting to brainstorm individually and to write something down. And then in group discuss and critically evaluate each idea. And not simply shoot down those, because once someone starts blurting out ideas like, oh, I have this idea for that, someone else is going to say, nah, not gonna happen. We don’t have time, we don’t have money And of course, that person is not going to come up with another idea, because they’ve just been shut down. So you’re shutting down the communication doing that. So that’s not really the best way to approach things.

Henry Suryawirawan: Yeah. So you mentioned this thing, right? I have another episode where they call this anchoring, right? So this is probably a community smell that people have to be aware of, right? So in your group setup, right, in your brainstorming, maybe try to do individual sticky notes writing first, right? And let people put forth their ideas rather than, you know, anchoring it to some seniors or maybe some people who are senior in the management level, right? So thanks for this insights.

[00:39:42] Creative State of Mind

Henry Suryawirawan: So maybe let’s skip to the creative state of mind theme now. So I think this is also important because your environment, maybe your physical, right, also kind of like have an effect to your creativity. So tell us more about this creative state of mind.

Wouter Groeneveld: Well, that’s when my previous experience and my current experience as a researcher really comes to mind. For instance, as a software developer before COVID of course, I’ve been working in many open landscapes, which are typical, really loud environments where everyone is just doing different things. Multiple teams are put together in one giant open space because managers think, oh, that’s bound to cross pollinate ideas. That’s a really good way to generate more and more value or more ideas. And the opposite is true, because nobody can concentrate and everyone is really shouting to each other, and the volume keeps getting up and up and up.

So that’s not really the best way to approach things creatively. So open landscapes, they just don’t work. And that has been proven in academic and academia before. There are multiple papers on this, on the topic. That just doesn’t work. But on the other hand, right now, I’m sitting in a small concrete room. In academia, you have lots of small rooms where researchers work usually alone, uh, working at chipping away at a paper or at their research. And that’s of course also not really the best way to approach things, because if you individualize the work itself without really talking to each other, then again, the cross pollination, I’m going to keep on repeating that, is not going to happen either.

So you have to somehow try to merge or marry those two things. Like if teams are working, leave them alone, put them in separate rooms but try to find a way for people to bump into each other, right? Ideally, people from different fields even. So for instance, the MIT buildings have been redesigned to do exactly that, um, where the physicist can bump into a computer scientist or psychologist, and then we could talk about the research they are doing. And perhaps, someone is like, okay, that’s an interesting thing that I can incorporate into my research. And then when they have to do the actual work themselves, the focused work instead of the diffused work, then they can go to a quiet room with a few other people or by themselves, to do the work itself without getting interruptions.

[00:41:56] Virtual Interruptions

Henry Suryawirawan: Yeah, thanks for mentioning about this open space layout. I don’t know how it all started, right? I think maybe 10 years ago or something like that, all major companies start this open office layout, right? And I think what you spoke is really true, right? Like we, instead of getting more creative, I think there are a lot of distractions as well. Which I wanna also bring to another topic, instead of just the physical aspects. We also, uh, live in a electronic aspect. You know, things like instant messaging, emails, and all the other interruptions that we have. So tell us more about the aspects of this virtual interruptions that can also affect our creative state of mind.

Wouter Groeneveld: Yeah. When you’re working, you have this creative state of mind or this flow of different thoughts that you’re trying to somehow systemize or summarize into something that you’re doing or trying to creatively overcome a problem. And then someone interrupts you like someone else comes down next to your desk and asks a question or you somehow feel the urge to grab your phone and starts scrolling through Twitter, or no, I should say X right now. Things change so quickly that I’m, I’m unable to keep up.

Interruptions are bound to occur so you just can’t avoid them, you can’t avoid. Of course, a few things you can do yourself, like deleting your X account. And trying to keep that cell phone away from the desk when you are actually doing the work itself. And also different focus tools like Pomodoro techniques or software that helps you reduce your screen time or disable your internet, things like that. These are simple things that sometimes can work. But still someone else might ask a question, come by asking a question, and then there’s the principle of trying to store your current state of mind, the thoughts you are having. Quickly write them down some way, either digitally or just with pen on paper, so that when the person leaves and the answer has been given, you can pick up where you left. And that’s an important one that I see a lot of people having trouble with, because after they’re gone, they’re like, oh damn, what was I doing again? You have to take a deliberate effort to get back in that flow state, and it’s been proven to take up to 30 minutes or even more. So before you Alt+Tab to your mailbox, try to remember that you’re gonna need 30 minutes again after that to get back into the groove of the work you’ve been doing. So that’s not really what I’d call being very productive.

Henry Suryawirawan: Yeah. If people love this topic, I think Cal Newport also have the book, right, that can teach you some insights how, yeah, how you can actually get in this creative mind without being interrupted by instant messaging and emails, right? I think these two are probably the killers of productivity most of the time.

[00:44:36] Well-Rested

Henry Suryawirawan: And also another thing important is you mentioned we have to have well enough rest or sleep, in short, right? I think a lot of programmers, including myself, I am like a night owl. I like to work at night and, you know, like maybe sleep less. So, tell us like from your research, what’s this importance of sleep or well rested?

Wouter Groeneveld: Yeah, it’s related to something I said earlier that happy programmers are usually more creative programmers, and that also includes that well slept programmers are going to be more productive, more happy in general and also do more work more willingly and be more creative in general.

So there’s this psychological wellbeing state that you also have to take it into account when being a creative programmer. I know it’s really easy for me to say something like that. A lot of people have problems with that. It’s usually not the employee, but the employer’s fault. So there’s still a lot of work that needs to be done. I think it also is related to trying to create a corporate culture where creativity is allowed. And that doesn’t really mean creativity limited to the software that you’re working with. But for instance, staring out of the window a few minutes to let your mind wander, to think about a few things subconsciously that you’ve been doing over the past few hours, and then just going back to work and coming up with a new idea or a fresh hat or something like that.

Something like that is sometimes frowned upon, especially in my experience, my previous experience in the industry. For instance, there’s a funny experience I’ve had is, um, we worked really hard before noon trying to put out a fire in production, trying to fix, hot fix a bug. And it took like 02:30 or something like that, so everyone was already finished eating and got back to work. And, uh, when it was finally done and we also decided to take a little break. And we like to play a few rounds of cards when we are having a short break. And of course, just at that moment, the boss came along and saw us playing cards at 02:30 in the afternoon. And he was like, what the hell are you doing? But he didn’t see us putting out the fire, of course.

So our brain can’t work eight hours continuously. You have to take some time off. And that doesn’t mean a few days off, but can also mean a few moments, a few minutes, a few half hours or something like that, yeah.

Henry Suryawirawan: Yeah. And speaking about cross-pollinating ideas, right? I think when you dream, I think it’s also the most creative state of mind, especially if you touch on this REM sleep, right? I think I read book by Matthew Walker. I think that’s also another way of you cross-pollinating ideas in your sleep, right? I think maybe programmers, if you haven’t got enough sleep, please try to sleep more.

[00:47:11] Curiosity & Perseverance

Henry Suryawirawan: And let’s go to the next theme, which is curiosity. One thing that I pick in this curiosity part, right. You mentioned curiosity and perseverance are the two most defining personality traits for creativity. So be curious and persevere. So tell us more about the importance of those two.

Wouter Groeneveld: Well, like I mentioned before, if you’re not curious, you’re not going to pick up on new ideas, because they just simply don’t really interest you. And one of the really strange things I’ve seen my ex-colleagues say is like, oh, but I’m a .NET developer, I’m never going to do any Java. And I was like, what? The CLR is exactly the same as the JVM. They’re constantly stealing ideas from each other, the world in Oracle and the world in Microsoft. Java and .NET are, or C# are basically the same language used for the same corporate purpose. So why would you limit yourself to only learning something like that?

And you can apply the same principle if you’re a Java developer. Why not just take a look at some conferences, which are focused on .NET. Perhaps they have talks about concurrency that you wouldn’t really think about when you are doing your Java stuff. If you’re not curious, you’re simply not going to check them out. And then you’re missing out on ideas. Of course, I completely understand that you have to devise your time somewhere and you can’t really take a look at everything or learn everything. So, again, you gotta choose your battles, is what I would say

Henry Suryawirawan: Yeah, and getting out of comfort zone, which you mentioned in the beginning as well, right. Sometimes, uh, I mean, I don’t know, like as we grow senior, sometimes we kind of like want to specialize a bit. And, you know, specialize in the kind of problems that we work with, the kind of technology that we work with. I think getting out of comfort zones from time to time, learning new technologies is always useful.

So, I won’t cover the last part, creative techniques. For people who are interested in this conversation, maybe they can go and read the book. I think it’s really, really, uh, insightful and interesting book for people who love this kind of topics. So I’ll refer you to reading that book.

[00:49:04] 2 Tech Lead Wisdom

Henry Suryawirawan: Wouter, thank you so much for explaining, uh, most of the themes, right. And I have one last question for you, which is called the 3 Technical Leadership Wisdom. This is something that I always love to ask my guests to share their wisdom so that we all can learn from you. Are there any wisdom that you want to share for us today?

Wouter Groeneveld: I think the most important part is that we have seen students and also software engineers in the industry say things like, I am very creative or say things like, I am not very creative. But they’re not aware that creativity is a skill that can be learned. It’s like a muscle. So it’s just the same like learning how to program, you can become more creative. Your creative potential can be increased by trying to look into these techniques and try trying out a few different things like that. It’s not just a simple matter of someone is more creative than the other one. It’s something that can be learned. I think that’s a really powerful and important message that we can try to pass along to the listeners.

The second one, perhaps, is convince your manager to also read the book. Because, I know the subject of the book is called the Creative Programmer. But it’s less technical than you might be inclined to think at first sight. And it’s that culture of being more creative is more important than you think. If some companies would be open to a few of those concepts and would encourage all of people to be a little bit more creative, would employ more coaches to help them, reach for those tools, then I think you as a software developer would be also a more happier software developer. And like we mentioned before, managers, you should know that happy programmers are creative and good programmers.

Henry Suryawirawan: Right. Thanks for the plug. So, Wouter, if people love this conversation, they wanna learn more, is there a place where they can find you online, including your professional bakery blog?

Wouter Groeneveld: Well, it’s, it’s not really a professional bakery blog. It’s a blog about any thought that I have. And I call myself a brain baker because I refuse to be a specialist So, yeah, you can find me there at brainbaking.com, I blog regularly. And I’ve been active on X/Twitter for years and years. So you can find me on conventional social media. So the best way to reach out is just to go to my blog and contact me via email if you have any questions or insights.

Henry Suryawirawan: Yeah. And also don’t forget to buy the book and read the book. I, I’ve read it during my preparation. I think it’s really, really insightful for me, at least. So you’ll find some interesting ideas from the book as well. And don’t forget if you love games, right? I’m sure by reading the book, you’ll be having nostalgic moment, you know, like old games and things like that. I think that can also spark new ideas.

So thanks again, Wouter, for this time. I really learn a lot and hopefully all programmers here can become more creative.

Wouter Groeneveld: Thanks so much.

– End –