The fun part is, that in reality the mountain is rocky and craggy. It’s often foggy up near the top, so it’s hard to tell if you’re at the major peak or not. If you’re lucky there may be a guide you can ask, or a map. It’s worth it, near the top the air is fresher, the view is great, and the sun is warm (when it’s shining).
What I think does happen on the slopes that is valuable is learning. On the left you might be learning from people who already know, and on the right you might be exploring processes and practices hitherto unknown.
And what can you find on the top of the mountain? Well if your company is anything like mine, you’ll find some programmers arguing about where the peak is! The smaller the boulders you’re arguing about, the closer you probably are to the top.
This metaphor seems to be almost infinitely extendable, and maybe I’ll draw up a few more cards one day. It’s worth remembering that your current project, and your next project, are probably on whole different mountains! Team size, tech stack and the work you’re doing all change the kind of perfectionism that is going to work best. It’s also possible you’re mountain is really a volcano, and tectonic shifts in scope or learning may move the peak even as you’re climbing.
It might be pragmatic to stay on the left side of the slope in order to stay in sight of colleagues who are still climbing. What you mustn’t do is settle with sitting on the slopes, not climbing, because it seems too steep. Try and work around it. Climb as a team, or maybe find a guide who has climbed similar peaks before.