Many beginner developers waste precious time reinventing the wheel. Because writing code is so much fun - I get it.
But then where does DRY (Don't Repeat Yourself) coding and package management fit in?
Well I'm going to break down how this works in the real world, and how you can master DRY and build your own reusable package.
And...this could be your next killer portfolio project!
Every second newbie does an e-commerce order page, or YouTube clone. Very few publish a package that other devs can use. Imagine showcasing not just a finished application, but also the reusable components you created—a testament to your understanding of efficient, maintainable code. That's the kind of project that gets noticed.
So, here's an overview of real world decisions around deciding whether to use a package...or make your own.
Engineering in the Real World
Imagine this: You're building a project, and suddenly you need to validate an email address.
Instead of writing the code from scratch (again!), you use a pre-built library.
Boom! Time saved, fewer errors, and you're one step closer to shipping your awesome app.
That's the power of DRY. Yes package managers are DRY on steroids!
Junior engineers or engineers who don't care about business needs will often try to build their own EVERYTHING because...well, because coding is fun.
But here's a technique that the most effective senior devs use: a quick framework to decide whether to "build your own" or use a third-party package.
The Roll-Your-Own vs. Use A Package Dilemma: Advanced Framework
Even seasoned developers face this choice constantly. Here's how the good ones think it through:
-
Complexity: How complex is the task? A sophisticated algorithm with edge cases? One that solves a general pattern of problem in multiple context beyond the one you're applying it to? A dependency might save you month. And see point 3. And then see point 4.
-
Security: Will this code handle sensitive data? Using a well-vetted, established dependency is generally safer than writing your own from scratch (unless you're a cryptographer!). Publicly maintained software will have many smart engineers working on it. Not fool-proof, but definitely solo-thinking proof.
-
Maintainability: How much ongoing maintenance will this code require? A dependency often means less long-term maintenance for you. Building your own means it's entirely your (team's) responsibility. Including security. Are you resourced for that?
-
Time: How much time do you have? Dependencies save time now, but might add time later if you need to debug or update them. Building your own cost time now, but if they aren't well suited, you'll need to extend or modify or customize them...and that could cost a lot of time to extend, test etc.
-
Team goals: Does your team want the responsibility for maintaining a new package? Is it a distraction? Does the benefit outweigh the cost (time for a business is money).
The Decision Matrix (Advanced Dev technique!):
Here's the simplified approach for you:
-
DRY (Don't Repeat Yourself): Before using any pre-built tools, master DRY. If you're writing the same code twice, make it a reusable function! This makes your code cleaner, easier to read, and less error-prone. Think about building a collection of these functions into a shareable package—that's a portfolio project waiting to happen!
-
Package Managers: Package managers like NPM, pip, Cargo, Go package manager, yarn etc give you access to thousands of pre-built libraries. Need to process images? Connect to a database? There's a package for that! Stop reinventing the wheel and start building amazing things. Writing code is not about writing more code. It's about building things that people use. The faster you get it into the hands of user the more impact you have.
-
Level Up Your Skills: Using packages exposes you to high-quality code, best practices, and accelerates your learning. You'll impress senior developers and become a more efficient coder—faster than you ever thought possible. And if you REALLY want to impress folks build added functionality to a package. Not only are you contributing to open source, you're learning how to build code that thousands of others may be depending on. That's awesome!
Now ditch the repetitive coding, build an awesome portfolio project, and unleash your inner coding ninja!
Three ways we can help you:
1. Wondering what learning to code actually means?
Becoming a coder is much more than just "learning to code" some languages. When I got hired at Google, for example, I didnt know 3 out of the 4 languages I had to write every day.
Check out
My FreeCodeCamp Course --> Before You Learn To Code (Video).
Updated version (including Google and other big tech experiences)
2. Inner Circle (Free Preview Included)
Our personalized, intensive mentorship program designed to help career changers go from zero to software developer—and actually get hired. It’s not for everyone, but if you’re ready to commit, we’ll walk with you every step.
Preview the Inner Circle Program -> free preview.
Apply for Inner Circle → parsity.io/inner-circle
3. Dev30
Want to learn the basics, but not quite ready for the Parsity Inner Circle? No problems - Try the Dev30 challenge!
It’s our 30-day JavaScript sprint focused on building real projects, learning in public, and creating a network in tech.
Join dev30 → dev30.xyz
