Build it your damn self!

There's a programming trope that goes around with few willing to check it. It posits that programming skill, and by extension software engineering skill, is merely a matter of being resourceful, specifically with regard to searching the internet for answers. Many thoughtlessly accept this assertion that programming, "is just a matter of copying and pasting" other people's work. Understand that if you embrace this outlook on programming you shall be forever and a day hopelessly uncompetitive against those of us who actually know what we are doing. Please allow me to impart the best advice I could possibly give, one programmer to another - build it your damn self!

Growth opportunities

Consider your options for these feature requests:

• Implement server-side validation for an enumerated list of fields.

• Implement a UI modal popup for users of a given application.

Surely you'd be able to find endless quantities of third party solutions for these problems. They'd come in all shapes and sizes for just about any framework or stack consideration. Shouldn't you just use one?

No! Neither of these considerations are of such complexity that you should give up on following a domain driven approach to building your software.

Let's consider the first problem with validation. Firstly, let's reiterate that this is NOT a difficult problem to solve. There are endless generic ways to implement a validation strategy that will embrace your domain. Secondly, consider the effects of choosing a package. How much effort will it take to conform to its conventions? It may be low, but then again it may not. What if it wants your models to implement an interface or derive from a class it provides? If you thoughtlessly embrace tailoring your domain to a validation package..., SHAME!

What about the second? Again, it is NOT challenging to implement a modal. It may be the very first time you do it..., but then never again. You're left in the same boat as the first, with an almost inevitable walk of shame discussion with a designer. "Unfortunately, the package we went with doesn't support this part of your design..." <- If this is "you" ... MORE SHAME!

So, what will these look like if we "build it our damn selves?" There are some nuances of course, but ultimately, we will simply meet the requirements, without any "shame." There will be no walk of shame discussions where we beg stakeholders to just live with some deficiency. We won't be shamed by a designer showing us live examples of similar designs to his working on other applications. More importantly, we will be better programmers and engineers for having done it. We will also know the solution inside and out. Extending our solutions, assuming they're high-quality, will be not only doable but of a generally routine nature.

Assuming such problems arise again within the same domain, you will have the opportunity for extraction (to a package) and reuse. When such problems inevitably arise from different domains (perhaps different organizations) you will have a vastly superior understanding of the problem (domain) and the potential solutions. You are an engineer, not a bystander!

Professionalism

Security

When you're implementing software there are a host of security considerations. These vary on context, however, every application layer has them.

Your responsibility to ensure your applications are secure DOES NOT go away when you pick a third party package and it is NOT acceptable to simply trust that the package you're using is "popular" and therefore, "should be okay."

When using a third-party package, you should ideally code review the solution (if open source) and penetration test its inputs to verify that it's in fact a secure solution in the context of your application.

You obviously need to do your due diligence when writing your own software. Don't ever for a second think choosing a third party solution for a problem absolves you of this responsibility. Because it doesn't!

Extensibility

We touched on this a bit in the previous section. When we implement our own software to solve problems, we are in the driver's seat when it comes to following best practices, design principles, etc. We can ensure our solutions are extensible and that they won't present as a brick wall the first time the stakeholders want to iterate a bit.

In addition, due to your unique understanding of the domain you're implementing the solution for, you might even find that you're able to be proactive in anticipating likely avenues of future iteration.

Exceptions

Last resort

Let's say we go down the path of implementing our own solution. We learn quite a bit, but after some reasonable amount of time, we're still quite a ways away from solving the problem. There's nothing wrong, at this point, with considering reputable third party solutions.

Also, unlike if you went straight to the third party solutions, you will come to candidate packages with a far better set of questions than you had before. You'll have a much better understanding of the space you're playing in, vice simply "trusting" that the faceless devs on the other side of that package did a good job.

Concrete objective justifications

There are some good reasons not to implement new solutions from scratch. Here are a couple examples:

• You want to lean on a reputable third party for updates and maintenance for a niche problem they're known to be good at solving (sdks for a third-party's own software).

• The scope of the problem is vast, but well understood, and existing solutions won't drive architecture away from your problem domain (web and db servers).

Even with these examples, it's worth mentioning that you should probably still write custom abstraction layers between third party code and your own to insulate the rest of your solutions from the influence of the third party code. For example, you'd want to isolate interactions with a third party sdk to a single service, vice depending on it all over the place.

Notice how I did NOT say, "to save time" or "because third party software will be better anyway." Damn is it sad every time I hear that second justification. What a depressing world you must live in to think so negatively on your own capabilities. Don't be like that!

Summary

If you want to be "that programmer/engineer" who always seems so confident regardless of the problem thrown at them, you must first realize that the difference between them and you IS NOT, "them being better at googling things." They don't have some exhaustive list of bookmarks or videos series to reference. They're certainly going to be very resourceful, and reference documentation and other resources when appropriate, but the key difference is that, "they know what's going on under the hood of their code and yours." They're confident they can solve the problem they're given with software because that's what they do almost every time they're given a problem - they solve it with software, THEIR SOFTWARE!

Don't shirk the opportunities you're given for growth by "writing software as a last resort." Invert that, and only go to the wheel store (npm, nuget, plugin markets, etc.), "as a last resort."

Happy coding, you damned brilliant craftsman you!