That's not being lazy, it's being sane. Nothing's worse than screwing up something basic that should have been handled by a library. Leftpad might be on the too many libraries end, but that's an extreme example.
The moral of story of leftpad should not have been people use too many dependencies.
It should have been don't arbitrarily grab code from the web for your production apps. If you had any form of caching where a validated library (i.e. leftpad) would be used for your builds instead of just reaching out everytime then your system wouldn't break. Nor would a random cryptominer get into your app.
--
Libraries should be a good thing in that it's definitely easier to review a line of code for a bug than write that same line bug-free. Of course, people (companies) rarely review the libraries they use (sometimes they physically/legally can't) so there are some outs.
As a programmer, your value prop/job/business isn't delivering code. It's solving business problems. If a library lets you do that faster, then it's a good idea. Flexing your ability to code has no place in the real world.
Introducing a towering pile of dependencies is _introducing_ a business problem; there is a cost of ownership to a dependency tree that only grows as it grows.
Grabbing a library from somewhere and saying "problem solved, onto the next one" isn't a sustainable development practice; there has to be some assessment of "is this library popular/the maintainer trustworthy/what risk do we carry if it gets abandoned/will someone pick it up/_does it solve a big enough problem to warrant the effort_" that goes with every choice to pick one. Further, every single 3rd party dependency carries security risks, and every time you add one, you make it more likely one of them will get compromised.
I used to be a "just grab the libraries and move on" guy, but we're currently working on getting $currentEmployer off some old major versions of React, CRA and Spring Boot because a previous developer was of the same mindset and half the stuff he grabbed has died and isn't forwards compatible. It's not a fun process, and many problems the libraries solve could've been solved in-house for less total effort.
Exactly. To me it just seems like a profoundly bad idea to become overly reliant on the code of others. Then your capability to solve business problems will certainly decrease.
I'm curious what environment you code on where you are not extremely reliant on the code of others. you may not use many libraries but you are equally dependent on the standard library, compiler, and OS you are running on.
What would be the ratio between the the line (or instructions ?) you write yourself and the one you rely on (OS, environment, compiler, firmware ...) ? one in a million ?
No. He’s saying that while another developer gets stuck in the weeds implementing their own byte-string library, he’ll be past that and shipping the feature that needs a byte-string implementation to the customer or end user.
It’s the same reason you’re writing this using someone else’s web browser, on someone else’s kernel, on someone else’s hardware.
And it’s not because you’re a bad/lazy programmer or because there’s no value in understanding how all of that works.
Because you utilise the labour of others every day with the knowledge that doing so allows you to achieve what you need to achieve, rather than spending all your time growing and harvesting corn or something.
Where on earth does he say that? There is no shortage of development in any given project. Writing my own http client/server, json parser, html parser, networking IO library, and a whole host of other stuff doesn't help me ship faster. I may experiment with implementations of these things on my own to learn more about them but:
1. Doing my own implementation of any of those things is a large amount of effort that isn't directly relevant to my needs in any given job.
2. My first attempts are going to be buggy and incorrect providing a source of bugs in my system that I didn't need. It would be irresponsible to use them in a work product.
3. I don't learn substantially more about software development doing these. I may learn more about http, or json parsing but I'm doing so at the expense of learning more about my business domain. There is some minimum amount I need to know about these things to do my job. The rest is unnecessary until I run into a situation requiring me to dig deeper. To borrow a Software Architecure truism? YAGNI, You ain't gonna need it.
It is a fact that I am deliberately limiting myself if I force myself to understand every layer of technology I need to leverage in order to do my job rather than specializing. I will always have to delegate some of that to someone else who has the time to go deep enough to provide a robust solution for me. I will also always have a responsibility to go deep on some of those things when it is relevant to my work.
People who use a lot of libraries still seem to spend most of their time programming. I'm not sure why using libraries means less practice programming.
