| So you suggest that we should put even more emphasis on Computer Science fundamentals? I’d say more like engineering fundamentals and robust professional practice, rather than CS as such. Ad of most jobs don't already put too mich emphasis on mindlessly coding reference implementations of naive classical algorithms and data structures as proof of competence. The thing is, when you neglect awareness of basic data structures and algorithms, and understanding of related issues like algorithmic complexity, you get developers who have no idea why (for example) their framework-based front-end is horrendously slow, and worse, who then assume they’ll fix the problem just by switching to React+Redux because They’re Fast™. You get people who have no idea how to weigh up the pros and cons of different designs, or where the expensive parts of their code will be, or what to do about those parts if they’re causing problems. You get people who are entirely reliant on other people knowing what they’re doing to get acceptable results. Encouraging inexperienced devs to embrace NIH (Not Invented Here) Syndrome is not the answer. I don’t want them to embrace NIH. I want them to think critically about the costs and benefits of developing some functionality themselves vs. reusing some existing code, and make intelligent decisions. Even poorly supported open source projects will often have better edge case coverage, testing, and battle hardened code than a prototype produced by a reasonably experienced dev alone could provide. I see little evidence of that in any field of programming I have ever worked in. It seems to me that a great many poorly supported open source projects are themselves developed mostly or entirely by a single contributor, so unless that lone developer is significantly better than whoever you have on your own team, there is no reason to expect their project to be better than what you would produce in-house just because it’s freely available. A good example is the now-infamous left-pad package that was a dependency of some of the most popular and high-profile projects in the JS ecosystem today. It consisted of a single function that was just 10 lines long, yet within those 10 lines it still managed to have potentially quadratic time cost, potentially surprising handling of null input, and potentially surprising behaviour given various non-English text input. The sad truth for devs who pride themselves on a strong knowledge of algos and data structures is, most jobs don't require those skills. Software produced for profit requires mostly composing an application of existing code, not writing original implementations. Well, that’s one way to build software for profit. Whether it’s actually faster, more reliable, more cost-effective, easier to maintain or otherwise superior to actually knowing what you’re doing and programming is a different set of questions. If you’re trying to create something more demanding than a simple front-end to a CRUD system with modest amounts of data and little complexity in what you’re doing with it, those questions may be answered very quickly… |