DEV Community


Posted on • Originally published at

How to investigate technical solutions

In my previous post on the subject I suggested the long term approach to the learning problem: focus on general knowledge rather than on specific tools and implementations. But what if you need to investigate a new technical field right now, let's say this week, to proceed with the project at hand? Tech leads do this kind of work regularly in order to prepare high-level estimates and architect new systems.

In this article, I will share my approach to a quick technical investigation. I apply it to new technologies and any other unknowns as they appear in my daily tasks. I mapped the steps to the days of the week, but the timeline can be scaled up or down based on the size of the problem. So, let's get started:

Part 1: Monday

๐Ÿ˜ You are great

It's totally fine to not know something. Don't treat it as your โ€œfaultโ€ or a lack of talent/education/seniority. You are going to figure it out and you are great!

๐Ÿ” Be specific

Narrow down the area of investigation as much as possible. In practice, it means that technical investigation starts with business investigation. When the problem is defined, ensure you can't solve it without further investigation. Sometimes people ask for AI, but their problem can be solved with a regular expression. Stop thinking that your solution isn't โ€œcoolโ€ enough. It's super cool as long as it solves the problem.

๐Ÿ™‹โ€โ™€๏ธ Ask people

If you need to proceed with further investigation, then first ask your colleagues and friends who were working on something similar in the past (don't confuse friends and colleagues with random strangers on the internet!). There is no point in learning something the hard way if you can just ask your teammate for help. An extreme variant of this option is to hire a person who has the necessary experience and learn from them.

๐Ÿ“ Pick 10 random articles

Google your problem definition using different wording and pick 10 random articles and videos (it also can be one short book). List them in your notes and start reading them all from top to the bottom. Don't try to figure out your final solution, don't make any decisions just yet, don't try code snippets suggested in the articles. Just read them.

Keep reading and taking quick notes. It can be a simple bullet list, a drawing or a mind map. Stop when you finished with your 10 articles. Sleep on it.

Part 2: Tuesday

๐Ÿ Fill in the gaps

Review your notes and compare with the problem definition. You'll notice some gaps in your notes. Google them again, find 2-3 extra resources and add them to your list. Finish the notes and stop gathering information. Most likely you have already learned just enough to proceed to the next step.

๐Ÿ‘ฏโ€โ™€๏ธ Show it to a teammate

Now it's time to present your notes to someone else. Explaining the topic to another person will help you understand what you learned.

While presenting, reflect the fact that the information is not yet verified. For example, don't say โ€œThe best A/B testing tool is Xโ€. Instead, say โ€œI found several authors who really enjoyed Xโ€. Pay extra attention to the remaining unknowns (instead of leaving them out of the discussion).

Together, narrow down potential solutions to a minimum. For example, if you have five A/B testing services in your notes, pick two most promising based on what you learned so far and on the problem definition. Don't worry that you may occasionally exclude the โ€œrightโ€ solution from your shortlist. There is no one right way to solving any technical problem.

Part 3: Wednesday, Thursday, Friday

๐Ÿ– Try it in a sandbox

Finally, we are in the famous practice step. I remember times when I was putting together something new that I barely understood only to push it to production faster. This approach was fast at the beginning, but in some cases, it slowed down further development dramatically.

Before starting to write any code, prepare a list of outstanding questions that you want to clarify through practice. When the problem is small enough, you can start implementing the real solution without properly finishing the investigation. But in the general case, proofs of concepts should not go straight to production to avoid unnecessary risks.

โœ๏ธ Write a summary

Finish with a concise report that you wish had been written by someone else before you
started your investigation. Don't put too much effort in it - such reports usually become outdated in 6-9 months. Share the report with the team and agree on the next steps. Switch to something else for a little while to clear your mind.

To summarise

My quick investigation process includes the following parts:

  1. Gathering & structuring information on a very narrow topic (X time)
  2. Sharing with someone else and filtering out (X time)
  3. Building proofs of concept to figure out some crucial details (3X time)
  4. Putting together a summary for discussion and further actions.
  5. Iterating.

This process is very intense because you consume and analyse a lot of new information within a short period of time. It also can be uncomfortable to touch something completely new and to feel stupid after being โ€œan expertโ€ in your field. As Josh Kaufman explained in โ€œThe first 20 hoursโ€ talk, the main barrier to learning something new is emotional. It's often hard to start and even harder to finish. I hope that my article will help you to overcome those issues when you next time will be investigating a new technical problem.

Remember, you are great!

Top comments (2)

v6 profile image
๐Ÿฆ„N B๐Ÿ›ก • Edited

I must now go one level above this soft skill, even, for now it's time to learn how to convince some guys I know that it's worth reading this article.

kalabro profile image

Haha, it's a tricky point. It's really hard to make someone learn - it should be their own decision, and for one it may take years to come to that decision :)