(no title)
EvanPlaice | 10 years ago
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.
Encouraging inexperienced devs to embrace NIH (Not Invented Here) Syndrome is not the answer.
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.
The issue isn't whether or not to embrace third-party libraries. Thr issue that it's very hard to get devs to join/support existing open source libs.
As a dev of multiple libs, one of which is widely used among the JS community, it's very difficult to promote my lob and draw more users/support. Despite the fact that the lib has been battle hardened, tested, and in common use by hundreds of thousands of other devs for over 4 years.
Somebody could easily create a framework specific wrapper of my lib that garners more stars/forks on GitHub in a matter of months; and worse, most wrapper/clones never bother to update from upstream so their users are left using old/outdated code.
If you want to stick to 'old values' then do the work to make existing libraries better. Don't waste time/resources producing one-off garbage that contributes to technical debt.
Not sure if you got the memo but the one distinctive benefit of employing software developers is that we provide the ability to automate away repetitive work and save the business money in the long-term. Including, saving development time, effort, and future maintenance by leveraging existing bodies of work.
Where the code comes from and how it works Is only relevant to software devs. The everybody else, the only thing that matters is the result it produces and how costly it'll be to maintain and update in the future.
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.
Chris_Newton|10 years ago
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…