How to Talk to a Software Engineer (for normal people)


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.

, ,

Post navigation

100 thoughts on “How to Talk to a Software Engineer (for normal people)

  1. Why do I find it funny? Is it funny? Is it supposed to be funny? Am I laughing at myself? Why am I sad? Am I supposed to be sad? ???

  2. At first I thought this was just a parody, but actually… I feel identified with a lot of his statements, lol.

  3. Lol, this was very funny, and yet not devoid of truth. When I was coding every day and daily active on a programmers forum, I was so bored communicating with people, it was so different, so imprecise. Thanks to my current job I worked on it a lot, yet I still find people are not able to clearly state what they want. Your boss constantly fails to anticipate scenarios where his instructions are irrelevant… So I end up fixing things by myself, calling the right persons into different services to fulfill orders of items that my boss keeps thinking the automation should work by itself and so never care (even though it is her job, and I point her out the flaws in the process that leads to inaccuracies in stock, making the said automation useless due to missing inputs). Ultimately, I have learned to live with people intellectual laziness and flaws, as well as my own, to a certain extent. We live in a society not driven by excellency anymore. People have been too much used to automation and no intellectual efforts.

  4. I am an engineer and think you got it right – hit the nail on the head. Perhaps because design engineering these is largely software, though with different languages. I use Verilog and VHDL but also C++ and Python. So there is little difference between software coders and hardware engineers. It teaches a bit of humility when you realize that when the computer says it is your problem rather than its problem, the computer is almost always right.

  5. The thing about spending hours talking nonsense with someone is something that I can't do.
    I prefer spending more time, building personal project I know I'll never use.

  6. Are you sure that you are talking about persons, not the programs they create? Asperger syndrome is quite rare. I suspect that you mixed one with the other, or this is just a joke :).

  7. I'm a software engineer.
    No one gives me orders, you state your needed outputs and conditions, I'll processes the needed material (usually coffee) and data and output the artifact (usually code), you better give all the needed inputs, like enough time for the task.
    Nothing is negotiable, there's no concessions, you think you won the negotiation but the hard fact is that there wasn't enough time or resources for doing the task and now the process has crashed and all your deadlines are going to be missed. If you said before what time constrains you had, it would be possible for you to choose what task were going to be done, no, not all of them.
    Authority means nothing, data is the real authority, you don't have time because you sold something that doesn't exist, there's no other way over this, you can't give orders to go fast, we always work at full speed, no order you can give will ever fix that mistake of the sales department, you can't blame me for that (blame is not a valid input, fear also is not a valid input), the only possible output is missed deadline or the programmer process will end (that means he quits).

  8. while(out){
    drinkcofee();
    }
    obviously, until out is false , there is no reason to stop drinking coffee…

  9. When you said spending their time in a basement communicating with machines that was %50 !True
    We do communicate with machines but not in a basement 🌚

  10. This video seems a little bit like a joke to all software engineers, but the truth is… this is right. That's how we communicate and understand people 😀

  11. Talk with the TechLead in this manner.
    If TechLead!=Creative:
    Print ("You don't know who is the TechLead!!!")
    else:
    Print ("Know the TechLead!!!")

  12. This video seems like a joke, i'm a software engineer in a group of software engineers, and this is way too exaggerated. We don't work like computer programs.

  13. i became a web developer, so i can put a Sennheiser around my ears and fucking code all day and no talking to no one for shit.

  14. Is it possible to become a software engineer without deteriorating into no more than an "if-else" robot? I'd hope that I can still have emotional conversations with normal people.

  15. The other day, I asked my friend if she wanted to come running with me. She said "I probably should". I nearly burst
    into flames.

  16. This line right here is hilarious : "You would get kicked out so fast you wouldn't even have time to demonstrate your firm handshake"

  17. "Time complexity and Space complexity of a conversation" – Genius. I wonder why people don't tell their story concisely and just go round and round without adding any value.

  18. This continues to be one of my favourite Youtube videos of all time. I watch it probably once every two weeks. Whenever I am in the need of some humour, I rewatch it. Whenever I meet a new dev, I send it to them. Whenever I start dating a new woman, I send it to her. You are TechLead.

  19. So this is how the TechLead became an ex-husband. I hope it was not caused by jealousy on some third-party API, just some statement errors. I'm still hoping his wife and child will one day return true from Japan.

  20. It was comical, especially delivered deadpan. So perfectly captured, it hurts. (Accidentally, all of this is borderline autistic, but then people in this profession tend to be that….) As it grew on me, though, over several days, it seemed less and less funny…. Because, side by side with the "my wife left me" video, this one must have been a passive-aggressive way of explaining how she didn't understand him…. She expected a non-robotic human?

    Still comical, though.

  21. Humours yet very insightful and imminently practical and applicable. If you talk to software engineers often, you'd want to review this video, else you will make their eyes roll. For those who need to interface with engineers, learn and practice the use of their jargon until you feel comfortable and it feels natural. I feel and think that this is a must view video for anyone in the tech field.

  22. Also, for the love of God, when asking an engineer out please specify : Time, Place, Price. ALWAYS. Duration can be null if it isn't constant.

  23. This is hilarious. But if I wanted to have a relationship with a computer I would just work all the time. Oh wait a minute….

  24. "You make sure you use very precise language… and not words like Maybe" Another evidence that the functional programmers are not software engineers? 😀

  25. I do not really agree with this. In my view, it is important that a customer or manager communicates the right goals and aligns with the overall vision of the project. If a SW engineer and a manager agree on the same project mindset, then I deem the conversation as successful. Unless you are the direct manager of a SW project, you won't be involved with most of the technical details.

  26. If dijkstra was a philosopher –
    Best path to a target node is neither the shortest path and nor the path with more nodes ,it is the path having the property max(sum of weights/number of nodes )

Leave a Reply

Your email address will not be published. Required fields are marked *