Because you can learn typing without loving it and you can learn mopping without loving it. Not so with programming which is ultimately a creative task. I know plenty of people who went through university and learned the mechanics of programming without really liking it. These people will never be good programmers just like most people who wrote essays in college will never be good writers.
Ironically a mediocre programmer really compares better to a secretary than to a great programmer. He may be able to churn out code when given detailed instructions, just like the secretary will type out your letter when you dictate it to her. But the great programmer on the other hand; he decides what letter to write...
Not so with programming which is ultimately a creative task.
90% of programming - sometimes 99% - is forms or reports. Validate and store some data, or retrieve and format some data. No-one does that "for fun". You need professionals who can execute at a high level of competence true, but "creative" is a bit of an exaggeration.
Well, that depends on your environment ofcourse, but I'd say when you're spending 90% of your time on forms and reports then you're doing something wrong. A smart programmer would probably find or build a framework that allows the consumers of said reports to build their own so he doesn't have to continiously waste his time on that.
That's btw one of the main differences that I see between great and mediocre programmers. When you give the task of "build a report" to a mediocre programmer then he'll go and build a report that meets to your specs. He'll keep doing that even if he gets the same task every week.
A great programmer on the other hand will soon start trying to optimize the process by generalizing and automating. That's where the creativity kicks in. Programmers who love to code will try to get a repetitive, monotone duty out of their way asap, in order to free their time for more interesting problems. Programmers who merely "write code for a living" will rather stick to such tasks despite their inefficiency, because that "one hour per day on boring recurring tasks" is one hour that they don't have to do real work.
There are a lot of great tools for building simple forms that talk to databases and generate reports. At some point when it comes down to the things that separate this from from all other forms already created someone needs to actually build the form. It's a boring few minutes and then it's done, but then they want to change something and someone needs to fix that. And so it goes.
You missed the point. A skilled, creative programmer will write their own utility or framework to generate the boring stuff. Assuming they've done that well, feeding the form specification to your form compiler is all there is to it.
I think your missing the point. We already have form generates so filling out a from specification is what the programmer is doing. At some point there is nothing left to abstract and you need to specify what's happening. Doing that is programming and it's boring. For any complex system it becomes repetitive in novel ways such as: What's the best layout for the form? What data are we willing to take? etc. And once that's done you are always going to need to fine tune it which is boring.
PS: The logical next step would be to hand the customer your form generating software and get them to solve their problem, but that just ends up with someone debugging a horrible Access database. (Or whatever system you build.)
In summery: Specifying a specific form specification to collect or show useful information is programming. (Say that 3 times fast.)
Defining the specifications of a form could be considered programming, as is defining formulas in a spreadsheet application. In this thread, I don't believe the definition of programming includes Excel users.
Creating an application for building forms (e.g., Wufoo) is programming, building a form with Wufoo is not.
Note, I like the idea of getting non-programmers involved in programming activities. However, just because you work as a programmer and get stuck with things a non-programmer can do doesn't mean programmig is boring, it means you have a boring job.
If your using Excel for simple data entry that's one thing, but like most advanced forms of this idea it's got a Turing complete scripting language. Access works the same way. If you know nothing about programming you can quickly create a huge mess that almost works.
I think you get the same then for any significantly advanced Form generating software. At some point you need to link 2 elements and do some math and you end up starting the whole ball rolling again. How would you build the "perfect" form generating software for a Pizza Topping Selector so the client can change any part of the interface in any way they want at any time and have any discount they want for any list of toppings? ... Great now is your form generator simpler than just writing the code?
PS: You can talk about just the GUI but tools like visual studio are already have GUI tools for building GUI's.
I think your pizza topping selector example is dead on. Because yes, that's your task as a programmer. You deliver a pizza-topping-selector-configurator that has all the flexibilities built in that the client needs and it will be easier to use than actually writing code.
Your job is also to extend said configurator when the client has new ideas (e.g. a new rebate system) but your job should not be to carve the forms for individual pizza's (which probably change by the season) into code. That's exactly where I would draw the line, thanks for providing this example.
Let's say they want the ability to have themes which automatically occur for special events. Now you have the back end (keeping track of the order), GUI (what the user sees), interface builder, script builder (Interface for deciding which themes show up when), topping interface (name, cost, picture), Discount builder (for groups of toppings and groups of pizza's).
But, what is this script builder and what is this interface builder, and discount builder? Well we want scripts that can change the interface and add the holiday special toppings, and change the billing information. And we want a nice interface for changing the look and feel of the website. Great, but who is going to use them and what are they going to be doing?
A: The most flexible interface is always code. It's also to complex for the average user to understand. So we constantly get this pattern n * Developer > Script builder > Script Selector > User. The secret is creating the most useful easy to debug scripting language. You want them to say 2 weeks before Easter and they don't have to worry about when the full moon is.
PS: Once you realize your building a scripting language it's a good idea to consider what type of language your building http://www.paulgraham.com/langdes.html because while it might be fastest for your script to be written in the same language you code in your users want something that looks no more complex than BASIC. (See: Excel) However, if they want you to build the script's then you can just use your language / IDE and EVAL the script.
It depends what stage the project you're working on is at. Adding new forms to an enterprise-level CRM might be where a lot of (boring) programming jobs are at, but it doesn't preclude creative programmers: those who create a system from scratch that does something that has never been done before.
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.
Don't knock secretaries. My mother spent a number of years writing letters for her EdD boss, who was close to functionally illiterate. (He was hardpressed to compose a grammatical sentence, much less a coherent paragraph.)
Ironically a mediocre programmer really compares better to a secretary than to a great programmer. He may be able to churn out code when given detailed instructions, just like the secretary will type out your letter when you dictate it to her. But the great programmer on the other hand; he decides what letter to write...