There are a couple of engineers on my current team that I can only describe as being a little too smart for their own good, and I'm struggling a bit with how to work with them. I've worked with this sort of engineer on previous teams as well, and they all share a few traits:
- They're brilliant, I mean very smart people (in an almost academic way?)
- They have a big appetite for adding complexity to systems
- They also have a big appetite for adding work to their own plates
- Their code has no consistent style
I work in embedded systems, so I'm generally writing C for resource-constrained systems. This sort of environment is rife with footguns, and I spend most of my time just trying to avoid those. A big part of that is keeping the things that my team controls as simple as possible, and while we are resource constrained, it's a balance. The tension comes when someone's more than happy to, for example, implement a complex caching scheme from scratch to save a few hundred bytes here, a handful of microwatts there. To me, adding that type of complexity for those sorts of performance improvements is missing the forest for the trees.
When an engineer like this proposes something that adds unnecessary complexity, it's usually hard to argue with. The proposed change typically does indeed make the system objectively better, and they're the one taking responsibility for doing the work and ensuring its correctness. But the overall system becomes a little more brittle, and a little harder to reason about, two things that are much more difficult to measure than memory and power.
Here's an example: an engineer on my current team recently proposed adding a significant feature to a module I wrote to make something dynamic that's currently statically defined at compile time. I pointed out that we could just change a couple entries in a static table to accomplish his goals, and we were able to avoid the extra work. What was notable, though, was his immediate willingness to write that feature. Maybe I'm lazy, but I'd sit there and think of half a dozen other ways to do it before settling on changing the module itself. But because he's smart enough to easily reason about a complicated solution, and he's willing to take on the extra work, he stopped there without weighing it against the larger system.
Have you worked with engineers like this? Do you have any thoughts on how to work with them in a productive and friendly way?
--
One more example if you feel like reading more:
In a past role, I got into a debate about code style with the smartest person I've ever worked with. It boiled down to me advocating for more whitespace in his code and him arguing that adding whitespace made the code harder to read. It took a bit, but eventually I came to understand that he is so good at reading code that he just wants it all laid out in front of him as densely as possible. He can effectively run it in his head, as long as he can see it.
That was baffling to me, I walked away thinking that I must be pretty bad at reading code. I use a very consistent style with long variable and function names, I keep my solutions as simple as I can, and I use whitespace generously to provide visual cues about the code's structure. All of this is to minimize the amount of brainpower I needed to understand my code, so I can put that energy toward thinking about the problem itself.
This requires some luck, but there definitely are things you can do to help the process along. In particular, I recommend allowing some probably-unnecessary complexity -- I'd expect your engineers to innovate less and learn at a slower rate if you try too hard to stamp this out -- but be strategic in where you allow it. Software that is already load-bearing for your business should be subject to higher standards. Set an expectation that stable functionality becomes easier rather than harder to work with over time. When the backend has to become more complex to achieve performance goals, ask your engineers to do their best to encapsulate that complexity, and keep the higher-level interfaces simple.