[silveroriole]

This is why I can’t do meetings. Like the article, all I end up saying is “I don’t know.” I get battered into agreeing with the other person in the meeting because I can’t debate with them off the cuff, and it’s like social interaction uses up 100% of my brain and leaves nothing for me to think with. I only ever manage to form an opinion after the meeting is over, or I end up not hearing 90% of the meeting because I was still thinking about something from the beginning of it. If you ask me a question verbally and expect an instant answer you’ll end up wondering whether I’ve even seen a computer before. It sucks.

[wruza]

My rule of thumb is to turn your doubt into a question with experience attached to it. E.g. when someone says “there’s an API for that, it should be easy”, I note that not all APIs are equal (enumerate examples) and it must be reviewed before we commit to deadlines. And until that we must assume it’s not “easy”. Ask if research was done and whose responsibility it would be. If it wasn’t, then why we decided to meet. Hanging responsibilities onto dangling tongues explicitly makes them dangle less.

How hard to push back depends on the nature of discussion. Being too pessimistic in a research phase is not useful. But if it’s a contract worth half a year or more, spending few days evaluating assumptions is wise.

Remember that fast thinking is not actually fast, but shallow and/or optimistic.

[hammock]

>fast thinking is not actually fast, but shallow and/or optimistic.

Sometimes fast thinking is fast. If you have mental models that the other doesnt, and those mental models are good in the limit of the context you’re in, it’s faster.

Of course if you both have the same mental models, or the models don’t work in the limit of your context, then more time lets you think deeper. Take chess. Two players in a 1min bullet game (mental models very applicable) vs two players in a 20min grandmaster battle (better to take time and think deeper)

[madelyn-goodman]

I really like this point, that fast thinking is shallow. I think there should be more respect for having to think deeply about things and process before coming to conclusions. I think that is more of a sign of intelligence than just responding to something right away.

[Jensson]

Answering quickly or thinking deeply first doesn't have much to do with intelligence, some smart people answer quickly and other thinks first. It mostly have to do with how much you care about being right, if you are deeply afraid of being wrong you will think a lot first before answering since you prefer spending all that energy over being wrong, while if you don't care you just answer now and think later.

Speaking before you think makes you look dumb, but it doesn't make you dumb. You see the difference? You might have met many such people who were smart, but that you identified as dumb since they weren't afraid of appearing dumb.

[lamontcg]

Lots of people used to think that Obama pausing for thought meant that he was taking time to cook up lies in his head.

Skilled liars are usually quick though because they're not considering if something is correct or not, they just need to figure out what kind of thing to say to make you agree with them.

[motbus3]

I tend to agree that thinking models are per se shallow. But I don't even believe much in thought models to be honest. I believe they are just heuristic for decisions and do not constitute the whole thinking process itself. But maybe I am wrong

[posix86]

I don't think you can generalize like that, at all.

A better sign of intelligence is knowing when thinking deeply is in place. And most often it's not. Most often it's more cumbersome to think for a long time than making the occasional mistake.

People that think long & hard about everything don't have their priorities right.

[JohnBooty]

Again, it really depends.

If you're doing a research or fun project, where failure has no consequence? Then yeah, mess around, move stuff, go fast, break things. Worse is better.

There are so many situations where there are, consequences, though. Either because failure is pretty dang bad, or (perhaps more commonly for our industry) a mistake will increase our tech debt. Our failure to spend a few extra hours thinking it through in the short term might lead to hundreds of hours of tech debt or (in the extreme case) our entire project/company to fail in the long run.

[posix86]

Duh, that's my point.

The previous comment seems to suggest that a sign of intellice is taking time to think, in general. I'm saying a sign of intelligence is knowing when thinking longer is worth it. Some people take their time every single time, and I wouldn't say that this indicates that they're smart...

[mattlutze]

The chess example may though count as "shallow" thinking, in that your quick games are pattern matching out of experience without much time for deep or self-reflective novel analysis.

[tsunamifury]

I’m sorry but in a practical corp environment this is a fast track to be fired. You become the person constantly in the room enumerating edge case doubts that aren’t often even relevant. You map the blockers vs the opportunities and end up focusing the team on them.

The goal is to avoid blockers, not enumerate them uselessly.

Can it be done? Yea? Sure ok then let’s figure it out. The million ways it can’t aren’t relevant.

[albatross13]

I love this line of thinking, it's how old companies I worked with developed entire rest APIs using only AWS Lambda and after sinking tens of millions into it they abandoned it :)

CAN IT BE DONE? OH YEAH!

[robofanatic]

at least now they know that it can't be done

[tsunamifury]

But this is the classic engineering mistake in how they communicate. They replace “why should we do this” with “we can’t do this” and it leads to the same old stupid conversations with eng who are probably pretty smart but have no self awareness of their communication failures

[KineticLensman]

> Remember that fast thinking is not actually fast, but shallow and/or optimistic.

Q: What's the difference between a novice and an expert?

A: The novice thinks twice before doing something stupid.

[Jensson]

Iterating on mistakes until it works is how most do programming, so yeah doing that faster is what experts do.

[JohnBooty]

Software development as a whole is iterative, but you don't always get the chance to iterate on individual things.

If you and I are working on Project Blahblahblah with a team of 20, sure, we're iterating that. But the crazy bad, hacky, barely-works spaghetti code I crammed in there for feature ABC? It might be a long time until we get to iterate on that particular ball of tech debt.

I think maybe that's why I'm burning out on this industry. It's ship, ship, ship, new, new, new and never a chance to iterate for quality.

[Infernal]

My name for this phenomenon in meetings when you have people "battering" you into agreeing with things is Bullshit Chicken. Chicken being the maybe apocryphal "game" of driving head on in a car against your opponent, with the loser being the one who swerves first. Bullshit Chicken being the meeting where whoever spins enough bullshit without swerving wins the "debate". I suck at Bullshit Chicken because I'm still trying to wrap my head around the first bit of bullshit (just an example from elsewhere in the thread "There's an API for it, so it'll be easy") and the bullshitter is on to the fifth point already.

Related to Bullshit Chicken, the bullshit asymmetry principle[0] - that it takes 10x as much time and energy to refute bullshit as it does to create it.

[0] https://en.wikipedia.org/wiki/Brandolini's_law

[Jensson]

And if you manage to refute all of their bullshit all that usually happens is that they get really angry and you get fired for not being a teamplayer.

The winning move is to make friends with leaders beforehand so that nobody dares refute your bullshit, or if you didn't do that then don't play the game.

[100011_100001]

If it's a small meeting I will say, "Give me a moment, I'm thinking". Even then it's faster thinking than I would like.

If I'm forced to answer something, the more significant it is the more of a caveat I will make. Something along the lines of "Right now, I think X would be fine, I'm worried that Y might cause problems. I will look at the code and let you know".

Then I always make sure to reply in an email to say for our conversation on X, I looked at Y, I found this, and also realized that Z will be affected. I'm basically buying time, the key, at least from my perspective is always going back and answering properly.

[au8er]

From my experience, saying "I'm thinking" actually makes it worse. Instead of thinking for a response, I internally start to panic (mainly thinking whether I have considered everything and the response is correct). After a few seconds of "thinking", I eventually give a response that is no different to my knee-jerk reaction.

I do find replying with an email to be extremely helpful. Even if the response is not correct, it does show you have put in the effort to reflect on the meeting after it has finished.

[magicalhippo]

> After a few seconds of "thinking", I eventually give a response that is no different to my knee-jerk reaction.

In interviews with Magnus Carlsen and the other top players, they all seem to say the same thing: the big difference between a short game (bullet/blitz) and a long game is that they'll have more time to verify the move in the long game. They don't spend more time finding the move.

I find this resonates with me. Very often the instinctive solution I come up with on the spot is often a very good solution and requires only minor tweaks.

> I internally start to panic (mainly thinking whether I have considered everything and the response is correct)

I just add a caveat: "I think X is a good solution but I have not had time to consider all the edge cases, so I will have to verify and come back to you" or similar.

Or, if the problem is complicated I'll just say that: "There are a lot of complexities/edge cases to consider here, I need to think more thoroughly about this. I'll get back to you later".

[8n4vidtmkvmk]

It's usually easy to iterate the possible solutions. Widdling them down to the best one is the hard part. Still, it helps to write them out. And if you're in a meeting, you should maybe just stop there and then write an AI to rule the bad ones out. (Which of course we could have done without a meeting, but I digress)

[8n4vidtmkvmk]

> I will look at the code and let you know

I used to do that. Now I just say "Look into X, Y, and Z, I think they might pose a problem" and let them do the research. I can't solve everything for everybody. If it's not my project, I'll give you some pointers, but not hours of my time.

[cratermoon]

I take inspiration from the portrayal of Dr. Legasov's respond to being challenged to explain how an RBMK reactor explodes. "I'm not prepared to explain it at this time". It's OK say, "I don't know yet, but I will find out", even at the most tense moments in a devastating catastrophe. I argue that moments like that are when it's most essential to pause and consider carefully.

https://youtu.be/AQ2g3l0U94g?t=116

[kqr]

Role models are useful! An acquaintance worked as a (somewhat) low-level volunteer at a (somewhat) large sports event. These things are run according to a schedule that is detailed down to the minute, but my acquaintance determined it was unsafe to send the competitors onto the field due to a screw-up by the organisers. (Concurrent event close by occasionally spilled over.)

Despite enormous pressure, he remained firm in advising the competitors to stay inside until the problem was fixed. And they did.

It reminds me that if you're not an ass, and a team player normally, and essential to the operation, you have a surprising amount of leverage even under pressure, and when your formal authority is low. It's okay to politely say "not now" until you're actually ready.

(The difficult bit is, as always, knowing when you're in the wrong!)

[cma]

Isn't that different? His reason for that was be had info on why the reactor was made that way that was considered a state secret.

[cratermoon]

As portrayed in the film (and who knows in real life), he only knew there was a flaw in the reactor design; he didn't know – with certainty – that the flaw would lead to an explosion. Under those circumstances, with that kind of uncertainty as well as the classified nature of his knowledge, I consider his answer is even more impressively measured. Anyone savvy about the KGB and the Soviet nuclear power industry would see the red flags go up and drop the line of questioning immediately.

[oxmane]

I think there are a few other issues with meetings except for just fast thinking. Some things I tend to better understand when written down. It also allows you to search for additional context which is harder to get in a meeting (it could seem as derailing the meeting). Another thing is just timing and energy levels. You're not your 100% self in a meeting, but you can choose when to review something offline, and answer accordingly. OTOH, I admit that meetings do spark some ideas from a back-and-forth quick exchange, which otherwise might've been missed, or would've taken long to get to.

[itissid]

For most people(junior and midlevel), there are two kinds of meetings: 1. Where you seek to get some information that is non trivial to ask on slack or at a water-cooler. 2. You are asked to contribute information that you already have.

Everything else that requires thinking and is a follow up, i.e. you can delay it(probably on slack of lunch or 1:1).

Also always try recording a meeting(minute big ones or voice record with consent to go over later). Forgetting and misremembering the facts a day or week later is probable.

[jrs235]

>Also always try recording a meeting(minute big ones or voice record with consent to go over later). Forgetting and misremembering the facts a day or week later is probable.

And if you or someone didn't take minutes or record it, followup with the participants in an email memorializing what you took away from the meeting and correct you if you misunderstood or forgot/left anything out. Sadly this is a bit of CYA (Covering Your Ass) but can help when questions like "who choose to go with that solution route and why?" arise weeks or months later.

[specialist]

"That's a really interesting idea. Hmmm, it's worth checking out. I'm really busy working on [hyper duct work over modulator], so gimme a few days to try some things. I'll get back to you, whatever I find. Thanks for speaking up!"

Always praise the suggestion. Diplomacy beats correctness in such situations.

Most often, whoever is in charge of the schedule will push back for you. Can't risk the deadline every time someone has a goofy idea.

[gardenhedge]

I feel like this is culture dependent. In my country and workplace, praising like this would uncanny.

[8n4vidtmkvmk]

> You are asked to contribute information that you already have.

Just ask me the things you want to know over chat or email. 90% of the time I have to look something up. Do you want to sit and watch me as I poke around for answers? Or do you want me to recite answers that I'm 70% confident on and then try acting on that?

[marcosdumay]

Recently things got so bad that I have started to simply tell people "Hum, I can't (decide on this | solve this problem) in a meeting. If possible, can I give you the answer first thing tomorrow?"

Some powerful people insist on the meeting anyway, always with disastrous results. But it's enough to not distress myself trying to make it work.

And yes, it's mostly because I can't think during a meeting. Very often I have an answer as soon as the meeting finishes.

[skylanh]

This issue has come up in the past on other forums, I think one of the answers that I identified the most with was saying:

"I'm not sure I agree with that, and I have a few significant concerns. I'm not comfortable agreeing at this time. We'll have to take this offline and come up with a well-formed (answer, options analysis, options assessment)."

You can also try to push back and ask for an option analysis or position assessment: "I'm not sure that the details are clear on this. Can you provide a (proper) option analysis on this position?"

In this case bureaucracy is your friend.

[BiteCode_dev]

+1. "Let me go back to you" and "i don't know" are sentences people should use more IMO.

[8n4vidtmkvmk]

Then they respond, "Sorry, I've already started coding this up. We want to dog-food it by next week"

[varispeed]

I used to struggle with this as I am exactly the same.

I just say at the meeting that it's something I need to process and that we should not make any final decisions. I sometimes don't say anything if I think it is not important.

Usually there is no problem. That being said I had a fair share of workplaces that hired bullies, so then I rather quit than fight. Life is too short and there is plenty of job offers.

It helps to take PM or someone else in charge aside and talk about this and neurodivergence and ask them to be more accommodating. In many countries, by law, they are required to make reasonable adjustments for accessibility.

[boringg]

The kicker is that after the fact you've walked through all the mistakes of the debate but its now null and void.

It's almost like George Costanza (not a great comparison to be fair) and the "jerk store called" joke episode.

[robofanatic]

I hate the kind of meetings where there are couple of smart guys, very experienced in a specific domain, talk about a complex concept in few abstract words and talk among themselves knowing that no one else is understanding, and you are not at a level where you can stop them and ask them to unpack what the hell they are talking about and take a whole lot of time from the meeting to explain.

[motbus3]

Same here. Usually I am randomly picked for conversations that I was not aware and people ask me an opinion on that.

I think I've made myself numb to feeling something for my opinions but I would prefer to stop and think for awhile. What the person is asking? What the person is really asking? Why is this important? What are the consequences? What are the pros and cons? Etc etc. All the questions come to mind instantaneously but none of the answers.

So people go along with those who sounds more convincing. After some time if I come back with a major problem on the process of thought people judge me as being envy or too late for helping on something.

I feel detached front reality l. Even more lately. It seems everybody has a ready-made thought about everything and only I need to take time to think.

[beebmam]

Can't you say: "I need to think about it for a bit before I commit"?

[analog31]

Ha ha, you just committed... to thinking about it. If you're the only person in the room who requires this kind of thinking, then you just committed to all of the tasks. Moreover, you've also tacitly accepted the burden of proof.

I've been there, which is why your comment caught my eye. I learned some strategies for dealing with the issue, but of course that learning came with age and stature within the organization, so YMMV. The best is to get agreement that analysis is needed, but delegate it if possible. Some examples of better responses:

* This needs some quantitative thinking before we commit

* One of the engineers can do an analysis

* I could mentor somebody on how to do this kind of analysis

[zmgsabst]

“That’s an interesting idea! — why don’t you write up a quick wiki entry and we can review it after standup/at the next meeting?”

I see several of us have played that game over the years.

To be fair, sometimes the answer was that I was being grumpy and it was a great idea — which I learned by reading the wiki entry. And the junior engineer learned to sell their idea in writing. Which means even when you “lose”, you still win at being a good senior engineer.

[8n4vidtmkvmk]

Wiki entry. Interesting. We write Google Docs for everything. Never thought of using wiki for researchy/planning stuff. Wiki is for "We've thought about this, and this is everything we know"

Docs are for "This is what I'm planning. Here are our options. Add your comments to the sidebar". Once you've ironed out the kinks and implemented it and wait a few years for it to start slipping from your collective minds then you cobble together the remnants into a wiki.

[gardenhedge]

Here's some advice that may help you:

* Every meeting should have an agenda

* If there's an expected outcome from the meeting then all participants should be aware of that

* All estimates should be brought back to your team after being discussed

[samstave]

Interestingly, this is why I attribute my self as a "Social-Kinetic-Learner" - meaning that I learn best in a social and kinetic (meaning doing) manner.

I am a slow thinker when alone because ADHD, thought-tangents-based-on-material, too-theoretical text based rote learning, and getting stuck at small hurdles where I dont have anyone to coach me through an issue.

But I thrive in meetings, design sessions, projects with others and am a very fast problem solver and thinker.

Its why its hard for me to learn new things alone.

[mmcnl]

No one can do meetings effectively like this. This is why I always suggest to participants to prepare upfront and use the meeting time to make decisions and not deep thinking. Also I try to never let myself be pressured into a decision without deep thinking up-front.

[nice_byte]

what I do in similar situations is drag them down to my level. make the other party explain themselves and break the idea down into smaller and smaller bits until you can process everything. sometimes this actually helps _them_ see the error in their judgement that I didn't even know was there.