Today we are drinking a yellowish water.

What are you looking at?

What I wanted to talk to you about today is

How to communicate with a software engineer.

I'm guessing that you're probably like a software engineering manager.

You've been appointed to be one

and now you need to learn how to communicate with your own team.

You probably don't know how to code and you're way out of your league.

When you accepted your job, you thought that these would be like normal people, but they're not.

They are more like animals.

Some of you may be dating a software engineer and there may be relationship troubles.

You may find that communication is just difficult.

It is breaking down everywhere.

It seems like you are with a robot!

Others of you may actually be software engineers

and have trouble communicating with yourself

and you don't quite know how to

make sense of what has actually happened to you

ever since you've picked up this profession.

I'm here to help as an experienced, ex-Google software engineer.

Now, first of all I should note that it is quite amazing that

we are even able to communicate you and I

because I'm a software engineer and

You may not be one and even if you are a software engineer it can

Also be difficult for two software engineers to practically communicate with each other.

I took this amazing leadership course where we did an exercise.

Some of you may know it already.

It is called the True Colors exercise, in which, we categorize people as:

Green, orange, blue, gold.

Each person can be categorized as a color and there are different personality types.

Now this was quite an interesting exercise for me, because

I had always thought that humans were

fundamentally very similar and that they reacted very similar to one another,

were rational logical beings.

But, that is not actually quite true for many people.

Green is the color for most engineers.

They are very scientifically, rational objective people.

But, there's many other different colors.

Blue is very, touchy-feely.

Orange is much more action-oriented, leadership oriented.

Gold is more process oriented

and you'll find that everybody is kind of different.

Many people, by the way, do not talk to software engineers, period.

They will only communicate with a software engineer through a translator

otherwise known as like a software engineering manager.

And this is a pretty good idea, actually I would say. Because if you attempt to communicate directly

with a software engineer, you may accidentally offend them and bring their wrath upon you.

You might find yourself being hacked or stalked by software engineers.

Many of these people have not properly been

Socialized by our society and yet they exist.

You don't see them, but they spend a lot of their time underground in basements and garages

Coding away, communicating with machines, and much of the time we are protected from them.

Even inside companies, you might find that software engineers are relegated to a separate entire building,

where normal people don't have to necessarily

communicate with them or interact with them or even see them in any way.

But every now and then you may encounter one and I have a few tips for you

to protect yourself.

The first tip is to communicate with them using very simple If-then-else statements.

This is a language construct

used by programmers all the time and they will understand this.

So, phrase your sentences like this

Such as, "If you want lunch,

then, come to the cafe at noon.

Else, give me a call. End."

You can also use do-while statements for loops, like, for example, if your to say,

"While I am out drink some coffee."

The programmer might just keep drinking coffee in the repeated infinite loop, until you come back.

You might make sure that you're using very precise language and you're not using words like, maybe.

In code, it's usually just true or false. There's nothing in-between, it's binary.

Questions need to be answered deterministically,

which means that, the answer to a certain question should be the same every time.

If I say, "Do you want pizza?"

Then, the answer should be yes, today.

And it should be yes tomorrow.

If I ask the same question

and the answer is different each time I ask it.

Well, you know computers don't work that way. Computers always give the same answer.

If you were to change the answer you might offend the programmer, you might piss them off.

You want to leave your emotions out, if possible.

Engineers are trained in such that,

even in scenarios where they're banging their heads on the keyboard,

because a program isn't working.

There's no apologies, there's no emotions coming from the computer.

They've already been trained in the manner in such that emotions will get them nowhere.

It's going to be a mistake if you're expecting pity or sympathy

or and your sort of emotion at all.

It's really all going to be about, cold hard facts and

Similarly, when you're talking to a programmer, you don't necessarily need to show them

sympathy or pity either.

They're not necessarily expecting that.

You know you can just give them horrible news, whatever.

Whenever you start a conversation with a engineer,

You want to clearly define the inputs and the outputs of the conversation.

Unlike many conversations, where a lot of people are

reading in between the lines,

looking at unspoken words,

checking out the body gesture,

looking at the face for clues.

and

In a conversation with the engineer, you need to understand that

when you're coding, the computer does not read between lines of code to try to

understand some hidden message that's being written out there.

The computer is just taking a look at exactly what's

explicitly written out and that is what a programmer expects, as well.

So for that reason if you're in a relationship,

for example, you're not going to want the engineer to be trying to read your mind,

trying to understand what you're trying to say.

You just be very explicit and direct about it and so that's why I recommend that you use the words:

"These are my assumptions." "Here are the givens." "This is what I'm expecting."

"These are my expectations." "These are my assumptions."

"Given these assumptions, this is the conclusion that I am reaching."

And, you don't necessarily want to say, like, "Well, hey.

Do we want to go eat pizza maybe?"

No, that's not quite what you want to do.

You want to say,

"Given the assumption that you want pizza and I want pizza too. Then, we should go eat pizza."

That is very a clear, understandable statement.

A lot of people like to just grab a friend and go to a cafe and just talk.

You know, just talk about life.

Talk about things.

And when you think about it, you don't really do that when you write code.

It's not like an engineer will just decide to have a random talk with the computer

and just write a function that doesn't really do anything, has no purpose,

just spins a few computer cycles, burn some extra energy

uses some power and

there's a set of random inputs enters a set of random outputs.

You know coders don't quite do things like that so

It really helps if you're gonna have a conversation.

You define the output the goal the purpose of the conversation and do it

efficiently and effectively.

The time and space complexity of your conversation are the two things you're going to want to focus on.

The time complexity of your conversation has to do with how efficient your time usage is.

How quickly are you conveying your thoughts?

Are you going in circles,

repeating the same facts over and over again in different ways?

That's not efficient and you're just going through multiple passes...

Think about it this way, if your story can be

optimally told in 10 seconds, but instead you started deviating around

and talking about all sorts of random stuff and it took you 100 seconds to tell your story.

Then, that's like N squared time that you're using

You should optimally be using big o of n time. If you need to say the story twice in two different ways

That's maybe 2 n times. That's still ok, but you want to avoid going into say

polynomial or exponential time

That's like saying for each story you say, you need to go into a sub story

and for each of those sub stories, you need

to go into another sub story.

Space complexity has to do with how much memory you're using and

this has to do with..

If you need to tell a story,

And then ask the coder to remember things and you say,

"Hey, do you remember that time we did this? And the time we did that?

And then you remember 2 years ago this happened and..."

All of this is causing the person to have to keep track of many different things in their mind.

That's using up a lot of space. The less space you can use, the better.

And ideally, it's stateless.

Where you don't have to ask the programmer to remember anything or hold anything in their mind.

You just have a certain request.

There's nothing about recall. There's nothing about thinking about what happened yesterday.

Generally, efficient conversations are going to have a time space complexity of

linear time

constant space.

That's how many optimal algorithms there are.

If you need some more space, like you might get into linear space

that might be ok too, but you do want to prioritize your time complexity.

If you need the additional help on this, you might want to do some leet code practice.

Lastly, you want to think about the role of authority and you want to be very careful about

telling programmers what to do because the source of truth for a programmer

is not going to be you. It is going to be in the data, the matrix presented them the facts.

You know, an engineer is going to view you as just a body of bugs.

...potentially very buggy code. It's like interacting with a third party API.

Programmers are generally going to be very wary about

depending on the third party API for the function of whatever they're doing.

You know, this third party API can fail,

they're notorious for having a lot of bugs, being poorly developed.

Just having all sorts of random problems.

Well, that third party API is you and if you start just issuing out commands, telling people things.

Every piece of knowledge that you're dishing out, has to be verified and authenticated.

There's otherwise very little reason to trust that any of this information is going to be correct.

Most codes are full of bugs. Most people are full of bad information.

The other thing is, coders are generally the ones in the position of authority.

They're the ones dishing out the commands.

If a programmer makes a statement to you, you want to be very careful and

try to obey that statement if at all possible, because, if you don't

You know you can unleash hell upon yourself.

It is like a computer that is refusing to obey a programmers commands.

This just doesn't happen, in general.

I don't know what would happen if you were to not do this.

I would run, if I were you.

You know just gather that scenario, because, who knows what can happen.

Statements are issued and they are run usually flawlessly.

So, that's the other thing is you want to be very competent in whatever you're doing.

If you're given a task to do by our engineer and then you failed a simple task.

You don't do it right.

You know that you just need to remember your competition.

Your competition are the machines.

They're flawless. They're doing everything perfectly, on time, highly efficient, very quick

without fail, almost all the time. Unless the compiler is wrong,

which it almost never is.

You want to try to be wrong about as often as compiler is wrong.

You know, one thing that I might comment on here is that there are two types of careers.

The traditional type of career is one in which there's a lot of posing, a lot of acting.

You know, people want to make themselves

look like more than they are.

They want to project their personalities, project themselves.

And this is about wearing suits, having a really smooth gelled hairstyle, and

just looking the part. Playing the part. Speaking the part.

And, a lot of this is going to be useful for certain careers, like, if you're doing negotiation

business deals, you know, talking to investors, trying to sell something, sell a car.