4 ms·

This comes up all the time and I never understand this attitude. Yes: dependencies are bad. Not having dependencies and writing everything yourself: also bad.

This comes up all the time and I never understand this attitude. Yes: dependencies are bad. Not having dependencies and writing everything yourself: also bad. Honestly, you have to rely on heuristics in your deps. How active is the project? How simple is the thing it's doing (simple enough to probably not have major bugs, but not so simple it's faster to code it yourself) etc. You get so much velocity from depending on external libs, it's straightforwardly bad not to take advantage of it. Are the junior devs at your company really going to write a better config handling library than the random one from github? Probably not. Maybe they'll both be bad code but the open source one has a better shot of someone else noticing it.

Ar-Curunir 6y ago
And by re-implementing a library, you're just importing dependencies into your code, with the difference that now you're responsible for bug fixes and security patches, without the opportunity to inherit performance improvements contributed by others.
- KSteffensen 6y ago
  You also have a much easier route to fixing issues, since there will be far less politics involved. Probably you will also have a deeper understanding of the code since you wrote it.
  - consolenaut 6y ago
    This is true, but I've found it far more common that a predecessor at the company I'm at wrote the code and isn't around to support it anymore. For simple components it's no biggie, but for non-trivial components it can take about the same time to debug as an external module, the benefit of the external module generally being better documentation, although thats not a given.
  - armada651 6y ago
    If you find the fix yourself you don't need to deal with politics if you don't want to. Submitting pull requests is optional after all.
    - KSteffensen 6y ago
      If you don't submit a pull request and get your fix merged, essentially you have given up on the benefits of an open source library maintained by other people. You will have to maintain your fix. At that point, you might as well have written the thing yourself, especially for trivial stuff.
marcus_holmes 6y ago
But once they've done it your junior devs will know how to write a config handling library. And they'll have hit a few bugs so they'll know about file locking, and concurrency problems, and overwriting, etc. It will be a great learning project. If you teach them to just import a dependency, then that's all they know. They'll never be able to write a concurrent library, they'll just know how to import one. Having lots of velocity is bad if there are too many potholes in the road. Slow is smooth, smooth is quick.
- habitue 6y ago
  > But once they've done it your junior devs will know how to write a config handling library This is true, but there are always so many things that need building. It's kind of like needing an end table, and either buying one from Target or building it yourself in your garage. End tables aren't that hard to build! The end table at Target is a piece of crap! You'll learn a lot trying to build your own end table! These things are all true, but the question that you have to ask before all that is: do I want to spend my limited time building an end table? > If you teach them to just import a dependency, then that's all they know. They'll never be able to write a concurrent library, they'll just know how to import one. This is probably true of some developers, but I don't think I've run into a developer that doesn't love building things themselves. (Possibly selection bias). The tendency coders have is to code. They're going to write something from scratch (and learn a lot) whether you tell them to or not. > Having lots of velocity is bad if there are too many potholes in the road. Slow is smooth, smooth is quick. I agree with this principle. The way I think of it though is that it's not a road you're on: the asphalt stretches out in all directions, and you don't know which direction you'll be going next. It's very often the case that you spend a bunch of time smoothing over a single pothole to perfection, and crash into a another one right next to it. It is probably correct to shittily half-fill all the potholes around you just to avoid catastrophe and come back later to the ones you run over again and again.
  - marcus_holmes 6y ago
    > It's kind of like needing an end table, and either buying one from Target or building it yourself in your garage. Except that, in this analogy, you're a carpenter. Building furniture is your profession, and hopefully something you enjoy doing. Learning how to build end tables quickly is a useful skill to have in your profession. Practising that skill by building an end table for yourself is not a waste of time. > It is probably correct to shittily half-fill all the potholes around you just to avoid catastrophe and come back later to the ones you run over again and again. Indeed, but that's another skill :) Knowing when to accumulate tech debt because you're not sure if the feature will be needed is important. And again, it's a skill one acquires with practice.

Ar-Curunir 6y ago

And by re-implementing a library, you're just importing dependencies into your code, with the difference that now you're responsible for bug fixes and security patches, without the opportunity to inherit performance improvements contributed by others.

KSteffensen 6y ago
You also have a much easier route to fixing issues, since there will be far less politics involved. Probably you will also have a deeper understanding of the code since you wrote it.
- consolenaut 6y ago
  This is true, but I've found it far more common that a predecessor at the company I'm at wrote the code and isn't around to support it anymore. For simple components it's no biggie, but for non-trivial components it can take about the same time to debug as an external module, the benefit of the external module generally being better documentation, although thats not a given.
- armada651 6y ago
  If you find the fix yourself you don't need to deal with politics if you don't want to. Submitting pull requests is optional after all.
  - KSteffensen 6y ago
    If you don't submit a pull request and get your fix merged, essentially you have given up on the benefits of an open source library maintained by other people. You will have to maintain your fix. At that point, you might as well have written the thing yourself, especially for trivial stuff.

marcus_holmes 6y ago

But once they've done it your junior devs will know how to write a config handling library. And they'll have hit a few bugs so they'll know about file locking, and concurrency problems, and overwriting, etc. It will be a great learning project. If you teach them to just import a dependency, then that's all they know. They'll never be able to write a concurrent library, they'll just know how to import one. Having lots of velocity is bad if there are too many potholes in the road. Slow is smooth, smooth is quick.

habitue 6y ago
> But once they've done it your junior devs will know how to write a config handling library This is true, but there are always so many things that need building. It's kind of like needing an end table, and either buying one from Target or building it yourself in your garage. End tables aren't that hard to build! The end table at Target is a piece of crap! You'll learn a lot trying to build your own end table! These things are all true, but the question that you have to ask before all that is: do I want to spend my limited time building an end table? > If you teach them to just import a dependency, then that's all they know. They'll never be able to write a concurrent library, they'll just know how to import one. This is probably true of some developers, but I don't think I've run into a developer that doesn't love building things themselves. (Possibly selection bias). The tendency coders have is to code. They're going to write something from scratch (and learn a lot) whether you tell them to or not. > Having lots of velocity is bad if there are too many potholes in the road. Slow is smooth, smooth is quick. I agree with this principle. The way I think of it though is that it's not a road you're on: the asphalt stretches out in all directions, and you don't know which direction you'll be going next. It's very often the case that you spend a bunch of time smoothing over a single pothole to perfection, and crash into a another one right next to it. It is probably correct to shittily half-fill all the potholes around you just to avoid catastrophe and come back later to the ones you run over again and again.
- marcus_holmes 6y ago
  > It's kind of like needing an end table, and either buying one from Target or building it yourself in your garage. Except that, in this analogy, you're a carpenter. Building furniture is your profession, and hopefully something you enjoy doing. Learning how to build end tables quickly is a useful skill to have in your profession. Practising that skill by building an end table for yourself is not a waste of time. > It is probably correct to shittily half-fill all the potholes around you just to avoid catastrophe and come back later to the ones you run over again and again. Indeed, but that's another skill :) Knowing when to accumulate tech debt because you're not sure if the feature will be needed is important. And again, it's a skill one acquires with practice.