The not so secret sauce of my work

Hi, Chethan here! Once upon a time, I worked as an assistant professor in an Engineering college. Then, almost three years ago, I joined Fyle as an intern. And here I am today, working as a senior member of technical staff.

Every time we get on 1x1 call, my manager Gokul admonishes me for not sharing my way of getting things done.

At this point I would give out a sheepish smile and say, I'll do it soon. This was happening for a long while now.

What prevents me from writing down the way I try to organize my work is the feeling that most people would already be knowing and doing what I got to share, or they may even have better practices. But in last 1x1, Gokul said that "soon is not soon enough" and made me commit to a particular date. He insisted that it will help at least few people in some way and that is a worthy thing to aspire for. So here I am, trying to put my process into words. I don't say that these are the best practices, but these are working well for me, and I hope it might help a few of you as well.‍

Self chat on Slack‍

Everyday, I use at least 15 different services to navigate through the day's work. To communicate, to track tasks on me, to document features I build, to share ideas, to schedule meetings, to test changes, and so on. To juggle between them is a maddening experience. So, I use self chat feature of Slack for anything that is text based. Links to PRs that I have raised? Tasks that are pending on me? Ideas I am nurturing? Short snippets of code I find useful? or links to interesting slack threads? All find their place in self chat of Slack.

Along with self chat feature, we build slack bots to deliver messages/commands from (and to) external services straight into Slack. This way I can keep track of almost everything that I am working on from one place. Unsurprisingly, this blog post also started its journey from there.‍

Use Terminal‍

Terminal can be scary, but it is not as hard as we have come to believe. After the apparent difficulty in initial stages, it makes things super fast and super cool as well. So, I try to use terminal where ever I can. There are so many command line tools out there that make installing new softwares, making network calls, triggering an action on remote service, super easy.

I even write scripts for multi step processes. You need not learn shell scripting for this. With universal prevalence of Node.js, you can write these scripts in javascript (or python works too).‍

Use Aliases

To save some extra key strokes, I create aliases for most frequently used commands in shell's configuration file (.bashrc/.zshrc). So git pull origin master becomes gplom, git push origin master becomes gpsom and so on.

It is not just git commands. I store shortcuts to directories, db connection strings, etc as well. Along with saving you some keystrokes, it has an added benefit of making you instantaneously cool!

‍Divide and Conquer‍

When I work on a feature, I try to divide it into several smaller components that are functionally complete at some level.

For example, I am working on a new admin tasks page, which has two sections: tasks that admin has to take care of, and sending reminders to spenders/approvers to take care of certain tasks. So, we already have two independent chunks. Further in reminders section, we have a list of reminders, with each element in the list having a count, tooltip, link, CTA associated with it. Now each of these reminders is independent. A passive component that takes an object with above information and renders it is functionally complete, and hence can be built independently. Going deep further you see that only count comes from API and rest of the information is static. So you write a function that gives you the static part and another function that fetches the count from API, and one more function that combines these two to give the final object that can be passed to the passive component mentioned above.

This way I drill down as much as possible and create task for each one of these pieces. Once I am done, I build the passive components, service functions (that can be reused) first and then put these pieces together to form final deliverable.‍

Start crude and then polish

‍‍Use the super power of draft. The biggest problem I used to face in the initial days was where to start. I used to end up spending a lot time in my head thinking of all the things I would do in a wrong way. I wanted every piece to be perfect from the start. But soon it made sense to build things just to be functional, without worrying about whether the implementation conforms to the designs, or about taking care of all the corner cases.

This way I had a base to improve my implementation upon. Then I would continually work on polishing the edges and edge cases. This helps me to speed up the implementation and gives a sense of progress which motivates me further.‍

Keep It Simple Stupid

In the real world, we build against constraints, which forces us to have tradeoffs in implementation.  As time progresses nobody remembers these constraints and tradeoffs made, and changing something in the existing code or integrating something new to it becomes a headache. So, I don't want to add extra cheese on top of it. But I pepper the code with comments if there are decisions involved so that home coming doesn't feel like a ride down the rabbit hole! (wow! Try making sense of this!)‍

I try not to write smart code. I know the jokes on developers are real. We won't remember why we wrote a piece of code, just two months down the lane.

Be proactive in finding out how your features are being used

I keep a track on how features are being used. This is not just about logging the usage, but actively trying to make sense of the logs to see if anything else can be done to improve user experience. Along with providing clues on missing pieces of the puzzle, this trains my mind over a period of time to guess what makes it easy for the users to get their work done.

‍‍

Avoid frequent jumps between tasks

As messages keep pouring on Slack (or any other internal communication tool), temptation to jump into the buzzing task is real. But don't fall for it. The price we pay for context switching is ridiculous.

In the initial days, I used to jump and work on latest of request by my manager. But that certainly didn't work out well as I used to end up with several incomplete tasks at the end of the day.

Then I started to note down all such requests, and work on any request only if it had a tight time constraint. Otherwise, I focused on the one task I wanted to get done on that day.

I stopped judging myself on what I could or couldn't achieve on a single day. Instead I started to measure my work in a week's time frame. There will be days when you are productive to a rockstar level, and there will also be days when you feel so much frustrated that you call your existence into question. So it is okay lose battles to win the war.

This way if I couldn't finish something on a given day, it was not a cause of worry; I could still get it done the next day. This removed the feeling of constantly on the run and made me feel more confident about my work.‍

Celebrate p0s

‍Well, not literally! When there were p0 calls (a bug in production app which needs an immediate fix), or bug triage calls, I used to join them as much as possible. This helped me know how senior developers go about debugging and fixing issues.

It also gave a glimpse of several tricks they had in their kit. How they were using the terminal? How they were using the developer tools? What commands did they use? What were the buzz words that flew around and what they meant? I learnt these things in my early days, which made my life easier.

‍Take frequent breaks

‍
I work when I feel like I am most productive. Also, I try to save long uninterrupted time of a day to work on my tasks on one side and bunch up meetings and requests from colleagues on the other side. If I feel stuck for long, I would just drop a message on Slack and take a long break. As our company culture is built on trust and focuses more on getting things done rather than on where and when it is done, I can confidently take breaks without guilt or fear.

‍Don't be afraid to ask for help

‍‍Initially I was trying to get everything done by myself. Even when I was stuck for days on a single problem, I refrained from asking for help. This was leading to frustration and my confidence used to take a hit. But I observed that senior developers would gladly ask others for help without a shadow of hesitation. So, I also started to ask for help if something took more than a day to figure out by myself. This helped me to understand that there is no shame in asking for help as long as I value others' time and have exhausted all my means before seeking help.

P.S. Thanks to Abhishek as well. It was he who pushed me to test my limits and mentored me in the last two years. A year and a quarter ago, when I started practicing guitar, he asked me to play 'Miracles' by Coldplay one day. I said I am still learning the basics and would play it "soon". End of story.