Ask HN: A question for those who went to MIT/Stanford/CMU
I am wondering what's the learning environment and what behavior makes folks at these and alike school smart. They don't get hung up on new Javascript framework or new language. My observation is that top performers from this school are focused on solving problems. I have met quite a few who are very smart folks but they are not chasing new Java/Scala/GO language feature. Heck, some even don't know Java programming.
Despite this, these folks solve hard problems and often solve it better than anyone else.
I am curious about distinction between chasing new language/technology/language vs solving problems. How do you see yourself after graduating from these schools?
56 comments
[ 5.0 ms ] story [ 118 ms ] threadFirst, I simply eliminated working on anything I didn't really need and/or want to do. I don't need to think about doing stuff I don't plan on doing!
Second, anything that needed to get done, I scheduled it. For simple tasks, I just created morning and evening blocks of time for home and work. The repetitive stuff I do first, and then I work on one off stuff until I don't feel like doing it anymore. It just gets done in the next block. For example, scanning N tax documents is lame, so I scanned maybe a dozen in one block, and just did the rest the rest in the next block. For important things, I schedule a single purpose appointment, and do my best to just make it happen.
Lastly, I bought a wall calendar, and nailed it to... aait for it... my wall. I "x" out every day I feel like I attended to the stuff I said I was gonna do. If I don't feel a "x" has been earned, it is usually for a specific reason, and I try to address that reason. I choose not to care about the "x" streak, days in in a row. I simply use the calendar to gauge whether I'm being as consistent as I'd like to be.
I've gone made pretty good gains on transitioning from Professor Procrastinator to Captain Consistent. Will always be a work in progress :)
That, and I don't believe you can be really productive for more than 3-4 hours straight (even a day, unless you take a long break) anyway on a consistent basis.
20% of the effort often gets you 80% of the way there. At that point you have to decide whether putting in the additional effort is worth it. Sometimes it is, sometimes it isn't.
If you don't love to work hard in your field and you do want to get to the top of the field, you're on a road to problems because everyone at the top of your field is as smart as you are AND they are driven by passion to work incredibly hard. You can't get into their league without both.
So, if you want to get to the top of your field and don't want to work hard in it, my advice is either (a) find the joy that makes you want to work hard or (b) find a different field that does bring you that joy and desire to work hard.
(Note there is no requirement that you want to get to the top of your field, this is just for those who do want to do so)
I believe most schools stick with traditional tools for educating, using Haskell and C for projects, although some are moving towards python.
I'd be surprised if any of them teach any javascript whatsoever unless you took a course specifically on that topic.
For me, MIT taught me how to think more than it taught me anything specific. Sure, I learned a bunch of engineering, but mostly, I learned to be skeptical, to think through and quickly identify the key aspects of a design, a business, or a model and zero my efforts in on the sensitive areas and ignore (or minimize investment in) the routine parts. (Part of it is you get this secondarily from having such a firehose of work and interesting opportunities around you.)
In industry, it has made me skeptical of the framework flavor of the week, but I also don't want to be forever stuck in K&R C, so there's a balance to be struck.
I also wouldn't be overly impressed with an MIT grad just based on that fact. Getting into MIT is hard. Getting out of MIT mostly takes determination.
Back in the day (perhaps still the case today?) there was not a single "learn to code" in some specific language anywhere in MIT's EECS department. There was Sussman's SICP class which taught scheme more or less in the first week. Barbara Liskov's class taught her research language named CLU more or less the same way. As a short diversion before getting to the meat of the course.
Most people I knew at school were a lot smarter than me. And the thing I noticed about them was that they saw things more abstractly. It wasn't about semi colons, or the latest frameworks; but a desire to see things a little more generally so that their understanding could apply to large classes of languages.
Beyond languages, another thing this helped with was being able to use mathematics, computer science and logic to model parts of the world with some level of mathematical rigor. In other words, answering an under defined question systematically by first formulating it rigorously.
One more thing abstract thinking seems to help with is that it makes learning new concepts a little easier. And so, being at these schools probably also teaches people how to learn, which can be useful throughout life.
This is the number one most important lesson a software developer can learn. Strive to understand the underlying abstractions and patterns, make sure to have a broad experience base so you can see many different ways these abstractions and patterns are applied in different languages and frameworks. You will be far more useful as your career progresses, quicker to learn things, able to spot the good and bad in the latest buzzwords.
I did not go to one of the 3 named schools but my observation over the last 20 or so years has been that while not a perfect correlation, better CS programs tend to do a better job instilling this sentiment into students.
Usually, the selection process of which you're seeing the results is that kids who are very good at engineering will choose to go to one of these schools to maximize the chances of meeting like-minded people.
These people were already budding great engineers in beforehand. The schools they attend do not apply some kind of Midas' touch that turns an ordinary person into a great engineer or scientist.
So, I think your proposition has its causality inverted. Potential great engineers often end up at MIT/Stanford/etc., and they continue being great engineers. It is not the case that MIT/Stanford produce great engineers by having some magic classes that the other top-20 schools don't.
They also have rigorous DS&A courses that make it easy to get into top companies, but the rest of the Top-20 schools have those too.
My observation is that top colleges tend to lump more work of greater breadth and depth in their students.
It's like joining a great sports academy where you develop faster by constantly being in competition with your peers and by also training harder.
[1]https://existentialtype.wordpress.com/2012/08/17/intro-curri...
[2]https://existentialtype.wordpress.com/2011/03/21/the-dog-tha...
Or, as a recent blog posting that made HN succinctly put it "'How' ages faster than 'Why'" (https://news.ycombinator.com/item?id=13500883). Knowing the "why" of CS means you never have to chase the "how" of the latest flavor of the month stack or framework.
I'm sure if there were more money in subatomic physics we'd observe the same thing.
A computer language is simply a tool to get things done. Education isn't about learning the latest and greatest tool but applying what you know with what you have in an effective and productive manner. To wit, Fortran, that old-timey language from the 60s, is still being used in modern research in physics, electronics, and other technical disciplines.
Also, I don't mean to be invidious but, programming languages are normally the easy part: Unless you jump from (say) VB.Net to Haskell most programming languages are actually fairly similar. In fact, programming languages are boring: Once you know a few, particularly if you know a bit about compilers (e.g. can work from the specification/grammar, Haskell made sense only after I'd read SPJ(possibly et al)'s, it becomes fairly easy to pick up a new programming language. However, software engineering is very important (e.g. Style, testing and optimisation, i.e. for the cache, are all very important skills that I'd assume most people learn by themselves.
I'm 16, so I can't exactly speak from experience; I also don't have any data: My guess would be that because of the difficulty of getting into the top schools/Unis, they cream off the top students. These students then spend years honing their skills, however (assuming your observations are true) they get particularly good at the more rigorous/theoretical side of their science. Supposedly, that would help you focus on the stuff that matters(TM).
In practice, I think that this is probably not true. I'd be fairly surprised (Or shocked) if MIT et al just spat out magically excellent engineers. I'd guess, that it just provides a nice foundation to learn on top of.
First, don't put too much emphasis on school. Great programmers can come from anywhere.
Many other commenters are emphasizing the role of selection effect: top-tier schools select good students, rather than teaching well. I think the effect of good teaching shouldn't be undervalued. Although, again, good teachers and courses can come from anywhere, here are some things CMU does or did in the way of pedagogy:
1. Focus on concepts and skills, not specific technologies. Many of CMU's intro courses are taught in Standard ML, a language used by basically nobody. This levels the playing field, forcing people who think they already know everything to learn things from a different perspective. It puts the focus on how to design and reason about programs, rather than the minutiae of popular languages.
2. Have project-based courses. The star example here is CMU's operating systems course, which is a thing of beauty and terror. At many schools OS courses teach you trivia about hardware. CMU's OS course involves some of that, but is mostly about (a) working with a partner (b) time management (c) designing concurrent programs. The compilers course is of similar quality.
3. Teach math-as-problem-solving. CMU has a course, 15-251, which is notoriously difficult, because it introduces you to a lot of discrete math very quickly. This is partly because discrete math is the core of CS theory; most programs will never need this, but when you do need it, knowing a bit of theory can save you days or months. But the other goal is to simply practice solving difficult conceptual problems.
These institutions do a damn good job at making you very very strong on your foundations of CS and problem solving and architecture. They deserve a ton of credit. They focus much lesser on teaching you cool and trendy stuff, and much more on grounded understanding of everything that forms the foundational basis of computing technology, especially in the first 2 years of the 4 year programs.
* what behavior makes folks at these and alike school smart *
My experience was that almost everyone I met at Stanford had done something pretty extraordinary in high school. Examples: teaching an AP science class, being an amazing pianist, doing well at national science fairs, being a published author.
To answer your question: Almost everyone was very smart, but at least at Stanford there was great variety in the kinds of intelligence on display. This was true even among CS majors.
* what's the learning environment *
I'm not totally sure what you're asking about here. Undergrad CS classes were pretty similar to what you'd see at most universities: Professors lecturing, then people taking home exercises or programming assignments. Collaboration was usually encouraged on exercises, and programming assignments were usually done in groups.
My honest experience was that a lot of big courses were not particularly well taught. The first few CS courses are an exception; they're taught not by professors but by lecturers, who are all really good.
The best CS classes I took were graduate "seminar"-type classes, where we'd read a few papers each week and then come to class and discuss them. Shout out to Dawson Engler; his operating systems seminar was inspiring and eye-opening.
I can't speak as much to non-CS classes. I took some math and physics classes; these were pretty traditional, with lectures and written homework. Collaboration was encouraged on homework, and personally I wouldn't have been able to get through those classes without help from my friends.
* How do you see yourself after graduating from these schools? *
Again I'm not totally sure what you're after with this question. One of the best things that happened to me was that I became friends with musicians and biologists and English majors; people who are (academically, anyway) quite different from me. I learned to dance, and swing dancing has become a huge part of my life.
I work at Google now, and that's pretty humbling. Working at Mozilla when I did was as well. But life isn't all work, and in a lot of ways the non-CS stuff I learned in college has been much more impactful to my life and how I see myself.
In my graduate adventure at Stanford, the course work was in Pascal, our research was in Ada (83), and I learned C, C++ (using Cfront), Prolog, Smalltalk, Lisp, and some formal specification languages. Assembly languages included DEC 10/20, VAX, Data General Eclipse, Sun IV, Cray I, and Sequent. Hennessy and gang were creating MIPS, and the CISC versus RISC debates were everywhere. My first job after Stanford was programming C and assembly language on IBM's brand new, unannounced RISC/System 6000 with a Unix-like OS. My next job was C programming on OS/2 on a very large office system with a homemade object oriented structure using C macros. The next job was a DARPA distributed system using CORBA where I brought in brand new Java to solve our multi platform GUI problem.
New programming languages are mostly boring; a Frankenstein collection of reused parts, badly stitched together. New frameworks are mostly silly.
Thanks to all of the parsing research in the early 1960s,resulting in LEX and YACC, plus books like the Dragon book, and Cooper's Compiler book, and LLVM, many programmers can invent and implement programming languages. But that does not mean that they SHOULD. Programming language design require aesthetics, which are not taught in Computer Science. Knuth's books are titled The ART of Computer Programming for a reason.
Much later I realized the classroom learning I'd thought was getting in the way of my experiential learning was what gave me the discipline to dig in and learn the things I needed to know to do the things I wanted to do.