You should never hire a secretary who doesn't type for fun.
You should never hire a caretaker who doesn't mop floors for fun.
Doesn't actually work, does it? Why are programmers "special"?
You should never hire a caretaker who doesn't mop floors for fun.
Doesn't actually work, does it? Why are programmers "special"?
You should never hire an artist who doesn't paint/draw/whatever for fun.
Seems to work ok for creative professions.
EX: There are a lot of programmers who spend a lot of time interfacing with buggy API's which is soul sucking work, because the bugs are random.
PS: If you are building a boy band you probably don't are about artistic talent. It might be useful but it's far from the most important trait.
What makes programmers special?
1) There are actually people who program for fun. If you looked for rockstar janitors who mopped floors for fun, you wouldn't find any.
2) There is an order of magnitude or two difference in the productivity of great programmers compared to average programmers, whereas a great janitor or secretary may be something like twice as productive as an average one. It's more important to find a good one.
3) Filtering good programmers is notoriously difficult - it's not like typing where you can give candidates a simple test and get a straightforward, quantitative answer, so every bit of information helps.
In honor of my late grandmother, who devoted about twenty years' worth of Saturdays to cleaning the floors and bathrooms of her local church -- for free -- I must inform you that this isn't true.
Whether or not she was maximally productive is quite a different question. A lot of ritual activity isn't especially intended to be productive.
Canada. I don't understand it either.
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...
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.
You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?
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.
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.
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.
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.
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.
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.)
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.
"Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.[2]" (http://en.wikipedia.org/wiki/Greenspun%27s_Tenth_Rule)
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.
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.
Lisp is great because it understands this pattern and works well. Viaweb is a great example of this: http://www.paulgraham.com/avg.html, http://lib.store.yahoo.net/lib/paulgraham/bbnexcerpts.txt, and there is also a good essay on their the scripting language they built but I can't find it.
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.
Also an rock star secretary can work smart rather than hard finding ways to remove repetition.
A janitor could be a rockstar if they used methods to clean an office space to extreme detail with utmost efficiency.
Admittedly the more work moves into the physical world, the harder it is to scale with simple mental skill, but programmers are not the only ones that can become "rock stars." Also, WPM is not as relevant a way to measure a secretary's skills any more just as it isn't a way to measure a programmer's skills.
@brl: I know you just wrote a sentence, and this really isn't a reply to directly to you, but more to the elitist us and them content of this forum.
My point is simply that the quality of developer talent at a software company will permanently influence the future of that company in a way that can't be compared by simple analogies.
There are good reasons to be more concerned with hiring the best programmers you can find than hiring the best secretary or the best janitor.
you can't force creativity. of course, not all programmers need to be creative, but some do have to be.
i agree though, it's a bit foolish to expect all your programmers to be "rock stars".