code and the oracular

How to be a creative programmer

leave a comment »

A Rap on Kevin Kelly’s Nine laws of God

  • Control freaks in management tend to say: “help ! everythings happening all at once!” as if some totalitarian rule of linear ordering has been broken. If feelings are more like a flashing pop video with images and musicality, then surrender to a feeling state is a broadening of awareness. You escape the linear logic of a verbal stream of thought, you’re out of your head, the bubble pops leaving a whiff of cinnamon.
  • This is a scrum of programmers all rapping about or brainstorming a problem without any leadership. Feelings defy the top-down imposition of logic but a solution is still found. Its based also on an optimally riotous classroom with some paper darts but also some attention paid.


  • Feelings open the mind to larger spaces, higher dimensions. When you are surrounded by the richness of such chaotic self-organising reality you have many directions to choose which all give benefit. Out of the chrysalis emerges a new form which extends the lifespan of the creature. Modelling software development on biology harnesses the wisdom of evolution.
  • Evolution depends on mutation, which is an error yet not a mistake. Feeling is also a changing Tao. Dogma is stasis, reinvention is progress. Creativity is not a fiat lux, it is a kid putting the same lego bricks together in new ways. A solitary genius who sits alone in a cave and dreams forth stuff is a myth, think instead of a chef with a roadside wok on a brazier, assistants bring him things from the market and he sings while he stirs.
  • The chef is alone but even better is to harness the wisdom of the social animal, team members spin off in collisions whose future cannot be seen – like a many body gravitation model. Buzz is never a thing experienced only by one, the shared mindspace can hold more than any solo thinker’s tired old head. No-one has even found a sketch of the space of all possible parallel computations, it is vast beyond knowing, yet available when each core is a human mind.


  • Teams with healthy conflict as well as healthy consensus thrive. They find their own balance that harnesses heterogeneity. Teams are not compute clusters ! Each core is doing a unique job on unique data with its own methods…
  • Knowing a few core tools well may mean you can use them to solve a problem that someone else thought they needed to learn a whole new platform to approach. You don’t accumulate knowledge as an end in itself you focus on problems not tools. this energises and motivates.
  • Creative people find spin off solutions and new inventions when a problem is interesting enough. if a new turning is that good, you can even drop the original problem and fork away completely.

A rap on The Unix Philosophy

  • The core utils are each an optimum size and complexity to be grokkable by a user with ordinary human complexity ceiling. Want to build something new? use combinations of small tools. The pipe is the conceptual glue of your new musical composition, operators are composed together to form a compound statement. The pipe is the true symbol of unix, flexible tools are still yielding new combinations that solve problems unforeseen by the authors, because the originator held to the ethic of open-endedness.
  • Allow plugins to extend, no need to rewrite and again the composition of modules harnesses recombination in new ways. It is an act stemming from a sacred duty to your successors, bequeath a colleague a fertile start point for his problem, you are paying back in.


  • make interfaces that perform cleanly and hand across data in a transparent way. Bugs can be narrowed down to the relevant module more easily and will not be proverbial needles in code haystacks.
  • Don’t polish until you’ve got the basic functionality. Then you won’t polish something incomplete and change your mind and have to the same job again on new code.
  • Leverage psychology. No-one likes throwing away a huge masterpiece. There is less of this bias when its a smaller component. Again modularity with a chunk size that makes it easy to grok the components code.
  • design for noisy failure so bugs are trackable. A quiet failure might propagate errors to other components as output pipes to input.
  • hide complexity in data. decalarative is easier to visualise than procedural because its usually less tangled. Less complex procedures are easier to read.


  • separate mechanisms from policies. Like Model-view-controller, tweaking presentation should not touch the back-end.
  • Don’t print unnecessary output. Makes everyone less strained since they can see what they can see.
  • Code simply, don’t be a Heath Robinson-ite and glory in how cool you are for conceiving some labrynthine monstrosity. it may work but consider others experience if they have to use or revise it.


  • Make your code reflect the stages of the problem solving thought you engaged in when you wrote it. This is like the difference between a good and bad novel. Make explicit what needs to be. Express data in clear ways that are self explanatory and commented or documented. This makes debugging easier, and sweetens up anyone who wants to reuse by considering their needs.

Written by Luke Dunn

August 27, 2014 at 3:49 pm

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: