We write code. That’s what we do.
Well, that’s not entirely correct. We solve problems. We provide solutions. When we can do it without code, we declare it a win.
But most of the time we write code.
How do we write code? We don’t chisel it into stone. We don’t have to pull individual pieces of type from various drawers and physically typeset it page by page. We don’t carve it into wood. We don’t spend the time and effort of bending pipe-cleaners into letters and numbers (and punctuation) and glue it to a large board.
No. We open an editor or an IDE or whatever and just start hitting the keys on the keyboard. Some are faster than others. (And most are faster than me.)
But is it hard to write code? Well, no. Certainly no harder than writing about code. Or writing about the design of code. So what we do is easy, right?
Well, sometimes. But overall not so much. Yes, writing code is easy. Writing good code, on the other hand, code that scales well, code that is robust, code that does what we think it does and what it should do, code we can read, code that can be changed reasonably when such changes in requirements occur, code that runs fast enough for our requirements, well THAT’S HARD.
Frequently we nerd wrestle over system design; we ask whether this functionality should go here or go there, whether we should take this approach or that approach. We stand at whiteboards and draw an endless array of pictures and diagrams, boxes, arrows, dotted lines, all that kind of stuff. Now I am, by no means, suggesting that these are not valuable activities. Thrashing out our hypotheses on things we don’t know yet, on systems yet to be created is our opportunity to learn, our opportunity to form a sufficient model of a system to actually implement it.
Sometimes, though, se can get a little stuck. Boxes and pictures and arrows can be somewhat ambiguous. Different people can come away from such a session with different understandings of what’s been proposed. What if (he asked) we had some kind of notation, some kind of consistent abstraction in which to express our system design decisions? Hmmm. What could something like that possibly look like?