If you make a habit of reading twitter or the writings of various thought lords and ladies of the internet, you’ve probably heard a lot of advice on what software engineers should do, like:
- Software engineers should deploy their own code!
- Software engineers must know how to operate their own services!
- EVERYBODY is in ops now! #devops
- Engineers need to care about business objectives!
- Even operations engineers need to care about design and utility! #designops
At some point even the most game among us starts to feel overwhelmed. Can’t we just go heads down and care about writing code sometimes? How can anyone ever know the full breadth and depth of technology? Are we supposed to hand-solder our own chips while simultaneously designing our own color palettes?? Is there no room for specialists anymore? Is it all breadth and no depth? Dammit, I just want to get my job done and go home!
Relax.
Opinions are like assholes, remember? (Everyone’s got one.) All this advice is being dished out by well-meaning folks, who by and large are using sweeping language to address particular pathologies. (“ALL engineers must be on call” … because some companies lack any feedback mechanism to expose developers to the consequences of their code.)
No advice is universal; most applies to very specific and narrow contexts. But the overwhelming number of statements like these are important because they describe a real shift in the engineering profession. As the size and sprawl and complexity of our systems skyrockets, many of us are finding that the most valuable skill sets sit at the intersection of two or more disciplines.
Why? Empathy, translation. The ability to intuitively grasp what your cohort is capable of.
Even a shitty, rudimentary grasp of an adjacent skill makes you phenomenally more powerful as an engineer — whether that is databases, design, operations, etc. It makes you easier to work with, it helps you instinctively avoid making whole categories of stupid mistakes, it means you’re able to explain things about one side to someone on the other side — in either direction.
The old-school engineering culture we grew up with is part of the problem
Think of the kind of engineer we used to aspire to be. Our heroes were these grumpy engineers who sat in the corner, coding all day and drinking mountain dew, who were proud when people were afraid to approach them and suffered no fools. The Bastard Operator from Hell had a comic book, ffs. Your DBA took pride in being the only one to swoop in and save the day when the db was on fire. Software engineers loved to grumble about how Hard and Mysterious or Trivial and Not Worth My Time all the other disciplines in the company were, from marketing to ops.
Nowadays, we’ve learned the hard way just how fragile our systems are with that kind of engineer. So we’ve engaged in an industry-wide push to change the engineering ideal — away from brusque lone heroes with attitude problems, towards approachable, empathetic people who share a generalized tool suite.
- The new best kind of engineer is a software engineer who can not only write the code, but also knows how to jump into prod and debug it, and is happy to be in the on call rotation supporting their own code.
- The new best kind of engineer is a DBA who proudly reuses terraform and packer and chef and orchestrates their shard replacement using the same tooling as the rest of ops … and trains everyone in how to recover data.
- The new best kind of engineer is a UI engineer that can not only code build configurations, but also understands how their work fits into a larger design system… and advocates for lowering the bar to producing production UI through automation.
People sense this. This is why every freshly-minted young developer now proudly calls themselves a “full stack developer”. (Later they grow up and realize that the full stack developer is a lie, but that’s the disillusionment of youth.)
You don’t need to know how to do everything under the sun. You do need to have respect for all the other disciplines that enhance your own and make your job possible, and vice versa. You do need to think of yourself as someone who has a responsibility not to be a single point of failure.
And while the world will always need specialists, speaking a common language is important, and there’s a great deal of power and awesomeness to be gained by learning even a bit about another discipline.
Want to learn more about the breadth of the systems your code runs in? Sign Up and give Honeycomb a whirl!)
