To my chagrin, or even dismay, I've discovered that most of the time people who 'code circles around someone' have found a way to handicap everyone else.
When you construct code to exactly fit your own mental model of the universe, you filter out a lot of other potential collaborators. You create a system where you have to do certain work because nobody else can. It's easy to interpret this as being about your qualities instead of your failings.
And eventually this bites everybody on the ass. These people will often become a bottleneck, because while it may look like they won't delegate to others, the truth is that they cannot. They don't know how, and they're standing at the bottom of a hole before it becomes apparent.
Even the idea of "coding circles around someone" is kind of odious -- team sport everybody. Yes you will have better and worse developers but if it's actively your aim to code circles around someone on your team you're not doing your team a service.
I tried my hand at basketball as a youth and the specter of the ball hog loomed big in the head of the coach. Fast forward six years and I'm a club cyclist, where I learned a lot about teamwork that I think most programmers never really learn. When you understand something but have no shared context, there can be a lot of resistance to change.
Peculiar to cycling, hiking, rowing, and only a handful of other team activities is how concretely they demonstrate both failing or succeeding together, and how our strengths and weaknesses complement each other. A person having a good day can bolster the person having a bad one, via literal load shedding, and that feedback is immediate and obvious to all. With basketball, football, or many other sports, this can be pretty subtle, and may be lost entirely on spectators.
Yes I believe I understand and agree with what you are talking about.
I was a varsity wrestler and football player in high-school and in football you can have one break out star and it really can considerably change the game but they are still largely supported by everyone on the field playing their position as best they can. Your QB can be absolutely amazing but if a guard or tackle is slacking that QB is going to be sacked over and over but in most cases it's a lot harder to see the impact.
In wrestling everyone can individually perform amazingly but at most you're only contributing 6 points to the score but if you've ever seen one wrestler perform well at the top of the lineup you can just see how it influences everyone else and triggers a run, like you said immediate and obvious to all.
Sometimes I think/know that I'm this person, and it worries me because I see it as squeezing my future to a very narrow path.
My project is "general", "flexible", and what I consider "done right" (time<->quality issues aside), and definitely requires a specific mindset. As you suggest, I often find myself, internally, blaming others for not being able to "see" it or caring enough to understand it, but I can make it dance beautifully when something new/strange needs to be incorporated, often "saving the day".
I know that if I left now, it would swiftly collapse, bringing the whole team to a halt. Management has also realized this, resulting in some nice shiny golden handcuffs.
The new developer we hired (since I did become The bottleneck) isn't the greatest (his performance reviews agree), and is slowly breaking things, but I'm only half stopping him because I'm trying to assume my rigidity in the "correctness" must be flawed, and I don't want to damage the relationship any more than it has been.
Now I'm in the progress of scaling this 10x, and I don't want to be a 10x bottleneck.
The only thing that holds back m imposter syndrome, and makes me think it's my, as you say, qualities, is that, after nearly 3 years, the churn from many of the other teams are finally converging towards the one implementation that I've had working, stably, in that same time span, for all of the same reasons that I implemented it the way I did.
tldr;
It's easy to interpret this as being about your qualities instead of your failings
This is probably me. So, what's the solution? Re-think the whole concept to come up with a different implementation? Simplify?
I've been there. I an built entire deployment/change-management system in very small IT teams (1 other person with different skills from mine). We eventually got the go-ahead to grow the team, including more admins with my skill set. At that point, I had written pretty much the entire thing while the other admin had been focusing on tasks related to their skills.
Whenever a request came in for something regarding the system, I would have to force myself to sit down with one of the other admins and walk them through making the change to close the ticket. It took 3-4 times as long to do the work that way, but after a few weeks, I could start assigning some tickets to them directly and eventually the time savings exceeded the expenditure and I could go back to big-picture planning.
It's a hard lesson to learn the first time, but worth the pain of going through.
Don’t take on straightforward tasks in the name of expediency. That’s the hole you’re already in and you have to stop digging.
A little pair programming or watching someone use the new thing you wrote can go a long way toward informing you on how to close the gap. The tricky bits may not be that tricky for others, and the obvious bits often aren’t.
It’s not all roses, of course. The person who doesn’t understand that you built a ladder for them to climb may complain loudly about how long it took you to get to the top of it. It takes a somewhat special team to be able to do the right thing and not get punished for doing so.
Somewhere in between that and Lord of the Flies is most teams.
Comments
To my chagrin, or even dismay, I've discovered that most of the time people who 'code circles around someone' have found a way to handicap everyone else.
When you construct code to exactly fit your own mental model of the universe, you filter out a lot of other potential collaborators. You create a system where you have to do certain work because nobody else can. It's easy to interpret this as being about your qualities instead of your failings.
And eventually this bites everybody on the ass. These people will often become a bottleneck, because while it may look like they won't delegate to others, the truth is that they cannot. They don't know how, and they're standing at the bottom of a hole before it becomes apparent.
You are 100% spot on. Lisp is not a single language. It's whatever language has been constructed around the given problem. This is the Lisp Curse:
http://winestockwebdesign.com/Essays/Lisp_Curse.html
Even the idea of "coding circles around someone" is kind of odious -- team sport everybody. Yes you will have better and worse developers but if it's actively your aim to code circles around someone on your team you're not doing your team a service.
I tried my hand at basketball as a youth and the specter of the ball hog loomed big in the head of the coach. Fast forward six years and I'm a club cyclist, where I learned a lot about teamwork that I think most programmers never really learn. When you understand something but have no shared context, there can be a lot of resistance to change.
Peculiar to cycling, hiking, rowing, and only a handful of other team activities is how concretely they demonstrate both failing or succeeding together, and how our strengths and weaknesses complement each other. A person having a good day can bolster the person having a bad one, via literal load shedding, and that feedback is immediate and obvious to all. With basketball, football, or many other sports, this can be pretty subtle, and may be lost entirely on spectators.
Yes I believe I understand and agree with what you are talking about.
I was a varsity wrestler and football player in high-school and in football you can have one break out star and it really can considerably change the game but they are still largely supported by everyone on the field playing their position as best they can. Your QB can be absolutely amazing but if a guard or tackle is slacking that QB is going to be sacked over and over but in most cases it's a lot harder to see the impact.
In wrestling everyone can individually perform amazingly but at most you're only contributing 6 points to the score but if you've ever seen one wrestler perform well at the top of the lineup you can just see how it influences everyone else and triggers a run, like you said immediate and obvious to all.
Sometimes I think/know that I'm this person, and it worries me because I see it as squeezing my future to a very narrow path.
My project is "general", "flexible", and what I consider "done right" (time<->quality issues aside), and definitely requires a specific mindset. As you suggest, I often find myself, internally, blaming others for not being able to "see" it or caring enough to understand it, but I can make it dance beautifully when something new/strange needs to be incorporated, often "saving the day".
I know that if I left now, it would swiftly collapse, bringing the whole team to a halt. Management has also realized this, resulting in some nice shiny golden handcuffs.
The new developer we hired (since I did become The bottleneck) isn't the greatest (his performance reviews agree), and is slowly breaking things, but I'm only half stopping him because I'm trying to assume my rigidity in the "correctness" must be flawed, and I don't want to damage the relationship any more than it has been.
Now I'm in the progress of scaling this 10x, and I don't want to be a 10x bottleneck.
The only thing that holds back m imposter syndrome, and makes me think it's my, as you say, qualities, is that, after nearly 3 years, the churn from many of the other teams are finally converging towards the one implementation that I've had working, stably, in that same time span, for all of the same reasons that I implemented it the way I did.
tldr;
This is probably me. So, what's the solution? Re-think the whole concept to come up with a different implementation? Simplify?
I've been there. I an built entire deployment/change-management system in very small IT teams (1 other person with different skills from mine). We eventually got the go-ahead to grow the team, including more admins with my skill set. At that point, I had written pretty much the entire thing while the other admin had been focusing on tasks related to their skills.
Whenever a request came in for something regarding the system, I would have to force myself to sit down with one of the other admins and walk them through making the change to close the ticket. It took 3-4 times as long to do the work that way, but after a few weeks, I could start assigning some tickets to them directly and eventually the time savings exceeded the expenditure and I could go back to big-picture planning.
It's a hard lesson to learn the first time, but worth the pain of going through.
Don’t take on straightforward tasks in the name of expediency. That’s the hole you’re already in and you have to stop digging.
A little pair programming or watching someone use the new thing you wrote can go a long way toward informing you on how to close the gap. The tricky bits may not be that tricky for others, and the obvious bits often aren’t.
It’s not all roses, of course. The person who doesn’t understand that you built a ladder for them to climb may complain loudly about how long it took you to get to the top of it. It takes a somewhat special team to be able to do the right thing and not get punished for doing so.
Somewhere in between that and Lord of the Flies is most teams.
Read Good To Great, The Phoenix Project, etc. It's about collaboration, not implementation.
May i suggest working on becoming a teacher / mentor / enabler for your teammates and pitching this plan to managment?