This was my first thought. I don't think I've ever worked in anything "ground breaking", but I've never had work that was just "connect A to B with no thought". I mean, even if it _is_ connect A to B, you still need to consider
- Is the client (internal, external, whatever) asking for what they really want?
- Is the client asking for what they really need?
- Am I correctly understanding what the client is asking for?
- Does building this make sense for the product as a whole?
- What As and Bs can accomplish what I'm looking for (assumes they exist, per the initial assumption)
- Of those As and Bs, which ones won't run into conflicts with the project
- Of those As and Bs, which ones are well supported
- Of those As and Bs, which ones are likely to continue to be supported (long enough for our needs)
- Of those As and Bs, which ones mesh well with the current coding/development style of the project (maintainability)
- How can I best use A and B in a way that is easy to understand (maintainability)
- How can I best use A and B in a way that I can test my code without having to write 1000 lines of mock (maintainability)
- and the list goes on and on and on
Unless you're a VERY low level developer, most software development requires a large amount of thought, both analysis and planning. It is very much _not_ like routine factory work.
Heck, I spend a fair amount of my day not even looking at my screen, as I ponder how best to solve "easy" problems.
