
The 7 Habits of Highly Dysfunctional Developers (1998) - TheLegace
http://www.ganssle.com/articles/7habits.htm
======
joe_the_user
It's kind of a random collection.

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.

------
buckbova
Similar to 7 habits of highly overrated people.

[https://news.ycombinator.com/item?id=6965295](https://news.ycombinator.com/item?id=6965295)

or ineffective people.

[https://news.ycombinator.com/item?id=1430695](https://news.ycombinator.com/item?id=1430695)

------
coolsunglasses
The glorify globals thing is...a bit off.

The real problem with global state is provenance, not the global state itself.

Global state has the property of being identifiable, debuggable, and
inspectable.

Add provenance and you have a log from which you can see how your program
executed and who did what.

Local state isn't necessarily problematic but local mutable state can make
some things really hard to track down / reproduce. "Subtle" bugs are bad.

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).

~~~
taspeotis
I think avoiding global variables is a good thing. Maybe at some large scale
global variables are unavoidable but I've had good results wrapping what would
otherwise be a global variable into a Context class and injecting IContext
into everything that needs it. IContext is bound to Context with singleton
lifetime in an inversion of control container.

The benefit of this over actual global variables is that I can create as many
IoC containers as I want and they can have their own "global" state. It's
great if the application inside of the IoC container is solving part of a
problem that's embarrassingly parallel - rather than creating 8 processes you
create 8 threads and one container for each.

~~~
logn
Shh. Don't tell the ineffective embedded devs about IoC containers or they'll
be able to take their game to a whole new level. Dependency injection is
great, but frameworks like Spring suck all the benefit out of it in my mind.
Great, so I have a nice interface I can implement to re-use your module...
except now I need to build a Spring app...

------
jrochkind1
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.

