Not too long ago, Jenna Bilotta wrote an excellent article called, How designers and engineers can play nice[1], in which she talks about ways for designers and engineers to work more productively. Having faced similar challenges working with designers (and also working with engineers, when I was on the UI side), I appreciate the pragmatic approach she suggests. It always helps to respect the other role’s process and understand their thinking when working together.
One of her points for engineers was not to say “no” so quickly. That one stuck with me for a while and swam around in my head. My first reaction was, “but you don’t understand why we say no!” And a million other defensive thoughts soon joined in the party. She is right, of course. We do say “no” very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.
Our reputation
Cards on the table, software engineers generally have a reputation for being arrogant, disagreeable, and moody. We also have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can. In general, this reputation is deserved. That’s exactly what we do, day in, day out, as we intermix writing code with checking in on Twitter and Hacker News.
(Side note: There are some who will say that’s not true of all engineers, and you’re right. There is a small subset of engineers for which some or all of these are untrue. Before scrolling to the bottom and leaving comments telling me how dumb this article is, please keep reading.)
Reputations aren’t randomly given out, they are earned based on experience. What makes the reputation disturbing to me is that I know many software engineers personally, and they are generally a fun-loving, agreeable (if not opinionated), and entertaining bunch. They’re the ones you want to hang out with after work and catch up with on the weekend. So why is it that in the presence of work, a different personality shows up?
Creators, not builders
I have a theory. That theory is that software engineers see themselves very differently than those with whom they work. I’ve come to this conclusion after over a decade in the software industry working at companies large and small. Companies (product managers, designers, other managers) tend to look at software engineers as builders. It’s the job of the product manager to dream up what to build, the job of the designer to make it aesthetically pleasing, and the job of the engineer to build what they came up with. Basically, engineers are looked at as the short-order cooks of the industry.
This is something that my very first manager warned me about. When the first company I worked at went under, he and I had a very frank discussion about my career. While we didn’t always get along, he gave me this excellent piece of advice (paraphrasing):
Nicholas, you’re worth more than your code. Whatever your next gig is, make sure that you’re not a short-order cook. Don’t accept a job where you’re told exactly what to build and how to build it. You need to work somewhere that appreciates your insights into the product as well as your ability to build it.
He was absolutely correct. There are a lot of companies that want short-order cooks, they want implementers and builders to march to a specific beat and stay in line. In fact, I’d say most companies want that, large and small. I can’t tell you how many startups contact me offering equity in exchange for building the founder’s vision. The implication: we already have all of this figured out, we just need someone to build it.
And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.
In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce. Software engineers aren’t dumb, they see this happening, and resentment starts to build (no pun intended). The engineers want to be part of that creative process and are denied. Thus you end up with the typical software engineer personality accented by grumpiness.
Wait, what’s the problem?
Product managers are interesting people. Their ideas and capacity for understanding markets are impressive. They also have a tendency to believe that their ideas are fully-formed when, in fact, there are holes so large that trains could fit through. I say this with love, as several good friends are product managers, and you all know I’ve said this to your face at one time or another. This is absolutely not a criticism of product managers, it’s just in their nature. Their job is a creative one, and ideas do not emerge fully-formed. And that’s part of what makes software engineers grumpy.
Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.
To understand the problem, consider the job of building a house. Someone has decided they want to build a house on a specific plot of land. The house is to be two stories and have a garage. There’s even a rough sketch of the front of the house scribbled down on a napkin. That person comes to you with this information and the napkin and says, “this is enough for you to start building, right?” Are you able to start building?
Logically, you can’t start building the house at that point. You don’t know the square footage. You don’t have floor plans. You don’t know what sort of codes the city requires for new houses. There’s literally not enough information for you to even start digging up dirt. At this point, you’d tell your customer that they are crazy and need to figure out exactly what they want. Now imagine you can’t do that, because there’s a deadline that someone set and you’re responsible for meeting.
“Well,” your customer tells you, “why don’t you just start building, and I’ll get you the details as they become available. That way, we’re not wasting any time.”
You know that there’s not enough information for you to start building, and further questioning the customer won’t yield any additional information right now. Yet, you have a deadline to meet and so you really can’t afford to sit around and wait for more information. What do you do? You start making assumptions.
The old adage, “when you assume, you make an ass of u and me,” is about as true as can be. Assumptions are dangerous and often wrong. Yet without making some assumptions, the project can’t move forward. So that’s what you do. You start by assuming that what you already know is true, the house will have two floors and a garage. The garage, should it be attached or detached? How big should it be? Well, let’s keep things simple and say it’s detached and houses a single car. That means you can start on the garage as a standalone structure on the side and then, when there are more details about the house, you can continue right next to the garage.
After a week of working on the garage, your customer emerges with more details. In fact, the house has to be three floors (phew, good thing you didn’t start there) and will have eight bathrooms. There’s no further information about the garage, but the house is going to be painted blue. You then logically assume that the detached garage should also be painted blue and so that’s where you spend time next.
A few days later, the garage is almost done. You feel pretty happy about the quality because you went on so little information. You’re now ready to start on the house when your customer comes back with more details. The garage actually needs to fit two cars and should not be detached. Your heart sinks, since you had created something nice and now it needs to be bulldozed to make way for the “real” thing. What’s worse, you now have less time to complete the entire project, which only increases the grumpiness level.
If this analogy seems crazy to you, you’ve probably never worked as a software engineer. This is our reality every single day. We try to keep projects moving by using our creative facilities only to find that we, in fact, can’t read anyone’s mind and therefore guess incorrectly as to what exactly it is that we’re building. And yet, if we don’t do that, we would sit there idle, as no one likes the waterfall process of software development.
In almost every other industry where things are built, it is expected that all requirements and details are agreed upon and finalized before building commences. Except in software. In software there’s “not enough time” to gather all the requirements ahead of time. The importance of moving quickly is hammered into us from day one. And so engineers learn to fill in the gaps left by product managers just to keep the project going. Product managers, of course, also have the reputation for changing their minds frequently, which means engineers assumptions are often invalidated partway through the process.
One of her points for engineers was not to say “no” so quickly. That one stuck with me for a while and swam around in my head. My first reaction was, “but you don’t understand why we say no!” And a million other defensive thoughts soon joined in the party. She is right, of course. We do say “no” very quickly, not just to designs, but to everything. That led me into thinking about the psychology of software engineers and what makes us the way we are.
Our reputation
Cards on the table, software engineers generally have a reputation for being arrogant, disagreeable, and moody. We also have a reputation for saying “no”, for debating pedantic details, and thinking we know how to do everyone’s job better than they can. In general, this reputation is deserved. That’s exactly what we do, day in, day out, as we intermix writing code with checking in on Twitter and Hacker News.
(Side note: There are some who will say that’s not true of all engineers, and you’re right. There is a small subset of engineers for which some or all of these are untrue. Before scrolling to the bottom and leaving comments telling me how dumb this article is, please keep reading.)
Reputations aren’t randomly given out, they are earned based on experience. What makes the reputation disturbing to me is that I know many software engineers personally, and they are generally a fun-loving, agreeable (if not opinionated), and entertaining bunch. They’re the ones you want to hang out with after work and catch up with on the weekend. So why is it that in the presence of work, a different personality shows up?
Creators, not builders
I have a theory. That theory is that software engineers see themselves very differently than those with whom they work. I’ve come to this conclusion after over a decade in the software industry working at companies large and small. Companies (product managers, designers, other managers) tend to look at software engineers as builders. It’s the job of the product manager to dream up what to build, the job of the designer to make it aesthetically pleasing, and the job of the engineer to build what they came up with. Basically, engineers are looked at as the short-order cooks of the industry.
This is something that my very first manager warned me about. When the first company I worked at went under, he and I had a very frank discussion about my career. While we didn’t always get along, he gave me this excellent piece of advice (paraphrasing):
Nicholas, you’re worth more than your code. Whatever your next gig is, make sure that you’re not a short-order cook. Don’t accept a job where you’re told exactly what to build and how to build it. You need to work somewhere that appreciates your insights into the product as well as your ability to build it.
He was absolutely correct. There are a lot of companies that want short-order cooks, they want implementers and builders to march to a specific beat and stay in line. In fact, I’d say most companies want that, large and small. I can’t tell you how many startups contact me offering equity in exchange for building the founder’s vision. The implication: we already have all of this figured out, we just need someone to build it.
And here’s the real crux of the problem: software engineers aren’t builders. Software engineers are creators. Building is what you do when you buy a piece of furniture from Ikea and get it home. The instructions are laid out and if you go step by step, you’ll get that comically small table you wanted. Creating is a different process, it’s birthing something without direction or instruction. It’s starting with a blank canvas and painting a masterpiece. Software engineers don’t get into coding because they want someone to tell them what to do, they get into it because they discovered they could create something useful. Every single software engineer fell in love with coding because she made a small, useful program early on and was hooked.
In the triumvirate of software, product managers, designers, and software engineers, only the engineers are expected to turn off their creative minds and just produce. Software engineers aren’t dumb, they see this happening, and resentment starts to build (no pun intended). The engineers want to be part of that creative process and are denied. Thus you end up with the typical software engineer personality accented by grumpiness.
Wait, what’s the problem?
Product managers are interesting people. Their ideas and capacity for understanding markets are impressive. They also have a tendency to believe that their ideas are fully-formed when, in fact, there are holes so large that trains could fit through. I say this with love, as several good friends are product managers, and you all know I’ve said this to your face at one time or another. This is absolutely not a criticism of product managers, it’s just in their nature. Their job is a creative one, and ideas do not emerge fully-formed. And that’s part of what makes software engineers grumpy.
Both engineers and product managers tend to think, incorrectly, that product specifications or requirements are equivalent to the furniture manual from Ikea. In reality, these documents rarely contain enough information to build an actual thing. They’re usually just the starting point. And that presents a unique problem to the engineer.
To understand the problem, consider the job of building a house. Someone has decided they want to build a house on a specific plot of land. The house is to be two stories and have a garage. There’s even a rough sketch of the front of the house scribbled down on a napkin. That person comes to you with this information and the napkin and says, “this is enough for you to start building, right?” Are you able to start building?
Logically, you can’t start building the house at that point. You don’t know the square footage. You don’t have floor plans. You don’t know what sort of codes the city requires for new houses. There’s literally not enough information for you to even start digging up dirt. At this point, you’d tell your customer that they are crazy and need to figure out exactly what they want. Now imagine you can’t do that, because there’s a deadline that someone set and you’re responsible for meeting.
“Well,” your customer tells you, “why don’t you just start building, and I’ll get you the details as they become available. That way, we’re not wasting any time.”
You know that there’s not enough information for you to start building, and further questioning the customer won’t yield any additional information right now. Yet, you have a deadline to meet and so you really can’t afford to sit around and wait for more information. What do you do? You start making assumptions.
The old adage, “when you assume, you make an ass of u and me,” is about as true as can be. Assumptions are dangerous and often wrong. Yet without making some assumptions, the project can’t move forward. So that’s what you do. You start by assuming that what you already know is true, the house will have two floors and a garage. The garage, should it be attached or detached? How big should it be? Well, let’s keep things simple and say it’s detached and houses a single car. That means you can start on the garage as a standalone structure on the side and then, when there are more details about the house, you can continue right next to the garage.
After a week of working on the garage, your customer emerges with more details. In fact, the house has to be three floors (phew, good thing you didn’t start there) and will have eight bathrooms. There’s no further information about the garage, but the house is going to be painted blue. You then logically assume that the detached garage should also be painted blue and so that’s where you spend time next.
A few days later, the garage is almost done. You feel pretty happy about the quality because you went on so little information. You’re now ready to start on the house when your customer comes back with more details. The garage actually needs to fit two cars and should not be detached. Your heart sinks, since you had created something nice and now it needs to be bulldozed to make way for the “real” thing. What’s worse, you now have less time to complete the entire project, which only increases the grumpiness level.
If this analogy seems crazy to you, you’ve probably never worked as a software engineer. This is our reality every single day. We try to keep projects moving by using our creative facilities only to find that we, in fact, can’t read anyone’s mind and therefore guess incorrectly as to what exactly it is that we’re building. And yet, if we don’t do that, we would sit there idle, as no one likes the waterfall process of software development.
In almost every other industry where things are built, it is expected that all requirements and details are agreed upon and finalized before building commences. Except in software. In software there’s “not enough time” to gather all the requirements ahead of time. The importance of moving quickly is hammered into us from day one. And so engineers learn to fill in the gaps left by product managers just to keep the project going. Product managers, of course, also have the reputation for changing their minds frequently, which means engineers assumptions are often invalidated partway through the process.
