On work

What's important? #

1. Create value - There is no point of working if we are not creating value for our customers/clients. Talking to customers, connecting with the product is crucial for the feeling of fulfillment. It might seem like we are doing it for them but truly we do it for us. Creation is the risk. Resonance is the reward.

2. Respect everyone's time - When doing deep technical work, I like to remain undistracted for 3-4 hours a day. Obviously, if there is a fire going on, or someone needs me urgently, I'd love to be reached out. If I am not a stakeholder in a meeting or can't add/gain any value from it, I'd prefer not being there.

3. Async written communication - My memory is super average 😄 I prefer to write even in a synchronous setting. When we write, we iterate over our thoughts, and only what's necessary and important comes out. Also, anyone can refer to written records. No need to repeat. If the written piece is version-controlled, that's even better. Anyone (including the writer) can refer to the history of the piece. The only drawback to written communication is 'conveying the tone.' Good writers have this figured out. Practice helps.

4. Ship and repeat - When there is clarity on what we have to build - Ship. Ship fast. Ship faster. Fail early. Fail better. Ship better. Iterate. Seeking perfection is overrated. Repetition is underrated.

5. Slow thinker/Time taking - When there is ambiguity about what we have to build - I like to spend time with the problem and grow with it. For example, if I am working on a problem and there is more than one way to approach it, I'd probably spend some time researching how others have solved similar problems, trade-offs of different solutions. Sometimes, I go back down memory lane and reflect on my previous experiences. If you ask me a random question and expect an instant answer, I might not have it most of the time. It's not only that I have to research it in the world, but also within my mind.

6. Balance between clarity and ambiguity - The best requirements have the most clarity. I love it when a product team provides a well-written PRD. However, I embrace ambiguity as well. Hard problems are not clear in the beginning. I consider it my job to simplify things. Especially in a tech company, major business/product decisions or even requirements are often driven by engineers.

7. People and perspectives - Humble people are very easy to talk to. I tend to do great work with people who are approachable. Can I propose a better way to write that method to you? Can we share knowledge regardless of seniority? Humans have limitations and biases. We love and feel at home with a specific technology. All is good, but different perspectives really help us grow. It's good to seek perspectives from others and share our own. Also, talking to people is fun. Most of my learning is attributed to the people I've worked with. Conversations can include inputs on a document, code reviews, DMs, calls, and meetings. Most of my learning is attributed to the people I've had the fortune to work with.

8. Interesting work - Keeping the work interesting is important. I do feel stagnant if I keep repeating the same thing for months. Sometimes, engineers tend to become owners of system components. As long as we evolve and change them, the fun remains. But only maintenance or support can make one feel stuck. After all, we are makers, breakers, and craftsmen. Things can be made interesting by looking outside the box for the same problem or moving on to a different problem. Also, this is relative; a system on which I have been working for 2 years might feel boring to me but interesting to someone else. They may notice what I might overlook. This point may sound contradictory to when I say, "I like to spend time with the problem in Point 2." What I really prefer is a balance. Boring and mundane work is okay. It happens from time to time. But if it's not interesting and challenging over a longer period of time, I tend to get bored.

Process #

• Ideation - What, why and for whom are we trying to build. Have we talked to the users? Do they want it? Is this clear to everyone on the team? Is everyone on the same page? Sometime, ideas come from non-devs - like a product manager or a client. Whether they have clarity?
• Brainstorming - How we can achieve our goal simplistically? Who'd be part of the discussion? Can we break the problem into independent smaller pieces? High-level tech architecture decisions.
• Planning - What kind of timeline are we looking at? Scoping the goal based on that? Availability of team members for the project? Is everyone who is working on the project on the same page? Depending upon the type of problem at hand - we may need to do benchmarking/profiling.
• Development - At this stage most of the things should be clear. Yet, anyone can have blockers. The key is to communicate blockers as early as possible and get unblocked. It can be anything - design had an issue, a technical challenge, someone got sick and needs time, etc. Dev testing and PR reviews follow.
• QA - Developer end-to-end QA before releasing on a prod-like (or prod) environment. Handover to QA team if you have one (shouldn't be needed for most projects. Devs should QA)
• Release - Generally, it's better to do controlled rollouts. Eg - under a feature flag, percentage-wise rollout, etc. Especially for critical changes where it may affect users.
• Monitoring - Ensuring whether the code is working as expected. Keeping an eye on the reporting tools - sentry, datadog, grafana, etc (whatever we use)
• Retrospective - This is often ignored by teams. Appreciating what went well, what do we need to work on, etc.

P.S. These aren't commandments. We can change things whenever needed. Different projects have different needs. Common sense helps.

• Next: On conflicts
• Previous: On communication