DEV Community: Abhin Rustagi

Insights as a 22yo Software Engineer

Abhin Rustagi — Sun, 31 Mar 2024 02:37:35 +0000

I’m Abhin, a 22-year-old developer from New Delhi, India. I am a JavaScript (+Typescript) and Django developer. I have been writing full-stack code for over 2 years now. Programming for me has been an outlet that challenges me, annoys me, and manages to keep me on my toes. I recently read an article from Lydia Hallie where she shared her insights and advice as a (then) 19-year-old software developer and it convinced me to write one of my own.

Background

How did I get into tech?

I was 12 when a friend of mine proposed that he and I could develop and publish Android apps together. For close to two years, we created and published Android apps using the MIT App Inventor, gaining over two thousand downloads for a variety of apps including a GPS, primitive photo editing apps, calculators, and more, until we discontinued for certain reasons. In my final years of schooling, I was taught C++ as a subject, and that was my first ever in-depth exposure to coding. I enjoyed having that kind of control to programmatically control a machine, instruct it, and develop whatever I could imagine.

In 2020, I reconnected with programming for good during the pandemic. Perhaps the biggest positive for me that came out of the pandemic was this rekindling. I started with Web Development and started my journey with HTML, CSS, and JavaScript. I took a liking to React and got opportunities to build real-life impactful projects for my college, and a few international organizations as a freelancer.

Later I secured a job as a Product Engineer (2022) at Openhouse (a then Series A startup, based out of Bangalore) where I was part of the back-end team. I learned Python, Django, AWS, and PostgreSQL on the go, and slowly became a dependable member of the team. It was an experience of immense learning for me.

The Undying Imposter Syndrome

When I had to choose a major for my undergraduate studies, I opted for Statistics. It was a moment of dire confusion and unawareness for me. I always enjoy playing with numbers and running my analysis on things that interest me such as sports. However, the decision to take it up academically didn’t sit well with me in the long run. Coming from a statistics background in the programming domain, I always felt out of place amongst software engineers who had studied computer science academically. It was always daunting when they would talk about Data Structures, Databases, and Networking concepts and I would have to play catch after the meetings using Google. However, both my manager and my tenure at Openhouse helped me overcome this anxiety.

I decided to pursue a post-graduate degree in Information Technology at the University of Melbourne starting in July 2023.

My key takeaways

Consistency is key

Only if you decide to show up every day, even if it is for a mere 5 minutes, will it compound into you becoming an awesome developer. You might get out of touch with a language, or a framework soon if you don’t use it for a long time. Sometimes just regularly thinking about a problem statement, or asking questions can also help keep your mind engaged.

Keep Learning

The biggest challenge (or the most exciting aspect) of the tech industry is that there’s something new every day. The industry is evolving rapidly. You need to spend some time at regular intervals to read the news and update yourself. Perhaps that might help you find your new niche.

Keep Asking Questions; Ask the why & Consider the how.

An essential quality that I come to cherish is to always ask questions and to be the curious kid in the room. Focus on the Whys and Hows. It will only make you a better problem solver, not just at your job, but in your personal life as well.

Each time you’re given a problem statement, consider how it affects your existing code. Why should we introduce a feature? Will it be a breaking change? How can you make this new feature future-proof?

Don’t just resolve bugs, solve the problem

A skilled developer knows the internal mechanics of their framework, tools, or language. I have worked with a few developers who, when they encountered a bug, would rewrite the code completely or change the flow. Here’s the problem with this approach — you didn’t learn anything from that bug. What you did was answer a question, but you didn’t solve it. You never got to learn why or how or what went wrong and how can it be avoided in the future the safe way.

Now whenever I encounter a bug, I only resort to the change-the-flow solution when it needs to be resolved on a crunch deadline. However, I also make sure to make a note of that bug, so I can dedicate a few hours later to debugging it the right way.

Think first, code later

Einstein once said — “If I had an hour to solve a problem I’d spend 55 minutes thinking about the problem and five minutes thinking about solutions.” This is an amazing piece of advice, specifically when it comes to software development. When I started, I would directly jump into coding, with no clue of the critical decisions to make, the scenarios to consider, and the pitfalls I may encounter. Over time, I have tried to develop the habit to try and spend more time thinking about the problem, than directly trying to answer it. Once you have figured out the algorithm, the architecture, and the product, you’ll be able to code without many breaks. Make proofs-of-concept, research libraries, and repositories, and see how others may have achieved what you are trying to. More importantly, it helps you handle the edge cases very well, and make a well-rounded product.

Take sufficient breaks

It will get overwhelming at times. You’ll be asked to balance work and personal life, and one may inevitably affect the other. It is important to take timely breaks and rejig your focus.

Be prepared for the next step; Aim toward growth

You should know what your next major step will be. I make sure to reach out to people much senior to me in this industry at regular intervals and just absorb their knowledge and wisdom. I ask them questions about the future, potential opportunities I can consider, and how I can be a better engineer.

On the flip side, it is easy to get lost in the rat race. Hence, it becomes necessary to keep reminding yourself of how far you have come, to take pride in wherever you are in your journey, and to balance that with humility. Your experience only makes you better.

Develop a Custom useTimer Hook in React

Abhin Rustagi — Sun, 31 Mar 2024 02:35:15 +0000

Timers are essential elements to several applications out there like Productivity Apps, Games, Task Management Apps, and many more. I’ve put forth a small example to create a custom useTimer Hook for React Applications to responsibly get around the mischievous setInterval/setTimeout function in JavaScript.

Building the Hook

Let’s start with our boilerplate tasks:

npx create-react-app usetimer-hook
cd usetimer-hook// Using VSCode for development
code . && exit// Bash in VSCode
npm start

Here I’ve used CRA to set up a standard React app and opened it in VSCode while exiting the bash window. Next, using the inbuilt Bash in VSCode, I’ve started my project, which will open the browser to localhost:3000 where our React App is running. I will clear out the boilerplate stuff from the App.js file.

Next, create a useTimer.js file in our src directory.

Here is a detailed explanation of our hook:

Lines 1-10

We’re using an inbuilt useState hook for multiple purposes here.

id: This will be a state parameter to memorize the ID of the currently running Interval.
status: This is an indicator variable to check whether the timer is currently On or Off.
Countdown (hrs, mins, secs): An object that updates each second with the timer to indicate the amount of time left.

Lines 14–45 (start Function)

The start function will do just that, ie start our timer. It takes in one argument which is the total duration in seconds. Optionally, you can supply the duration in other units, and call a custom-defined conversion function on it.

For the first if block, it checks if any other timer is running. If it is, it throws an Error stating the same. In the next if block, it checks if the duration is supplied or not, or if the duration is 0, and accordingly throws an error or not.

Inside the try block

We define a locally scoped variable that assumes its value from our duration parameter. You can add checks to the parameter to check whether it is an integer or not. Next, we finally call an interval using the inbuilt setInterval function in JavaScript. Now, the setInterval function returns an id to uniquely identify it. The id is of Number type. Since the setInterval function is asynchronous, after it is called, we directly move on to the following statements. We set our id state to the timer id, and the timer status to “ON”. We return an ‘ok’ flag to verify that the timer successfully started.

Now, inside the setInterval function, we update our countdown state after each second, by supplying the interval duration argument as 1000 milliseconds (or 1 second). We do calculations on the timer variable to obtain the hours, minutes, and seconds remaining and update those values into the countdown state.

On line 34, we first decrement the timer variable by 1 and then check if it is less than 0. If it is less than 0, we call the clear function to clear the timer.

Lines 47–58

Inside the clear function, we first check if there is any timer running or not, if there isn’t we simply return.

Next, using the inbuilt clearInterval function in JavaScript, and using our stored timer id, we clear the running interval and then refresh our state variables. Finally, we return an ‘ok’ flag.

We then move on to returning these functions and states so defined.

Using the Hook

Using the hook is pretty simple. Simply extract our start, clear functions, and the countdown state from our useTimer hook, using destructuring.

In the image above, we have called the timer for 60 seconds, i.e. 1 minute.

Asking the right questions — an underrated soft skill

Abhin Rustagi — Sat, 29 Apr 2023 21:56:01 +0000

I recently completed 11 months at my first full-time job, as a Product Engineer at Openhouse, an early-stage startup based in Bangalore. My day-to-day responsibilities include collaborating with the Product Managers, Engineering Manager, and other able members of the product team to discuss, and eventually solve problems and build new features. During my tenure, I have been fortunate to work with developers, professionals much senior to me in terms of experience, and with a vast intellect. If for me, there has been one key takeaway, it has been that in order to solve a problem, you must first ask the right question(s).

It is parallel to what data scientists say — gathering data is never useful as long as you don’t know what questions to answer from it.

It is a skill that should come with time, and experience. However, perhaps a conscious effort of working on it may help exponentiate how well one can exercise it. It can contribute immensely to one’s problem solving skills.

We’ve been told as students to ask questions in the classroom, oft even prompted by professors to ask the same question repeatedly. Although, if the question is not comprehensive and well laid out, the person who asked may never receive a satisfactory answer.

In the workplace, I think it comes down to precision, effort, and resource management.

I believe the more comprehensive and precise you are with the details of your question, the words you use, and in the opposite scenario, your answer, the better you’ll convey your point and also set the right expectation. Simply asking someone can they deliver a certain task on a deadline, compared to asking them to provide an estimated number of hours, will help set the right expectations, and help others plan their tasks.

If you are a developer, asking the right questions can help you account for all kinds of impact to your code when you’re building a feature, or making a production level fix. Just asking how the introduction of a new feature may impact the old & existing users, or what happens to the existing flow, can save large amounts of unnecessary development time, and future code breaks.

Andy Hunt, in his book The Pragmatic Programmer, mentions the importance of Critical Thinking. He mentions 5 key tips to regulate critical thinking, which I feel can be applicable to developing the skill of asking the right questions I so mention:

Ask a question, and get an answer. Dig deeper by asking “Why?” Repeat as if you were a petulant four-year-old (but a polite one). You might be able to get closer to a root cause this way.
Who does this benefit?
What’s the context?
When or Where would this work?
Why is this a problem?

As I mention above, it is a skill that should come with time, experience and repetition. You shouldn’t be afraid to ask many questions, it will slowly funnel you towards asking the required one.

Why is reading the documentation so important?

Abhin Rustagi — Sun, 23 Jan 2022 18:38:55 +0000

Quite often the process of writing code (especially while using a certain library) goes like this: write code, encounter error, modify code, encounter error, go to StackOverflow, copy code, run code, repeat.

I recently came across the acronym “RTFM” which literally stands for ‘Reading the f*cking manual’. I realized as simple as the acronym is, it is equally very true, and a great piece of advice offered to me by a senior developer.

Reading the documentation has been the most missing step in every developer’s journey early on. No online course or module ever explicitly mentions that the course-takers should actually take time to read the documentation of the technology they are using.

Some often jump into projects without fully understanding how efficiently they can make use of the libraries, frameworks, or packages they’ll use.

While some think one introductory YouTube video will be sufficient to start working with a library. But what they’d experience was spending time debugging code, which may have been solved if only they’d read the documentation, or at least skimmed it.

While watching a YouTube video is not wrong, but perhaps the purpose can be. Not often you will find a YouTube tutorial that covers a library end to end, describing the use of all the functions and features inside it. It may become important at that point to at least visit the guides.

When you avoid reading the documentation, you’re missing out on understanding the deeper mechanical processes of your code, which may lead to you writing less efficient code. You’d end up spending precious hours on websites like StackOverflow or Github Wiki, trying to find why that line of code on line 7 doesn’t work, or suddenly why did the compiler throw an error, and you’ll find a response like this:

The solution to this problem is making a certain declaration in options while initializing the library. It is given in the documentation under the “ABC” section.

You did find the solution. Unsurprisingly, the solution came from the documentation, but it was not your effort, and you got lucky that some random User3190 had read the documentation. You might encounter problems that others haven’t ever, and so they most likely don’t even exist as questions on Stack-overflow, and you’d spend hours trying to find an answer when you could have just read the documentation, and the solution was actually given on page 3.

Sometimes the package may have a function that you’re not aware of. To counter that you write another function to accomplish your task, sometimes making use of other functions within the package. Here’s one primitive example from Python library Pandas:

Code if you didn’t take time to explore:

import pandas as pd
data = pd.read_csv("./data.csv")

# Code to remove certain rows
false_rows = [2, 3, 5]
data_new = data.drop(index = false_rows)

Code if you did take time to explore:

import pandas as pd
data = pd.read_csv("./data.csv", skiprows = [2, 3, 5])

While it does sound like a Herculean task to read the documentation of all the packages or libraries you use on a regular basis, you might attempt to do it in parts, or be really smart about it.

There’s an abstract concept in programming called the 80–20 rule. It says that for a particular library, framework, or package, you don’t need to learn all of the functions. You only need to learn 20% of the functions, because you’ll use them 80% of the time. You’ll use the rest 80% of the functions only 20% of the time.

Hence, it becomes important to be aware of the functions that you end up writing in almost every project. Something like the read_csv function above is one of the most commonly used functions in the Pandas package so it would make sense to know what kind of arguments you could use with that function going forward.

To save time, you should not read the guides for every new package, but maybe just the ones you use every day in your projects.

For example, as a React Developer, you can choose to invest time in reading the guides for React.js, but perhaps not as much time in reading the guides of libraries like Axios, or, helmet, whose function in your app is very limited and you may not be using every time in a project.

In conclusion, reading documentation is perhaps an investment you can make to become a better developer in the long run and know your tools better. So, just RTFM. :)