[zooso]

We are still trying to figure out the right size of projects and who it benefits the most. Obviously, We have heard arguments for the both sides. Would really appreciate if I could get your input on it too. If you are interested in talking for few minutes at anytime. Email me at : [e-mail]

[pacala]

An example of project that impresses me to no end: The Monte Carlo Revolution in Go, http://remi.coulom.free.fr/JFFoS/JFFoS.pdf, http://en.wikipedia.org/wiki/Monte_Carlo_tree_search. Took a simple well-known technique, applied it to a simple, well known, but notoriously difficult problem, and got better results than much more "sophisticated" attempts prior. You can code that in a couple of weeks.

The art of matching a problem with a solution with minimal effort is much much more valuable that spouting out thousands upon thousands lines of shoddy code with poor understanding of the fundamentals.

It's ironic how history rhymes. The "enterprise rockstar"(1) programmer of today is very close to the stakhanovite of yesteryear, building his reputation on an army of people making his code actually work. http://en.wikipedia.org/wiki/Alexey_Stakhanov#Record_dispute...

(1) I use "enterprise rockstar" here in a technical narrow sense of someone that spits out a ton of code that kind of works, but to actually operate requires vast amounts of support effort. Force diluters. There are true rockstars out there, but they usually specialize in being force multipliers.

[zooso]

Thanks. I agree."The art of matching a problem with a solution with minimal effort" will be the core of software engineering The rest will someday be automated or delegated. (just like any other engineering field matured to that)