4 ms·

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,

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.

gaius 18y ago
All Web 2.0 is is forms and reports. You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?
- moe 18y ago
  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.
  - gaius 18y ago
    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?
    - moe 18y ago
      Didn't I just explain that in my previous post? 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.
      - timr 18y ago
        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.
        cstejerean 18y ago
        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.
        timr 18y ago
        You're arguing idealism; I'm arguing reality. In most cases, programmers serve a role that is closer to the construction worker than the architect.
        cstejerean 18y ago
        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.
        moe 18y ago
        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.
- daleharvey 18y ago
  I think with almost every comment here cringing at the terminology, people calling themselves (or others) "rock stars" are in the minority

gaius 18y ago

All Web 2.0 is is forms and reports. You think, back in the 60s when it was the latest thing, COBOL programmers called themselves "rockstars"?

moe 18y ago
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.
- gaius 18y ago
  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?
  - moe 18y ago
    Didn't I just explain that in my previous post? 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.
    - timr 18y ago
      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.
      - cstejerean 18y ago
        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.
        timr 18y ago
        You're arguing idealism; I'm arguing reality. In most cases, programmers serve a role that is closer to the construction worker than the architect.
        cstejerean 18y ago
        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.
        moe 18y ago
        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.
daleharvey 18y ago
I think with almost every comment here cringing at the terminology, people calling themselves (or others) "rock stars" are in the minority