Placeholder Image

Subtitles section Play video

  • Hey, Tech Lead here and welcome back to another episode.

  • 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