On Code Monkeys

Believe it or not, communication is in the job description.

23 September 2019

Working at a chimp-related company, I’m often the butt of uncreative “code monkey” jokes tossed around by developer friends. Luckily enough, this couldn’t be further from the truth at Mailchimp (we’re hiring 😉), but I’d be lying if I said these off-hand comments didn’t frustrate me a bit.

Since my start in the industry, I’ve noticed the most effective engineers I have worked with all have a skill that sets them apart, and it’s not necessarily being an above average coder — they’re all exceptional communicators. Code monkeys, developers not concerned with conceptual design nor technical communication, make my blood boil, and I’d argue it’s one of the worst insults you can give an accomplished engineer. Yet, it seems that the industry often rewards code monkeys and their ilk… or at the very least turns a blind eye to this behavior and perpetuates the myth of the misunderstood, eccentric 10x developer.

LeetCode and the Code Monkey Interview

Developer site after developer site mentions LeetCode and cite its importance in the tech hiring process. Pedantic tech workers argue over who has completed more LeetCode hard question, grinding until they’ve committed questions and methods to solve them to memory.

The difficult parts of writing software aren’t doing brainteasers or reversing the order of a singly-linked list. And yet, these are the skills that are treasured in interviews at some (most?) of the biggest tech companies in the world. LeetCode-style questions reward code monkeys and teach tech workers to value the wrong things. This is unsustainable and altogether obnoxious.

Code Monkeys Don’t Grow

Physically, maybe. Mentally, how could you? The premise of code monkeyism is avoiding situations for growth.

Technically, if you’re never challenging yourself to make architectural decisions, facing the excitement of scaling an application, asserting your support for a specific technical stance on a project, you’re no more equipped to do these things in the future when you’re “more senior” and folks are relying on you.

In the realm of “soft skills”, you’ll never become a more effective communicator, you’ll never learn to mentor (or perhaps be mentored) other developers, and you’re gonna have a really tough time talking to legal when GDPR issues arise or design when you need to describe the limitations of your feature. That’s a real shame — working with non-developer folks is awesome and you learn so much from them.

Being a code monkey is a fixed mindset. It’s a mindset that inhibits personal growth and the growth of those around you. Bad on all fronts.

Code Monkeys Aren’t Fun to Work With

I’ve heard many-a-story of folks approaching developers with questions to be met with grunts and groans — better yet, I’ve heard of developers that simply ignore others in meetings, discussions, or workplace interactions. Simply put, this makes for a really toxic workplace, and these code monkeys aren’t improving themselves or those around them.

While I surely value quiet and focus at work as much as the next person, it’s important to build a rapport with your coworkers. A healthy relationship will allow you to perform more seamlessly and encourage the challenging of ideas in a healthy environment. If I knew my interjection to an architectural decision would be met with indifference, scoffing, or snickering, I’d probably never contribute ideas. Empathy and kindness go a long way.

Code Monkeys Suck The Creativity Out Of Development

Like it or not, coding is just as much an art as it is a science. I’ve even heard of folks who programmatically generate art with code (how cool is that?!?!). While print('hello world!') will always do what you’d expect, it’s painfully evident that poorly constructed systems were poorly constructed once you start working with them. My intention isn’t to malign those whom occasionally use ✨ Stack Overflow ✨ (because, surprise surprise, we all do), but for each developer I’ve heard that’s excited to work on a greenfield project and architect something from top to bottom there’s another developer that “just wants to be told what to do”. Yawn.

Perhaps it’s the former Liberal Arts College student in me, but I don’t think we need more Code Monkeys. In fact, while it’s important to have developers that know the ins and outs of parallel computing and designing operating systems, I also think it’s important to have more philosophers and classicists that are developers—more artists and historians. Development needs folks who care about accessibility and optimization, and I think pulling from a wider audience might help that (sound familiar?). Maybe this would remedy the issue? Until then, we’re stuck in a Code Monkey’s world with folks grinding on LeetCode and groaning when asked for help.

← Courteous Flying Raspberry Pi Door Notifier →