Creativity in Programming: The Good, The Bad, and The Ugly

The Good Thing about being creative in programming is that creative programmers can come up with solutions which exploit some of the specifics of the unique problem or its context to create a solution which is either simpler, or more efficient, or more robust, or more usable, or provides some additional functionality at no or little extra cost (in effort, complexity, or performance). This is why having an especially creative developer on the team can be a big advantage in many situations. In order to best use this advantage, you should make sure that the creative programmer (or, for simplicity, all programmers on your team who are interested) has access to as much specific information as possible about the problem, the context, the business case, the constraints and, of course, the users.

The Bad Thing about creative programmers is that when they have to do non-creative work, they might easily get distracted by some creative ideas and lose focus on the thing that they need to get done. To mitigate this problem, it is important to establish a clear goal for the non-creative work ("this and that needs to work, don't care about anything else for the moment"), motivate them by explaining clearly why this goal is an important milestone (and necessary before other more creative things can be started), and put a less-creative type on their side to help them keep the focused on the goal (for example by regularly asking how it's going and by helping with some small and especially difficult or boring sub-tasks).
Also note that if a lot of the work done in a team is inherently non-creative that's demotivating for many or most programmers, but the most creative types will be affected most strongly. If several people in a team are affected by this, you definitely need to find better tools and platforms to get the busy-work out of the way. If only one person is affected, then this person should consider switching to another area inside or outside of their current organisation.

And finally, The Ugly Thing about creative programmers is that they might sometimes choose an individualized solution where something standard would be more appropriate which can, for example, lead to not adhering to coding standards or non-use of established patterns. To mitigate this problem coding styles should be enforced: as much as possible automatically (source formatters, linters, compiling with high warning levels, and other pre-commit sanity checks), but also socially with design review, code review, or pair programming. Note however, that problems in this area will be much less likely when the creative programmers can make Good Use of their creativity as explained above and when they are less exposed to the Bad Side of it as also explained above.

This is written from personal experience and you are welcome to contribute your own thoughts or experience. Thank you for reading!