People here are arguing the semantics of what you mean by “smart”, for no reason, because I know exactly the type of person you are talking about and they likely do as well. I call them “twitchy smart”, and I think they’re the worst to work with. In my experience, there’s no hope working with people like this because there is usually a strong case of stubbornness and unwillingness to see things from the other side. I have literally had to write code that automated cleaning up a person’s, who was like this, code because they were incapable of slowing down and doing it themselves.
My thoughts are that they need strong management to exert a lot of control and to come up with various ways of slowing them down and automated systems to gate check their code as much as possible (style guides, linting, static code analysis, tests and test coverage, auto-formatters, etc.). Otherwise, I think most people like this are just not worth having on a team because they aren’t interested in being part of a team and just want to solve problems they think are important. They will go off inventing all sorts of stuff, leaving a massive wake for the rest of the team. I also call them “wake makers”.
I call them complexifiers... because that's their habitual response to problems. I prefer to hire simplifiers (within reason).
Some complexifiers are not nearly as smart as they seem - they can often have tunnel vision due to their brilliance in specific domains, and miss the big picture. Which puts them in the "dumb and gets things done" quadrant: https://www.johndcook.com/blog/2010/12/27/dumb-and-gets-thin...
This is my experience - they are very often people who are so highly specialised in one thing that they lose the ability to talk to other people. Their egos are inflated (as no-one else understands them) they go around causing havoc.
I tended towards this but was - I guess - lucky to have had a manager who identified this and helped me grow.
My approach: the young ones need to fail. Hard. Then they'll learn.
The older ones who failed and reacted badly (it was everyone else's fault). I take them out of their comfort zone, tell them about my experiences and talk about the feeling of self-doubt when moving to different domains. Work with them to turn them into truly excellent team members (which they - in my experience - can be as they're usually driven, hard working and egotistical).
It is orders of magnitude harder to simplify things than it is to make them more complex. I think this skill comes with experience more than anything else.
Short term complexity can also be long term simplicity. One can make an educated guess of what new requirements might emerge in next half a year and implement a more generic design that accommodates them from get go. If people are really smart, they may anticipate future needs not obvious to others, or they can of course overthink just because they can.
The real wisdom is knowing when to apply the complex generic pattern and when to just copy/paste/mutate an existing design. Also, enlightened coders will document 1) the choice and 2) the implementation so that future coders have an idea of why things are the way they are.
I don't agree that "there's no hope of working with people like this"; I've had a few "twitchy smart" people in my organizations in the past. This is valuable energy that can be usefully directed with competent management and technical leadership. But it requires a good understanding of the nuances at play, as you've noted, and a clear statement of the importance of the team's overall success, not their personal triumphs.
>> a clear statement of the importance of the team's overall success, not their personal triumphs
This doesn’t jive with my experience of devs i can see fitting with the OP’s description. Talk of team success just isn’t on their wavelength, you may as well talk about the weather. It’s a different value system, it values heroism, it values cleverness, it does not value useful business outcomes like maintainability or cost of ownership.
For keeping them on track, they can sometimes respond to automated controls better than to people telling them what to do. A linter in the CI pipeline will usually cause them to follow a style where another person could simply never convince them to make the same change. But everyone’s different and so even this is not guaranteed.
I really should have qualified that with “often”. Of course these are people and can be worked with, but without evolving, they’re worse than under-performers because they create so much stuff that everyone has to deal with.
I think my contention is that they can definitely evolve (at least based on personal anecdotes), but that they require a different management style. Sometimes that's okay with an organization, and sometimes it isn't.
I was going to joke that it’s easy to tell who’s over 30 in this thread, but surprisingly the complexity farmers don’t seem to be correlated with age. It seems to be a learned habit that they just never drop. Indeed, they feel it’s a matter of professionalism not to drop it.
I agree with you that there’s not a lot of hope when working with such people. The best you can do is not to engage most of the time, then do some strategic social jujitsu when they’re proposing their astronaut designs in meetings.
It's not age. I have a uni mate the exact same age as me and we worked together and still talk about work.
He's the kind that would do his own oop framework in plain C (true story) while I would rather do the minimum necessary for things to work (well, if that includes UNAVOIDABLE complexity, so be it). It was like that when we were 25, it's the same 20 years later.
Well now I'm confused about which type I am. I consider myself a "simplifier", but writing your own OOP framework sounds fun I would have definitely chosen that route.
I think both types can enjoy fun diversions. I think being a "simplifier" just means you can make a distinction between diversions and solutions.
For me, every additional moving part has a cost, and that cost needs to be amortized over sufficient use-cases. Sometimes writing your own OOP framework in C is just what the doctor ordered. Sometimes it isn't.
> The best you can do is not to engage most of the time, then do some strategic social jujitsu when they’re proposing their astronaut designs in meetings.
In that case, fire them. Seriously..
If you can't engage with someone, it does nobody any favors. Getting the team up to speed to agree on an approach can often take 10x longer than implementation. (Settimg up meetings, perhaps two days in a row three days from now, etc..) Set that pattern where it takes weeks to do design reviews, and the other person will be frustrated they spend all their time blocked trying to get the teams buy-in. So, they may go ahead and do stuff so that they can be unblocked.
Worse, if the rest of the team are just 9 to 5'ers, they have no incentive to dedicate so much time in a design review. They might not care.
How does a person consider the teams impact of a complex solution when it might not be obvious - by engaging. Perhaps the problem domain is actually very complex, the rest of the team is suffering from the "shit is simple" syndrome. Or maybe the inverse is happening. Either way, social jujitsu strikes me as very passive aggressive and not at all enabling for the _whole_ team. Sounds like it can easily devolve to a case of " we have a team of 10x'ers, but our process and team cohesion reduce efficiency by 95%"
I call them “cowboy developers“, and product owners and non tech manager sometime call them “10x developers” because they can delivery anything quickly.
In my experience, they are the worst people to work with.
In my experience, a less complex but more thought-through solution often requires more time to implement. It's easy to just stick more layers onto a big ball of mud, but it takes excellence to change it such that these layers aren't necessary.
> Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. (I have made this letter longer than usual because I have not had time to make it shorter.)
Or more generally, how does doing the simple low complexity thing benefit them?
If you are a manager who wants your reports to just do the work that makes your job easier and you look good then you are in for a long hard road in most corporate environments.
It also sounds like a pretty good way to incentivize sloppiness, but I guess it might work if X,Y,Z are very clearly defined, including tests (and their quality), documentation (and its quality), and what not.
I have had similar experiences. Divas too busy showing of their computer science skills, not understanding that software engineering should be about managing complexity and keeping it low.
The problem is when you work for a company that values leetcode style quizzing interviews, then all you hear is how this new guy is such a genius and how he aced the interviews. Then you are stuck dealing with him in whatever SaaS crud app codebase you have to work in.
The rub is that not all problems are as simple as others try to make them out to be. Engineers who are able to vastly think through all of the nuance from business requirements and other systems that adds necessary complexity are by nature going to be seem like engineers who are attempting to add unnecessary complexity. A lot of the examples posted in this thread don't necessary sound like this case, but it's something I see on a near-daily basis at one of the BigCos -- engineers complaining that X is too complex when they're only looking at it through the Y lens and missing the other Z edges.
Even Senior Principals seem to over-ask "why are you building this new service when you could just work with the other team to modify theirs?" when in actuality working with that team would also mean working with 4 other teams who all have set roadmaps; it would result in a complete failure to launch. Even very smart people in high positions can very easily not grok such a situation.
The flip side of that is that not all problems are as complicated as they seem. "You Ain't Gonna Need It" is a thing for a reason.
Often the best solution from a business perspective is to ignore the complexity and throw the problem down the line. Sure, it won't scale to 1 billion users, but right now we are a startup trying to acquire our tenth customer. And there is often more than one way to skin a cat: why waste developer time trying to optimize something like CPU & memory usage when you can just spend a few dollars and throw an extra AWS instance at it?
Someone smart will solve the issue a few years down the lines when it actually becomes an problem.
You had me until the last couple of sentences. Yes, the "twitchy smart" are actually just "immature clever" and it takes serious finesse to harness them to do something useful. The can be oh so frustrating to work with.
But the "wake makers"? You want to discard people who solve hard problems and invent things? Yes perhaps they have no place in _your_ team, but these types can be incredibly valuable to an organization, specifically because they are resistant to corporate middle management color-by-KPIs mediocrity.
The problem is that "wake makers" have a tendency to invent problems and then "solve" them. They will want to switch to a new framework because something about the old one bothers them. Heck, they'll even end up writing their own framework, in a language they themselves invented.
They see literally everything as a problem which can be solved by throwing as much complex code at it as you'll let them. Great for academia, terrible for business.
I totally agree with this comment. just such a person was the manager of the team I was on. and it wasn't really possible to argue. The only thing he understands from arguing is that he is right in the end. Imagine this happening even in the smallest of arguments.
100% agree. Do what you can with commit hooks (or however you enforce it. Some people argue these checks should only be done before merge), but ultimately the people you work with have to prioritize the team and the longevity/maintainability of the code base above their own desire to be clever or whatever it is they think they're doing. Oftentimes, as you hinted at, these types of people simply can't and won't change so getting rid of them is sometimes the only solution IMO.
I never worked in tech. I started learning programming at a young age with BASIC, thinking I know everything, gotos are good, single letter variables are good etc. Even arguing with teachers when my working but spaghetti code got marked a low grade. Probably the reason why I didn’t end up in tech.
My background is similar to GP's. I would say that my first inkling that something was wrong was working alongside someone more egregious than me. I also spent half of my career supporting a product built by someone who sold his company to my employer, started another company writing add-ons for the product he'd just sold and sold that to my employer, then started another project and sold that to Google. Six years of cleaning up his messes was enough.
I really don't know of a way to learn that lesson other than the Hard Way. I definitely remember coworkers pushing back on my ideas and writing them off as boring and unambitious. Fortunately they had seniority over me, so most of my harebrained schemes never saw the light of day.
You could deal with it by automating stuff, but then they'll see your automation and say "that's so cool," and proceed to 15x the size of your automation code.
My thoughts are that they need strong management to exert a lot of control and to come up with various ways of slowing them down and automated systems to gate check their code as much as possible (style guides, linting, static code analysis, tests and test coverage, auto-formatters, etc.). Otherwise, I think most people like this are just not worth having on a team because they aren’t interested in being part of a team and just want to solve problems they think are important. They will go off inventing all sorts of stuff, leaving a massive wake for the rest of the team. I also call them “wake makers”.