How do you figure things out?

Be sure to add as much context as you can to your question, this increases the chances of you getting answers:
why are you asking this?
what have you tried already?

I would like to understand from the community on how you “work things out” like tables, flows, mindmaps… I have tried a lot of these before, however, I’m keen to go back to basics, revisit and learn from you all.


I tried to work this out once back in 1998 or thereabouts. At the time I was just a programmer, and I was trying to understand what kind of experience network one requires in order to have just enough knowledge to troubleshoot. Which is one of many measurable versions of your question, since “figuring it out” is not a directly actionable thing in itself. And the thing about troubleshooting is that it requires prior experience of similar working parts of the current systems, but when used in other systems. And that works because part failures are always modal, parts tend to fail in the same way, and although they never have the same effect on a system, any real-world machine part itself always ends up either crushing, bending, twisting or just changing colour if it’s in a helpful mood. That’s not to say the parts will fail that way, just, that when they do it’s the same pattern, same cause, and same remediation.

So I guess, understanding how a software system works is often emergent from the components and any visible interactions you can have with it as a end user. I’ve been coding for too long, so I always build a mental picture of the inner workings of any app I use. (It’s often an outdated image of what the back end is doing, but it works.) And I guess, that is how I “figure out” most apps, I try to imagine what the programmer wanted to accomplish as a target, and then assume that they had to use a lot of implicit knowledge to make the app work. So the whole time, I’m trying to understand what is going on under the hood so to speak. Implicit knowledge fills in many many gaps in any system, and is possibly the missing sauce when it comes to many people figuring it out. Maybe that’s, a circular way of saying, “experience”!

/edit. I so do hate that it came out with just one word.


In the old days if I was trying to figure out an existing codebase I would draw a Data Flow Diagram of it.

  1. Define the data stores.
  2. Define the processes/methods that write to the data store.
  3. Define the processes/methods that read the data store.

Sometimes the diagrams were rather large but it still gave me a starting place to understand what was in the system.


Such happy memories.

I once spent a week debugging for a customer, the eng manager says to me stop and draw a diagram. As I finish the diagram (which took all day, really the whole day for one A4 pencil drawn diagram) I go to his desk and point out the error, he told me not to fix it, but to photocopy the diagram and file it, THEN fix the bug. It worked perfectly.


A few times, I’ve sat down and reduced a workflow, or data relationships in a system, to a diagram. Never underestimate the power of pencil and paper!


A long time ago I read an article from Jon Bach on guided learning, where the tl;dr is that comparing the “spend 4 hours on learning the system” vs. “find all ways you can update your username” have very different effects on the efficiency of learning. So one pattern for me to figure things out are give myself product related missions and pursue them. I have also specifically applied testing tours to the same effect. Like do the cancellation tour, or claims tour etc. Since that is also a guide.


Once I tested a file. I noticed something strange in the structure. In my mind I could see how the file was created. So, I verified this assumption with a successful security test.

More details are in the following blog post:


Simply explore it.

Either if it’s a tool or framework, have an exploration day/night about it with some friends.
For other tools: Give yourself a project. I’ve forked the Pet Clinic project to test on. So if I had a new testing tool to discover, I could use that project to test everything.

Use the same project over and over but keep improving your project. So if you have a new branch of something new to add to your mind map if you like, you won’t forget it the next time you are discovering a new tool or framework. Every person figures things out differently but I tend to figure out stuff by doing mostly.

Hands on work is probably the best option in most cases. Perhaps before your start, search for someone who can give you an introduction and you don’t get overwhelmed at the beginning.


Are you asking how to work things out using tables/flows/mindmaps, or are you asking how to work out things like tables, flows and mindmaps?

If it’s the former, then that’s a really big subject and it’s dependant on a whole lot of stuff. What are you there to do? What do you need to show that you’ve done? Who are you doing it for? Who are you doing it with? What resources do you have to help you? What are you doing it to?

You need a plan. A plan guides your project, using a strategy (how you’re going to test) with your logistics (the resources you have and how you’re going to use them to do your strategy).

So based on the context I’m working in, the challenges I have identified, for the mission that have and for the purpose of meeting the needs of the people involved and their requirements, I get myself a practical, informed, product-specific and risk-focused strategy.

One generic way to go about it is to start blurry and get sharper. Start with what the thing is supposed to do (why it exists at all). Follow up by learning what exists in the system - what is there to learn about? Then learn what those things are, what they are for and how they might fit together. Then you can think about all those things and problems they might have and how to look for those problems, or whatever other thing you’re expected to do.

It’s a question that needs scope. The question “How does this login page interface with the database?” and “How does Twitter work?” are both working things out, but at vastly different scopes. I can write a diagram of database calls in a timing diagram, and I can write an overview of Twitter’s tech stack at a high level, so written stuff is just representing some abstract, high or low level.

If it’s the latter - well those are artefacts written by someone. I’d ask whoever wrote it.