I'm skeptical of these lists because people can work through things. For example, the stuff listed under "Inability to determine the order of program execution" is something that many people will get jammed on eary on as they try to take their brains (which is honed on the syntax of school level maths) into the programing world (where equals is an instruction rather than an assumptions). Another one is "Lisp is opaque to you". It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire. If someone isn't a natural programmer but is happy to work at it to overcome hurdles then there's nothing wrong with that.
One of the examples of bad technique is:
Homebrew "Business Rule Engines"
Can anyone give examples of the sorts of things the author means by this? What sort of systems have people seen, and why is it necessarily a bad thing?
"It's very sweet for MIT types to make these declarations from mount olympus, but lisp is something that can take time to acquire."
Don't worry. In the Valley, people from MIT don't have a good reputation as great programmers. For some reason, their education is a lot of 'theory' and less practice.
Apart from Standford\Caltech, Some of the best schools that produce great programmers are your average state school.
I have a theory behind this, which may be correct. Learning to be a great programmer takes years, and school is just the start. People that do well enough go to something like MIT, think they are already very smart, and don't try hard when they come out.
But if you are hungry, and smart, and just happen to go to your average state school, you probably will do better, as you probably are humbler to begin with.
It seems when the rubber meets the street, in startups, building products, that's where the great programmers are made, and lisp is not a requirement to know to be a great programmer, or actually build great products. Having an idea of what functional languages are is a must, knowing them is not.
nope not the case,
I know a bunch of people at these various schools, and the crux of the problem is that theres a huge culture at MIT (and moreso than many peer schools) of celebrating herculean last minute efforts that get the grade. This is great for experimental hacking on a weekend, and "good enough" for research, but it does not encourage an incremental design sensibility, owing to its last minute nature.
This is not to say that any of these people are bad at what they do, they just have bad habits that they need to walk off, but first someone needs to tell them!
the crux of the problem is that theres a huge culture at MIT (and moreso than many peer schools) of celebrating herculean last minute efforts that get the grade
That's a very astute observation. I work and have worked with many MIT people, and even TA'd an MIT course. The "all nighter" hazing ritual culture was very prevalent. To this day, my friends who went to MIT prefer to work 24 hour shifts, late nights, and on weekends - even though they've been out of school for a decade. In addition, MIT had a culture of boot-camp style negative reinforcement. "You suck, are not smart enough and are lazy, work harder" was the driving attitude. (at least it was in the late 1990s)
In contrast, when I moved to the west coast, all the Stanford people I met were more about basking in their obvious awesomeness and mastering time management. Get the project done early, schedule everything around ultimate frisbee team and rock climbing club, go to the outdoor concert on Friday night and still make it up to Tahoe for the weekend.
I think it's much simpler than that: Most good programmers are self taught. School is just increasing their exposure and nailing down some good habits.
Even fricken DeVry will help you with that if you are already motivated.
While I'm not an MIT student, I think the school puts a huge emphasis on being pragmatic ( see http://news.ycombinator.com/item?id=530659 ). Also, given the huge disparities in abilities of the freshmen there, I'd reckon that, more often than not, an MIT education would be a humbling experience.
My dad, an MIT alum (though in chemistry, not CS), likes to tell the story of how whenever new grad students arrive on campus, everybody's wearing Phi Beta Kappa rings. By the second week, they've all disappeared. When everybody's got one, flaunting yours displays arrogance a whole lot more than intelligence.
Well, his alternative careers for those who with an inability to determine the order of program execution are pretty good. I wouldn't mind being a civil engineer.
I (a Haskeller) interviewed there, and ended up in an long debate with their CTO Yaron Minsky poking at warts in each other's pet languages and patterns of thought -- in retrospect we were trolling each other pretty hard just as a natural reflex.
He doesn't. What he really cares about is memory consumption, especially stack consumption. Order of execution can influence that a lot: unevaluated chunks may hold quite a lot memory, and their evaluation in normal order may overflow the stack (in most implementations).
These problems are called "lazyness leaks". This is why he still cares about order of evaluation.
This one time I had to work at a place where a postgresql install was not only the main datastore, it was also the main system message bus by abusing notifies. Further the enterprise message bus was a homebrew thing that was written to both pass messages and do RPC, oh and be the main way to monitor if a remote site was up or not. I think both of those count as well.
For those who are curious: given these were linux systems, d-bus was the right answer for the former, and something like RabbitMQ or OpenAMQP, or even JMS solutions would be the proper answer to the latter.
Good question! The postgres solution was unexcusable, it was always used side-by-side with dbus. The other was around before any affordable[1] enterprise message busses existed, however as that changed the buggy solutions was still touted as "amazing new tech that keeps us ahead ofthe competion. No we can't switch to something else".
[1] Affordable being defined as: this particular company could pay for it without going out of business.
One of the examples of bad technique is:
Can anyone give examples of the sorts of things the author means by this? What sort of systems have people seen, and why is it necessarily a bad thing?