A friend of mine calls it "the curse of the gifted" -- a tendency to lean on your native ability too much, because you've always been rewarded for doing that and self-discipline would take actual work.
You are a brilliant implementor, more able than me and possibly (I say this after consideration, and in all seriousness) the best one in the Unix tradition since Ken Thompson himself. As a consequence, you suffer the curse of the gifted programmer -- you lean on your ability so much that you've never learned to value certain kinds of coding self-discipline and design craftsmanship that lesser mortals *must* develop in order to handle the kind of problem complexity you eat for breakfast.
But you make some of your more senior colleagues nervous. See, we've seen the curse of the gifted before. Some of us were those kids in college. We learned the hard way that the bill always comes due -- the scale of the problems always increases to a point where your native talent alone doesn't cut it any more. The smarter you are, the longer it takes to hit that crunch point -- and the harder the adjustment when you finally do. And we can see that *you*, poor damn genius that you are, are cruising for a serious bruising.
As Linux grows, there will come a time when your raw talent is not enough. What happens then will depend on how much discipline about coding and release practices and fastidiousness about clean design you developed *before* you needed it, back when your talent was sufficient to let you get away without.
http://lwn.net/2000/0824/a/esr-sharing.php3
How Linus Torvalds works (as written in this post) is how I cook. ;) I don't measure, I eyeball everything. I do things until they "look right" and then I stop.
I would never ever ever do that fast, loose, play-it-by-eye-and-natural-talent with a design system, because I have learned that it just doesn't scale. In fact, I design... design systems specifically to avoid or mitigate the "curse of the gifted".
At the end of the day, a design system that isn't easy enough to use by all involved in the SDLC, so much so that it becomes the default pit of success that teams fall into together... is a failed design system. Or one that is currently failing, at any rate. Failures can be remedied, so there is that.
I see a disturbing tendency to approach design systems (especially for enterprise) with far too much reliance on 'the curse of the gifted'. This is especially evident when every piece of a design system is designed on an ad-hoc basis, with no regard to how it fits into everything else. If the designer's eye is good enough, they can skate by on the curse of the gifted - until they cannot, anymore. And their teams? God help their teams.
When it comes to design systems - I want the opposite of skating by on talent. I want to help build design systems that enable delivery teams to fall into the pit of success together. The kinds of systems that improve collaboration for everyone, because of a clear, shared understanding of what it is we want to do, and what we have on hand to do it. Design systems where the default is usually the right choice, where guesswork is kept to a minimum... and yet where necessary changes can be made on the fly with the minimum of cost, or drama. And while I'm describing my ideal pony, I want to be able to stay and see such a system grow and evolve over time.
Right now, I'm still looking for that pony. Maybe I'll get lucky. ;)
Right now, I'm still looking for that pony. Maybe I'll get lucky. ;)