I had a similar experience with a silly little content assist widget of all things. The company I was with had a very particular set of standards that made a lot of sense for the sort of work they did, but none of the features we wanted were standard in the common drop down libraries. After about a day and a half of trying to wrap my head around some of the hilariously complex content assist widgets, I had a conversation with a colleague that prompted me to write my own. Two hours later, I had it. And it was compact and simple enough that other developers were able to easily make modifications as our problem space evolved.
This is an eternal problem of software design, when do you borrow, and when do you implement your own. I don't know the answer but I think there are some factors that can lead you in the right direction.
Did you do your homework? Implementing your own tools should be the last resort not the first resort. It should be driven by frustration at the inadequacy of current tools, and not based on a whim to do something cool.
Of the examples tools you've found, how much customization is required to get them to do what you want? If a 3rd party library requires a lot of hacking to do what you want, it's a hint that those tools don't actually solve your problem and you're going to end up hand rolling what you really want anyways.
How much overhead do the other tools bring in? Sometimes you need to do one simple thing, but all the tools available have a lot of overhead. That's a hint that maybe you should do your own implementation
Have you talked to other people about this problem? A conversation with a capable colleague is usually the fastest way to get useful perspective on what exactly you're trying to do.
How well do you understand the problem space? No matter how much it may suck, if you don't know what you're doing, take the time to figure out how to use the tools instead of creating your own.
All of these factors must be balanced against each other. One of the most important things though is that if you do decide to hand roll a specific tool, don't keep it to yourself. Such pieces of code can be a little hairy sometimes and you need the feedback from others to ensure the code is clean, and to make sure they know what's going on.
> Did you do your homework? Implementing your own tools should be the last resort not the first resort. It should be driven by frustration at the inadequacy of current tools, and not based on a whim to do something cool.
IME having to learn a fancy framework to edit a couple of things on an open source app that was mostly what we needed hurt a lot more than it would have to make something very KISS with something like Flask as a proof of concept.
Whether choosing to implement your own thing from scratch should be a last resort, or that it necessarily requires tremendous breath of experience, really depends on the circumstance, as you described. In many circumstances you don't have to be a genius to know NIH is probably the sanest option.
This is an eternal problem of software design, when do you borrow, and when do you implement your own. I don't know the answer but I think there are some factors that can lead you in the right direction.
Did you do your homework? Implementing your own tools should be the last resort not the first resort. It should be driven by frustration at the inadequacy of current tools, and not based on a whim to do something cool.
Of the examples tools you've found, how much customization is required to get them to do what you want? If a 3rd party library requires a lot of hacking to do what you want, it's a hint that those tools don't actually solve your problem and you're going to end up hand rolling what you really want anyways.
How much overhead do the other tools bring in? Sometimes you need to do one simple thing, but all the tools available have a lot of overhead. That's a hint that maybe you should do your own implementation
Have you talked to other people about this problem? A conversation with a capable colleague is usually the fastest way to get useful perspective on what exactly you're trying to do.
How well do you understand the problem space? No matter how much it may suck, if you don't know what you're doing, take the time to figure out how to use the tools instead of creating your own.
All of these factors must be balanced against each other. One of the most important things though is that if you do decide to hand roll a specific tool, don't keep it to yourself. Such pieces of code can be a little hairy sometimes and you need the feedback from others to ensure the code is clean, and to make sure they know what's going on.