Despite the amount of time we here at Starling seem to spend on sales, business administration, accounting, systems administration, and all of the myriad other things that go along with running a small business, we still find a reasonable amount of time to spend on actual development. Development, besides being our most enjoyable activity, is after all the whole point of the company.
We sit between a couple of computers and a whiteboard, and though we’re often writing code, we’re constantly switching back and forth between typing, talking, and drawing. Much of the work we do during this would be considered “design” or “architecture” work in many shops, and would be done in meetings separate from the time you spend in front of your computer coding. That’s why we prefer to call what we do during these times, “development” rather than “programming.”
But still, the code is the true embodiment of the idea, and the proof that it actually works.1 It’s also often the only thing left after the diagrams have been erased from the whiteboard and the details of the discussions are forgotten. So it’s important that the code not only works, but is as much as possible a clear expression of the ideas embodied in it.
This blog is devoted to discussion of the technical nuts and bolts of creating and maintaining that expression. But even if you’re not a programmer, this may provide you with some insight into how we work.
I recall a humourous comment once made about a project to the effect that the run-time platform it ran best on was Powerpoint.↩