A scientific guide to knowing what you don't know
Ever been in a meeting and a client or your boss asks you for a solution you didn’t have or hadn’t considered? Or sat down to start writing and have zero idea of where to start?
Did your heart rate increase? Did you get frustrated? Did things get weird? Was there was an awkward pause? Well if so, congratulations! You’re normal!
You may have had a mild bit of anxiety and this can (and often does) lead to panic. So, how do you avoid the wasted energy that goes along with this panicking?
Well, first you have to recognize it and accept that you don’t have an answer RIGHT now… The client or boss need not know that, exactly, but you do need to keep their trust. So, what do you do?
As a former chemist, research is something I still love. As a new developer on a team of incredibly talented people, I constantly don’t really know what my next step will be, or what could be asked of me. This is not uncommon among developers or creatives. What could come out of that next meeting could cause a little anxiety and potential panic. Taking a scientific approach to knowing what you don’t know will save you time and energy, and will help you save face at the next encounter with “The Nothing.”
How to know what you don’t know - a scientific approach to panicking
1. Ask an initial question
Once you take a deep breath and let your client/boss know that you don’t have the final solution yet, but that you are working on it, ask yourself: what caused the panic? This should not be a long process. It’s often a waste of energy to spin off into the realm of “how could I be so fill-in-the-blank?” But acknowledging how you got to the point of feeling blindsided is valuable if you can avoid it in the future.
So… How did I get to this point and what exactly is the issue? Understanding the question is key. If you don’t fully understand, you get to cycle through this step a few times, reviewing notes or reaching out to the client for clarification.
Keep the question(s) SIMPLE. Don’t overcomplicate things. If you find your questions getting complex, break them down into simpler questions. Keeping a running list of questions will help you prioritize, compartmentalize, and shed light on where clarification may be needed.
2. Ask some more questions (Research)
Now that we know what the question is… let’s ask some more and gather your resources. Is this something you’ve dealt with before? Do you have any code snippets (in my case) or references from previous experiences you can draw from? Do you know anyone with similar skills you can reach out to?
Finally, search online and keep your search criteria specific. Think of your issue in terms of key words and be focused. The web is exactly that, so try not to be too broad and waste energy on unrelated issues or worse… the wormhole of gifs and videos that can certainly be distracting. Start your search with trusted references and then expand out to the global search in your favorite browser. Talk with your coworkers, design community, or look at trusted forums. Chances are this issue is not unique to you, and someone else has been here before.
3. Hypothesis (Ideate)
Now, the fun part — start conceptualizing what the solution looks like. Begin by drawing or diagramming what needs to happen and refine it. And the best part is, you do NOT have to be right: many times your first guess is not the right one. Revisiting is part of learning… what isn’t the answer is still getting you to what is.
This is the part where, if you are communicating or dealing with a client, managing expectations is key. You want to keep their confidence in you by maintaining a level of transparency and honesty. Provide timelines and stick to them or give ample time to update if a process is taking longer than anticipated. Give yourself some cushion in case things don’t go as you initially expect, and you’ll have time for further examination in the next step.
4. Test/experiment (Iterate)
This is where things get exciting and can also get frustrating. Put your nose down and start — whatever that means: attacking code, sketching, putting down words, etc. Be present and keep your focus on the specific question you had in mind. Keep the others (if others exist) in your periphery, but don’t focus on them yet. If you find something that tips another, create a clear reference for it and come to it later.
Once you’ve created your content, written code, or completed a piece of work, have others review and test it. Put it through the ringer with people whose feedback you trust and admire. This will help see things outside of your slim view and may present other questions that you hadn’t considered or even simplify a solution (which happens to me often: being a data wrangler early on, I tend to overanalyze from time to time and fresh eyes give me perspective).
5. Draw a conclusion
Now, DOCUMENT it. What is the end result? Write it down, draw it out, finalize it. In the event this issue comes up again or you are faced with something similar, start a folder for your own reference. For me, in coding, it’s a Code Snippet folder I keep by project and tools used. I try to mark them with tags or keywords so I can refer back to them. The more I use the reference, the more confident I become and the more I can share it with others feeling that same sense of panic.
6. Share with the world (or your client or boss)
This is the best part — you get to deliver the results now and move on to the next problem. Which will be a piece of cake since you are now equipped. Not only have you solved the issue, but you learned something in the process (probably many somethings). This is certainly better than copying some code, pasting it as is, and praying it works. Or hacking away at layers in an Adobe file, or even recklessly and tirelessly reviewing unhelpful documentation.
When you get to that final conclusion and have nailed it, there is no better feeling than learning and, ultimately, teaching yourself. It’s huge for self-awareness and helps refine your skills for these kinds of tasks. Celebrate. By sharing your findings you will digest the magnitude of the issue and give yourself a little perspective on what it took to get there. You may also help someone who is struggling with a similar (if not the same) issue.
- Panicking is wasted effort. A little mild freak-out is ok — we all need it to identify next steps — but don’t let it consume you. Put that energy elsewhere. Bring it on.
- You have the resources. Use them.
- Don’t hack away at a problem. Consider it carefully and identify the specifics of what you don’t know.
- Research… through your networks, peers, the internet or good old-fashioned books. Gather some knowledge around the issue and apply it. This is a hard concept in the days of “just google it” and CTRL+C and CTRL+V, but it is time well-spent and will cut down on research time in the future. Practice this, and you will be more proficient.
- SHARE (don’t brag). Show people what you have discovered. It may be similar to other issues, but supplemental for those struggling with a similar need.