Coding: a formality

After defining, understanding and solving the problem, the next step is to actually code something.

In the beginning, we create whole worlds in our heads. Massive universes of interconnection, smooth flows of information through perfect conduites of awesomeness. User experience merging man and machine forging one single union.

You know it's serious when we take on the persona of a component - 'Well I can work that out from these two inputs, but only if you provide me with access to that' - wait, I mean "it can" - I'm not the computer. (or am I...)

Of course, the flipside is that not one of my projects - ever - has fulfilled my ethereal vision. They are clunky, horrid, unstable messes, limited by the wires and reality and these pesky users. Relatively speaking, anyway. I have high standards.

It's tempting to focus a lot on the code. It's easier. The code is king. It's the thing which has to 'work' in the end. It's the fruit of our labours. It's what we get paid to write. It's something we need to get good at.

Eventually, once the language is mastered, the code gets back in its place. In the background. Enabling, not limiting. The language, once fully embraced, can even become part of the initial thinking, enabling through limitation, developing in a familiar and structured way.

It's so important to know more than one type of language. It's going to define even the way you think about problems.

But the part where you actually write the code. That's just the paper at the end of the study.