Really good post. I can relate to all the points you mentioned. Last week our team had a board game night, we played Terraforming Mars - it was a good moment to connect outside of usual work.
P. S. I took your idea from your XP book of having values, principles, and practices into my work. We had a session with the team where we put those down in writing - it has been immensely valuable for us, thank you.
Is the lumper/splitter dichotomy an instance of a larger class of fundamental disagreements about what good code and good design look like? There seems to be no end of these.
We need to find some concrete ways to build this "shared..." approach. In my experience, working collaboratively is essential. Each team member will have their contribution and the results will be better. Collaborative work and continuous improvement is even better.
As basic principles, a vision adapted to the context is needed on how the design is kept clean and how it evolves.
A word I started emphasizing more recently is "strategy". Why do different political groups, from the same side, that share the same end goal, can be fighting so much on what to do. Because they disagree on the strategy.
Even for a shared target, there are many different strategies, many are possible, but with a lot of unknown on which one would work or not. What it will look like depending on a strategy, which strength and weaknesses can sometime be grasped. But is it necessary, is it going to work at all, is not as clear.
We are trained for competitive environments, where the best strategy wins over the not as good one. So fighting over strategy is important, because it is success or not. In a cooperative environment, with many actors, strategy has a way different impact and should be addressed differently.
Some started noticing this and describe their reviews as "personal", "style", "how I like it", "nitpick" instead of principle of this must be done differently.
Does the code work, yes. But there may be issues in the future if we need to do A B C. Is it worth or not putting more effort for this? It might bite us if we don't, or we may spend a lot of effort for nothing practical, it's strategy. You do not need to sit on your principle to accept that code you do not like (for good reason, of course).
Then you can describe more what are the strength, weaknesses you see in your strategy compared to the other one. And you can more easily comply to another strategy, as it did not affect your values, just the way to reach them.
For years, I have paraphrased "Zen and the the art of Motorcycle Maintenance".... Regarding the question "Are you a good welder?" there 2 contexts:
* The production line welder who knows ahead what's needed and perfects that over time.
* The repair shop welder who never knows what's coming up next, yet gets the job done.
I've used this set up many times to set up discussions in training classes.
I have often contrasted "good welder" with "good actor" by comparing a good Shakspearean actor (who repeats 400+ year old lines) and an improv actor (who says lines that didn't even exist at the beginning of their sentence).
You've just added many more dimensions to that discussion. Thanks!!!
P.S. I shared the welder distinction at a software mender session earlier this week, and someone (who was not even born when the book was popular) gave a new take on my well-worn story --
> The shop weld becomes the production weld.
He nailed it! And gave me insight into my own story (which built on the stories of other bards - William Shakespeare and Robert Pirsig).
Really good post. I can relate to all the points you mentioned. Last week our team had a board game night, we played Terraforming Mars - it was a good moment to connect outside of usual work.
P. S. I took your idea from your XP book of having values, principles, and practices into my work. We had a session with the team where we put those down in writing - it has been immensely valuable for us, thank you.
Can I submit an MR to remove the "s" from the first "programmer" in “I’m a programmers, you’re a programmer, our work affects each other.”?
Is the lumper/splitter dichotomy an instance of a larger class of fundamental disagreements about what good code and good design look like? There seems to be no end of these.
We need to find some concrete ways to build this "shared..." approach. In my experience, working collaboratively is essential. Each team member will have their contribution and the results will be better. Collaborative work and continuous improvement is even better.
As basic principles, a vision adapted to the context is needed on how the design is kept clean and how it evolves.
A word I started emphasizing more recently is "strategy". Why do different political groups, from the same side, that share the same end goal, can be fighting so much on what to do. Because they disagree on the strategy.
Even for a shared target, there are many different strategies, many are possible, but with a lot of unknown on which one would work or not. What it will look like depending on a strategy, which strength and weaknesses can sometime be grasped. But is it necessary, is it going to work at all, is not as clear.
We are trained for competitive environments, where the best strategy wins over the not as good one. So fighting over strategy is important, because it is success or not. In a cooperative environment, with many actors, strategy has a way different impact and should be addressed differently.
Some started noticing this and describe their reviews as "personal", "style", "how I like it", "nitpick" instead of principle of this must be done differently.
Does the code work, yes. But there may be issues in the future if we need to do A B C. Is it worth or not putting more effort for this? It might bite us if we don't, or we may spend a lot of effort for nothing practical, it's strategy. You do not need to sit on your principle to accept that code you do not like (for good reason, of course).
Then you can describe more what are the strength, weaknesses you see in your strategy compared to the other one. And you can more easily comply to another strategy, as it did not affect your values, just the way to reach them.
For years, I have paraphrased "Zen and the the art of Motorcycle Maintenance".... Regarding the question "Are you a good welder?" there 2 contexts:
* The production line welder who knows ahead what's needed and perfects that over time.
* The repair shop welder who never knows what's coming up next, yet gets the job done.
I've used this set up many times to set up discussions in training classes.
I have often contrasted "good welder" with "good actor" by comparing a good Shakspearean actor (who repeats 400+ year old lines) and an improv actor (who says lines that didn't even exist at the beginning of their sentence).
You've just added many more dimensions to that discussion. Thanks!!!
P.S. I shared the welder distinction at a software mender session earlier this week, and someone (who was not even born when the book was popular) gave a new take on my well-worn story --
> The shop weld becomes the production weld.
He nailed it! And gave me insight into my own story (which built on the stories of other bards - William Shakespeare and Robert Pirsig).