This is basically how things work at Valve, since it's almost entirely an engineering driven system that keeps us moving forward. Therefore there's always incentive for anyone in any non-engineering department to pick up what they can to make their work easier or more efficient. Of course the converse is true, too, you see engineers learning more about the art pipeline, business, et. as part of the concept of wanting to become more T-shaped.<p>My quintessential example of this is seeing artists create a new effect, model, or sound, and lacking the appropriate hooks in code, go into the C++ source tree and hook their assets into the game themselves.
> One of the core tenants at Yipit is that everyone should think and act like an entrepreneur.<p>Does everyone get to learn how to do sales, marketing, customer interaction, forcasting, and corporate financing too? Seems like they are equating "being able to code" with "being a successful entrepreneur" when it's not that at all. (See <i>The E-Myth Revisited</i>)
Concurrent with learning to code, I've often wished that my co-workers would at least learn how to write parseable documents.<p>I don't mean something as structured as XML. I mean something as simple as keeping notes/numbers/links in a spreadsheet, which enforces at least some degree of information integrity (<i>why are there a bunch of missing/ambiguous dates for these incidents?</i>). And if it's done well, then all it takes is a simple script to parse that data into something usable, either a webpage or an interactive report.<p>Theoretically, it seems like you could learn to do that without learning to code. But maybe once you've learned for loops and if statements, it's much easier to understand the value of parseable documents.