I would assume it was (to most of them) but knowing and doing are two very different things (i.e. everyone knows smoking is bad for you and yet people still do it / start doing it).

So to me the far more interesting and helpful question to answer is: Are there most efficient ways to keep people from making the same mistake over and over, other than repeating what everyone already knows, over and over?

Identify the forces that drive people away from best practices most often and give us ideas and tools to tackle them.

The best approach is to apprentice with someone who knows not to make them. If you can't do that, check in with someone regularly who:

  1. Won't sugar coat feedback,
  2. Has shipped games,
  3. Has a healthy sense of humility, and
  3. Is genuinely concerned about your success.

I really like sitting on advisory boards in this role, but my secret to being good at it is that I regularly ask for feedback from others who are smarter than me at the things I don't get (which is most things).

In the long run, it's like most things. It takes practice.

To the criticism that the game industry is behind the rest of the software industry in software engineering practices, I do believe the rest of the software industry can eat something phallic. :)

I'd like to see them pull off what we have to with about 10X the competition, juggling massive game assets, a fraction of the budget, finance, and exit options, needing to meet a tough frame rate budget (even more exacting now with VR), all issues GPU-ish (when was the last time you wrote a shader, Mr. Website Developer?), and having people with a huge range of technical skills requiring direct access to the source/asset repo.

Something about your last paragraph rubbed me the wrong way. Sorry.

> about 10X the competition

Steam added 1500 games in the first 7 months of 2015. Crunchbase had over 8000 investments in 2015. So I don't think that's true, even accounting for a Christmas peak.

> juggling massive game assets

Lots of data goes into games, lots of data comes out of websites. The difference to my eyes is that the industry has multiple, principled, well-understood frameworks to deal with the data problem and the games industry has...what? Maybe the state of the art has moved on in the last 5 years but when I left it was all "well it's just a DAG, how hard can it be to write a tool to recursively build it".

> a fraction of the budget, finance, and exit options

Being willing to work for less and with fewer resources is not a sign of good engineering practice. I don't know if I'd say it's the opposite but it's at best irrelevant.

> a tough frame rate budget

Not very different to needing to meet tough latency/error rate SLAs, except instead of failing TRC (or getting your exec producer to stare down MSFT/Sony), you'll just go broke. Oh, and you don't know what the SLA is, ever, so it's a continuous process of tradeoff.

> all issues GPU-ish (when was the last time you wrote a shader, Mr. Website Developer?)

Ignoring that some "website developers" (many of whom are not "Mr" - something else that the games industry does not do well at) do write shaders in the form of GPGPU optimization of ML tasks, obviously tasks differ. Let's not pretend that banging out something in Cg is PhD-level shit. It's not harder than writing a Spark job, for sure.

> having people with a huge range of technical skills requiring direct access to the source/asset repo.

You have Mr. Blow upthread sneering at Twitter for employing 4000 people to build something "trivial" but you think that each of those people have identical programming chops in every bit of the code they touch? If there's a single thing that argues against your idea it's this - the rest of the industry has become pretty good at modularizing areas of the business and auditing changes to it with code review, build/asset/deployment tagging etc. The last games company I worked at, someone stayed at the office until 5am before going on holiday for a week and sent an email that effectively said "I've rewritten quite a bit of the engine, you'll probably need to fix the build because I didn't test anything, see you in a fortnight". People gasp when gmail/twitter/facebook is down for half an hour but I've worked in places where there _wasn't even a canonical build_ that could be broken.

"Let's not pretend that banging out something in Cg is PhD-level shit."

Almost everything you implement in CG is "PhD-level shit". Implementing techniques from SIGGRAPH papers in your game engine are usually non-trivial. Game engines/games are some of the most complex systems in software engineering, the complexity can't be compared to web apps at all.

I think by CG you mean computer graphics? Cg was nVidia's shader language that compiled to HLSL or GLSL. Writing shaders is sometimes serious business but more often than not it's just as drudgey as writing CRUD pages.