Jonathan Blow

so how to change surrounding and how to study on good examples when you can't distinguish between good and bad on the start of career? Also more experienced colleagues can show bad examples as 'right' thing

It is difficult!

Do you remember? http://doc.cat-v.org/bell_labs/utah2000/utah2000.html … Anything changed? I don't think so.

Do you think formal methods have a role to play here? Maybe as a way of specifying the simple behavior thus allowing cruft to be shed while maintining a metric for "good"? Or will necessary complexity quickly outpace any formal spec?

Formal methods are mostly orthogonal. The impulse to increase complexity is independent of that.

Is there anything to curb that impulse apart from just, I guess, knowing better? If not, how is knowing better passed to the next developer? Or is the hope to gather a small coalition of people who know better to write good foundations to teach by example?

I think it just involves knowing better. If we change the way things are taught, more people will know better, but that probably takes a long time.

Can we create tools that make complexity and its cost more painful and visible, like a time travel debugger where you move around the execution with WASD, so every line of code makes the number of keypresses bigger? Something like this: http://clinei.github.io/codeliteral 

I definitely want to make some kind of tool that shows growth in the complexity of your code base over time..

I've been looking at tools like this, and they all have slow and cumbersome UI, so I made a proof of concept that should be as intuitive and responsive as a game. If you have 20 minutes, could you check it out and let me know what you think?