When I read pieces like this I think 'young and inexperienced.' Not in a negative way, just in a haven't learned enough about stuff to put the various pieces in perspective yet.
People always start out at implementors (or at least they should in my opinion) and as they implement they develop a 'style' and an aesthetic for how things should be done. Sometimes that comes from learning the hard way, sometimes it come from re-implementing or re-working the same code for several different uses, sometimes from reading an insightful paper on a similar problem. After a while, they will have more ideas than they can meaningfully implement in a lifetime, but with the help of other implementors they can make wonderful things.
So they begin teaming up with other implementors, some not as experienced as they and perhaps others with different histories. The build bigger things faster, and begin to appreciate that working in parallel is faster but not more efficient if at integration time everyone has to rewrite what they wrote. So they start spending time thinking about how the pieces of this bigger project should fit together, they keep this complex inter-relationship in their head as they work with various team members who are working on other bits. At some point the part of the implementation they own is falling behind because they are constantly on the move, talking, listening, advising, questioning, deciding, on various bits about the project. As they weave and integrate more and more bits they begin to discover the subtleties of a thousand different things about how stuff is put together and recognize the benefit of finding people for whom that particular part of the implementation space has fascinated them for years and they know inside and out.
They will find themselves giving advice on how something should be done to an implementer who is doing the work and wondering why it should be done that way when they could do it more easily some other way. They may find themselves recounting trying it different ways, the advantages and disadvantages of each, and the outside influences that perhaps this particular implementer isn't aware of which have guided the opinion of how it should be done. They may find that the implementer dismisses them as 'out of touch' because they aren't doing the implementation themselves. They might chuckle at that, or if they have had a long day and they aren't looking forward to the unsatisfying 'when you've done this longer you'll understand' conversation they might be a bit short with them.
People always start out at implementors (or at least they should in my opinion) and as they implement they develop a 'style' and an aesthetic for how things should be done. Sometimes that comes from learning the hard way, sometimes it come from re-implementing or re-working the same code for several different uses, sometimes from reading an insightful paper on a similar problem. After a while, they will have more ideas than they can meaningfully implement in a lifetime, but with the help of other implementors they can make wonderful things.
So they begin teaming up with other implementors, some not as experienced as they and perhaps others with different histories. The build bigger things faster, and begin to appreciate that working in parallel is faster but not more efficient if at integration time everyone has to rewrite what they wrote. So they start spending time thinking about how the pieces of this bigger project should fit together, they keep this complex inter-relationship in their head as they work with various team members who are working on other bits. At some point the part of the implementation they own is falling behind because they are constantly on the move, talking, listening, advising, questioning, deciding, on various bits about the project. As they weave and integrate more and more bits they begin to discover the subtleties of a thousand different things about how stuff is put together and recognize the benefit of finding people for whom that particular part of the implementation space has fascinated them for years and they know inside and out.
They will find themselves giving advice on how something should be done to an implementer who is doing the work and wondering why it should be done that way when they could do it more easily some other way. They may find themselves recounting trying it different ways, the advantages and disadvantages of each, and the outside influences that perhaps this particular implementer isn't aware of which have guided the opinion of how it should be done. They may find that the implementer dismisses them as 'out of touch' because they aren't doing the implementation themselves. They might chuckle at that, or if they have had a long day and they aren't looking forward to the unsatisfying 'when you've done this longer you'll understand' conversation they might be a bit short with them.