Naming Things is Hard
Life for me has been full of blank slates. Staring at a blank painting canvas, an empty word document, a new programming function that needs logic, and even my own name as a trans woman. Years later I still find new names I want to try on just as I wish I had spent more time revising other work I had done previously.
Nowhere in my life is a more egregious example than my career in software development. I don’t spend 40 hours a week at my day job writing code. I spend it reading, deeply comprehending, and finally revising existing code to be more clear.
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. 😂Leon Bambrick
In writing, it can be difficult to find just the right word for something critical. In coding, my mentors and readings continue to impress upon me the importance of taking time to find the right names for elements of my code. Robert C. Martin’s Clean Code (pg. 18) suggests, “Choosing good names takes time but saves more than it takes. So take care with your names and change them when you find better ones. Everyone who reads your code (including you) will be happier if you do.” In code there’s a concept called refactoring to perform code cleanup, which directly parallels revising in writing.
Clutter can, at times, feel like the goal in the workplace—with the plethora of industry specific acronyms, phrases and terms. Recently at work a subject was incomprehensibly explained to me as the following, “Budget’s sibling product, Manage, has Budget Buckets. They are unrelated to the Budget product though”. Needless to say my understanding was not made any more clear due to confusingly similar product and feature names. Zinsser’s On Writing Well (pg. 6-8) describes this as “Our national tendency is to inflate and thereby sound important…” with the reader having to “…hack through the verbiage…”
Patience spent early during the writing process means readers have more patience using the software I code and the articles I write. My preference is writing in simpler, less inflated language, such that anyone can understand. Regardless of if they are as deep in the weeds of a project as I often am.