How to begin?

June 01, 2021  |   2 min read

Every engineer likes to get things shipped as fast as possible but sometimes knowing where to begin with a big technical problem can be a daunting challenge. I like to break this into 3 phases:

Gathering context

  • Understanding the problem space - Good understanding of the domain and the problem space is the key to forming a good solution. Without knowledge of the problem space, you’ll only work based on your assumptions which will not result in robust solutions.
  • Gathering just enough information - Don’t fall into the trap of gathering all the information before starting work. Gather just enough information that can help you get started. Always default to building and never shy away from writing throw-away code. Many developers are scared of re-writing and re-iterating through solutions. But in my experience, I’ve written some of my best code through various iterations while building. Get comfortable with the discomfort of not knowing a lot when you begin.

Gaining insights

It boils down to validating your ideas and potential solutions.

  • Good idea vs a bad idea - A great way to validate ideas is through prototyping. Write just enough code to gain insights into the pros and cons of each solution or ideas. Having solid insights/data allows you to set the technical direction of the task/project with more confidence. It will also help you present your ideas clearly to your team or stakeholders.

Writing code

Since you have gathered enough knowledge of your problem space and validated your solutions, it’s time to write production code.

  • The plan - I like to begin with writing a rough breakdown of the task. Hopefully, you might’ve already done some of this when you were validating your solutions through prototyping. I’m a big fan of “TODO” comments for this! TODO comments are infamous but I find them helpful. It’s my way of brain dumping all the steps I have in mind. Then I proceed by writing the interface of functions (or classes) and go on to “fill” them with business/application logic.
  • Make it work then make it better - Don’t over-optimize from the beginning, start by writing the simple way and make your feature work. Then iterate to make it better by maybe breaking into more components or creating hooks for business logic.

Many people directly jump into the third phase; I get it - we all want to write as much code as possible. But taking the time to understand the problem space and validating solutions through prototyping is equally essential to building the right thing.