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.
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.
You work at Valve? That's cool, and this may sound kind of dumb but oh well: you guys are my heroes. I am an engineer who does a lot of computer graphics programming and I have always looked up to you guys.
I know a lot of people have seen that new employee manual but I assumed that only applied to the 'elite' & that there is a giant pool of peons that support them. Am I right or do the people doing things like billing and tech support get the same royal treatment?
For example, the support team has internal tools that they use to do their job, and for the most part do all development of that tool themselves. Sometimes other developers help them out with specific features that are in the domain of that developer, but most of the tool grows as the support team needs e.g. better wizards to answer tickets quicker. Several members of the support team are taking programming classes, too, to learn how to do more developmental work along these lines.
Concurrent with learning to code, I've often wished that my co-workers would at least learn how to write parseable documents.
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 (why are there a bunch of missing/ambiguous dates for these incidents?). 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.
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.
This is an important philosophical question: should humans become better at communicating in machine-parseable ways, or should machines become better at parsing human communication?
Preferably the latter, but human communication is inherently ambiguous and heavily sensitive to context, and so actually implementing this is really hard* and thus the former is actually (slightly) feasible at the moment.
*In fact, probably impossible: how often does one have to actually ask the author what they actually meant? Not appropriate for offline computer processing.
> One of the core tenants at Yipit is that everyone should think and act like an entrepreneur.
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 The E-Myth Revisited)
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.