General

Why I’m writing this blog?

Hi there! I'm Nikhil Pothuru, a software engineer based in the Bay Area. With over 6 years of experience writing software, including 2.5 years in the industry, I've been reflecting on my journey and thinking about the next steps in developing my software engineering skills. This blog is an extension of that motivation. My mission with this blog is to share software engineering knowledge and document my process toward becoming a product-minded software engineer.

What is a Product-Minded Engineer?

Recently I was reading Gergely Orosz’s blog post on "The Product-Minded Software Engineer”. In it, Orosz describes a product-minded engineer as someone who is proactive with product ideas and is curious about the product from end to end. His description of the product-minded engineer paints a holistic image where the engineer is not only focused on implementing business requirements but also dedicated to the task of analyzing the product and how it meets the needs of the stakeholder. It definitely describes a role that is far more than just a programmer sitting in front of a screen.

From my experience, I have found this description to be consistent with what I’ve seen among senior-level software engineers. Across the board, I’ve noticed that at higher levels engineers begin to work with ideas across multiple domains. My hypothesis is that to be effective at a high level, an engineer must quickly understand concepts and problems across the domains and be able to communicate their findings effectively. For simplicity, I’ve divided these domains into two: (1) the product domain and (2) the technical domain.

The Product Domain

So what is the product domain? In the context of this discussion, it refers to the specific industry or market in which a software product will be used. For software engineers, understanding this domain of their work can help them design, develop, and deliver products that meet the needs of their end users. Depending on the industry, the requirements for the product may include considering regulatory requirements, revenue streams, and technical constraints. All of these considerations ultimately lead to a product that solves the stakeholders’ problems.

There are several reasons why a product-minded engineer must be comfortable with the product domain.

Being comfortable with this domain helps software engineers align their work with the overall goals and vision of the product
Being knowledgeable about the domain in their industry helps software engineers identify and prioritize the most relevant and valuable features and functionalities based on the needs of the market
Learning about the product domain can help software engineers anticipate and mitigate potential risks and issues such as scalability limitations associated with their product

The Technical Domain

When it comes to software engineering, the technical domain is a fundamental aspect of the job, and perhaps something that feels far more familiar. It consists of the knowledge and tools needed to take a product from design to deployment. The technical domain can often seem pretty vast because it consists of knowledge regarding all things needed to build great software. This includes, but isn’t limited to the following:

Programming languages: The bare bones of any software engineer’s skillset. Programming languages bridge the gap between humans and machines by serving as a means to convert human-readable logic into machine code. There are a number of programming languages such as Java, Python, C++, Scala, etc. and they are the fundamental building blocks of software systems.
Data structures and algorithms: All logic operates on some data. Data structures provide the means to organize this data on a computer, while algorithms refer to the steps needed to manipulate this data. By choosing the right data structure and algorithm, software engineers can create software that is both scalable and easy to maintain.
Operating Systems: An OS is a piece of software that manages computer resources such as memory, processors, etc. They also run some essential services like file management, network connectivity, security, and process management. In essence, the OS provides the environment for software to run and interact with computer hardware.
Databases: Since software also needs to persist data over a long period of time, we have databases that make it easy to store and organize data. Most common databases are relational which provide a language called SQL to query and manipulate data stored in tables. There are other types of databases, though that would be beyond the scope of this section. Just remember, databases make it easy to read and write data in a secure manner.
Testing and Debugging: The work that needs to be done to build systems that work and scale. While these aren’t the fanciest skills, it is important for every dev to know how to test their code and debug it to figure out the problems.

How is all this important for building a great product? For a product-minded engineer, one of the most important things is to be able to translate requirements into software that can efficiently read and write data. Perhaps it’s as simple as persisting the data the customer gave as is. But it can definitely scale from here. Depending on the size of the data and the format it is provided in, there’s going to be a lot of work to get the data into a format the software application can work with. The way I see a product-minded engineer can serve as an abstraction from technical concepts. They can understand user requirements, evaluate product and technical tradeoffs, and translate product ideas to secure and scalable software.

Focus on the process, not the goal

The work to become an expert in both domains can seem monumental. While it can seem daunting, I’ve often found that focusing on the process rather than the goal can be far more encouraging. It makes the goal manageable.

One experience that put this lesson into perspective was training to run a half-marathon. The COVID-19 pandemic pushed me, like many others, to prioritize my health and set an ambitious fitness goal. In my case, the goal was to run a half marathon. During my runs, I spent a lot of time reflecting on how I could improve my lifestyle to make the experience of running more enjoyable. To better equip me for this endeavor, I turned to the internet for guidance and watched countless YouTube videos about proper running form, nutrition, and training. These videos inspired me to make incremental changes to my training regime, which eventually helped me progress from running 1 mile a day to an average of 5-7 miles per day.

In the past, I had set fitness goals but quickly lost motivation because I was too focused on the result. When I look back on this experience, I noticed that a key difference was that with my training I was less focused on the end goal and more focused on the skill acquisition. By focusing on the process of improving my skills, I was able to make achievable improvements that gradually prepared me both mentally and physically for the half marathon.

I want to apply this same principle to my journey in software engineering. I’ve defined my process as exploring different habits, acquiring new knowledge, and working on software projects to learn about the different aspects of engineering. This blog is focused on making this process transparent and easy to follow.

Structure of the Blog

To achieve this, the blog will consist of (1) long-form posts and (2) snippets. The long-form content will either consist of documentation of my experiences working on software projects or explanations of concepts that I want to elaborate on. The snippets will consist of posts that are a bit more free-flowing. They will exist as a means to ideate on anything interesting about software engineering or tech that I’ve encountered throughout the week.

One of the goals of this blog will be there to capture the process of working on different projects. The goal of these articles is to highlight how I tackle different aspects of the software development process. Early in my career, I was always looking for examples of how engineers planned and worked on different pieces of software. These articles will serve as my documentation of the experiences I go through working on different software projects. With the software development process, here are the key steps I have identified in my journey so far:

Defining the Problem: The first step in any software development project is to define the problem that the product aims to solve clearly. This step involves a deep understanding of the customer pain points and the requirements that will help solve these problems.
Feature Requirements: Once the problem is defined, the next step is to create a set of feature requirements that will solve the problem. This step involves a deep dive into how and why the features being built will solve the problem, and what trade-offs need to be considered.
Technical Architecture: After defining the feature requirements, the next step is to come up with a high-level technical architecture. This step involves bringing suggestions and trade-offs to the table and refining the technical plan based on feedback from the team.
Rapid Development and Early Feedback: Once the technical architecture is defined, the next step is to build the feature quickly and get early feedback. This step involves working with the development team to build and deploy a minimum viable product and getting early feedback from customers.
Post-Deployment Analysis: After shipping the feature, the final step is to analyze the impact of the feature on the product and customers. This step involves following up with product managers to see how the product is performing in the hands of the customer, and conducting a deep dive analysis when the feature does not perform as expected.

As part of my learning journey in software development, some of the long-form posts will be dedicated to explaining the concepts I have learned. These articles will oftentimes be derived from longer-form content such as college lectures, podcasts, tech talks, or books that I’ve come across and would like to share. I will include a prerequisite section in case the concept being shared requires a certain level of background knowledge.

The other form of content I have in mind is snippets. These posts will be a bit free-flowing since I’ll use them to discuss any topic in software engineering or tech that interests me. This can include commentary on current events or commentary on technical/product concepts that seem interesting.

In its current form, the blog structure was designed to be able to produce content over time consistently. The goal will be to get 1 article out a week.

How to get involved?

I view this blog as a platform where the readers can interact and, I've set up an email to help facilitate conversations with you all. I am available to contact at blackboxdemystified@gmail.com.

Thanks for reading! Until the next article!