quite the contraryQuote:
1) Not everything in life is easy. Nobody said that all code will or should be easy to understand.
in fact, "write working, but first of all simple and understandable code (possibly readable as plain english) - KISS!" is the first thing they usually tell you when you first join a team (if you dont already know it)
usually followed by "dont do microoptimization, focus on the algorithm and the design first" and the coding conventions and practices (involving writing documentation - lots of it) you WILL have to follow... if you want to retain your job and even see your code compile, that is
a checkstyle pass is usually in place to ensure all code conforms to project-wise criteria and metrics (thus if some method or variable has a non conforming name, or is too long or has a too high cyclomatic complexity, the build process fails, ie the build is broken, and you're the one who's broken the build),
but more importantly, you're usually told that the whole team is responsible for the whole codebase - this means that you have to be able to understand any of your teammates' code as if it were yours, and any of teammates will have to be understand yours as it it were his/hers, so there should be no code "popping out" due to a particular specific style, instead project code shall have "its own" uniform style
otoh, due to this, if you understand your teammates' code but they're not able to understand (and maintain) your code as theirs, it means you havent done enough to conform to achieve uniform clarity - thus it's also your fault
doesnt matter at all when/if the lone uber-programmer goes his own way, producing code that works but is not easily understandable, is (like all fresh code) possibly buggy (but being obscure or convoluted is hardly debuggable) and is not documented - at which point other developers ("average" ones) developers are tasked with auditing and debugging his codeQuote:
2) A single gifted programmer can do the work of tens of average developers.
at which point they may decide it's better /effective /future proof to revert and rewrite it that spend longer trying to sort it out...
get off your high horse, please, and consider that in the above no money is involved - it's only about professionalism in being a team developerQuote:
The fact that you're professionally hired and paid says nothing about your skill. Focus on pay only says that you are a prostitute, as opposed to an actual practitioner of an art.