Eight things I learned in eight months as an engineer at a tech startup

8 is a lucky number in Chinese; It’s pronounced [bah] which sounds like the character for generating wealth [fah]. While my first 8 months at DevRev have not yet generated wealth in the traditional sense ($$$), it has generated wealth in other ways. And since I figured it was finally time to stop saying I would write and start actually writing, here are the top 8 things that have generated the most “wealth” for me in the last 8 months at DevRev.

Read and comprehend

Yeah, I know, super basic, but I couldn’t exclude it.

Growing up, I was one of those kids that would go to the library once a week, check out 8–10 books, read them, then return the books and repeat the process the next week. Unfortunately, by the time I got to high school, I read a lot less and my tolerance for reading long periods of time dropped. Towards the end of my college career, I decided to pick up reading again. While I found that my reading speed was still quick, my comprehension skills were abysmal; I often had to reread text once or twice before truly understanding it.

You might be thinking “But Violex, you’re a software engineer. Why do you even need to read? Just write your code.”, which is a fair enough argument. However, all the best software engineers I know have high reading comprehension skills and tend to be avid readers as well. Think about it: while writing code is integral to my job, I can’t do that well if I don’t understand the codebase first. Writing code without understanding the existing codebase is like trying to put in a puzzle piece blind; you don’t even know if your piece is part of the puzzle, let alone what it looks like in the grand scheme of things.

In addition to reading the codebase (or at least some of it), reading comprehension also comes in when doing code reviews. Since I am in my early career, I’m not requested to review that much code, but every time that I am, I find that the more I work towards reading and comprehension, the quicker and more pain-free the process is. By working on reading comprehension, I’ve been able to do my job more and more efficiently.

Build solid habits

When I was in college, my life was in disarray; I would sleep at odd hours, exercise sporadically, and nothing about my lifestyle ever seemed consistent. While it worked for me at that point in my life, after I started at DevRev, I realized that I seriously needed to establish solid habits because the effects of my habits were no longer isolated to me. Having solid habits is the foundation of having a healthy and productive lifestyle.

While there is certainly no one-size-fits-all in terms of habits, I’ve found that establishing habits around integral parts of my existence (sleeping, eating, and exercising) has not only improved my quality of life but has also made establishing more complex habits easier. I’ve learned a lot of what I practice from various books but the one I recommend the most is James Clear’s Atomic Habits. Clear clearly (haha) breaks down how to establish habits and build them up.

If I could offer one piece of advice though, it would be tonever skip habits twice in a row. Nobody is perfect, certainly not me, so having days of skipped habits is going to happen. However, if I skip a habit, like working out, two days in a row, I’m far more likely to continue skipping it, which builds up a habit of not exercising. Technically, everything and anything can be considered a habit, as long as you do it consistently.

Put everything in your calendar

Yes, everything. While you don’t need to tell your coworkers you are getting a colonoscopy between 2 pm and 4 pm next Tuesday, you should at least block it out with an event titled “busy” in your calendar to signal that you are busy. I even put personal events that occur outside of 9–5 in my calendar. Because DevRev is a global company, blocking out time for personal things is sometimes necessary as my personal time may be another person’s working time.

Another trick I’ve found to be useful is to set up working hours. As much as I love my job and coworkers, I refuse to have meetings before 8 am and after 8 pm and working hours lets my colleagues know when I am officially on and off the clock. (It’s still possible for someone to schedule a meeting with me but they are forced to acknowledge that it’s outside of my working hours.)

In addition to work benefits, having an organized and updated calendar also helps me visualize my work life balance; Google Calendar has even come out with insights about time spent in meetings.

Making sure my calendar is up-to-date helps others be respectful of my time and vice-versa. It also helps me be respectful of my own time :)

Listen more than you speak

I believe it was one of our co-founders, Dheeraj Pandey, who said that one should listen two times more than one speaks. This holds particularly true for me at this point in my career. Because I work at a startup that values ownership and believes in the power of youth, I am often asked for my opinion, which I’ll happily give. However, it’s when I hear the opinions and thoughts of others that I gain the most; I am surrounded by people who usually have at least a decade of experience on me and each time they voice their opinions, I gain insight.

The colleagues that I most look up to actively practice listening more than speaking as well. I think it’s human nature to want to hear yourself talk and in this day and age, being loud is often equated with being important or being correct, but this is very anti-productive. Think about it: you already know what you think so if you truly want to gain information or insight, you should shut up and listen to what others think. This isn’t to say you have to agree with them or even value their input but how will you know if they have valuable input if you don’t even listen to them speak?

Say goodbye to comfort zones

I am a self-proclaimed backend developer. Unless you count copy-pasting code from StackOverflow to cobble together a website as frontend development, I have zero frontend experience. Despite this, I have spent the last two weeks working on our product’s frontend.

While I won’t get into why, I will say that this is one of many times where I’ve stepped out of my comfort zone and each time it happens, I learn something new. For example, after three weeks of working on the frontend code, I’ve developed not only more respect for our frontend team who tirelessly work to build something beautiful and usable, but also a far better understanding of the relationship between frontend and backend.

I’ve been able to see where the backend code I normally write fits in and this allows me to be a better developer overall. For the tech industry in general (and I’m sure other industries as well but I only speak to what I know), staying in comfort zones actually results in not just a stagnant but a declining career; if you’re not willing to step out and learn and experience more, then you’re outdated.

Take ownership

At DevRev, the owner’s mindset is really emphasized. At its core, having an owner’s mindset means that you are personally invested in the product and the product’s success, or lack thereof, reflect on you. While this may sound like the opposite of work-life balance, it really isn’t; having an owner’s mindset means that you want to work to better your product because it belongs to you.

The owner’s mindset doesn’t just stop at the product; it also applies at the company level as well. Owners don’t just follow examples; they lead by examples. Whether it means owning up to mistakes, taking on new responsibilities and projects, or even making new colleagues feel welcome, for me, being an owner means being personally invested.

Even though I’ve only been working at DevRev for eight months, I’ve done my best to get my hands on and contribute towards a little bit of everything. This hasn’t just meant working on frontend things as a backend engineer — this has also meant owning things in realms like publicity and hiring, which are both outside of what a “traditional” SWE does. However, by taking ownership of these things as well as my “normal” duties, I’ve gained a higher sense of clarity about both DevRev as a company and as a product. This heightened clarity allows me to perform better and hopefully inspire others to do the same.

Be stretchy

This is directly taken from the book “Stretch” by Scott Sonenshein. In this book, Sonenshein breaks down two concepts: stretching vs. chasing. Essentially, stretching makes the most of resources while chasing exhausts resources in the pursuit of more. While DevRev is not exactly a “typical” startup thanks to a hefty seed round, we are consistently reminded to stretch and not chase. Having a stretchy mindset leads to innovation because making the most of resources often means utilizing those resources in nontraditional ways.

Prior to DevRev, I definitely leaned more towards chasing; if I needed to hammer in a nail and didn’t have a hammer, I’d buy a hammer. However, after joining DevRev and learning more about stretching, I’ve realized that I’ve wasted countless resources because of self-imposed limitations. Who’s to say that a shoe or a tape dispenser or a book can’t be a hammer?

While there are some things in life that I believe are worth chasing (my personal picks are gold jewelry and leather goods), pivoting to stretching instead of chasing day-to-day has meant that my resources (whether it be money, time, energy, or something else) have increased since the resources I do possess have increased in use and as a result, I’m spending less resources overall to pursue wealth.

Fail often and fail fast

There was some cheesy quote on my middle school science teacher’s wall, something about how Ben Franklin didn’t fail 1000 times before making a working light bulb but how the light bulb just took 1001 steps to make. Ben Franklin controversy aside, I actually really like that quote. (Another quote I like also came from a middle school classroom wall: “Shoot for the moon and land amongst the stars”… but I digress.) Without trying to be too deep, the light bulb quote is essentially saying that failure is not just part of the process, but integral to the process.

One thing that quote doesn’t cover, however, is failing fast. This is tangentially related to being stretchy as it’s also about conservation of resources; failing fast means that when something isn’t working, then it’s best to cut losses and move on. This doesn’t always mean entirely pivoting away from a goal; sometimes this can just mean re-evaluation of the current methods to reach that goal. In the context of the lightbulb quote, out of the 1000 failures, there should be at least 400 unique failures.

For example, theoretically, if you throw a ball at a wall infinite times, it is bound to pass through once. However, reality isn’t theoretical and if you sat throwing a ball at a wall over and over again hoping for it to go through, you’d realistically be an idiot. Essentially, failing over and over again by repeating the same process is a huge waste of time and resources. Ideally, you should learn from each failure and every new iteration should be different in some way.

The last eight months have been a whirlwind; in addition to starting work at DevRev, I also graduated from university, moved to a new city, and got a dog.

Ranger!

However, despite all the changes in my life, the eight things that I shared with y’all today have helped me stay centered, focused, and productive, giving me more energy and motivation to work on a product that will generate wealth for developers everywhere. However, that is yet to come so I hope you’ve at least gained some wealth in reading this article :)