Write it all down: Tech Edition
Revamping this site has meant I have to come up with a whole bunch of fresh content, the subject of which is, uh, me.
As in, what have I learned in the past couple of years, and how can I share that in a way that’s accessible to someone to who’s just landed here to get to know me?
Hoo boy. Where to start?
It reminded me of the best advice I have for starting (or re-starting) a project from scratch:
Write it all down.
Whatever “it” is, just brain dump it. Don’t over think it, don’t plan what phrases you’ll use. Just start putting words to page/screen, and don’t stop till it’s all out.
Ian. Are… are you trying to take credit for the concept of brainstorming? you ask, not unfairly.
I know this is not exactly breaking news for people in creative fields. The notion of “you can’t edit a blank page” is well-known by writers, and Morning Pages are a key concept of the Artist’s Way.
But it continually surprises me how often this ridiculously simple tactic provides tremendous value in more technical and/or structured settings as well.
Here are few examples:
Resume writing
While it’s generally true that a resume is a pretty concise and formal document, especially for Engineering related roles, I’ve found that drafting a long form version of your work history first pays dividends to the final product.
It can be easy, in your day-to-day, to forget everything you actually do in a given role. Taking a step back and writing it out paragraph style forces you to tell the story of your work.
Scroll back through your Slack & commit history, your emails and calendar invites: anything that takes you back in time, and jot it all down with as much detail as you can stand.
What about that clever piece of code you wrote for that one internal tool? Or that meeting you led? What about when you caused that site crash, and then turned around a quick hotfix?
Once you’ve done completed getting it all out of the nooks and crannies of your memory, read it back, preferably aloud, and maybe to another person you trust for honest feedback.
What sort of picture does this paint? Does your work persona come through? Is anything missing? What’s most important, most exciting?
Yes, you’ll have to condense this back down to bullet points, key phrases, and statistics next, but I guarantee the outcome will be richer and more thorough than if you didn’t do this exercise.
BONUS: when you get that interview after submitting your excellent resume, and you’re asked to describe a time you took charge or faced a challenge, etc, those stories are all right on the tip of your tongue! Noice!
Difficult conversations
Asking for a raise? Discussing an uncomfortable subject with your boss or direct report? I absolutely cannot recommend having a script enough.
In fact, I might even go one step further and write both sides of the script, or at least some key points to stick to in your replies, especially if there’s a chance the other person may try to refute what you have to say.
The more you put yourself in the other person’s place, the more empathy and understanding you can imbue the discussion with. What questions do you think they’ll have? What direct and indirect impacts does your conversation have on their life? Where are they are coming from in this discussion?
What you end up saying may only be a few sentences, but I don’t think there’s such a thing as being too prepared for situations where emotional reactions may (often understandably) come to the surface.
Time management debugging
Stressed as heck? Don’t know where the time goes? Calendar invites not telling the whole story?
Write it all down, either as your day progresses, or during a wind-down period when your work day is over.
What meetings ran long? What code reviews took forever?
How did you feel during all of it? Was there a particular context shift that was the hardest on you? When were you drained, when were you energetic? Did you step away to take a walk or eat or stay hydrated?
Sometimes even putting this much focus on myself and my own needs can feel selfish. But if I can put it in writing, sometimes it feels more “real” to me.
Not only does this exercise help me identify actions I myself can make to change or free up my schedule, but it also gives me a foundation for what to say to a boss or co-worker for things I might need assistance or buy-in on, like changing a meeting time or frequency.
Code Comments
I’m not really a believer in the idea of “self-documenting code”, and I’m apparently not alone. Computers, as a rule, are not really big on why certain things are done, just how. So why would we expect computer speak to capture the whole story?
Hopefully whatever it is you’re coding has a spec doc, mockup, or some other supporting artifacts that give more background. And of course, documentation is so much more than code comments.
But for an explanation of why this one function is written in this particular way that seems to contradict the code style guide, for example, comments are just about the best thing going.
I saw a talk entirely about comments a few years back at the SoCal Python meetup, and I was delighted to see someone dig into this underrated art form.
I haven’t been able to find a video or the accompanying slides for this talk online unfortunately, but some key takeaways were: once you decide a comment is needed, really spend time crafting the right message. Put yourself in a role a developer new to this file or feature and really explain what’s going on. Then, read aloud what you’ve written to make sure you’re not missing words or phrases.
A thousand words can paint a picture
Humans are naturally drawn to stories, both listening to tell them and telling them.
Creating richer more meaningful experiences isn’t just for design and product folks. There is power in simply telling the whole story of whatever it is you’re working on. Not all of it may make it into the final work product, but the essence of the story will be there when others read it.