wouter groeneveld

Congrats to the winners! Really interesting questions, I hope these have helped everyone contemplate the subject!
If there are any questions while you're reading the book, let me know!
It would also mean a lot if you could write an honest review afterwards. This will help put the subject and the book in the spotlight!

Cheers,
Wouter

T H Lim wrote:How to convince a manager who thinks that creativity in programming is overrated? He believes that programming is about grinding the stone non-stop until the stone takes the desired shape

Hi there, good question, I often wondered about that myself and have a few stories related to that included in The Creative Programmer. I think the best way is to have him read the book as I cite scientific studies that provide cold hard evidence that creativity is very much required to solve complex problems in software engineering!! It contains ample of examples that would make this post too long to copy here.
I think it's important for reluctant managers that don't believe their team to have them see the benefits, based on either other success stories or perhaps more importantly sound research.
Hope this helps!

Junilu Lacar wrote:

wouter groeneveld wrote:you cannot be creative at something if you don't have any proficiency in it. Sure, you can cook up code that works "by accident", but then you don't know what you're doing, meaning it's not intentional, meaning there's no room to reflect and grow.

Oh believe me, I've seen some pretty creative ways some people have found to write bad code that left a lot of room to reflect (and rant) and grow.

Remember that what you think is creative might not be creative to the person that's doing the work. It's contextual: if I'm randomly typing out code or copy-pasting from Stack Overflow and it happens to work, and rejoice and move on, then is this creative or just random and lucky? If I'm repeating the same pattern again and again because I've been doing this for ages, and yawn and move on, then is this creative or has it once been like that? But it might totally be as applying that pattern might be novel to others.

Hi Lucian,
That's a valid question and the central theme of chapter 2 (which is aptly titled "Technical Knowledge")!
I don't think I'd have the space here to answer such a broad question and would recommend you to read the chapter instead, but it boils down to this: you cannot be creative at something if you don't have any proficiency in it. Sure, you can cook up code that works "by accident", but then you don't know what you're doing, meaning it's not intentional, meaning there's no room to reflect and grow. That chapter also discusses how to digest new knowledge, how to keep organized using for instance a Personal Knowledge Management system, and how to discover links between the apparantly disjointed bits and pieces of information you've gathered.

One of our interviewees once mentioned: "creativity is the brew of input". No input, no output :-)

Krystian Kowalski wrote:I have a question - how does this book is different from other "creativity" books or the ones that try to help you build good habits?

Hi Krystian, to answer your question: this one is very much rooted in software engineering, comes with tons of examples from that world, but also shows you can extract and transfer your creative skills from other domains.
But most importantly, The Creative Programmer is based on sound scientific research. The chapters are based on publications of my colleagues and I, where we try to bridge computing (education) with cognitive psychology. So it's very much scientifically based but made "understandable" - not at all a dry academic work; that's what the papers are for!
If you're interested you can leaf through the publications that made The Creative Programmer here: https://brainbaking.com/works/papers/

The debate of code as an art vs a means to an end is an interesting one, but I'm inclined to go for creativity as a tool to come to the solution instead of creativity as the goal. In our research and in the book, we/I've always approached it as being the means, not the goal: your goal as a software developer is to solve a problem (or to identify one). Sometimes you don't need to be creative to solve something: you can simply remember a pattern applied in another project and apply it in the current one - there, works flawlessly! But sometimes a problem leaves you stumped, not knowing where to start. Or sometimes there's "something" wrong but you can't even identify the problem. That's where a creative approach should come in.
Again, there's nothing wrong with creativity as an art - far from it - but in context of The Creative Programmer, you're... well... programming!

Perhaps it's interesting to bring in this famous blog post by Dan North: https://dannorth.net/2011/01/11/programming-is-not-a-craft/ and see if you can agree (or not).

Coding practice certainly makes perfect, but we're still focusing on the technical aspect of creativity in software engineering while the non-technical aspects are as important, if not more. To me, refactoring, code kata's, etc are all very well-known and well-employed practices that should be augmented with other creative skills.
Reading indeed is paramount -- if you don't know about the multiple dimensions and socio-cultural aspects of creativity, you won't focus and exercise on those, as simple as that. But reading a book like The Creative Programmer doesn't work if your boss tells you to: you need to be intrinsically motivated to do so!
In a recent study, my colleagues and I discovered that graduate computing students perceive creativity in programming mostly as a technical endeavour like you mention here. They didn't even realize creativity in itself is a skill that can be learned and practiced. One of the reasons why I wrote the book is to spread the message and to help people realize the multidimensionality of creativity. If there's one thing you should take away from it, it's that!

Hi Paul,

I think I'm going to be a jerk here and say that all exercises are "the most important" exercises, hope you don't mind! The problem with seeking quick-fixes, especially when it comes to creativity, is that in the end you're not really flexing any muscles but just plugging that one hole. Creativity is systemic and contextual: this means (1) it's connected to everything (to collaborative efforts, to the global available technical knowledge, to your critical thinking, ...) and (2) it depends on the situation (that includes the project, the team, the support of your superiors, your mood, ...).
If you were to pick out one as "most important", say a thinking outside of the box exercise, you're simply getting better at divergent thinking. Which is great! But that's not creativity--that's just _one_ aspect of a multidimensional phenomena that's harder to grasp than you might think.

In short: when it comes to creativity, don't get better at one thing but try to explore and develop all dimensions (which are of course mentioned in the book)!
I hope I didn't let you down haha!

Hi Sai, that's a tough one! It's briefly touched upon in the book The Creative Programmer but to be honest I could easily fill a second one by diving deep into that topic. The question it boils down to is: are you being creative for the sake of being creative, or are you being creative because you HAVE to since you're facing a problem that can't be solved by conventional measures (e.g. apply the thing you did a hundred times before)?
There's nothing wrong with giving in to that creative urge that we have - I think that's why many of us are programmers - but for my research so far, creative problem solving is creativity in context of a real problem, not just to express oneself (as the term "creative coding" does imply, where p5.js is regularly used to just mess around with and make something cool, just because).
That said, I think we *can* and *should* fool around just because -- this in turn will help us attain and sharpen the skills needed to solve the real problems. But yes, a colleague engineer that goes overboard with their creative urge can easily lead to speculative generality and overengineered solutions that have you scratching your head after a few months (or even days lol). I think in that case it's important to pair that person up with someone who can help push in the breaks. The interaction between colleagues - the collaborative part - is another important aspect of creativity, which is the central theme of chapter 3.

Hope that answers your question at least partially!

Happy to be here, cheers!!

Thanks for the link Junilu I'll be sure to give it a read!
You're absolutely right; insight is an important aspect and in fact one of the main themes that got its own chapter in The Creative Programmer.
But before you're at the "insight" step, a lot of other steps have to be carried out, namely executing hard & long work, not merely waiting for the insight to occur (as sometimes one ought to think)...

Campbell Ritchie wrote:

wouter groeneveld wrote:. . . Never heard of S&S . . .

My bread is almost ready to go in the oven; it is rising quickly because of the warm weather and because I used yeast from a new can. I usually bake plain wholemeal because it is what I eat most of and don't have the time to experiment. Well, maybe just occasionally.

I'm getting hungry, post a pic when it's done!
If you only use a tiny pinch of yeast (dried?) you can let it rise overnight to increase the flavors!

Hi Krish, good questions! That's explained in the first chapter of the book. There's this ongoing debate among creativity experts whether or not creative skills are domain-general (transferrable across for example painting and programming) or domain-specific (not transferrable). I think that depends on which level you view your creativity: micro or macro?
To me, the answer is both, thereby we're outsmarting academics and sidestepping the debacle. It's domain-specific: if you don't know how to code multithreading in Java, you won't come up with creative solutions to your parallelism problem on the JDK. It's domain-general: if you know how to think beyond the canvas to capture ideas, I reckon that skill will come in handy and you can do the same when facing production issues in code. That's just a silly example; the book contains more of those that are properly substantiated with references. There's been a lot of research published regarding your question!

BTW I'd say "coming up with new approaches to solve things" is indeed a creative skill needed in context of programming, but merely ONE of the many skills needed and sometimes not at all easily applicable or relevant (e.g. legacy software, hard deadlines, tight maintenance releases, budget, annoying boss who won't let you, ...)

Hi Burk,

Burk Hufnagel wrote:Welcome to the Ranch, Wouter!  

I'm curious, is this your first book? I know it's published by Manning but when I googled your name I got a link to Simon & Schuster and they listed you as a author and showed "The Creative Programmer", which has me wondering if S&S owns Manning - do you know?

Never heard of S&S so no idea :-) It's my second book, the first one was a Dutch one on the science of sourdough bread, haha!

Also wondering if you find bread baking as potentially creative as programming? I suspect there are limitations on what you can do and still have it recognizable as bread, but I think that may be similar to being restricted by the syntax of a language... does that seem reasonable?

That's a good question! I think that depends on what you're trying to achieve with bread baking. Most professional bakers are aiming for consistency and volume to sell as much as possible and keep the bread taste the same as not to chase away customers, while some try to reinvent bread by experimenting. The former could perhaps be seen as maintenance coding and the latter as a greenfield software project? I think both approaches have opportunities to be creative, but at different levels, and with different constraints. Does that make sense?

Cheers!

Hi Fintan,

That's kind of a vague question, I'd be inclined to say the first part of the answer is being motivated to be more creative! Without intent and interest, nothing much will follow. In my book, I've divided the "how to be creative" question into seven main themes (chapters 2 and onwards). Feel free to take a look and perhaps afterwards rephrase your question to something more specific ;-)