How to understand any problem more effectively?

First answer the question: what would be an indication of understanding? i.e. how would you show comprehension to yourself or others? Perhaps it could be by adding a log statement, fixing a bug, or being able to write a paragraph in your own words about the problem.

Having a clear outcome defined is a huge helps since it orients your work. Once you have that, then create a version of that outcome. Relieve yourself of the burden to make it good. In fact, I tell myself "I just want the most ugly/horrible version of a fix imaginable, and then I'll improve it."

(This is why 'done is better than perfect' is a great slogan!)

Related: Fighting Perfectionism as a Software Engineer (and getting important stuff done)

Preface: I'm interpreting this question as "I don't fully understand the problem I'm trying to solve" rather than "I don't understand how to solve the problem". Please correct me if I'm wrong!

People understand everything in terms of deltas. In other words, the most powerful way to understand a problem is to make it clear what the before state is and what the desired after state is. Here are some examples:

• You are fixing a bug - Have a video of what the bug looks like before. This should generally be enough as the broken behavior should be obvious, but if it's not, get a video of what the working flow looks like.
• You are adding a feature - This one is trickier as the before state is effectively nothing (i.e. this feature doesn't exist yet). In this case, try to understand things in terms of user value. What user need is being fulfilled by this new feature? What would the user desperately try before without this feature? At Instagram, we had a framework for this called JTBD (Job To Be Done).
• You are improving a process - What were teammates doing before this process was improved? Where were the pain points? My case study about revamping oncall is an excellent example of this: [Case Study] Revamping Oncall For 20 Instagram Engineers - Senior to Staff Project

If you aren't getting this information in your tasks/tickets, you should ask for them and work with owners to fill them in. Talking with your tech lead/manager/product manager to disambiguate tasks is a great sign of seniority.

If you're front-end, outlining the delta should be incredibly easy as you can attach images, videos, and general designs. If you're back-end, you need to be more creative, but you can still attach things like desired API outputs. A lot of the tactics/advice here is similar to my lesson about test plans: https://www.jointaro.com/course/level-up-your-code-quality-as-a-software-engineer/have-a-test-plan/

Lastly, it's possible that your slow understanding stems more from your personal mental state as opposed to needing some sort of mental framework or more information in the task. In that case, I recommend following general productivity advice (sleep well, get good exercise) to focus your mind: [Taro Top 10] Time Management And Productivity

Personally, I struggle with comprehending problems, whether they are coding or business related. I often need to read through the problem multiple times to fully understand it

There can be comprehension issues when it's hard to connect the problem to some context or goal. If you aren't able to do this, it's easy to just passively read something but not grasp it fully.

It helps to have higher company goals or principles in mind as you read through a problem. As you read through the problem, you can think more critically about whether the problem can solve a higher level goal or whether it distracts from the higher level goal.

My crutch for problem understanding - "Can you describe the before vs. after state?"

I've rarely seen things go wrong when all parties are aligned on the before vs. the after.

The solution is the bridge we need to cross, which is usually relatively simple and obvious once the start & end are well-defined.

Illustrate the before-after, and present your understanding to your stakeholder BEFORE starting any work.

• What WILL remain as-is (forcing function to ensure the current state is fully captured)
• Specify what WILL directly change
• What MAY change as a second-third-order effects

I've been burned countless times in consulting when we don't do this. Simply listing out the scope and tasks you will perform to solve the problem isn't enough since it doesn't clarify expectations or what's actually desirable.