If you feel like writing your own solution to a problem which is already “solved” by standard tools, go for it. Write your own. Don’t look back. Particularly if you don’t like the standard solutions you find.
Don’t be afraid of the magnitude of the problem. If it is a worthy problem to solve, you will solve it. And you will learn the problem better than through any teacher, book or documentation. When I wrote lith, I learned that there’s 108 tags (16 of them void) in HTML5. When I wrote cicek, I learned how cookies and etags work.
Tackling challenging, interesting problems with the freedom to choose your approach will make your programming become stronger, bolder, more resolute. You will feel you’re walking in firmer ground and that you start to understand what’s going on under the hood.
Politely disregard the naysayers. You’re doing this on your own time. You’re putting no one in danger, except a few egos, which are afraid that you might become a better coder than them. If someone tells you that you’re reinventing the wheel, they are probably afraid that you might end up inventing the engine.
You might end up with an incomplete tool. Or a complete tool that will never be used. Sometimes you may use those tools as the infrastructure of other (maybe even external, paid for) projects. And maybe other people might end up using your tool. But what happens with your tool does not matter. Writing your own tools, for many of the programming problems you will encounter, is a path worth traversing for its own sake.
“In any field, the Establishment is not seeking the truth, because it is composed of those who, having found part of it yesterday, believe that they are in possession of all of it today. (…) Therefore, to anyone who has new ideas of a currently unconventional kind, I want to give this advice, in the strongest possible terms: Do not allow yourself to be discouraged or deflected from your course by negative criticisms – particularly those that were invented for the sole purpose of discouraging you – unless they exhibit some clear and specic error of reasoning or conflict with experiment.” — Edwin T. Jaynes
“Now we get down the the nitty-gritty. This is our first clash with the establishment. The conventional approach, enforced to a greater or lesser extent, is that you shall use a standard subroutine. I say that you should write your own subroutines.” — Chuck Moore
“Although we entertained occasional thoughts about implementing one of the major languages of the time like Fortran, PL/I, or Algol 68, such a project seemed hopelessly large for our resources: much simpler and smaller tools were called for. All these languages influenced our work, but it was more fun to do things on our own.” — Dennis Ritchie