I often think about writing a feature like writing a story. If I do my job well, it is coherent and easy to read, write, and maintain. When there's a lot of indirection, it feels like a book with its pages out-of-order.
There seems to be a lot of similarities as well.
We have readers, it just so happens that our readers are machines -- as well as our colleagues.
We have a narrative, making sure code is easy to read, easy to understand, and has a logical flow to it.
We have structure, grammar, and syntax.
Hidden within our files is a visual design of code. I want code to look pretty
and at times I can be picky about what doesn't look good. It's one reason why I
really do not like ruby. It looks foreign and ugly to me. The syntax feels
awkward and some of the "best practices" for how it should look really leave a
sour taste in my mouth.1
I was talking to a friend who is writing a book. As we were talking, it became relatively clear to me that the challenges an author faces are very similar to what we have to do as professional software engineers. Getting stuck in a scene where the writer needs to move the plot forward while staying internally consistent. There seems to be a lot of problem solving as well. What's the setting? What are the scenes? How do I connect these characters together? How do I bring ideas to life?
These problems all feel very natural to me.
Also, I can easily spend months without needing to think about any math at all, and if I do my job correctly, most of the time I can reduce the logical complexity of a program to simple for-loops and if-statements.
As far as software engineering is concerned, it feels closer to writing a book than writing complex algorithms or math calculations.
-
For example,
unless-- and more specifically, inliningunless-- is really ugly to me. Not just from a visual design perspective, but the concept. I have to re-read those blocks of code multiple times to understand what the writer is trying to tell me. ↩︎