Engineering Field Guide For Founders

9* Things I _____ About Engineers

This article is part of the “The Unfounded Field Guide for Founders” series.

engineer
noun • en·gi·neer • \ˌen-jə-ˈnir\

Software startup or not, more and more businesses rely on the talents of engineers to plot their success. For some, like startups, the engineering effort is critical, often a foundational part of its existence. For others, engineers are engaged both strategically and tactically across the organization. Let’s not pretend, engineering is indispensable.

Engineers are one of the most mythological groups in the organization. Often seeking out the shelter of darkness, engineers often prefer minimal human interaction, naturally gravitating to the hidden parts of your organization. Their intense work schedules also tend to put their schedules askew from many others in the organization — some might even argue by design.

Finding great engineers is one the hardest things you’ll ever do in life — kind of like the hunt for Moby Dick or the Giant Squid. As a result, they’re highly regarded and carefully guarded. In short, don’t F with the engineers, or else.

To know them is to love them, those geeky bastards.

#0: They Count From 0

Quick, what’s the first number? I bet you said 1. Guess what, you’re likely not an engineer, hurrah! Wait, what?

Seriously, I’d try and explain this, but your 1-based head will likely explode on the screen and you won’t make it through the rest of the list. The important thing to note, however, is that this 0-thinking is actually a reflection of the world they are working in.

Designing and implementing software is almost entirely a mental construct that, if you’re good and paying attention, relies mapping those mental constructs to some constraints down below (aka how the computer translates stuff and stores it — ones and zeroes).

Why this really matters to you, though, is that once you start to realize that there’s an army of people who believe 0 is the first number, just how many “other things can you possibly disagree on? Hint, hint ∞.

Dig in, it’s gonna be a long slog.

#1: Logic is a Language

Engineers value logic over all else. For them, everything should be reduced down to as few choices as possible, ideally 2, aka binary.

If you listen close enough, you’ll notice that they’re quite economical with simple words and quite liberal with a series of multi-syllabic words that are actually used to described very specific situations — in actuality, these longer words are more for communicating a set of words.

Don’t believe me? Orthogonal. Ever heard that word before? It means “of or involving right angles” or “statistically independent”. You might more commonly use the word “unrelated”, but you’re a commoner.

Given enough time, you’ll find that you actually will develop this same form of terseness. It’s not all bad, I promise. You just have to appreciate the concreteness of it all and forgive the lack of humanity it embodies.

Get your thesaurus out, you’ll need it.

#2: Tabs vs. Spaces

Precision is an important thing to engineers. It’s why they prefer their sentences short and their eye contact shorter.

This attention to detail is pervasive. From the equipment they use, to the setup of their machines, through to the environment they write their code in. Everything has to be just right.

If you’re feeling bad that you can’t agree with your engineers, don’t worry — they usually don’t agree with each other either. In fact, the arguments they have are waaay bigger, by far.

Case in point, the tabs vs. spaces debate. Try this experiment. Run down to engineering and yell, “Spaces forever, tabs suck” and then run like hell. That’s the engineering equivalent of yelling fire in a movie theatre.

Engineers believe all their things, all the time. And they’ll believe it until they’re cold and dead. I just googled, there are 502K search results for “tabs vs. spaces” with charming defenses like:

“and honestly, if you’re editing code with a box that doesn’t have regex to do the reverse, what the fuck development environment are you running there?”

So, yeah. There’s ^^this. Don’t say I didn’t warn you.

#3: They’re Pampered Pooches

Engineers are critical to the organization, and don’t they know it. In no other part of your company will it be normal for any employee to…

• Arrive any time they like, because they work later, if they show up at all
• Consistently avoid meetings and the calendar in general
• Overload their laptops and desktops with RAM RAM RAM
• Build forts with monitors to avoid observation and eye contact
• Granted excess authority regardless of experience (ok this applies to founder and most other early employees, but it stays consistent for engineering)
• Never have to learn what the company really does or what customers look like
• Skip any of the cultural or manual tasks everyone is expected to help with

Sure all those screens give them the ability to do more, even if doing more means a screen dedicated to their Spotify playlist and another for monitoring the monitors. Sure those beefy machines are needed to power all those screens and make them more effective (at playing network games once the plebs leave). Sure those meetings are just getting in the way of writing code, so why waste it. Sure, sure sure.

Many the organization are scared to offend their engineering teams. No one feels they have the luxury to anger, annoy or otherwise antagonize the engineers. Most aren’t bad, don’t get me wrong, but it’s a common sentiment from many the founder and beyond.

Engineering matters, especially when it’s integral to everything else.

#4: Context(switching) is King

Context switching, another technical term applied to humans:

In its simplest form context switching is jumping between various, unrelated tasks. Even if you’re lucky enough to work from home, context switching is probably still sidetracking your productivity in other ways. — Trello

The theory is that every time you are interrupted, you waste precious time. If you’re paying attention, efficiency is the common thread so far and anything inefficient is shitty. Engineers hate switching context, especially if that switching involves talking (yuck).

LIFO — last in, first out — another nerdcronym. Your brain processes the stack, so every time the stack gets longer, the worser off you are. I saw a stat quoted that it takes 45 minutes for an engineer to get “into context”, which means that dropping boulders on them is extra expensive.

Truth is, this is an actual problem and the ability to work, uninterrupted, is critical for engineers to be productive. But here’s the thing — it’s true for EVERYONE ELSE, TOO!

It’s not like everyone else is sitting around their desk saying, “Hey, why doesn’t someone interrupt me”. But engineers would love to be king of the hill, or heap.

#5: Everything is Easy

For a group so focused on precision, you’d think they were also amazing listeners. Not so fast…

Engineers are great pattern matches and sometimes that works against them. Here’s what happens:

You: “So we want to send this email when they click here”

Dev: “OK”

You: “You sure, I want to.. (Charlie Brown voice)”

Dev: “Yeah, yeah, easy. Got it”

Now, of course, what you were saying when you started sounding like Charlie Brown was the important part, but the pattern matching took over and basically you got tuned out. Once the pattern fit, done, easy.

You can’t really blame them, they are doing what most of us do. The main difference, of course, is that these mistakes become systematic to your universe and eventually, they’re either dragging you down or become a debt you owe.

Most things actually are easy, but the devil is in the details — make him known.

#6: Everything is Hard (Until it is Easy)

Everything is a no, until it’s a yes — that’s the golden rule. Engineers work problems from unknown to know, which means that your likely to get a no for a long while before you get a yes.

The process of reaching clarity can be infuriating for most, especially those who don’t frequent stand ups, pointing meetings, and the other tools in the product-engineering toolkit. As we already know, logic is the language.

Here’s the thing. Things are as hard as we make them. While you’re there hoping for a little give and take, remember that the other guard rail is the light, easy glossing that we just covered.

Striking the right balance is of the utmost importance. Time, patience, and a good rapport go a lot further than you can ever imagine.

#7: Shiny Object Syndrome

Patience is hard when you live in a world filled with distractions. On any given day, Hacker News releases about 4 dozen new shiny objects to whiz and entertain engineers. All that wonderful open source stuff your apps are built on also floats a raft up updates, point releases, and alphas, betas and more. All shiny, shiny objects.

Engineers love shiny things — it’s like the best thing evah. Sometimes it’s real things that need to be looked into. Other times it’s a new version of something old or a new approach to an old problem. And sometimes, just sometimes, it’s just effin’ cool and we just “gotta know” how it works.

Distraction becomes delay. Shiny becomes syndrome. All of a sudden, you’re hours, days, weeks, months behind schedule and it was a small little itch that turned into a rash that gave way to full-on leprosy.

Just because your engineers want to do something doesn’t necessarily mean it’s a good thing — ask the right questions or get someone who will!

#8: Optimization Syndrome

They say that you can never know enough. And they’d be wrong. Sometimes knowledge is power, other times it’s a bag of shiny bricks for your engineer to carry around. Which is better?

Most engineers will tell you they need context to provide solutions to our needs. They’re telling the truth 100% of the time. Of course, that truth has the potential to run away from you, fast.

Imagine this conversation:

You: “Hey so I want to build an SMS appointment reminder (X)”

Dev: “OK, got it. Just SMS?”

You: “Eventually, I want to have push notifications, too (Y)”

Dev: (thinking) Cool, need to research how to do push notifications (Y+X)”

Those few simple words didn’t just give context, they inspired scope. Too often, when we’re not careful enough, what can readily happen is we can force capabilities and optimizations that aren’t necessary or warranted.

Developers hate building things twice. They also hate building single-use things. Given the chance to prevent re-building something and solving for the problem of specificity, they’ll take it.

This can also bite you in the ass in the other direction, if you’re not careful — so don’t clamp down too hard. Turns out that when you’re developers don’t bother to think about any other use cases you end up with precisely the problems they over-eagerly try to prevent. You know, like the Y2K bug and stupidness like that.

It’s hard to have it both ways — screwed up, right?

#9: Estimation isn’t Exactly a Science

Speaking of time, it’s best not to.

Well-oiled teams eventually find a cadence and are able to more predictably estimate how long things will take. A number of things help:

• Team staying consistent
• Great documentation
• Clean roadmap
• Minimal interruption

You should be laughing your ass off right about now, but in case you missed the joke, that’s not how anything works in Startup Land. What usually happens is that the estimate is too low or too high but we won’t know until it’s too late.

Until you’ve mastered all the things on this list, you can’t really expect to get the things you want when you want them. A good engineering manager won’t let this get too far out of whack, otherwise, you got two problems.

Sorry, no shortcuts.

If you enjoyed this article, let your friends know with ❤︎ or a share. Follow me for future articles.

Gregarious Narain is a serial entrepreneur and product strategist. A reformed designer and developer, he writes on his experiences as a founder, strategist, and father on the regular. Connect with him on LinkedIn or say hi on Twitter.