« ACM Queue adverts - how not to do it | Main | Generating feed identifiers can be tricky »

Programmers' block

Here's what I don't always like about high level languages: there is nothing to do except solve the problem. You can't fool about with braces, create abstract classes, factories and interfaces, move some methods about, write redundant code, write yet another plugin manager, yet another fast file reader, yet another configuration language, or goof around with the build file for the nth time this week. There is nothing for your conscious self to do except solve the damn problem.

Sometimes it's great to have nothing but a problem to deal with. And it's clearly a good thing to be focused on the task at hand. In fact, the aspects mentioned above are exactly what many programmers come to loath about some programming languages. They are the very things that drive them to find more elegant and concise forms of expression. Why then would anyone want to keep a hold of that stuff?

I think part of the answer can be found in programmers' block. Programmers' block is like writers' block, but instead of staring at a blank page you're staring at a blank screen with a blinking cursor:

                 >>> |
                      Programmers' block in Python

Now, I'm not saying using a high-level language results in programmers' block, just that high-level language will make it evident you don't know what to do next. Sure, it happnes to everyone, but having nothing but you, the problem and your inability to solve it now, can be uncomfortable. Even stressful - many programmers' self-esteem is tied up with their problem solving ability and intelligence. Languages with inbuilt distractions give you somewhere momentary to hide from the problem.

                public class Main
                  public static void main(String args[])
                      Programmers' block in Java

About the most you can do with a high level language is change the syntax coloring, which is much too obvious a wastefulness to be beneficial. Continued blatant wasteful activity, such recolouring code, should result in guilt and low self-esteem, emotions I suspect will damage one's ability to solve problems, whatever the language.

One view on this is to think a bit of inefficiency, some distraction and slight verbosity could be a good thing in a programming language. Being allowed to fidget and zone in and out of a program might be valuable because it affords a way for your conscious self to spin its wheels without feeling bad, while your unconscious self gets busy in the background doing whatever it is unconscious selves do to provide us with insight. Perhaps having some shiny toys around for the conscious self to play with is important for working on software problems. Some slack in a language could be healthy.

Another reason to want to avoid programmers' block is that it may not be acceptable to be not writing code, as you must be seen to be productive by your peers and your managers. There are after all no accepted objective measures for programmer productivity, so we often resort to instinctive (but unjustified) measures such as counting lines of code of function points, or simply watching overtime [1]. In some companies extended periods of non-production of software may be acceptable; this is notably so working in highly technical environments, where it's accepted that the programming is going to be difficult or where the founders were from an academic background, where punctuated silences are not unusual. In more business and service-oriented companies, and even startups, cranking out code whatever the form might be an implicit requirement. This is not so much a matter of right and wrong as it is a matter of prevailing cultures. But if someone is working in a culture that does not understand or accept "dry periods", it may be perceived as analysis-paralysis, ineffectiveness, or worse, laziness and incompetence.

The difficulty comes when there is so much inefficiency, endless distraction and fatuous verbosity in a programming language that you'll never complete in a reasonable amount of time. This starts to rear its head when building larger systems (collections of problems). Shiny toys become attractive nuisances, and to fool about with the braces, create abstract classes, factories and interfaces, move some methods about, write redundant code, write yet another plugin manager, yet another fast file reader, yet another configuration language, or goof around with the build file for the nth time this week, becomes an end in itself, not a means.

If programmers' block is real, and clinging onto some problematic aspects of a programming language is a means to cope with it, then it's arguably a high risk means. Are there better ways to keep our conscious selves occupied so we can use an alternative high level language without fear? Or better ways to use a less productive language when we get stuck?

I think there are. Refactoring is one way. Refactoring is a technique to manipulate the structure of source code without changing its behaviour. It's best considered as a means of managing technical debt in software. Ironically refactoring started with the HLL Smalltalk, but has truly blossomed in languages like C#, and especially Java.

While refactoring is important for codebases that are expected to provide a product dynasty rather than a legacy mess, it's often devalued as mere tinkering by those removed from source code, as it doesn't provide new functionality - it can be very difficult to explain to a non-expert why not adding, or even delaying features now, will help with delivery of features later. The idea of tinkering should be a valuable clue. Rather than add cruft and needless indirection to code, refactoring can be actively used to refine the structure while providing a useful distraction. If we're going to be need be zone out from time to time, we may as well do something useful.

Another way is to write tests as you develop, in particular to use the act of passing tests to drive development of code. It's often easier to stay productive when you have something concrete to aim at, which is exactly what a test provides.

The presence of tests also change the nature of problem solving. I think one of the reasons we get blocked is that we tend to think of problems in terms of solutions which are right and wrong. This attitude is deeply ingrained in computing, and probably comes from mathematics and logic where solutions do tend to be right or wrong, rather than having relative levels of expediency and usefulness. It's so powerful that companies like Microsoft and Google famously use problems with no right solution to test candidates during interviews, as much for their ability to deal with stress and hazing that results from "no right answer" as their creativity. What a test often does is let us think of programming as a series of moves along the lines of a game. Moves in a game aren't right or wrong, they're better or worse [2]. That can be enough to snap out of a blocked consciousness.

[1] Martin Fowler has more than once suggested that we may never be able to measure programmer productivity.

[2] This is paraphrasing Alistair Cockburn, the agile software guru. Beyond testing, Cockburn has been establishing a compelling theory to explain why software projects succeed or fail based on co-operative games.

February 12, 2005 02:07 PM


Alan Little
(February 12, 2005 08:12 PM #)

With python, if you can't think of anything interesting to put on your website you can always spend three months deciding which web application framework you're going to serve it with instead. Then give up and spend another three months writing your own like everybody else has already done.

(February 14, 2005 03:16 AM #)

With the more inviting languages (e.g Ruby, Python ) you can spin around writing short apps to do assorted side tasks. It's like doodling while your hidden brain works out the real tasks.

These same languages also provide different ways of accomplishing a task, different forms of expression, and shifting code around (but short of what might be considered refactoring perhaps) may give you code in a form that is more conducive to continued development (much in the same way that rephrasing a paragragh can help you write the next one, even if the content is essentially unchanged).

Joshua Allen
(February 14, 2005 05:32 AM #)

All of that refactoring and writing frameworks are usually a form of procrastination. Like how you suddenly get interested in organizing your desk or reading "The Now Habit" when you have a really important deadline you should be working on instead. Users of high-level languages need to procrastinate by reading blogs, instead.

Alexander Somma
(March 16, 2005 02:25 AM #)

I quite often end up reading up on how other people are dealing with their problems when I have programers block.

Post a comment

(you may use HTML tags for style)

Remember Me?

Trackback Pings

TrackBack URL for this entry:

Listed below are links to weblogs that reference Programmers' block:

» programmer's block from Gregor J. Rothfuss
bill de hora has an awesome essay on programmer's block. i have nothing to add.... [Read More]

Tracked on February 17, 2005 05:22 AM

» More Green Bar from Agylen
An interesting quote from Bill to complement my previous Green Bar post: Another way is to write tests as you develop, in particular to use the act of passing tests to drive development of code. It's often easier to stay productive when you have some... [Read More]

Tracked on February 17, 2005 02:24 PM