| 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. |