As the years go by in this profession, more and more I see an expectation that professional software developers will utilize any and every framework or library available to accomplish various programming tasks.
The truth is, there isn’t very much code to write that hasn’t already been written a hundred times over. Every general programming “problem” has been solved, and there’s often a generally accepted “best” method to solve any such problem.
However, if you’re in this business because you enjoy the “art” of developing software, then you probably enjoy developing your own solutions to programming problems, even if canned solutions to those problems already exist, and even if the solutions you come up with aren’t necessarily as elegant or optimized as the solutions that already exist.
In other words, lots of us like reinventing the wheel. It’s part of what we enjoy about what we do.
When we’re working on our own independent projects, this isn’t an issue. We’re free to do as we please.
But when we’re taking a paycheck from an employer or charging a client for our time, their ultimate goal is to get the desired finished product, as quickly and cheaply as possible. Our desire to spend extra time developing our own solutions to problems is usually incompatible with their goal.
But there has to be a balance.
Yes, it may be unreasonable to decide you want to write your own xml parser on your employer’s/client’s dime when so many other canned solutions already exist.
However, keeping you engaged, challenged and interested in the project and your work is also a very important factor, for both parties.
So if someone suggests that you use Framework X to make web service calls, library C to process the returned results and open source project N to display the results in a nice, pre-fabricated UI, if that’s the majority of the application’s functionality, then they’re asking you to become a puzzle assembler, a code monkey, a paint-by-numbers “resource” who likely won’t take any joy out of the work you’re doing.
Find the balance. Determine which wheels would be unreasonable for you to reinvent, which wheels you will learn the most from reinventing and which wheels you can bring something new to the table for.
Then have at it!
But most of all, don’t get trapped assembling coding jigsaw puzzles for the rest of your career, which likely won’t be very long if that’s all you’re stuck doing.