Wow, the IQ thing really got under peoples skin, but I think his point is that the hard part of being a really good programmer is dealing with all the bullshit that managers invent to keep the mediocre programmers on the straight and narrow.
Problem being, those efforts essentially make one programmer indistinguishable from another by putting shackles on everyone. I admit there's a certain logic to it, building a business that's dependent on one person's talent can be dangerous. Better to make people interchangable.
All the same: Can you imagine John Carmack writing Doom back in the 90s having to deal with what most coders have to deal with nowadays (With all the "agile")? "No sorry John, you can't commit your highly inventive code without a proper story. We're going to need to have a planning meeting on this and size up story points. Please take a defect off the list. We don't need any heroes or cowboy coders."
I have to object that there is seriously more to project management than keeping the "mediocre programmers" in line.
I mean, there are overly ambitious programmers that do have to be reigned in, there are people held back by whatever structure you might and many variations of this.
And code has to be appropriate for it's purpose. I'm sure the code for Doom is great for Doom. If it is "cowboy code", it's probably not what anyone would want for an inventory control program that will be passed to someone else in six months.
But that's kind of the point isn't it: project management, and especially agile, is about making work predictable. There's an undeniable business logic to this that I wouldn't refute.
Yet works of greatness are almost never predictable. You can't reign it into story points or whatever. There's too many false starts, or sudden insights. It certainly takes process and discipline, but not necessarily the kind that can be measured and reported.
That's probably fine for most business, because your inventory control program doesn't need any individual brilliance; but I think it can be frustrating for really good programmers because they do want to create a work of greatness.
Yet works of greatness are almost never predictable.
Actually, most great artists work with a lot of constraints. There are many great realist painters who accept the constraint of realistically representing the world. Any programmer works with the constraints of the machine.
And working in the constraints of project management and multiple-person provides plenty of room for creativity I would say. Yes, you have the constraint of the code working and you have the constraint of the code being understandable. You might even have the constraint of telling the other programmers how to do the difficult thing you can do and they can't. Greatness is possible there given that greatness is possible with code that compiles as opposed to code which is merely unpredictable.
And project managers are always happy to have people finish faster than expected.
Problem being, those efforts essentially make one programmer indistinguishable from another by putting shackles on everyone. I admit there's a certain logic to it, building a business that's dependent on one person's talent can be dangerous. Better to make people interchangable.
All the same: Can you imagine John Carmack writing Doom back in the 90s having to deal with what most coders have to deal with nowadays (With all the "agile")? "No sorry John, you can't commit your highly inventive code without a proper story. We're going to need to have a planning meeting on this and size up story points. Please take a defect off the list. We don't need any heroes or cowboy coders."