Placeholder Image

字幕列表 影片播放

  • 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

  • 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.

  • If you're a salesperson, marketing.

  • A lot of these careers that deal with people, clients, and partners, you're going to want that.

  • It is not really so genuine.

  • However you might notice that there's other types of careers, such as, engineering or art or even writing books.

  • For a lot of these, the body of work stands on its own and

  • it is evaluated on its own merits.

  • You know when you visit a website or use an app,

  • You don't really look at what type of hairstyle the programmer who wrote the app had.

  • How he was talking.

  • What type of suit he was wearing.

  • I think for that reason you may see many engineers, who dress down, who dress very casual, and

  • similarly for you

  • When you interact with them, it is very important that you're acting genuine

  • and you're not projecting yourself or pretending to be more than you really are.

  • This is why if you' were to go to an engineering interview

  • Slick your hair back, put on the suit, and put on some shiny shoes.

  • You might get reject. You could get kicked out so fast that

  • you wouldn't even have had time to demonstrate your firm handshake.

  • Anyway, that will do it for me.

  • If you have any additional tips for how to communicate with software engineers,

  • please post below in the comments.

  • Would love to hear what you guys think.

  • If you liked the video, give it a like and subscribe and I'll see you next time.

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

字幕與單字

單字即點即查 點擊單字可以查詢單字解釋

A2 初級

如何與軟件工程師交談(對普通人而言 (How to Talk to a Software Engineer (for normal people))

  • 1 0
    林宜悉 發佈於 2021 年 01 月 14 日
影片單字