I think one of things that "millennial" self-taught programmers have trouble understanding is OS. While the need to implement OS functionality is now a niche (l

I think one of things that "millennial" self-taught programmers have trouble understanding is OS. While the need to implement OS functionality is now a niche (like process scheduling), I have noticed that "millennial" self-taught programmers have gaps in knowledge with respect to threading, mutex/semaphore, consumer-producer pattern, synchronization vs. lock-free (blocking vs. non-blocking), concurrency and parallelism. I still feel these are essential topics to understand since these issues often come up in most programming languages (JS, Ruby, Go, etc). When deciding between Nginx or Apache, for example, knowing the difference in philosophy is useful (asynchronous vs. thread-based). One of things that CS trained me very hard was to think about cost; when I programmed before my CS education, the old adage of everything looking like a hammer was particularly true for me. Also, many of the self-taught guys need to use fewer libraries/gems and more stdlib and primitives because every additional include is not always necessary and may unnecessarily increase complexity :) Pipelining is another concept that I feel self-taught programmers have weaker foundations--many of whom I have worked with write code that waits for all results to become available, while an operation that's blocked by I/O doesn't necessarily mean we can't do stuff with the CPU while we're waiting for the next batch of I/O to come through. I have also seen self-taught programmers accidentally write O(n!) or O(2* * n) functions and not realize it. I think data structures is definitely a good chapter to have. Especially when writing queries to a data store. I think explaining how a hash table works would be excellent since it is such a useful and fast data structure. A lot of set-taught programmers sort of treat them like magical black boxes when it's not a very complex data structure yet it's practically O(1) for most insertion/reads/deletions. Memory management is fortunately something we don't really need to worry as much about. With languages and interpreters that do a very good job of cleaning up after our code and now that memory is relatively cheap, we can afford to ignore it until we need to scale. Of course, if you have a good product, you can get away with inefficiency and hire CS guys when you have built a unicorn. ;)