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.
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.