How do you get good at understanding and communicating technically?

Alex covered in plenty of detail how to ask questions and that is by far the best way to learn things quickly, because it typically leverages other people's knowledge! Do this when possible.

That being said, I'm interpreting your question and followups as you being interested in how to better understand and learn about complex technical concepts (sometimes on your own). For this, I want to share some personal tips that might be able to help you.

What does it mean to understand something?

Before we dive into how to better understand things, let's define what it means to understand things, and what it is not.

I believe that understanding something means being able to describe it relates to everything else. In other words, it's about understand the relationships between a concept and nearby, relevant concepts. This question/answer on Quora does pretty good job giving an example of what I mean.

Understanding is NOT having the memory of a fact ("Knowledge"), especially if you can't make use this fact to make any predictions. You should never have to memorize anything you have understood.

Understanding is NOT blind intuition either - how you feel about something could be totally wrong, especially when you have yet to study it in depth.

How do you then gain understanding of something?

So if you struggling to understand complex technical system(s), I suspect you might specifically be struggling with connecting what you are learning about with what you already know.

I see this happen all the time when folks are assigned tasks about systems they are unfamiliar with. They sometimes jump straight into the code or detailed design documents of the target systems, gets overwhelmed by the irrelevant details, and end up feeling really bad about themselves.

Instead, I recommend doing exercise by listing (1) what you already know about the target system, (2) and how it is relevant to something you already know. Maybe the target system is downstream dependency that a service your know well call can via a certain API. Maybe the target system is very similar to something you've seen before, from another job or school. Start exploring from there.

People do this all the time. Sentences like "Lacrosse is like soccer, but with sticks," or "Typescript is like Java, but with functions as first class objects" help people position a system in relation to another system they already know. So as people learn about typescript, or Lacrosse, they will keep comparing/relating it to what they know and learn by applying from concepts from one to another.

Another way to visualize the process of learning as a graph search problem.

You are at node A, and you need to find the shortest path to node C.

Jumping straight into the target system's code or docs is like sampling random nodes surrounding C, and trying to figure out if it's part of your shortest path. Bad idea - you will probably waste a ton of time computing paths that doesn't lead you anywhere. At best, you will end up with isolated islands of facts about the target system that doesn't help you predict how it will behave since you are unlikely to understand the principles with which it was built with.

Instead, start with where you are - at node A, and examine every node related to it that gets you closer to node C. You may still dig into details of the systems along the way a little bit, but only pay attention things that gets you closer to your goal. Ignore everything else. (I think this basically A* search, which is fairly good algorithm for solving this type of problem.)

I hope this helps. Best of luck!!

Understanding and communicating are connected but are 2 fairly different things in the end. A common case I've seen among software engineers is that they're great at understanding (they're naturally intelligent and their brain works fast), but they're awful at communicating (usually spouting way too much context and obscuring the core points). Because of this, I'll split up my response into 2 parts.

Understanding

Improving your technical understanding largely revolves around asking good questions and really taking advantage of meetings. Here's some resources for that:

• "I struggle to come up with things that add value to a meeting - What do I say?"
• Asking Effective Questions That Get Great Answers Quickly
• How To Actually Learn Software Engineer Skills

Communication

I actually think this one is a lot harder. Understanding is largely a problem concentrated within your own mental space (i.e. "How can I process the information in a way that my brain can break down the core ideas?"). Communication is fundamentally tricky as there are infinite permutations based on who you're talking to. A communication style that works with 1 person might not work with another: This is something you always have to aware of, not just as a software engineer but as a person in general.

That being said, here are my recommendations around improving at interpersonal communication and technical writing:

• [Course] Effective Communication For Engineers
• "How to improve on non-technical skills like writing Software design document?"
• "How to get more visibility on work?"

Asking good questions also requires a good understanding so this is fundamental...

I would actually push back on this a bit. It's true that having a good understanding of the overall problem space lets you ask more pointed, higher-quality questions, but I don't think it's necessary to have a good understanding of something to ask good questions about it.

Let's take a common example: Onboarding into a new codebase. When I'm doing that, I will more or less ask someone: "Hey, I'm new and I have 0 idea what's going on. 😅 Can you give me an ELI5 explanation of the overall high-level components in the codebase and how they interact with one another?" This is a fairly blanket, high-level question stemming from my non-existent understanding of the overall system, but I can improve it with light-hearted delivery, a sense of self-deprecation, and a general aura of kindness when presenting it.

In general, it's good to ask questions, and the delivery of the question alone can make it good - You shouldn't feel pressured to demonstrate some very impressive understanding of the space before asking others for help and insight.

Do you have any techniques you use that help you organise your thoughts/thinking process and really be confident that you have a good understanding of the problem ?

Ah, this one's easy: I write stuff down. Generally manifests in 2 ways:

1. For bigger things - I'll write a system design doc.
2. For smaller things - I'll include the context in the task (Jira, Asana, etc) and in relevant pull requests.

Thanks for the detailed response!

Asking good questions also requires a good understanding so this is fundamental and I find that I often don’t appreciate a problem in its entirety specially as complexity/scope increases

The consequence is often getting called out on something important that has been missed

Do you have any techniques you use that help you organise your thoughts/thinking process and really be confident that you have a good understanding of the problem ?

Thank you for your help!

Great - thank you!

The best way to get better is simply to practice. How can you manufacture opportunities to practice technical communication?

• Setup a brownbag on a topic you know a lot about
• Write a post on the company blog or your personal blog
• Create a 2-3 minute explainer video on a programming topic