Boriska, a young boy over-seeing the casting of a bell, in Tarkovsky's Andrei Rublyov
Most developers aren't paid to think about what they build. This "divorce of head and hand", as Richard Sennett puts it, is counter-productive. The more pronounced this divorce, the less likely you are to innovate. Why? Because programming is a craft, and innovation happens in the midst of practising this craft. Sennett's latest book, The Craftsman, is a study of craftsmanship through the ages. I'm writing this as a collection of my after-thoughts on the book (which I'd recommend, despite its grammatically inept first edit).
The workshop ethic
Sennett discusses the history of the workshop and explores what he calls the 'material consciousness' of a craftsman who knows his tools and working materials intimately. In a workshop, authority is equivalent to skill. Historically, the most skilled craftsmen (masters) have had authority over journeymen and apprentices in their workshops. We could learn from a closer modelling of development teams as workshops - most developers are told what to build (and in some cases even how to build it) by managers who don't possess a 'material consciousness' relevant to software engineering, which often leads to problems.
On Engineering
Why does our industry separate out the 'lead engineer' from 'engineering management'? Dealing with software engineering as craft would indicate that a hybrid works better - craftsmen are motivated to work for better craftsmen, in order to improve their skills. In the traditional workshop, the master craftsman would interact with clients (read: product managers/executives) and manage the rest of the craftsmen whilst running the workshop.
By this logic the most effective software engineering manager is an experienced, highly-skilled programmer (hello Mr. Gates). By definition they should still be programming ("If you stop coding, you stop learning" - Beck), for the same reason a master craftsman never actually stops practising his craft. Because to stop practising is to stop evolving the material consciousness that makes you a great craftsman in the first place.
The arguments against this approach are obvious - how's a lead engineer also going to manage developers? Surely he can't do two jobs? Let's take a step back. In order to manage great developers effectively you need to gain their trust and respect. Without this you'll struggle to get anywhere. Upon which we come to a programming truism:
In the work-place, the only way to get the full respect of a skilled programmer is to prove yourself at least as skilled as them at programming, and the only valid evidence is actual working code.
I don't think I've ever met a developer for whom this isn't true. Bear in mind that your average software developer, not known for their humility, will often not dispense this kind of respect until you've coded alongside them (or in a visible forum such as that of an open source project) for a while.
Given this, you can't feasibly manage great devs without being one yourself. I mean you can (it happens all over), but it's a fruitless, unproductive and frustrating operation for all involved compared to what happens when you get it right. In this regard, I'm assuming you agree with the notion that programmer productivity is a completely non-linear phenomenon (see Paul Graham). If you address the issues of trust and respect at the core of a programmer's productivity, you open up a lot of potential. This overrides (by an order of magnitude) the fact that a hybrid lead/manager doesn't have as much time as two separate people, because it gives the individual developer a higher degree of agency in their work and a clear reporting line to a developer that a) speaks the same language as them, and b) which they are motivated to work for and with.
Pretty much all successful startups naturally possess someone who fulfills this hybrid role. It's only when companies grow that this 'workshop' ethic is lost.
Another argument against letting a lead actually manage anything is that the lead has lousy social skills. You'll hear a lot about skilled programmers that are completely socially inept. In application development, I don't even buy this notion. To be a great application developer you have to have superb natural language skills as the entire craft is equal parts natural language and logic. Algorithm-driven programming may well be a different kettle of fish, but app devs absolutely are measured by their capacity to communicate in natural language.
Design & engineering: hybrid minds
This kind of logic about craftsmanship leads to some more questions - particularly around the separation of 'front-end engineering' from 'web design'. Why? The syphoning off of these two disciplines is a symptom of this separation of head and hand; one that stifles the feedback loop of discovery and product evolution at the heart of craftsmanship (the 'designer' only has to think about the final product, not actually craft it). This design/engineering split is obviously evident across sectors (take architects and civil engineers), but rarely do you find a practice like software, where results can be near immediate and design/build feedback is quick. If designer and engineer are to be separated then they will need to work as a hybrid mind in order to innovate in any case (e.g. if Cecil Balmond, a lead at ARUP, and architect Rem Koolhaas hadn't developed this kind of relationship over decades, you wouldn't get results like this).
On technique and expression
Sennett explores the craftsman's worldview that technique "is intimately linked to expression". I believe this to be true. There's an obvious difference between a purely technical innovation (such as the evolution of object-oriented design paradigms in the design of Smalltalk and its dev community in the early eighties) and a software product innovation (e.g. Joshua deciding book-marking the web should be a social activity), but I intuit that the two are linked. Both these types of innovation (indeed, all types of innovation) are highly expressive acts, and it's impossible to be expressive without cultivating expertise in technique.
On 'theoretical' practice
This leads me to think about so-called 'theoretical' disciplines such as pure maths and quantum physics that, whilst being highly abstract, are expressive and require technical expertise. Can such theoretical practices display a 'material consciousness'? Physicist Richard Feynman is a good example of how they can. In Feynman's anecdotal autobiography, he talks about his need to come up with clear material examples when discussing any kind of physics problem, no matter how abstract. His grasp of mathematical techniques was rigorously practical (and as a result, unorthodox) as he was always trying to solve 'real world' problems. He was as skilled in his ability to grasp the right problems (it's no coincidence that the word 'grasp' alludes to the hand and the handling of materials) as he was in his ability to solve them. You can't put it better than Feynman when he says "What I cannot create, I do not understand".
The pyschology of the craftsman
Lastly, a note on what I think might be one of the most illuminating insights into the psychology of the craftsman in the history of art, Tarkovsky's epic film Andrei Rublyov, in particular the penultimate vignette, which depicts a young boy that takes on a commission to cast a huge bell for the Russian Prince in the 13th Century. Those 30 minutes of cinema express a lot more than can be summarised here, depicting in detail the process of founding and casting the bell, and the young boy's descent into a craftman's obsession (his life depends on the bell ringing true). I'd simply ask you to watch it. There are other observations on the artisan/craftsman and their relation to religion and art (a foreign concept in the period the film is set in) throughout the film, which is the (mainly fabricated) biopic of a famous Russian icon painter.
PS: Whenever i've used the term 'craftsman' or 'craftsmen' I actually mean men and women, obviously.