A short note on writing
From an engineer who didn’t like to write.
Like some of you reading this, years ago I chose my college major, at least in part, because I really didn’t like to write papers. I preferred more well-defined problems. To succeed in writing, you learn some general practices and guidelines — some do’s and don’ts and some qualitative interpretations. I was more interested in being measured on what I perceived back then to be objective criteria.
When it came to writing, I also struggled to come up with good, non-repetitive ways to say things. I usually bored myself and I dreaded the work. I wrote my share of essays and papers, but I rarely enjoyed the process — other than the joy of being done.
That was college-age me. So what am I doing here now, many years later?
I’ve been developing software for a really long time (maybe longer than you’ve been alive). And, it turns out, writing is a substantive part of my work life. I actually write a lot. I write proposals and specs and designs. I share updates and status. And I comment and question things in writing all the time. Sometimes I’m good at it, sometimes less good. But I know it’s important to my success as both an engineer and a manager.
I write for a number of different reasons and in a number of different ways. I do it sometimes simply as a means to get things done. Other times, it’s literally my job to communicate, and writing is a great medium, especially with remote teams. And I use Slack for all sorts of reasons — answering questions, connecting people, providing some emotion and occasional humor (yah, I know, not easy on Slack), and so on.
I don’t blog much, but the more experience I’ve accumulated and want to share, the more it seems a reasonable strategy. I also work at a company where we value teaching. So, here we are and below are a few stray tidbits that might be helpful if you are, like me, someone who doesn’t like to write :)
Getting Stuff Done
I am biased towards action. And writing is one of my means to getting things done and moving forward.
There is a scenario I run into with some regularality. Say there are some folks — collaborators, peers, reports, or even my boss — who I know need to work together on something. I know they will have ideas, or they are stakeholders in a project, or they have some other interest or expertise. Earlier in my career, I would have identified these folks, gotten them in a meeting room to discuss our ideas on the topic, and tried to make some decisions and plans.
Today, I almost never do that. Instead, I write down my ideas on the topic in as efficient a manner as I can. Sometimes I ask others to do the writing instead. Either way, I want to start with something concrete — a proposal or perhaps something less formal, even if it is imperfect or biased — for us to discuss. We can comment on whatever is written, and we can see if an in-person discussion would be needed or helpful. After that, we may still schedule the in-person review, even if there is agreement, because there is nothing like being in person. But these meetings are so much better and more productive because of the writing in advance. Committing “pen to paper” (OK, keystrokes to Google Docs these days) literally helps us move forward.
The format, grammar, and all that are rarely that important. What matters is just writing enough down to communicate ideas you have. And writing about what you know well always makes writing easier.
Efficiency
The teams I work with generally prefer to spend time designing, building, coding, debugging, testing, and doing the work that is core to software development. They don’t love interruptions to flow and meetings. We use quick daily standups for status and some process meetings around design and planning and retrospective.
So, for good or for bad, I rarely schedule meetings just to share things that could otherwise be written and shared. If I don’t expect a lot of controversy or follow-up, I go with something written.
Other than that, it’s mostly reading and writing or very focused reviews like I described above.
Commenting
OK, this isn’t a surprise. But I comment a lot. As a manager, it’s part of my job to review ideas, work, code, and the like. So I comment in whatever tool we have — GitHub, Google Docs, wiki, and so on. I try to be polite (yet I don’t always succeed). And I try to think about how the author(s) will take or (mis)interpret my comments and adjust them in advance. And when I notice a comment thread is too long, I recommend we break out into some other form of communication.
Blogging
OK, hopefully someday this section will be longer. In the meantime, at least I’m trying :)
