Some time ago a wild shower thought came into my head: “Programming activities can be divided into two separate groups - either creative activity or problem-solving activity.”
But what does it mean exactly? You could say that solving problems can also be a creative task, so I tried to define these groups more precisely:
In creative activity, the goal is loosely defined, and there are a lot of possible valid solutions. In the beginning, you don’t know how the result will look like, because you have to create it.
In problem-solving activity, the goal is precisely defined and there is only one or a couple of specific valid solutions. In the beginning, you know exactly what the result has to be, but you don’t know yet how to achieve it.
We have all went through this in school - creative activities are like essay writing, problem-solving activities are like solving math test. This comparison also leads us to another important topic of this post - people very often describe themselves as gifted in only one of these. I bet you can tell about yourself “In school, I liked writing essays more than solving tests” or the other way around. A lot of jobs revolve around this division too - we have some jobs that are purely creating, that can’t even materialize their creation on their own (designer, music composer, architect), we have a lot of jobs that only improve existing creations (text editor) or achieve some strictly specified results (this can be some specialized IT roles like database administrator or various engineering roles). There are, of course, a lot of jobs that mix these two activities, where you can set your goals, design the solution, implement and improve your creation. Programming is a prominent example of this. I think that it’s important to be aware of this division and sadly, I have never seen anyone writing about this.
Examples of creative activity in programming are creating a new page in a web app (if there isn’t any mockup), refactoring codebase, deciding on system features, or creating APIs. Examples of problem-solving activity are all tasks that have a specific definition of done - bugfixes, performance improvements, etc. Naturally, in most cases, there still is room for creativity in choosing how to solve the problem. For example, solving a bug could (and in many cases, should) be associated with some code refactoring - you have to decide how the codebase will look like in the end. Improving performance is also often achieved by architecture changes and requires new approaches. Somehow, even if requiring creativity in choosing a solution, problem-solving activities very rarely excite me as much as creative activities. If I know from the beginning what exactly the final result will be (like “after completing this task, query from the database will be executing in time under one second”), it feels more like a chore to me than a passion.
It’s great to observe this division on platforms like dwitter.net - some people are creators - they say with excitement “I’ve created an animation that draws cat emoji in rotating spiral, it’s awesome” and then they move on to create some next thing because they are satisfied with how cat emoji rotating spiral looks like. And some people are code golfers - they say with excitement “I’ve remixed your dweet - it looks the same but I’ve managed to implement it using 20 characters less!” and then they go back and challenge themselves to shave off some more characters from it. They are comfortable with having an exactly specified goal (cat emoji rotating spiral with least amount of characters) and their area of exploration is not possible animations but all possible implementations of a specified animation.
My preferences are very well reflected in how I choose my personal projects. I like to explore new possibilities and create new things - for example, I was wondering someday “It would be fun to have an app that would draw fractal images based on parameters provided by the user like color, texture, angles, etc.” and the only way to discover it was to build it on my own. Now I know how it is and it’s a big fun. Another time I was thinking “How Sierpinski carpet with randomly applied division would look like?” And there wasn’t any image on the internet with it. Now it is and it’s also fun.
But sometimes, in a different context, people take the opposite role. In my case, it’s when I help my wife writing her blog. I take the role of code golfer there - I’m not that interested in topics she writes about, but I work on all the small details and technical problems of the Polish language - I challenge her to convey the same content in fewer words, with better emotional impact, with better language, and in a more comprehensible way. In this context, I am the one that isn’t interested in creating, but improving.
Ok, but why did I write that for me it’s a very important topic to talk about? It’s because of team building. During the phase of assigning certain programmers to certain tasks, teams, and projects, it’s an important factor to take into consideration. People think of “programmer’s preferences” in categories of technology, scrum practices, amount of meetings and amount of bugfixes, but are not used to think of creative and problem-solving categories.
- When you build a team, try to match the creative-to-problem-solving ratio of a project with team members’ skills and preferences.
- When you want to join a team, raise a question about that ratio to avoid such a problem that the project’s specificity doesn’t suit your expectations.
- I guess that if you want to become a senior developer, you probably would need to learn to do both these types of activity on a satisfying level.
- If you feel that you are on one of the ends of a spectrum (so, you hate creative tasks, or hate improving and problem-solving tasks) maybe try to follow a specialization (for example, become a UX designer) to take advantage of your talent and send a clear message about what things you won’t be doing.
And you? Do you describe yourself more as a creative programmer or a problem-solving programmer?
Sincerely yours,
~Marek