One aspect of growing in a career in development is knowing when to write your own code and when to use the work of others.

So many libraries available via others work.

So many libraries available via others work.

This isn’t a hard and fast rule, but when we start out it’s like we want to roll everything on our own. I don’t know if it’s because we want to prove to our employer, our clients, or ourselves we can do it. Maybe it’s a mix of the two or maybe we just welcome the challenge.

Maybe it’s all the above.

Whatever the case, we’ll eventually work on larger projects and eventually become more specialized. That is, we’ll identify what we need to write and where we can use an existing library.

Third-Party Code (And All The Feels)

This results in a mixed set of feelings. Sometimes I think…

  • It feels like we’re “selling out.” I mean, we’re having to incorporate someone else’s code into what we’re building.
  • We’re left wondering “could I have written this if I had the time to do it?”
  • What if the third-party library isn’t maintained and ultimately hurts our project?
  • What if the library introduces more complexity into the application than anticipated?

All are common questions. I’m sure I’m missing plenty of others, but the point I’m getting at is this:

Knowing when to roll your own solution versus using the work of others is the sign of developer maturity.

Honestly, I can’t sit here and write these words without saying that I’m not as mature as I’d like to be. But I know I’m further along than when I first got into this field.

I’m Still Immature

Just like anyone starting something new, I was out with something to prove. I felt I needed to prove to whoever would pay attention even if it was only myself.

That actually sounds kind of pathetic when I write it down, but that’s how it goes sometimes.

Thankfully, I had a group of people who helped me see things differently. I learned when to roll my own solution and when to take use the work of others.

Sure, this is a fantastic aspect of open-source software. But this was during a time when I was working in closed-source software. I mention this because the divide between the two isn’t as stark as it sometimes appears.

But I digress.

Though I go through a process of trying to understand:

  • The problem at hand
  • The problem’s domain
  • A potential solution for the problem

I also try to identify what may needs to be custom code and what can be third-party code. In doing this, I still have that pull within myself wanting to write the entire thing on my own.

Aim For Maturity

But that’s foolish and it’s immature. That’s not why people specialize if writing small utilities for unique problems. It’s not how others build businesses on top of a single, niché solution.

The deeper we get into development, the more we should be thinking through what we have to write and what we don’t. Ultimately, I believe this will contribute to more successful projects and our own maturity.