It's kind of a random collection.<p>A lot of these are bad things programmers do when there's a lot of pressure to get results quickly. I tend to think that keeping to standards, estimating realistically, keeping discipline etc are things that managers need to make a priority - if a manager just demands results and won't allocate time for proper construction methods, management gets these bad results and is responsible. 'Course the programmer in a good position can just quit but what someone actually does depends on their life position and thus cutting corners isn't necessarily their fault.
Similar to 7 habits of highly overrated people.<p><a href="https://news.ycombinator.com/item?id=6965295" rel="nofollow">https://news.ycombinator.com/item?id=6965295</a><p>or ineffective people.<p><a href="https://news.ycombinator.com/item?id=1430695" rel="nofollow">https://news.ycombinator.com/item?id=1430695</a>
The glorify globals thing is...a bit off.<p>The real problem with global state is provenance, not the global state itself.<p>Global state has the property of being identifiable, debuggable, and inspectable.<p>Add provenance and you have a log from which you can see how your program executed and who did what.<p>Local state isn't necessarily problematic but local mutable state can make some things really hard to track down / reproduce. "Subtle" bugs are bad.<p>Things like modern games tend to are often developed with "local" data in the small being immutable and larger data being global (mutable is a coin-toss depending on how you're thinking about it).
From 1998, this is mostly interesting as a sort of historical look back -- this is what we were complaining about 15 years ago. some ways similar and some different to what we're complaining about today.