Last night I wrapped up about 16-ish development hours rewriting and refactoring some code used to integrate with a third-party service. (Actually, I spent double that time, but the other half was spent on a lot of peripheral refactoring and unit testing, as well as significant changes to the feature set.) The TL;DR version is that the previous integration work used an open source library that didn't quite do things right in wrapping a REST service, so a lot of the normal kinds of failures you expect to get were difficult to get instrumentation around. I completely dropped the dependency on that library. Now it works, works fast and fails in a predictable and observable way. Hopefully my team and customers will be happier for it.
Interestingly, the dev team of the product we're integrating with once wrote a blog post suggesting that you really don't need a library, SDK or whatever wrapped around their API, because REST is pretty simple. There was a time when I might have said that I also wasn't interested in reinventing stuff, but I've eventually come around to see their point. In fact, as much as I've embraced the open source world and taken shortcuts to reach my destination faster, I've come to realize that this conflicts to some degree with my hiring philosophy.
I can't stand the developer types that think that quizzing people on encyclopedic knowledge of algorithms and design patterns is a good use of time. Sure, you should have a good understanding of how HTTP works, but I don't care if you remember what SOLID stands for as long as you practice it. I'm absolutely in the column of putting a candidate through a coding exercise, and I don't care what they need to do to arrive at the end product, because it's that journey that I'm most interested in. The most valuable developers, in a world of managed code and countless open source projects, are the ones that can skillfully compose solutions in a way that makes the product maintainable, extensible and scaleable. If they have to get all over StackOverflow to do that, I don't care, so long as they thoughtfully compose and don't just cut-and-paste.
That brings me back to my point about dependencies. Packages, libraries and frameworks definitely have their place in your project, but taking those dependencies should never be taken lightly. Should you endeavor to write your own front-end UI framework or a back-end dependency injection container? No, that's a waste of time, and you probably won't be good at it. Should you take a dependency on some package that you could write yourself in 17 lines of code? No, because those kinds of trivial dependencies can "break the Internet." The reality is that you need to look at the cost-benefit ratio of taking these dependencies, because sometimes the shortcuts don't save as much time as you'll use later on supporting something you don't own.
No comments yet.