Write the code, or solve the problem?

I am committed that you have the best possible software, but I am not attached to the outcome.

Yeah, right, 'cos I'm that enlightened.

There are programmers out there, some of whom I have worked with, who are happy to just do as they are told and write the code they have been asked for. These programmers seem to enjoy their jobs a bit, they work from 9 till 10, coffee, 10:30 till 12:30, lunch etc, and occasionally stay back until 5:03. When the boss asks them to do something, they say 'ok', go back to their desks, google it if need be, and paste in someone else's code to solve the problem.

These people are extremely valuable to a team of more than 5 people. There is always boring grunt coding to be done, and they love it.

If you try to build your team entirely out of these people... your software probably work. Just. It will meet spec, but it won't be 'great' or 'inspiring', definitely not 'ground breaking'. And your life will be much more comfortable in the short term.

I don't mind the grunt work myself, it's part of seeing an idea through, but it's not why I love to program. I love solving the problem then seeing it work.

The only problem with my outlook on programming is that the project doesn't always go my way.

Sometimes the 'other way' is better, and yields some other fantastic outcome I would have never thought of. I allow the boss/client to push my ideas, and I say 'ok, I thought that was insane when you started, but I think it might just work'. These are mostly the times when I am being slack, 'it should be done this way because that's the way it is done' - which usually translates to "I've already solved this in my head, it's not perfect, but can we just move on?". Sometimes if I just say "Yes" some wonderful things happen.

Sometimes the 'other way' is clearly not going to work. Like running a PHP web app on a windows server (Eek!). Quite often this type of 'other way' stems from a blog post or buzzword. It's very useful to read hacker news, not just for the great articles, but also to be aware of what your entrepreneurial non-tech boss/client is reading about how technology works. "I was reading up on Progressive Enhancement and Graceful Degradation, they sound like a good idea. I think we should do it". And always beware the 'we have always done it this way'. It's not an answer, it's a deferral.

It's quite a challenge to tell the difference. I generally ask the following: Is this a problem which has already been solved in our code or the wider community? If not... you are stuck, you have to build SOMETHING to solve it. But most problems have already been solved at least one way. So the real question is: "Is this THE problem we are trying to solve?" If it is, go for it, it's time to break some ground... but if not, maybe just leave it and focus on the bits of ground you ARE trying to break.

And other times you just have to say "Yes" to the person with the money. It is their project after all.