It's going to be difficult to draw a generalization because I have mostly my experience from MIT, but I can't tell how that's the same/different as others from MIT or other schools. 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…
I would add to that MIT taught me how to learn new topics very quickly without much handholding at all. That's the skill that makes one not so prone to obsess on one framework versus the other, because if necessary you can learn both.
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.
It's rather simple: A proper CS education, one that has all that "useless" theory that a number of HNers love to deride, equips its bearer to understand how anything in the software world is implemented. You don't have to study as hard to pick up a new technology or stack because you will know roughly what the underlying implementation has to look like and can simply poke around to identify the components and interfa…
This seems a bit like saying a physicist is more capable of understanding how satellites work than an engineer who designs satellites because he knows the underlying theory better. It's kind of true in some sense but doesn't really capture the context or nuance that goes into a non-trivial engineering effort, or the more general case asserted by the topic author.
Not really. More like: if the way you make satellites dramatically changes on a continuing basis, then some solid knowledge in physics might prepare you better to adapt to the changing times than being trained in the current methodology.
That's not a very good analogy. Most would agree, I think, that the separation between CS, as taught in most programs, and professional software development is far, far smaller than the separation between physics and aerospace engineering.
Well, that's another discussion altogether. I'm of the view that the closeness of professional software development to academic CS is one of the biggest problems in the industry from the perspective of regarding it as an engineering discipline.
I think that's just a function of how much money is in the field - more people end up in industry than academia AND industry has an even bigger interest in pushing the boundaries. This leads to blurring between the lines of industry and academia.
I'm sure if there were more money in subatomic physics we'd observe the same thing.
Yeah man coming from CMU there is an intense focus on not getting lost in microtrends and "new" ideas which are simply rehashing what's already been done. You want to avoid poisoning your mind by learning say functional programming in Rambda.js instead of going straight to the source. Before CMU I would pour over blog posts by amateur developers arguing that Ruby on Rails is always better than PHP or some other trite…
The second half of your comment really resonates with me. I was generally pretty good at really understanding how things worked at the system level, but there is one friend I used to work with who was simply amazing at it. He was the guy who would go deep on our web farm, figure out what was wrong in the garbage collector, monkey patch a workaround, and send a bug report to Microsoft with what needed to be changed on 16-core NUMA machines, saving us 25% of performance across the farm AND reduce page times by a 100ms or so. Or troubleshoot a sporadic network issue by isolating the issue via testing in production (without access to the network gear) and tell the network team where the bottleneck is. (Needless to say, this can ruffle some feathers of the easily offended, or with the people who believe that purity is more important than functional and that one simply shouldn't write code that understands you're running on a NUMA machine, but it was amazing to watch time after time.) He's moved on to another local company where I've heard from him (and others) that he continues to do the same over there.
Bigger question to me is - how do we non-Top4 plebs rise to even 70% of their level?
Because there's an enormous spectrum of talent at those schools and outside those schools. For every top MIT/Stanford/CMU grad, there are 20 more people someplace else in the world with the same raw talent and ability.
PhD student here, and I'm exactly the same. I procrastinate a lot (not good!), but I've been able to get things done. My current goal is to figure the optimal way to minimize procrastination...
I've recently made pretty good gains at minimizing procrastination. First, 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…
I've recently made pretty good gains at minimizing procrastination. First, 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…
Thanks for sharing!
This morning I wrote a note to myself that I didn't earn the "X". I've been trying to wake up at 7a, and go thru a start of day checklist. I want the "X" damn it. Tomorrow, maybe I'll read the checklist. Still, I got way more done this morning before heading into the office than I would have if there was no concept of a plan :)