I've encountered a few Ricks. The dirty little secret is, they aren't actually as good as they think they are. Have you ever looked at a solo developer project? It'll be full of strange code that matches the mind of the solo developer. THAT's what's happening here. One you let a Rick go, they'll fuck up the codebase, rewriting everything into their own style and pushing everyone else out (because who wants to work on Rick's weird code?). When other developers try to become involved, the Rick will effortlessly jump through layers of abstraction (which Rick wrote) and help them solve the problem. It would take them 10x as long to solve it on their own. Oops - shouldn't have let Rick loose to begin with!
It isn't a matter of stacking more Ricks. Ricks don't like working with Ricks. That'll lead to high drama and one or more Ricks flaming out in a blaze of glory. Each Rick has their own code style, why would they work with someone else's code? If multiple people are all claiming that "The existing design is terrible, let me rewrite it", while the person who made the existing design is still there, and is a Rick, then you'll just have a codebase being torn in multiple directions.
Yes, poor management enables this. If you know how to handle these people, you can surround each Rick with non-Ricks and force them to document their code, and justify every rewrite, etc. Like a nuclear reactor surrounded by graphite. But ideally you want to turn a Rick into a non-Rick. Usually that involves taking them down a notch. Maybe you can set up a John Henry vs the Machine style situation. Have the Rick try to out-code a team of non-Ricks. The Rick can't compete, despite writing 10x as much code. It's almost like layers of abstraction aren't a universal benefit. Huh.
Comments
I've encountered a few Ricks. The dirty little secret is, they aren't actually as good as they think they are. Have you ever looked at a solo developer project? It'll be full of strange code that matches the mind of the solo developer. THAT's what's happening here. One you let a Rick go, they'll fuck up the codebase, rewriting everything into their own style and pushing everyone else out (because who wants to work on Rick's weird code?). When other developers try to become involved, the Rick will effortlessly jump through layers of abstraction (which Rick wrote) and help them solve the problem. It would take them 10x as long to solve it on their own. Oops - shouldn't have let Rick loose to begin with!
It isn't a matter of stacking more Ricks. Ricks don't like working with Ricks. That'll lead to high drama and one or more Ricks flaming out in a blaze of glory. Each Rick has their own code style, why would they work with someone else's code? If multiple people are all claiming that "The existing design is terrible, let me rewrite it", while the person who made the existing design is still there, and is a Rick, then you'll just have a codebase being torn in multiple directions.
Yes, poor management enables this. If you know how to handle these people, you can surround each Rick with non-Ricks and force them to document their code, and justify every rewrite, etc. Like a nuclear reactor surrounded by graphite. But ideally you want to turn a Rick into a non-Rick. Usually that involves taking them down a notch. Maybe you can set up a John Henry vs the Machine style situation. Have the Rick try to out-code a team of non-Ricks. The Rick can't compete, despite writing 10x as much code. It's almost like layers of abstraction aren't a universal benefit. Huh.