I think Chris and Steve mirror the two phases of problem solving.
The first phase, the exciting creative process where the problem is a challenge. The second phase, is when the creativity is done, and now its simply a matter of following through the implementation.
I experienced these phases a lot in school, especially in math classes. I was never a homework doer. I'd start, eagerly wanting to do it, but after the first couple of problems I couldn't motivate myself to do the rest. Because I just could not stand the repetition--the same formula over and over with different values. I'd usually do the first problem in a section and call it quits. Then rely on my test grades to pass the classes with a C average typically.
I was afraid that trait of mine would affect me professionally in my programming career, and it indeed started to. Some projects despite starting out at race pace would quickly come to a slow down as I labored to finish up tail end of the project.
However, luckily I ended up working with a colleague was a great compliment to me. He was able to and enjoyed doing the implementation tasks--the portion of coding that is done when you have the solution and its just a matter of putting the pieces together. However, his shortcoming was the creative process.
Together, we make an outstanding team.
Maybe we could officially categorize these two phases into new job positions. Problem Solvers and Solution Implementors.
At a certain stage in your career as a "developer" you realise that your time is better spent sketching out solutions for others to follow than it is in seeing through all the work yourself.
Some people naturally gravitate towards seeing the whole solution (at the cost of being impatient about the details) and some people gravitate towards diligent completion of defined goals.
Craftsmanship requires both broad vision and attention to detail during execution. It's challenging, but there's no reason a someone can't do both, even if they prefer one over the other. There are lots of great "one man band" developers out there who clearly have to wear both hats. To me, this smells like folks wanting to shirk their responsibility for the part of the job they don't like.
The first phase is really fast-paced uber-productive (as you assemble all the bits from past experiences), and the second phase really slows down as you deal with the nitty gritty of implementation and attention to detail. Just doing the first phase is the equivalent of being an ideas guy. I.e. useless without the implementation.
I agree it's important to practise a bit of both for personal development. But why would you continually fight against the grain if you could be playing to your natural strengths and delivering more value?
Because every kind of work has components that you find pleasant and ones you don't like as much. It's not realistic to just say "I'll try to avoid the part I don't like", especially when there's usually some parts that _nobody_ likes.
Yes, that's very true. I believe the point here though is to play to your strengths for the good of the project. If someone else is better at the detail work then let them do it. The project as a whole will be better produced and that's your end goal. We're not here to build character by completing unwelcome tasks, we're here to build products.
I experienced these phases a lot in school, especially in math classes. I was never a homework doer. I'd start, eagerly wanting to do it, but after the first couple of problems I couldn't motivate myself to do the rest. Because I just could not stand the repetition--the same formula over and over with different values. I'd usually do the first problem in a section and call it quits. Then rely on my test grades to pass the classes with a C average typically.
I was afraid that trait of mine would affect me professionally in my programming career, and it indeed started to. Some projects despite starting out at race pace would quickly come to a slow down as I labored to finish up tail end of the project.
However, luckily I ended up working with a colleague was a great compliment to me. He was able to and enjoyed doing the implementation tasks--the portion of coding that is done when you have the solution and its just a matter of putting the pieces together. However, his shortcoming was the creative process.
Together, we make an outstanding team.
Maybe we could officially categorize these two phases into new job positions. Problem Solvers and Solution Implementors.