Description: https://images.manning.com/360/480/resize/book/e/5600d0c-6a71-4cb7-9dd0-b27f02e47708/Groeneveld-MEAP-HI.png

From The Creative Programmer by Wouter Groeneveld

Creativity is essential to being a successful programmer. The stories, examples, and groundbreaking research in this book will help you unleash your creative potential and make you a more successful developer.

Read on for more!


Take 25% off The Creative Programmer by entering fccgroeneveld into the discount box at checkout at manning.com.


We humans love to create. Homo Faber—creating to control our fate and environment—is a manifestation of man’s innate being in nature, according to philosopher and novelist Umberto Eco[1]. In this vein, this book will take you on a journey towards your innate being as a creative programmer.

Chances are that you’re interested in this book because you want to become a better programmer. You’ve come to the right place. Only, don’t expect the unfolding of the latest technical marvels such as a JIT compiler of some virtual machine, or to learn more about programming language x or y. This is far from your average programming book.

Instead, we’ll be working on a different level. You’ll learn how highly creative individuals (and groups) approach problems, what their habits and thought processes are like, and how they arrive at both more productive and more creative solutions. Once you’re a certified Creative ProgrammerTM, you’ll be able to unravel any technical marvel with ease and learn multiple programming languages at once. Well, at least according to the theory. Whether you just picked up programming as a new discipline or you’re an experienced developer, my hope is that you will acquire at least a few new creative tricks to put up your sleeve.

More experience in a technical trade such as programming does not necessarily equal more creative output. I’ve been in the software development industry for more than a decade and witnessed few highs and a lot of lows. Software seems to be doomed to fail. Pragmatic programmer and co-creator of the Manifesto for Agile Software Development Andy Hunt starts his book Pragmatic Thinking & Learning on a similar troubling note[2]:

Whether you’re a programmer or frustrated user, you may have already suspected that software development must be the most difficult endeavor ever envisioned and practiced by humans. Its complexity strains our best abilities daily, and failures can often be spectacular—and newsworthy.”

While Andy’s approach is to teach you how to think & learn, my approach is to teach readers how to approach problems more creatively. After witnessing so many software failures (and unconsciously helping conceive them), I’ve become convinced that the deficit may be one of non-technical skills, not of technical ability. This obsession even led me back to academia, where I have spent the last four years researching creativity in software engineering. The fruit of my hybrid industry/academia work is this book.

But before we can get cracking, we first need to get a few questions out of the way.

Why creativity?

Why bother becoming a creative programmer when you’re already a competent programmer? The answer is multidimensional. Let’s examine the major reasons to lead a creative developer’s life.

First, simply put: because employers ask for it. For years, nearly every software development job advertisement contains the word “creative”[3]. Everyone knows that job ads are bulging with meaningless words made up by the HR department to attract as many candidates as possible. Soft skills are all the rage these days. Instead of scanning ads, we conducted our own research by simply asking software development experts “which non-technical skills do you think are needed to excel as a developer?”[4] Guess which word popped up. If you want to sell yourself, you’ll have to be creative.

As for the reason why creativity is such a sought after skill, the answer lies in problem solving. When conventional methods fail, bringing in a splash of creativity might be the way to go. Knowing how the creative process works is half the solution. For example, if your web application is struggling with handling thousands of requests per second, it might be a good idea to look at message queuing, load balancing, caching, or co-routines. If nobody on the team suggests any of these, you’ll likely go in circles. A creative programmer breaks the team out of those circles.

Sometimes though, problem solving is not enough. Sometimes, the problem hasn’t yet been found—let alone defined. In cases like that, your typical problem solving skills won’t be very effective: you will need to rely on your creative senses to see the problem.

When Charles Darwin left Plymouth on the Beagle in 1831, a voyage that would last five years, he had no intention of solving the problem of evolutionary theory: the problem domain didn’t even exist yet. The British Royal Navy researchers were only tasked to chart the coastline of South America. The exotic vegetation and animals Darwin encountered and meticulously kept notes of planted the seeds for his theory that would only be conceived years after the voyage itself.

Darwin wasn’t a problem-solver. He was a problem-finder. What can we as programmers learn from Darwin’s way of thinking? We’re usually swamped with small and well-defined (sub)problems. Tasks in a swim lane that have to make it to the “done” column somehow. But perhaps, somewhere along the way, enough dots are collected and later connected to form an entirely new question. Perhaps we discover a problem our clients didn’t even know they had. A creative programmer is both a problem-finder and a problem-solver.

The second reason to care about the creative judgements of others is because the opinions of your peers should matter. In case you haven’t noticed yet, software development is a team-based activity. Creativity is meaningless in isolation, because it is a social construct. Mutual respect makes everyone feel more at ease, thereby increasing the cohesion of the team. This opens up the possibility for you to learn and grow, and to help others learn and grow as well.

A third reason to be creative is because creativity is fun. Many experts we interviewed mentioned the sole reason for being a programmer is the opportunity to be creative. Creative programmers deeply enjoy their work. They love taking a deep dive, getting out of their comfort zone, connecting unusual ideas, discussing different approaches with others, and being in the flow. In short, creative programmers give in to their creative urge. They become Umberto Eco’s Homo Faber.

Many creators hope to achieve immortality through creative work that might outlive their feeble body. The lucky few that realize their dream of leaving a permanent mark on the world are hailed as true visionaries. We, as programmers, working with highly volatile technology, might be better off taming our immortal aspirations. I bet by the time this book is published, dozens of existing technical books on programming can be safely moved to the “vintage” bookshelf. And we all know what that means.

A roadmap to becoming more creative

This book is not about how to become a genius or visionary, which has little to do with “creative genes”: as we will soon discover, there is no such thing. Instead, it is about the connected processes of problem finding and solving. By applying different creative methods and insights into creativity, neatly wrapped in seven distinct but heavily intertwined themes, it is my hope that you will be able to become a better programmer. If you are not a programmer, don’t worry: we will see that many of these methods can be easily transferred to other domains.

Andy Hunt’s Pragmatic Thinking & Learning starts with a beautiful hand-drawn mind map that doubles as a roadmap. Since his book also leans to the softer side of programming, I’ve let myself be inspired by his drawing and used it to brighten up our research report—which was considered very creative and promptly accepted. The mental map, as shown in figure 1,  also serves as a guide for this book. Each “tentacle” in the map represents a chapter with a distinct theme related to creativity.


Figure 1: The Creative Programmer mind map that ties together all seven chapters of this book.


All illustrated figures in this book are hand-drawn by me to better fit the creativity theme.

The Seven Creative Programmer themes

The following adventures await us:

1. Technical Knowledge

Anyone who produces something creative must have a firm grasp of the state of affairs in their domain. This might sound so obvious that it almost seems excessive to waste a whole chapter on. A programmer can’t be a creative programmer if he’s not a programmer in the first place. Even though learning before doing is quite self-evident, it still pays off to pause and think about various ways to consume information, continuously learn, be aware of cognitive biases, and to manage knowledge.

Creative programmers understand how to convert a steady stream of knowledge into new ideas.

2. Communication

Creativity never happens in isolation. Refinement of ideas is a social process. Without any kind of feedback, it is impossible to upgrade your slightly original idea into an excellent one. Your peers can act as catalysts for change. In this chapter, we’ll explore the concept of genius clusters, how to build dream teams, and techniques to enhance the creativity of teams.

Creative programmers are always aware of the subtle interplay between ideas, individuals, and teams.

3. Constraints

Tackling any kind of problem involves taking constraints into account, whether they are self-imposed or external. Contrary to popular belief, constraints actually spark creativity instead of diminishing it. We will explore multiple cases of creative outbursts that are the result of converting what might look like annoying limitations into sudden advantages.

Creative programmers know how to take advantage of imposed constraints instead of only complaining about them in retrospect.

4. Critical Thinking

Coming up with a lot of ideas is only half the work; the other half, which is arguably more difficult, involves vigorous scrapping until the best idea is left standing. Then, and only then, it might be time for action. In this chapter, we’ll try to engage in a symbiotic relationship between critical thinking and our everlasting fountain of crazy ideas. We’ll discover that creativity is not only about generating ideas, but also about decision making.

Creative programmers are able to fluently switch between sprawling ideation and critical evaluation.

5. Curiosity

Why are you interested in this book? Are you curious about its contents? Are you eager to learn? If the answer is yes, we’re off to a great start here! According to creativity researcher Mihaly Csikszentmihalyi, curiosity and perseverance are the two most defining personality traits for creativity[5]. We’ll regularly revisit Csikszentmihalyi’s excellent work on this subject in the coming chapters.

Curiosity implies motivation to learn new things (technical knowledge). Curiosity leads to asking “why” questions (critical thinking). We’ll discuss why having a sense of wonder is advantageous, not only for the absent-minded professor, but also for the creative programmer.

6. Creative State of Mind

We all know that frequent interruptions are detrimental to the programming flow. Getting into the right state of mind will greatly improve your creative work. We’ll inspect how flow and insight work, what insight priming can bring to the table, and how to increase those ever so important but fickle “a-ha!” moments.

Working on your individual state of mind is one thing. Enhancing the collective state of mind of your team or company is another—and both are equally important to a creative programmer.

7. Creative Techniques

Last, we will discuss several practical creative techniques that can positively impact the concepts explained in all of the previous chapters. Just like creativity’s systemic definition, these techniques are intertwined with all dimensions of creative problem solving. They do not necessarily fit neatly into one distinct theme. We will take a critical look at classic brainstorming sessions and more unconventional techniques such as giving your ideas some legs.

The structure of the book

Each chapter starts with a background story to set the scene and provide examples of creative thinking in and outside the world of technology. I also have a tendency to use video game references as contextual assistants, next to conventional examples. This isn’t just because I happen to like games. Dozens of studies—including my own—have proven that visual examples better capture interest and usa of games triggers playful learning. Since this is a book about creative programming, it would be a shame not to dig up stories about game development. After all, aren’t they also considered pieces of art?

Chapters are also generously sprinkled with exercises marked with a distinct border. Since this isn’t a technical programming book, the exercises aren’t as hands-on as you might be used to. However, they are still valuable as thinking exercises and can serve well as subjects in retrospectives. Of course, I can’t force you to suddenly be creative. All I can do is point in the right direction. Converting those pointers into action is up to you.

Sometimes, as an aside, I’ll digress from the topic to provide additional amusing and insightful background stories. You will recognize these off-topic sections as gray sidebars in-between the text. If you’re in a hurry, they can be skipped, although you’ll likely miss out on creative triggers if you decide to do so.

We’ll end each chapter with a checklist that summarizes the new concepts covered in in that particular chapter. These can serve as a reminder, but please take their context into account: just scanning the summaries isn’t going to get you closer to creative coding mastery, nor do they serve as a complete overview of best practices.

You are now ready for your creative adventure. Learn more about the book here.



[1] Umberto Eco et al. The open work. Harvard University Press, 1989.

[2] Andy Hunt. Pragmatic thinking and learning: Refactor your Wetware. Pragmatic bookshelf, 2008.

[3] Judy L Wynekoop and Diane B Walz. Investigating traits of top performing software developers. Information Technology & People, 2000.

[4] Wouter Groeneveld, Hans Jacobs, Joost Vennekens, and Kris Aerts. Non-cognitive abilities of exceptional software engineers: a delphi study. In Proceedings of the 51st ACM Technical Symposium on Computer Science Education, 2020.

[5] Mihaly Csikszentmihalyi. Creativity: Flow and the psychology of discovery and invention. HarperPerennial, New York, 1997.