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. But also, beside the technical knowledge, something else was important but I wasn't really sure what. And after a few years I noticed that creativity is an important aspect of problem solving and
software development. Hey everyone, my name is Henry Surya Virawan and you're listening to the Technically Journal Podcast, the show where I'll be bringing you the greatest technical leaders, practitioners and thought leaders in the industry to discuss about their journey, ideas and practices that we all can learn and apply to build a highly performing technical team and to make an impact in your personal work. So let's dive into our journal. 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 Walter Gronwald. He is a software engineer, computer science education researcher and the author of The Creative Programmer.
In this episode, Walter dives deep into what makes good engineers truly exceptional and that is creativity. He describes his definition of creativity and shares the seven 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 Walter after some quick words from our sponsor. Hey, thank you for being part of the Technology Journal community. This show wouldn't be the same without your ears, and you are the reason this show exists. Creating this podcast is a label of love, but the truth is it also takes time, resources, a whole lot of passion, and an
extra bit of caffeine. So if you're loving TLJ and want to see it keep on growing, consider becoming a patron at Techledjournal dot dev Patron or buying me a coffee at Techledjournal dot Dev Coffee. Every little bit helps field the research, editing and sleepless nights that go into making the show the best it can be. Thanks for being the best listeners any podcast could ask for. Hello guys, Welcome back. To the new episode of the Techno
Journal podcast. Today, I have with me Walter Gronerfeld. 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're going to learn about creativity as in Programmer from Router and what aspects are really really needed when we want to 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, Walter. Thanks for having me. Welcome. Hi. Walter, 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. 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 definitely roles.
And we started doing interviews, trying to get new people to join people from colleges and universities and also all the 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. I know, 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. 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 half time at 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 coddling 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 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 program, 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. Thank you for sharing your story. I always love reading this kind of book, right?
A book that came from Academy or will, you know with well back research, right? I think I have few episodes or 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.
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. So 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? 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 the major problems. But as a researcher, I of course can just say OK, 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 all those great and the result was a huge list of non tactical requirements. People were saying OK, lots of communication based skills are really important. A lot of people were saying you got to really be good at constraint based thinking. A lot of people were saying no, no, it's got to 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 it's a really huge list of competences 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 that's
interesting. Then we try 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 and 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,
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. 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. Yeah, sure. So one of the, let's call it, classic definitions of creativity is something is creative when it's 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 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 teams,
let's call it teams. 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 programming. So one of the most obvious domains or aspects of being a creative programmer is having technical knowledge.
In essence it means imagine you're 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 got to 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 heterogeneous group than in a homogeneous 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. This stuff has to work on an older CPU because it's still deployed somewhere. Or the banking industry says it's got to work in Pascal or in VB dot VB. Six older, older software technologies that you have to work with.
Of course you want to use more in 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 critical thinking and a creative state of mind. So what does that mean? Creative program is a critical thinker.
That means you have different IDs, but you still need to critically evaluate each of these IDs to see whether or not they're applicable to what you're doing right now. For instance, which is really relevant today. And if you ask ChatGPT for a question it usually comes up with an answer that more or less works.
Or GitHub Copilot. Most of my students, I'm I'm Speaking of course about students right now but most junior or some senior colleagues also do this is 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, wait, 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 option. But you can't just skip that
step. And then you have a creative state of mind, which is like the classic aha moments when you're showering 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 6th 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 program. One of those, of course, is a technique everyone uses and knows zooming out. If you're really focused on a few methods you're 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 mop to the world of software genieing to help become a more creative program. 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 sense of all this. Thank you for the high level overview of the seven different themes to become a creative programmer.
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 that, I think it's also kind of like insightful, right, Because it 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. Yeah, sure. Creativity is a systemic, which means it's linked to all 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. 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 that something is 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 wow, Because with modern art, you 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 know the long and you're you're like, OK, yeah, yeah, and this is going this has got to 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.
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. Yeah, indeed. That's the difference between having 10 years of experience
doing exactly the same thing. Which means actually 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 you're going to fail multiple times, but that doesn't mean that you're not learning anything. I think that's a really
important take away. If you want to be a creative programmer, you have to experiment like one of the concepts is. Of course, also being curious, so that's indeed an important aspect of it. Right. So let's go into the themes, right. So maybe we start from technical knowledge also. I just want to also give to listeners, right, how Walter explained these theme in the book, right? You have a mix of 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 Walter is explaining for each of the theme. 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 a software you need to know Java. But maybe I want to touch on not on that aspect because that is kind of like given.
Most people should sure should by now understand about that I hope so. I want to 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. 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, OK, 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 IDs 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.
Especially with nowadays the Internet, like social media, Doom, scrolling, keeping up to date, the conclusion is you got to 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 e-books or other things that you hear even her on the streets passing by like 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. 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 wonder how much time I have to actually consume all of them. So when you mentioned 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 loop gather internalized at 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. Yeah, quite discipline. Yeah, I noticed indeed a few ex colleagues of me having things
like personal wikis. They store technical information or how to do a grab or how to do regular expressions in Java or in Kotlin or whatever. For the 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 got to 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 program 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 input, there's too many things to do, and to read, 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. Now you have to summarize it yourself in your own words. When you're doing that, then during that process you're probably linking it to something else. If that linking doesn't occur, then the cross pollination and the new IDs are not going to come. And of course the ultimate goal of having a personal knowledge management system is having UIDS capturing the new IDs and doing something with it.
Like Nicholas Newman, a really well known German academic, used the principle called Settle Kasan technique. It's really popular lately. 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 Lumen 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. 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 text, but also in audio. Like this podcast and also video on YouTube and maybe even like short clips, you know, like. YouTube shorts and it's crazy.
There's just so, so many 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 podcast before I made it, such a framework like it's called 4 CS. So you you first, you consume, consume a lot, but you have to create the second seat.
Yeah. And then you connect with people, maybe create some kind of network or maybe groups to actually share the creativity that you have. And the 4th one is actually to do it consistently. So I think that is also probably one thing that listeners can learn from. 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. 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 IDs for years and years, and I didn't really do anything with those IDs. 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 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 filling it in. And of course I can work based on this book. I still have open IDs or questions I didn't have before
writing them. Some of the chapters I can write some more fleshed out examples for, or I've had IDs for future research based on what I've been writing. And if I wouldn't have written this, then I wouldn't have those IDs. So it's just a continuation of what you've been doing before. 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 about this word like so, so many times, right. Cross pollinate, it's really important. Yeah. And then the last one is take action, right. So you can be creative if you don't produce or you know do something about it, right. So I think that is like a good summary. 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 some are more introverts, some prefer to speak to the machine other than people. Some also don't like working in teams, they just wanna go solo. So tell us more about this importance of collaboration. 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 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 Cameratas 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 ID 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 ID even better. But of course you need to be open to to do something like that.
What I also mentioned earlier, and one of the most interesting parts perhaps of this chapter, is that the ID of the community smells in the later part of the chapter. Which means you have this concept called technical depth, which I guess everyone knows as a programmer, 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 depth, you have social depth, a concept called social depth. 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 the individual level, because. If you're unhappy and 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 it's not going to be that creative. So 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, ignoring everyone and just pushing get commit A and it's done, completely ignoring the team based rules. And of course, when that guy goes to home, the team is angry. And as they we've heard a few things or has to modify a few things, but that's not really a great way to form a real community. It's a theme, 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 Damien Tamburi, a professor in the Netherlands who has been working on empirical software engineering and also behavioral software engineering. The moment that I read this part right, the community smells and also the social that right? I think it's really really insightful.
Many people these days call out software engineering as a social technical problem, right? It's not only technical but there are social aspects that you also need to take care of. Just like what you mentioned right? There are some anti patterns in terms of behavior, so 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're 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. Well, for teams, I think it's obvious that everyone should be open to the IDs of others, should be respectful to one another, even if you do not agree with the IDs 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 this 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 alliance 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 IDs or publish
something, why not share that? It shouldn't always be work related, as 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. Thanks for some of the tips. I think some techniques like, you know, pair programming, more programming is also quite useful, right? For sure 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. Let's move on to the third team, 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. Right, so most programmers usually get angry when they're
giving constraints. Let's just be honest, if someone says it's got to 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 got to write software and go. Unless you manage to convince someone to write a microservice in another language. But that's just a constraint that's inherent 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 clause, 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 Sweet question 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, 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 constraints, which means if you have too little constraints, for instance barely one or two, then the project is never going to be done.
If there's no deadline and there's no money, you have an endless amount of money. Imagine. Then you're 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 then on the other hand, if someone says it's got to be done by tomorrow and you only have like a few €100 of budget and
then that's next to impossible. So if you have two 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 a really interesting
one. A silly 1A 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. Yeah, I wish that we all can have this unlimited money, unlimited time and. Then we 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 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 kind of features that we have to build so that we can be more creative, focused, kind of
effort to solve the problem. And for me as well doing this podcast, the time based constraint really works for me because every week I have to produce something and that kind of creates a lot more output for me. Yeah, that's that's true. I do something similar actually for my.blog@brainbaking.com. A bit of people doing there. I say to myself, I want to have something online every four or five days and it doesn't really matter what.
And most of the IDs, I just look 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. Yeah. And sometimes it's not about the high quality of the content, right. It's the act of just producing that I think can improve the quality over the time. And yeah, just the mezzo as well. So Walter here is a professional
Baker as well. So if you're interested in learning how to bake, I think you can learn from Walter's blog. So the most important thing about this constraint scheme 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. 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? 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 IDs of approaching a problem in a
different way. There are for example, 10 different these and sometimes I've seen just people pick the ID 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 forecast 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 ID, did you evaluate the order aids After that? Did you talk about those? Sometimes things like that gets easily forgotten. Yeah, so I think another thing that you can do in the team that I learned right, you can do these things called spike, right in your Sprint you allocate time to do spikes, you know learning a new technologies, doing PO, CS and you know sharing their findings right in a time box manner.
The key is the time box 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 technique that is commonly used to be more critical, right. And 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? 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 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're programming different functions, but also on a high level when you're approaching a client or when you're discussing something with a functional analyst. You always have to take these things into account. And it's a bit like putting on different hats, like the critical thinking hats. And then you have to ideate hats
coming up with different IDs. You can't do both at once, because if you try to do that, then you would have a lot less IDs because you're shooting down the IDs 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 ID 8 and not really evaluate whatever ID comes to mind, and then you critically evaluate the IDs.
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 ID and not simply shoot down those. Because once someone starts blurting out IDs like, oh, I have this ID for that, someone else is bound to say, Nah, not going to happen.
We don't have time, we don't have money, and of course that person is not going to come up with another ID because they just been shut down. So you're shutting down the communication doing that. So that's not really the best way to approach things. 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 senior in the management level, right? Exactly. So thanks for this insights. 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. 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 load environments where everyone is just doing different things. Multiple teams are put together in one giant open space because managers think, oh that's point
to cross pollinate IDs. That's a really good way to generate more more value or more IDs. 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 landscape, 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 working at chipping away at that 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, 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, OK, that's an interesting thing that I can incorporate into my research. And then when they have to do the actual work themselves, the focus work instead of the diffuse 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. 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 to have this Openoffice layout, right? And I think what you spoke is really true, right? 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 live in an electronic aspect, 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. 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 start scrolling through Twitter. Or no, I should say X right now. Things change so quickly that I'm unable to keep up. Interruptions are bound to occur, so you just can't avoid them. You can't 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're 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 states, and it's been proven to take up to 30 minutes or even more. So before you all talk to your mailbox, try to remember that you're going to 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.
Yeah, if people love this topic, I think Cal Newport also have the exactly 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. 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'm 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? 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 and more happy in general, and also do more work more willingly and be more creative in general. So there's this psychological well-being state that you also have to take it into account when being a creative program. 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 ID or fresh head or something like that. So 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 as 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 2:30 or something like that. So everyone was already finished eating and got back to work. And when it was finally done, then 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 2:30 in the afternoon and he was like, what the hell are you doing? But he didn't see us spitting out the fire, of course. So our brain can't work 8 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.
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 R.E.M. Sleep, right. I think I read this 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 and let's go to the next theme which
is curiosity. One thing that I picked 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. Well, like I mentioned before, if you're not curious, you're not going to pick up on new IDs because they just simply don't
really interest you. And one of the really strange things I've seen my ex colleague 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 GVM. They're constantly stealing IDs 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're 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 got to choose your battles. That's what I would say. Yeah. And getting out of comfort zone, which you mentioned in the
beginning as well, right. Sometimes, 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 insightful and interesting book for people who love this kind of topics. So I'll refer you to reading that book. Walter, thank you so much for explaining most of the themes right. And I have one last question for you, which is called the three 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?
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 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 Program, 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 other 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 we mentioned before managers. You should know that happy programmers are creative and good programmers. Right. Thanks for the plug. So Walter, If people love this conversation, they want to learn more.
Is there a place where they can find you online, including your professional bakery blog? 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 brainbaker 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 slash Twitter for years and years, so you can't find me on conventional social media.
So the best way to recharge is just to go to my blog and contact me via e-mail if you have any questions or insights. 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 Walter for this time. I really learned a lot and hopefully all programmers here can become more creative. Thanks so much. Thank you for listening to this episode and for staying right until the end. If you highly enjoyed it, I would appreciate if you share it with your friends and colleagues who you think would also benefit from listening to this episode.
And if you're new to the podcast, make sure to subscribe and leave me your valuable review and feedback. It helps me a lot in order to grow this podcast better. You can also find the full show notes of this conversation on the episode page at Techlyjournal dot dev website, including the full transcript, interesting quotes, and links to the resources mentioned from the conversation.
And lastly, make sure to subscribe to the show's mailing list on Techlyjournal dot dev to get notified for any future episodes. Stay tuned for the next Techlyjournal episode, and until then, goodbye.