Notes on problem-solving in software development as a full-stack engineer.
|Last Tended||Sep 2021|
What you are going to do. Gather as much information as possible. This step is the foundation of all work preceding it. The more time you can dedicate to this step, the stronger your understanding of the problem, the more likely a solution will present itself & the better everything proceeding it will go.
Have a face-to-face conversation with the information provider (for example, a Product Owner) if possible. You want to remove any communication barriers that come from other mediums, such as lack of body language in written mediums like issue tickets.
In the current web development space, you might jump straight to React as the choice for creating the user interface. I think the composability that comes from React’s component-based architecture is exceptional for scaling complex projects. You could also argue that in today’s society, requirements rapidly change, and choosing a foundation that can scale is a good choice. But benefits come with costs. React increases your bundle size, increasing download time &, when you consider you should try to keep your page load time under 3 seconds, could cost you users. The goal isn't to build the "perfect solution", it’s about building something that has the best pros to cons ratio given the current information. Be aware of the pros and cons of your choices. Document them.
Take Hacker News as an example. A popular tech news site. It has maintained and grown its readership even despite not adding new features over its lifespan. I would argue that React would have been a poor choice for this site. Due to the requirements of this site, the site’s complexity appears low & the cost of increased bundle size & buy-in of a library outweighs the scalability benefit that React provides.
How your going to do it. Explore the existing code base (if there is 1), APIs (use Postman) & documentation. Based on this and the requirements, write out what you need to do in pseudocode. You want a clear idea of where you’re going before you start walking. Do this in a .txt file. No styling, just tabs and letters.
Using your pseudo code as a step and step guide, start coding.
Once you finish coding, walk away. After coding for an extended period of time, you can get tunnel vision. Going deep and solving something complicated while making simple mistakes in the surrounding area. Take a break. Go for a walk. Come back to your work with fresh eyes & check:
Submit a PR. To help your team review your work:
1 thing I used to do was to start the next task while waiting for reviews. I think this is a mistake. While working on a problem, you build up context. When you start working on another problem, that context begins to decay. You want to maintain that context until the code has been merged. You want to be able to respond quickly and accurately to any comments made on your PR as well as confidently make any required changes.Source
In my experience, the above steps don’t occur in order. Rather, you will be jumping back and forth between them as you start building context in your mind. For example, while coding, you build up more understanding of what is required of a task. Time estimations made in the information step may need to be revisited and tasks removed. A better analogy would be to think of them as nodes in a graph rather than steps on a linear line.
Talking with a designer friend, they mentioned that this pattern is similiar in his work. The Double Diamond is a popular design process model. On paper, his team uses this model to solve problems and it pleases management when it comes to reporting. However, the Design Squiggle is a more accurate representation of the process.