3 ms·

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 sma

by moe 18y ago

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.

Retric 18y ago
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.
- mattrepl 18y ago
  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.
  - Retric 18y ago
    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.)
    - mattrepl 18y ago
      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.
      - Retric 18y ago
        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. "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 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.
        moe 18y ago
        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.

by moe 18y ago

Retric 18y ago

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.

mattrepl 18y ago
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.
- Retric 18y ago
  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.)
  - mattrepl 18y ago
    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.
    - Retric 18y ago
      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. "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 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.
      - moe 18y ago
        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.