The joy of programming
Your growth as an engineer is mostly defined by your climbing of the ladder of abstraction. Everyone’s road is different, but the landmarks are pretty similar: you start out implementing facts, then features, then architectures, then ideas. The line of code begins as your primary currency, the artifact by which you know your job is done, but it recedes into the horizon.
This isn’t to say that I write less code than I did when I was a younger engineer; I probably write more. But the code is less important — implementation is more of an afterthought than a going concern.
Sure, the code is important. Correctness is important; readability is important; technical debt is important. I’m not saying any of these things aren’t, but I’ve recognized them more as lagging indicators of other aspects of engineering: things travel downstream, and leaky abstractions in code come from leaky abstractions in real life.
I’m asking myself “why doesn’t this code compile?” less, and asking myself “what don’t I understand about the underlying domain?” more.
It’s tempting in these cases to find yourself in a sense of disillusionment with programming: to see it purely as a means to an end, as opposed to a magical art in of itself.
Anyway, I built my own personal public notebook this weekend. It took me three lines of code:
ls notebook.md | entr ./notebook.sh, which monitors a text file for changes and executes a script whenever the file changespython3 -m markdown notebook.md -f index.html, which takes that file filled with notes and converts it to HTMLs3cmd put index.html s3://notebook.jmduke.com --acl-public, which uploads that HTML file to S3.
Is this programming? Maybe it’s more like duct tape, I didn’t build any of these tools, I just jammed them together like LEGO bricks. But now I have a text file that automatically publishes to the internet whenever I save it. And that part of this life will never grow boring to me: the ability to will tools into existence.
Happy Sunday.
I hope you build something you love.