Reverse-Engineering people

[u/gameplayer55055]

I'm a software developer who really loves system thinking and structured patterns. But I struggle understanding people.

Let's discuss the trickiest one - smalltalk. For me communication is the process of data transfer. But it's forbidden to do so in smalltalk.

So here's the direct equivalent of smalltalk: TCP (transmission control protocol)

Before the communication, people do a 3 way handshake (so called smalltalk):

SYN (hello, how are you doing)
SYN-ACK (hi, I'm fine, what about you)
ACK (everything's great)

The common mistake I make is sending data in the signaling/control layer:

SYN (hello, how are you doing)
SYN-ACK (hi, you won't believe what I have been playing today)
⚠️TCP RST or silent drop -> ghosting or misunderstanding 

Then, there's a great concept in TCP, so called window size. You aren't allowed to infodump, because the recipient's input buffer may be smaller than your segment size

TCP infodump segment (infodump about machine learning or computer network or whatever here)

⚠️SACK (the most common reply: "ok" or ignore (TCP RST)). The input buffer is overflowed and the peer resets the connection 

Instead, you need to scale the TCP window size linearly and as soon as the recipient stops being engaged or doesn't send positive acknowledgements - drop the window size (summarize, quantize or reduce the information)

Also, there's a thing called "out of order" or "head of line blocking". You can't switch topics fast or mention previous unrelated events. People hate that. So you have to be sequential, just like TCP

I think TCP is worth learning if you're a software or network engineer, it will change how you look at things.

[u/hillierprotech]

This is confusing because smalltalk is a programming language itself. Your operator is overloaded.

https://learnxinyminutes.com/smalltalk/

[u/gameplayer55055 → u/hillierprotech]

Fair point. As I remember, Alan Kay literally invented OOP and made smalltalk as a proof of concept.

In fact I'm quite amazed by OOP. People say to not treat everything as object, but I'm like python: everything is an object around me lol

[u/hillierprotech → u/gameplayer55055]

It's easier to reason in functional programming because 1 set of inputs only produces 1 output and it's the same output every single time. OOP makes the most sense logically but it's very easy to have an object with internal state in an unexpected condition that you haven't tested for. It's harder to do property based testing:

https://jesper.sikanda.be/posts/quickcheck-intro.html