There are a couple of reasons why I started writing. First, it’s so easy to get it published today that I can’t believe that I hit publish and it’s available to read. Sometimes, I write it for myself so that I can come back to it when I want. Great job, team! Second, I don’t want to watch the show from the sidelines. What I mean by that is that in this content creator economy, I feel I am not contributing, and given that I have never done it in the past, it’s really hard to get started now. Everyone around you is creating content. Some people are so good at it that they take your work and repackage it well, which is easily digestible. There is an art to that. I feel there are two parts to the story: 1) You need to have original thoughts and ideas, and 2) you need to know how to present it to the world so that they can digest it and learn from it. I think I do a pretty good job at #1. I have written more than 100 design docs, wikis, etc., which cater to a specific group of people. We have various AWS services based on the ideas presented in those docs to VPs and Directors here at AWS. So, I would say I am decent at coming up with ideas and original content. #2 is where I feel I haven’t done a good job. It could be because of a skill gap or my lack of motivation to make strides here. I honestly don’t know where I lack (maybe this post is coming out that way; I’ll see in a year or so where I land). I call this a known-unknown for me. Known, as I know I lack in this aspect; unknown, as I don’t know why. While I understand it’s a “me” problem, I’m almost certain that a lot more people struggle with this. I have several 1:1s and discussions where people express the desire to become more visible and be able to present their work. My message to them is: Do this, Try, and Fail. It’s okay to fall flat on your face! You may get a few bruises, but next time, you will be ready and might be able to add a cushion to the blow. You don’t have to go all out and start writing in forums and all, but you can take baby steps. Here are some baby steps that you can start with and slowly build your muscle and get better at it. Meeting Notes One of the things I did early in my career was to always volunteer to take notes in meetings. I paired with a few senior engineers and told them I would be happy to take notes for them if they invited me to meetings. Initially, they invited me to the ones where I was needed, but then, due to the convenience of note-taking, they invited me to other meetings if I was free to tag along. I mostly said yes and tagged along. I not only got better at note-taking, but I also learned so much more. I was more informed than most of my other teammates and certainly knew what was coming next or what may disrupt our roadmap/sprint. This was such a great advantage I had. Of course, I had to work extra hours to compensate for this, but it was a no-brainer for me at the time. I was in the mood to drink from the firehose. It was definitely overwhelming at times! Anyways, enough about my little hack, back to note-taking. When I first started, I jotted down bullet points and sent them to the organizer before sending them to a wider audience. I got immediate feedback and improved. By the 5th or 6th meeting, I had built a template that I followed. Here was that sample template that I wrote and got approved with a senior engineer at the time: MOM (Minutes of the meeting)Date: XX/YY/ZZZZAttendees: ABC@, xyz@….Summary: We discussed ABC. There were two options. Option A and Option B. We discussed and decided to go ahead with option B for XY reason. Please refer to XYZ doc for more information.Action Items: 1. Specific Action Item#1. ETA: AA/BB2. Specific Action Item#2. ETA: XX/YY3. …..Next Steps: Finish AIs and then jump on to the implementation. These are just some random text. Trying to highlight what I was doing as SDE 1 fresh out of college. MOM (Minutes of the meeting)Date: XX/YY/ZZZZ MOM Date: Attendees: ABC@, xyz@…. Attendees: Summary: We discussed ABC. There were two options. Option A and Option B. We discussed and decided to go ahead with option B for XY reason. Please refer to XYZ doc for more information. Summary: Action Items: 1. Specific Action Item#1. ETA: AA/BB2. Specific Action Item#2. ETA: XX/YY3. ….. Next Steps: Finish AIs and then jump on to the implementation. These are just some random text. Trying to highlight what I was doing as SDE 1 fresh out of college. As you can see, this was nothing fancy, and I definitely had help from senior engineers at the time. This was a good start, giving some structure to meetings and how to keep making progress on things. It was a good writing exercise for me, as I got instant feedback on my notes! ADRs (Architectural Decision Records) After my success with note-taking, I wanted to take it to the next level where I not only took the notes but also started to capture the actual discussion, as the notes were not sufficient for capturing the nuances in disputed situations. Even though we agreed on something, we kept coming back to why we decided that and again required us to go through the whole design doc. So, one of the seniors suggested doing something about it, and I did some research and found about ADRs and thought it would be a good idea. I experimented with it and used it a couple of times, but it took a lot more time than just note-taking. Also, it needed a lot more context and nuance capturing. I suggested the doc owners own this. Here is the template I used then: Title: For e.g. Selecting java as a language to write libraries for this specific implementation.
Status: (Accepted/Rejected/Proposed)
Record Date
Date when this got finalized.
Context
What is the issue that we’re seeing that is motivating this decision or change?
Decision
What is the change that we’re proposing and/or doing?
Consequences
What becomes easier or more difficult to do because of this change?
Future Action Item Title: For e.g. Selecting java as a language to write libraries for this specific implementation. Title: Status: (Accepted/Rejected/Proposed) Status: Record Date Record Date Date when this got finalized. Context Context What is the issue that we’re seeing that is motivating this decision or change? Decision Decision What is the change that we’re proposing and/or doing? Consequences Consequences What becomes easier or more difficult to do because of this change? Future Action Item Future Action Item We followed it for some time, and then, because of the overhead it added, we decided to discontinue it. Even though it was discontinued, it gave me a couple of good opportunities to exercise my writing muscles. One Pagers As you might have guessed, I was not only just writing these notes but also growing in my career. I was continuously delivering my assigned projects and exceeding expectations, and I got promoted within 2 years’ time. I wrote various design docs and got them reviewed by my colleagues and senior engineers. One thing I always felt was that sometimes you don’t need a full-blown design doc to seek guidance from senior folks on the team. I myself faced this dilemma on what is the right level of detail to have before seeking feedback or ideas. We definitely did a lot of whiteboarding, but we never followed any quick one-pager document style review. To address this, I created a one-pager template for my team (which I evolved over the years and still actively use). Here is the template that I created and wrote several docs on: Background
Tell us about the background. For e.g. I am working on project xyz which will help improve the deployment time from N hours to M hours. As a part of this project, I am working on migration of active prod workload.
What is the problem?While doing the active workload, I have to pause customer operations….
Why is this a problem? As this will be visible to customers in terms of 5xx errors and ….How would you solve this problem? I was thinking of building a staging area…ConclusionTODO: Fill after the meeting. Background Background Tell us about the background. For e.g. I am working on project xyz which will help improve the deployment time from N hours to M hours. As a part of this project, I am working on migration of active prod workload. What is the problem? What is the problem? While doing the active workload, I have to pause customer operations…. Why is this a problem? As this will be visible to customers in terms of 5xx errors and …. How would you solve this problem? I was thinking of building a staging area… Conclusion Conclusion TODO: Fill after the meeting. It not only helped me, but the team also liked it, and our discussions became more frequent and more structured. These are the things that I did earlier in my career. All this work that I did, I never wrote about it. If you’ve read this article till this point, now you may understand why I claimed that I’m not struggling with #1 (having original thoughts and ideas) but #2 (knowing how to present it to the world) is where I have to shift my focus, which is equally important to share the knowledge and make yourself heard. Conclusion Every one should write. Writing is a fantastic way to express your authentic self and share your unique perspective with the world. It doesn’t have to be perfect right from the start — the most important thing is to simply begin. There are opportunities all around you to start writing. Start small, experiment, and don’t be afraid to improve over time. So take that first step, and let your voice be heard! Disclaimer: These are my own views. They have no relation to where I work. Disclaimer: Disclaimer: These are my own views. They have no relation to where I work.

The is an opinion piece based on the author’s POV and does not necessarily reflect the views of HackerNoon.

Every

Most Outages Don’t Start in Your Database — They Start in Your Cache

How ‘Helpful’ Retries Can Wreck Your System—and How to Stop It

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Can Writing Make You Better at Your Job? This Software Developer Thinks So

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Backpressure Isn’t a Bug: It’s a Feature for Building Resilient Systems

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Soft Skills Every Developer Needs

12 Effective Communication Tips Every Software Engineer Should Imbibe

2021: The Year of Remote Tools, Soft Skills, and AI Innovation

Backpressure Isn’t a Bug: It’s a Feature for Building Resilient Systems

10x10: Ten Life Lessons from a Developer After Ten Years in the Industry

10 Soft Skills Every Developer Needs

12 Effective Communication Tips Every Software Engineer Should Imbibe

2021: The Year of Remote Tools, Soft Skills, and AI Innovation

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps