| >You don't want to become experienced at writing software in your unique, bespoke way, only to realize that you've been doing things inefficiently and/or differently than everyone else in the field and have to start over from first principles While a good ideal, the speed of change makes that difficult for universities that simply operate on a longer timeline than the current industry. To use the bowling metaphor: there isn't a right way to do software as well-known as bowling well. When you go to find that foundation, you get CompSci fundamentals (which are a solid foundation) alongside a bunch of industry best practices that appear to be changing really quickly. Software certainly isn't only about CompSci fundamentals. The Javascript scene has slowed (for the better IMHO) but it's a good example of a drastic change of styles/techniques over a short time span. Plus we have new languages that are doing new things that may not be taught in undergrad courses. Even if you zoom out from a single ecosystem like JS and look at the major styles - OOP, functional, procedural - that has changed pretty quickly too. OOP is not necessarily the "right way to bowl" any more than procedural or functional is. My conclusion here is that the theory of peak practice is very difficult to apply to writing software, however, it probably works with purely CompSci stuff (which can be practiced in any language). By contrast, this theory applies well to bowling, because bowling well is a much slower moving, more well-known target to work towards. |