That's nonsense, web programming is not (at least not in the general case) about forms and reports.
If forms and database queries eat up a large portion of your time then I'd suggest to look into proper frameworks. In fact, that's what web programming is about these days: Find ways to make the common tasks as easy as possible, without sacrifying performance or flexibility.
You don't want to spend the lion's share of your time on creating forms and views. You want to spend it on making the creation of forms and views so easy that the friction for actual feature development approaches zero.
Do you seriously believe that the Web 2.0 kids invented that? Frameworks, code generators, CASE tools, the whole lot have been around for a long time.
If web programming isn't all about validating and storing data (the tag is even called <form>), and retrieving and formatting data (into HTML) then what is it?
Ultimately all programming is about "garbage in / garbage out" or, as you put it, input, validate, store, output.
Summing up a specific programming domain like that is a bit like saying "architecting a house is about placing walls, doors and windows".
That statement is ofcourse true but it falls short of describing the real challenge which consists of deciding how and where to place said walls and doors under the premise of what we're trying to build (a train station or a shopping mall?).
Similarly, if you're spending more time on writing forms than on the features backing these forms then you're probably doing something wrong.
I think the point is that the construction workers don't get to decide where the doors and windows go. In most cases, programmers aren't the architects.
If you work in a team where there is a difference between the programmers and the architects, GET OUT! In a healthy environments programmers get to help shape the direction of the product and everyone should be able to voice their opinions or concerns so that the best decisions can be made.
That depends on whether or not you have it in you to be an architect (or your own boss for that matter) or are content just to lay the bricks according to someone else's plan.
Not all programmers were born to be architects, not all architects were born to be programmers either. There is enough special knowledge that goes in to design, engineering and assembly that there is room for specialization.
A really good coder can work just find with a really good 'architect' (systems analyst). "rockstars" tend to work only well with themselves, so they probably aren't part of a team to begin with.
The whole idea of teamwork is to work together but to let each individuals special talents take precedence.
If you are all three disciplines in one person then most likely you'll end up founding some startup.
Sure, and maybe right now is not the time to find a new job, but being treated like a construction worker should not be acceptable to any competent programmer. I'm not arguing that it doesn't happen, just that it doesn't have to be that way. Anyone stuck in those kind of conditions should know that there are better jobs out there where they can be treated like smart, competent adults instead of code monkeys.
I'm with cstejerean on this issue.
Remember the premise of the original article was an idealistic one, it basically said: "Which kind of programmer should you hire when you have a choice".
Given the goal is to make money I know which kind of team I would prefer. I'd definately prefer the one that automates everything out of the way as soon as possible because in an IT-heavy operation that really is one of the most basic dogmas in order to maintain momentum in the long term. If your goal is to cash out fast and close shop in 2 years then fine, spit and glue may be just right for your project. If your goal is to build to last then you'd damn sure better hire people who know what they're doing.
You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?