My 2020 Theme and Goals

I have been setting yearly themes since 2018. My theme for 2018 was “Relevant and Resilient” which helped me design a lifestyle that was resilient to external factors (such as the political climate in the US). The theme motivated me to build my professional brand — I started blogging, building my YouTube channel, and buying my own apartment in my hometown. The theme resulted in the most intense and productive year of my working life.

It did flare up my workaholic tendencies though. As a corrective measure, I set my theme for 2019 as “Prioritize Play”. An yearly theme is an excellent decision-making tools. “Prioritizing Play” meant that I chose fun activities over activities that felt like work. For example, given a choice between making a YouTube video (which is more work than play, believe me) and playing Dungeons and Dragons on the weekend, my theme dictated that I play Dungeons and Dragons. 2019 saw me develop new interests (D&D, art tours, city tours, etc.), take epic trips across India and the US, and even try out a new career path (aka prototyping a DevRel career). It was a year of intense experimentation and fun!

In retrospect, 2018 and 2019 were productive and fun, yet very intense. In 2020, I want to chill. To rest and reset. So my theme for 2020 is “Establish Balance”.

Setting Goals

The next step is to set goals that align with the yearly theme. My 2020 goals are:

Appreciate and celebrate

My first goal is to identify and appreciate elements of balance already present in my life (things like the 4-day workweek at Cockroach Labs, flexible work hours, unlimited paid time off, good health, friends and family who love me and care for me).

Cultivate interests

I developed several new interests in 2019. In 2020, I would like to cultivate my interest in D&D, art, travel, and fiction writing:

  • I want to complete the current Dungeons and Dragons campaign and possibly start another one.
  • I want to complete two Paint with Numbers projects.
  • I want to take an epic Europe trip with my parents.
  • Apart from my tech writing tasks, I want to explore writing fiction as a hobby.

Wellness experiments

I want to focus on health and wellness this year. But instead of setting punishing goals like lose x amount of weight or workout 5 days a week, I want to honor my body and set realistic, tiered goals:

  • To start with, I want to be able to comfortably complete 12 suryanamaskar (sun salutations) and meditate for 10 minutes for 21 days in January. The goal here is to get in the habit of dedicating time to my yoga practice consistently.
  • In February, I want to follow the meal plan-prep-plate method to ensure I eat well.
  • In March, I want to complete the 21 days of couch to confident yoga program.

Based on the results of the first quarter’s experiments, I will set health and wellness goals for the next quarter.

Changing the success metrics

The follow-up to the idea of setting a yearly theme and goals is to change the metrics by which I judge how “successful” my week. For my 2018 theme of “Resiliency”, my success metrics were the traditional productivity metrics — how many PRs did I open, how many blog posts I wrote, and so on. For 2019’s theme of “Prioritizing Play”,  my success metric was how many fun activities did I participate in that week. For 2020, with the yearly theme of “Establishing Balance”, I want to measure the success of the week in terms of the self-care/well-being activities I do in the week. Did I eat well? Did I sleep well? Did I complete my wellness challenge?

What this means is that even if I have a fantastic week at work but I don’t do the well-being/self-care activities, I would not consider the week to be a “success”. From my past experience, I know that aligning the success metrics to the yearly theme helps me make the mindset shift that is crucial to achieving my overall goal for the year.

The Year of “Nope“

The final tool in my arsenal of achieving my goal of establishing well-being and balance in my life is saying no by default. I suffer from the “shiny, new idea” syndrome — I get excited by new project ideas and proposals and only later do I realize that I don’t have the time and energy to see them through. So I end up working on several demanding projects simultaneously because I have committed to them, but I am miserable the whole time.

I am not the only one who suffers from this syndrome. It’s a common affliction in my social group, as evidenced by this conversation on Twitter. One of the tips I received in that conversation was to make my default answer to new project requests be “Let me think about it”, thereby giving me a few days to see if I am still excited about the idea or if my enthusiasm for the project has waned. If I am still excited about the idea, I should definitely take it up. If not, I can say no and save myself and others a lot of anxiety and mental stress. This will help me be intentional, selective, and mindful in my projects, thus helping me achieve a sense of balance and well-being.

So that’s my yearly theme and goals for 2020! I would love to know what your theme and goals are. Comment down below and let me know!

Prototyping a career in Developer Relations

I currently work as a Senior Tech Writer and am contemplating a career progression to Developer Relations. It seems like the logical next step in my career, but there are a lot of unknown unknowns in making that decision. To help me decide, I am following the method proposed in Designing Your Life which talks about prototyping the life you want to live to see if it works for you. This video details my experiment of prototyping a career in Developer Relations:

Paraphrased transcript:

My starting point was to figure out what DevRel is and what it means to me. My favorite definition is that Developer Relations is building relationships with the developer community. Building genuine, authentic, mutually beneficial relationships with your users.

Building a relationship with your users kind of involves the same principles of any relationship: genuinely caring for the other person and understanding their pain points and then figuring out how you can best help them achieve their goals and resolve their pain points.

This sounds really good in the abstract but my goal with the Developer Relations experiment was to figure out if I would actually like doing it as a job. I needed a concrete, measurable framework that I could devise my experiment and projects around.

I started reading a bit more and I came across this excellent framework by Eddie Zaneski. He talks about Developer Relations as having three areas or three components: Code, Content, and Community.

Code involves creating sample applications and sample repositories and plug-and-play applications that will help your developers get productive with your product faster and reduce the barrier to entry or the friction of onboarding. And the reason for this is that you have to remember that the developers who come to you for your product don’t actually care about your product as much as they care about achieving their goals. As a Developer Relations person or Developer Advocate, my job would be to help the users reach their end goal by minimizing the friction for our product which is a small part of their overall tech stack.

The second part of the framework is Content which involves technical documentation, technical blog posts, Twitter content or social media content, slide decks for conference presentations, or tech videos.

And then the final part of the framework is Community. This involves developing one-on-one personal relationships with your users in the form of online forums or again, social media, or meeting with them in person at conferences and meetups, or organizing and participating in events like hackathons.

The first time I heard of the framework and I realized what each of the areas mean, and the activities that are part of each of the areas, it was super overwhelming. I was confused about how one person would do all of these things. So I asked a couple of experienced developer advocates about how do they manage all of these activities and they told me that they don’t!

The expectation is not that one person would be an expert in all of these areas. The expectation is that you choose one area to be an expert in and then be reasonably good enough in the other two areas.

That got me thinking about how do I figure out which area do I want to be an expert in. Content seems like the most logical area for me but I was really curious about Code and Community as well. So I decided to devise projects for each of these areas and then prototype and experiment. So here’s the experiment plan I came up with:

For Code, I enrolled in Udacity’s nanodegree program for Full Stack Web Development. And the reason for that is that I wanted to go back to the beginner mindset. I feel like I have been so focused on CockroachDB for the past two years that I have kind of lost touch with the end-to-end tech stack and the pain points that the users go through at each of the user journey of which CockroachDB is just one part. And I hope this course will help me get back to the Code Newbie beginner mindset that’ll help me understand my users better.

For Content, I started live-tweeting tech events that I went to. I do make tech videos but I want to make more of them. And I want to experiment with tech doodles and tech zines.

And for Community, I have been attending a LOT of tech events. I think I have attended an event almost every week for the past two months. And I have been traveling a lot for the events as well. Because developer relations involves a lot of travel, I wanted to see if I actually like
traveling as much as is needed or do I just like it in theory.

So that is my Developer Relations experiment. I will keep sharing the results and my observations and the things I learn on this channel.

If you are thinking of making a career change to Developer Relations, I highly recommend that you come up with your own experiment and prototype your career as a DevRel person before making the leap. And if you do that experiment, I would love to know about it, so please let me know in
the comments down below.

And if you are an experienced Developer Advocate, I would love to know your opinion or your feedback on my experiment, so again, please comment down below and let me know.

Thanks for watching (or reading)!

Why you should participate in Google Season of Docs

Season of Docs is Google Open Source’s new program to help technical writers contribute docs to open source projects by working with mentors and earning a stipend for the participating in the program.

Season of Docs is a unique program that pairs technical writers with open source mentors to introduce the technical writer to an open source community and provide guidance while the writer works on a real world open source project. The technical writer in turn provides documentation expertise to the open source organization.

Here’s why you should participate in Season of Docs:

Build your tech writing portfolio

In last week’s video, I discussed how my open source GitHub profile serves as my technical writing portfolio. I shared how my publicly accessible GitHub profile helps me demonstrate my technical skills, tech writing skills, collaborative skills, and flexibility and proficiency with tech writing tools.

Participating in Season of Docs and writing documentation for an open source project is an excellent way to build your tech writing portfolio.

Work with mentors

My favorite thing about Season of Docs is the opportunity to work with mentors. Contributing to open source projects is a daunting prospect; especially if you haven’t worked with GitHub and other open source tools before. Having a mentor who can guide you through the overwhelming parts of the process and is invested in your success is incredibly helpful.

Earn a stipend

After a successful project evaluation at the end of the program, Google will pay you a stipend calculated based on your location. For details, see Technical writer stipends.

Work with me!

I am participating in the program as a mentor for Hydra Ecosystem. Here’s a list of our project ideas: https://www.hydraecosystem.org/seasonofdocs-2019

If you find the project interesting and would like to work with me, apply to the program as a technical writer and select the Hydra Ecosystem project. And feel free to contact me if you need help coming up with a proposal for the project. I look forward to hearing from you 🙂

Bonus: To know about additional ways to find open source projects and then choose the project that’s right for you, check out this video:

 

My technical writing portfolio

I published a video about my technical writing portfolio! In this video, I talk about how my publicly accessible GitHub profile serves as my technical writing portfolio and helps me demonstrate my tech writing skills, my collaborative skills, and my flexibility and proficiency with tech writing tools. Check it out!

The dummy puffin

A few days ago, a colleague shared an article with me about the dummy puffins installed on islands to attract real puffins. I found the article fascinating and the puffins utterly cute (they are my new favorite bird). The story resonated with me more that I expected, but I couldn’t fathom why. So I filed it away in my mental cabinet and got back to work.

Until today.

Today at the company-wide team meeting, we discussed the issue of lack of female leadership and diverse representation in the tech industry, and how we, as individuals, could play our part in remedying the situation. The discussion reminded me of a time a few months ago, when I was frustrated about the lack of diverse representation.

I am fully cognizant of my privilege to do things which I could have only dreamed of a few years ago: like attending the Write the Docs conference that I yearned to attend since I first heard about it, or see my absolute favorite YouTubers (John and Hank Green) speak IRL, or work at a brilliant startup building cutting-edge tech. The 20-year-old-me would be proud of where I am now. From her perspective, I have “made it” in life. I have a seat at the table.

And yet, more often than not, I find myself being the only one at the table that looks like me or sounds like me or does what I do.

For instance, consider the Write the Docs conference. It was the most well-organized, thoughtful, inclusive conference I have ever attended. Yet, I observed a lack of ethnically and culturally diverse speakers. Knowing the organizers’ intent of making the conference as inclusive as possible, the under-representation of minority groups certainly wasn’t their fault. One possible explanation was that the organizers hadn’t received many talk proposals from people belonging to underrepresented groups. That was even more infuriating. Why weren’t more people from diverse backgrounds volunteering to speak at these events?

Another thing I found myself complaining about constantly was the YouTube tech community.  I LOVE the contemporary YouTubers in tech: Jarvis, Mayuko, Charli, and others present a realistic view of programming and design careers in tech. But there’s no substantial content about contemporary tech writing. Why wasn’t anyone making videos that I would benefit from?

The probable answer: Imposter Syndrome. As a brown, female, non-US person, I am familiar with the paralyzing fear that the Imposter Syndrome creates. The fear of being judged, being “found out”, coupled with a deep-rooted insecurity and inferiority complex – these are the demons I battle everyday. I know how scary it is to speak up, because if you are wrong, it might not only cost you your reputation and credibility, but also your job, your livelihood. Not every risk is worth taking.

But if I wasn’t willing to take the risk, what right did I have to ask someone else to do it so I could feel represented and validated? If I wasn’t willing to work through my discomfort, how could I expect someone else put themselves through it?

So I made a deal with myself: if I found myself complaining about any form of inequality or lack of representation, I would ask myself if the issue really matters to me, and if yes, I would step up and speak up. If I chose not to do that, I wouldn’t complain about it. Simple. It wasn’t enough to have a seat at the table. I had to use my newfound privilege to make room for more people at the table.

Some of the actions I took/am taking are:

  • Started my YouTube channel to talk about tech writing
  • Joined Toastmasters to work on my public speaking skills, hoping it’ll help me speak well at conferences and events
  • Participate in events (like this and this) that feature non-traditional leaders in tech
  • Currently planning a talk proposal for next year’s Write the Docs conference(s)

Every step of the way, I battle my insecurities. The Imposter Syndrome makes me question my worth: Why would my opinion matter? There are smarter, more knowledgeable people out there, why do I deserve their attention?

That’s where the dummy puffins come into the picture: I am a dummy puffin. I want to be out there on the seemingly lonely island, just representing puffins, with the hope that smarter, wiser, more knowledgeable fellow puffins will show up and be encouraged to share their experiences and perspectives with the world. Because, in the words of the great Captain Holt:

Related image
Image source: https://goo.gl/images/1aFFz3

 

 

Why and how tech writers should work on their technical skills

A few weeks ago, I was invited as a guest on one of my favorite podcasts: 10-min Tech Comm. Check out my episode about why and how tech writers should work on their technical skills:

https://app.stitcher.com/splayer/f/73517/55624504?size=large&variant=twittercard&autoplay=1&auto_play=true

PS: Tom Johnson is hosting a poll based on the podcast. Cast your vote here: https://idratherbewriting.com/2018/08/10/how-much-time-devoted-to-learning-tech-is-needed/

Blog Updates (Back from hiatus)

In May, I announced a hiatus from blogging because my parents were visiting me in New York and I wanted to spend quality time with them. We had an excellent summer in the city – I have never seen them so relaxed and happy! Now they are safely back home in Pune and I am back to my routine.

The hiatus proved more beneficial and necessary than I expected. Not only did it cure my homesickness, but also gave me a chance to take a step back and rethink my purpose for this blog and its future. You see, the reason I started blogging consistently in 2018 was because I had a lot of things to say about life as a Technical Writer and the blog seemed to be the best medium to share my thoughts and experiences. But now I find that having this blog as my only platform is pretty limiting. I have so many more things to share, but not all of them fit the content structure of a blog post. Some topics are better suited to video content, while others need more long-form content, such as a full-blown course or even a book. Some topics are about my knowledge gaps that need collaboration with other content creators in the tech writing space.

So that’s what I want to do next – experiment with different content platforms that best suit the topic I want to discuss. I still want this blog to be my central platform, so I will continue writing blog posts and link to other content as and when I create it. I hope you find this experiment helpful and entertaining.

Until next week, happy creating!

Reader question: Contributing docs to open source projects

As you might know, I recently conducted a webinar about contributing docs to open source projects. In this blog post, I am answering few follow-up questions about the topic.

Vinaya Krishna asks:

How to acquire domain knowledge of these communities? (Since you work in Cockroach Labs, there are people who guided you there. But how did you start working on others? Is it just by browsing their pages? Or did you actually get KT from other fellow members?)

Acquiring domain knowledge of the project depends on the complexity of the project. For beginners, I would recommend that they start by just observing the projects that they are interested in – follow the repository, see which contributions are being made, participate in their communication channels (probably Slack or Gitter), and keep an eye out on the issues list. When you feel confident enough to make your first contribution, start small – pick the easiest issue you can find and get a win under your belt. This will help you get familiar with the process and tools, and then you can move on to handling the technical complexity of the project.

I cannot stress enough the importance of being self-motivated and self-reliant when contributing to open source projects. Remember that the project maintainers are most probably employed full-time elsewhere and are working on the project on their own time. We cannot expect them to handhold us through the project – so make sure to do your homework, try figuring stuff out on your own, and approach them only when absolutely necessary.

More details in the presentation: Contributing docs to open source projects

Can a for-profit organization use Github with their data confidential in it?

As far as I know, yes. So GitHub has two flavors: you can choose your GitHub repository private or public. The repositories that seek contributions are public repositories. But you can make your repositories private to keep your data confidential.

Can you please upload the PPT somewhere so that we can visit the links you had mentioned in the closing slides of PPT?

Yes! Here you go: Contributing docs to open source projects

Update: A helpful reader, Suzanne de Veld, suggested the following projects that accept contributions and other useful links: