Ask HN: How do I get better at creating well-reasoned arguments?

I mostly rely on an internal feeling If you are like most people, intuition is really mental shortcuts you have developed over time. There is nothing wrong with mental shortcuts as long as you reflect why you feel the way you do. By reflecting, you will distill your thoughts into a few core principles. For example, software should be scalable (can easily accommodate thousands of concurrent users) and should fail gracefully (failure should be limited to the direct user and should not negatively affect all users). You have to be able to repeat these talking points over and over again, so that everyone knows where you are coming from.

participate coherently in oral discussions? In an oral discussion, you have to first help the other person present his arguments. Then you can rebut. This means you have to ask clarifying questions. (1) what do you mean by this term -- please give an example? (just because you two use the same word doesn't mean you are talking about the same thing) (2) help me understand why you think X? (what is his basis for saying X is true) (3) help me understand the consequences of X? (what is his reasoning for what happens if you choose X).

Throwaway here...

Just wanted to say that I identify with this issue a lot. Intuition and exploration feel very key for me as well, and I think despite it mostly working ok for me so far, it adds (a ton) to the feeling of Imposter Syndrome I have.

"You can imagine how problematic this thought process is for active oral discussions" -- this hits home for me so much it hurts.

Thank you for writing this. I'm looking forward to reading the responses here.

> It is only through writing down my thoughts that my argument gains clarity.

Start writing a daily journal... it is a huge help in clarifying your thinking in all aspects of your life.

Also, do a search for Lincoln & Euclid. Early in his law studies Lincoln took a break to study Euclid's Elements to learn how to reason and demonstrate an idea clearly. You probably don't need to slog through The Elements (but that would be great) so check out TheGreatCourses.com for some good basic lectures on mathematical reasoning, the older the better. I bought the Dunham lecture "Great Thinkers, Great Theorems" and it is excellent. He walks you through simple proofs such as proving the Sqrt[2] is an irrational number and much more.

NB: Don't pay list price unless you can afford it or can't wait. Most items regularly go on sale at signficantly discounted rate. I got the GT,GT lectures at a discount because I found it posted to YT and emailed them to alert them.

- Argue against your position: similar to "reductio ad absurdum". It often is easier to argue against a position and demonstrate the invalidity of these arguments, than it is to argue for a position directly.

- Write down your thought process, let people submit pull requests for bug fixes or improvements. In other words: share your reasoning process and let others poke holes in it or run with it. The resulting conversation will be a draft for the next iteration. I often share something like a "Here is what I think, and here's why I think it's true". Conclusion and premises. The questions and remarks can shatter a premise, or shed light on an assumption and my whole argument can crumble, but I want that. Imagine if people building bridges relied on "gut feeling" and forewent testing. Testing is the willingness to see what you built be destroyed in a controlled environment so it doesn't in normal operations. Testing code, testing rationale, testing a bridge, testing an electronics design, etc.

One accelerant of this is the following: Imagine you won't be available for two weeks starting tomorrow, what would you want your team to know that you consider most important. Write those bullet points, expand on them, share them. What would hinder the team's progress if you didn't communicate it?

Writing things down also allows you to diff what you think, which is not obvious if it's continuous. Going back to what you wrote three months ago is humbling, as you may have learned new things.

One of my routines is going over our backlog and asking: "What was true a week ago that is not anymore?". We document the rationale in our issues so we clearly see what really isn't true.

For example: we're doing X because Y. Y can be the fact that a third party library or another part of our system simply cannot do Z (reference the issue and the conversation, not just "I think it can't do Z"). A week later, Y could change and X is now possible.

If we don't do this, we'd have to carry it in our heads with a gazillion other parameters or, worse, continue thinking Y.

One other advantage of this is that teammates can look at something, and decide or act by themselves because the reason we did not do that isn't because Jugurtha said so, but it's because Jugurtha thought so based on X, Y, Z that are documented, and are not true anymore. I can't count the number of times a teammate ran with something because they clearly saw an opening, because the thought process was documented, and could act on their own...

I think someone else has mentioned this, but regular writing is a big help.

Secondly, as uncomfortable as it is, replay conversations where you know you did poorly in your head, and perhaps write the better version out.

Many people find writing a great help here. And you say it works for you! Try to structure your involvement in discussions so you can prepare more. Some suggestions:

Anticipate things that will come up in a particular meeting/conversation and write your thoughts down beforehand.

When you feel really strongly about something in a conversation, don't start throwing arguments at the wall. Instead, describe your high-level concerns as succinctly as possible, and ask for an opportunity to get your thoughts together and email or discuss the next day.

Pay attention to recurring themes, and write about them, the next time they come up you'll have cogent points to make.

These won't work all the time. I suggest trying to move the needle on a few things you care about.

if you dont have an argument other than gut feeling and experience, just tell them. chances are they dont have anything either.

The best way to deal with questions like this is often practice. You may well already have the ability to form the well-reasoned argument (achieving a PHD is evidence of this) but finding the words in a timely manner - especially during an adrenaline-fuelled debate - is difficult.

I would recommend trying to find a regular spot in your routine where you can spend a timed 10 minutes doing an exercise of your own choosing - and record yourself on your phone doing it. For example, you might spend a week with the exercise "Pros and cons of a technology". Then speak to the camera and write out the lists.

For example, one day you might choose PHP, and decide to be against it - so you would write

Cons:

Poorly designed

Leads to terribly written programs

Lack of decent security patterns

Pros: - each having a counterpoint, because you've decided to be against it.

Ubiquitous (but rubbish that everyone uses is still rubbish)

Good documentation (it needs to be because it's so hard to write well)

Good online help (though also poisoned with bad advice)

Keep each line 10 words or less, and if you find yourself becoming incoherent, strike through the line immediately and move on to a different pro/con. Don't be disheartened if the first few goes at this are all crossed out lines!

Don't feel you HAVE to watch back the recording - it's simply there to provide artificial pressure, and can often be useful when things go wrong as a kind of post-mortem - why did I start to stutter there? What words could I have used to better convey my point? How did that look from someone outside my head?

The key here is to practice your arguing skills, pressure management and multi-tasking - not to improve your knowledge - so use topics you know well and start with viewpoints you hold yourself. As it gets easier, try to flip to the opposite viewpoint, e.g. argue that PHP is the best language, and try to argue that. Then, try to come up with new challenges for yourself that work on the key weaknesses you've identified in yourself.

Once you feel you're getting the hang of it, look into joining a local debating club or public speaking club. Many exist, with vastly different flavours - and having a real human being on the other side of your argument will notch the difficulty up a bit, but in a supportive environment. And often you'll get good feedback on your technique.

Lastly, remember that most people are secretly socially awkward (especially in Tech). Some of us present a better facade than others. Don't be scared to take a deep breath, or say "I'll come back to you on that", or ask "can you reword that as a question?" and write the question down to deal with later. This is a difficult skill that we're not evolutionarily designed to excel at, so cut yourself some slack and build your personal heuristics. You can do this, but it takes practice. Good luck!

Learning to argue both sides can help. One of the reasons I'm (fairly) good at persuading people or at least expressing my rationale even if I fail to persuade is that I have long practiced the counterarguments in my head (and often with others). It helps that I was very introverted and introspective as a teen and college student. That is, I don't start from a position of "I'm right" but a position of "What if I'm wrong", and then work towards a set of arguments that either go against my initial position or sufficiently justify it. At that point, I feel comfortable presenting my ideas to others.

With enough practice, this becomes something you may be able to do on the fly. If you're a relatively slow thinker (I often am), it can help to set the pace. Make enough noise when you're thinking something through that others can't steamroll over you.

--------

Learn to express your assumptions. If I go into a design meeting and I say, "X is good and how we should do it." I should back that up with my assumptions. "We're targeting an embedded, resource constrained, real-time system so we should use an appropriate language that gives us tight control over the runtime and memory usage. Therefore, I recommend we use C, given that our team is very familiar with it."

--------

A reason for stating assumptions is also that many debates are based on a misunderstanding. You're arguing against each other's positions because you enter with different assumptions. Using a real experience: A colleague strongly objected to the use of recursion in programs. When we finally worked it out, it wasn't that he didn't like recursion full-stop, it was that his experience was almost exclusively with real-time, embedded systems where recursion was avoided for good reason (along with things like heap allocation). He'd internalized so that it was almost a reflex to be anti-recursion. Once we were able to realize why he argued against recursion, though, he was willing to relax his stance given different circumstances (writing desktop applications, or similar environments with relatively few constraints).

If you state your assumptions it gives people a better chance to realize where you're coming from. And then you can start asking for theirs. Though maybe not using the word "assumption". Ask "why": "Why do you object to inheritance ever being used?" or the counter position "Why do you want a 20-deep inheritance hierarchy?". What about either of those positions makes either the design or the maintenance easier or harder, what are the trade-offs. Maybe they selected a design based on ease and speed of implementation, or ease of testing, or ease of maintenance. But each of those can have tradeoffs with the other so get them (and answer this yourself, don't just expect others to answer these) to state their priorities. Then, even if you lose the final argument, you can at least understand why a decision was reached (difference in priorities, different in experiences, whatever).