Why am I writing this...?

·

3 min read

I've tried writing a blog in the past, back in college. I was a broke college student, so I wasn't writing it for the actual benefits it provided to me and others. Back then I was writing for the potential financial benefit of it.

The things I wrote about were clickbait-y with things like VSCode Extensions for Cloud Developers and more to that effect. After several pieces of clickbait content, I would stare at analytics dashboards and watch the numbers tick up. I spent hours trying to increase SEO tool scores and include the most relevant content I could imagine. Anything to get those metrics up so that, hopefully, I could make a buck one day. It was very selfish. It was also getting unhealthy. It was an EC2 instance running WordPress that somehow exited a free phase at some point so it was also becoming a financial burden for me -- particularly so while in college where every dollar mattered way more. I also just lost interest and deleted it because writing clickbait is incredibly boring and there's no heart or soul in that. I've now made a pact with myself that this time I won't care about the metrics. I'm not gonna monetize this, and I won't try to shill affiliate links. I'm just gonna share my ideas, experience, and knowledge with a broader audience as well as for myself.

In this new remote-first, highly collaborative workspace we are in now, the skill of writing is incredibly important. I'd argue that it's the most important skill that any engineer can have. I've seen how poor writing skills lead to conflict when working in a highly collaborative, asynchronous workplace. I've also seen how great writing and communications lead to quick, effective, and self-maintaining work. If we cannot clearly and concisely elaborate our positions and ideas then we will waste time trying to understand each other rather than creating a great, scalable product. If we understand each other right off the bat, then we can move right into building a great product. The only way we can effectively work together remotely is if we can understand each other and our writing is clear. This is particularly true when we talk about technical writing and documentation. We as engineers cannot get away with just being talented at writing code. We must also be able to explain how to use the things we build. If no one can understand how to use our products (whether technical like a library or a consumer offering of some sort) then we are not effectively providing value. Being able to clearly explain how to use the products we offer provides value not only to the end-user but to those who might maintain it later which may be ourselves when we come back to the project months later.

Writing should also be a team sport. Everyone in the organization should want to write better and should be encouraged to write often. Setup team blogs whether they're internal or external and create a culture where sharing your ideas is encouraged. That's not to say "create a safe space," but it is to say to create a space where ideas are encouraged to be shared with the whole org in a clear, concise, and "challengeable" way. We should encourage discussion within the organization about ideas. Challenging new ideas is the only way to strengthen or debunk the idea. We cannot accept ideas at face value. However, if we cannot clearly explain our ideas, we cannot discuss them.

So this time I'm going to do better than last. I'm gonna put my heart into it and share my ideas. I invite anyone and everyone who reads this or anything else I write and challenge it. Prove me wrong when I am. I also invite everyone to start writing on their own or get your team to start writing.