Junior Developer: Ok, now I’ll learn how to program in JavaScript! Where should I start?

"Senior" Developer: That's very easy, you don't even need to write a lot of code! Just go to npm, install the Zebra and Koala Open Source modules, and you're done!

Junior Developer: Cool!

npm: Hi little grasshopper how can I be of assistance?

Junior Developer: Give me the Zebra and Koala modules.

npm: Of course, here they are.

Junior Developer: All tied up. Now my work is done!

*One day later*

Junior Developer: Now I need to add this feature. Where should I start?

“Senior” Developer: That’s very easy, you don’t even need to write a lot of code! Just go to Zebra's Github repository and ask them to implement it!

Junior Developer: Hi Zebra, I need to add this new feature, would you help me out?

Zebra: Of course, create a Pull Request.

Junior Developer: Here it is.

*2 days later*

Zebra: Your Pull Request is not good, you need to fix a few things.

Junior Developer: Here it is.

*2 days later*

Zebra: Now your Pull Request is good, I have merged.

Junior Developer: Thanks. Now my work is done!

*3 hours later*

Junior Developer: Now I need to fix this bug. Where should I start?

“Senior” Developer: That’s very easy, you don’t even need to write a lot of code! Just go to Koala’s Github repository and report it!

Junior Developer: Hi Koala, there's a bug in your module.

*2 days later*

Junior Developer: Hi Koala, are you there?

*1 week later*

Junior Developer: Is anybody maintaining this module?

*1 week later*

Junior Developer: I'll fork and fix it. Done.

*6 months later*

Junior Developer: Now I need to add this other feature. Let's look up which module I need to change first:

1*SRxZPGixj9CQraELn7L2Kw
The diagram of the Junior Developer project's dependencies. It's a bunch of scratches forming an unreadable spaghetti.

Junior Developer: Err… I guess something went really wrong… JavaScript is so hard and complicated! What should I do now?

Real Developer: The problem is not JavaScript.

An external dependency tends to be too generic and therefore has a lot of complexity to account for edge cases you probably don’t have.

As a principle, you need to reduce your dependency on an external code as much as you can. Over time dependencies will incur a cost of change if you rely on them for the core purpose of your project.

Evaluate their need critically.

It’s possible to write your own code for things a generic module can already do for you without having to reinvent the wheel, as long as you design it correctly. That includes (but is not restricted to) no side-effects, low coupling, high cohesion, proper interface, enough affordance, no crap testing tools, code that can be deleted, no "over-engineering", no copy/paste, strict, small and without false positive tests.

If you don't design it correctly, you'll end up in the same mess, or even worse.

If you’re a plumber and the pipe leaks, it’s your responsibility to fix it. Not somebody else’s.

It’s all about applying software principles and techniques. It’s about learning how to program.

Don't blame the scalpel.

Junior Developer: Ok, now I’ll learn how to program. Can you help me?

Real Developer: Yes.

*7 years later*

New Junior Developer: Ok, now I’ll learn how to program in this popular language! Where should I start?

Former Junior Developer: I can teach you, but that's not easy.

I've been through this.

Sit down.

Let's talk.

Thanks for reading. If you have some feedback, reach out to me on Twitter, Facebook or Github.

Wanna chat in person? You can find me in the Sydney Software Crafters meetup.