CÓMO conseguir que un programador esté 100% interesado en escribir un EA basado en su IDEA - página 8

 
KimIV:
vaa20003 escribió (a):
Una vez hubo un cliente decente - sólo sabía lo que quería y explicó cómo debía funcionar. Y el resto - se trata de "botón rojo ..." :)
Aunque parezca ridículo para los programadores, seguro que los clientes también tienen un sueño sobre un programador ideal. No tendría que explicar nada, de modo que sabría lo que quiere el cliente. Que tuviera intuición y no pidiera dinero. Como, escribo C++ para la comida.


Bueno, hay muchos psíquicos y telépatas :-)

Y luego una doble pregunta: si un desarrollador ya lo sabe todo sobre el problema propuesto (y al final del desarrollo es incluso mejor para entender la esencia de la cuestión que el propio programador), entonces ¿por qué necesitamos a este mismo programador? Por experiencia, mientras no he hecho grandes proyectos por mi cuenta siempre he tenido que buscar bibliografía especial y estudiar de forma independiente la cuestión planteada, ya que el director del proyecto rara vez puede dar una respuesta coherente a las preguntas directas (ya que no sabe) y se confunde todo el tiempo.

Y otra pregunta muy delgada: ¿por qué un desarrollador DEBE conocer TODOS los aspectos de una empresa (para permitir la automatización de los procesos) y recibe menos dinero que las personas que trabajan en departamentos especializados responsables sólo de una parte limitada?

 
Cronex:
KimIV:
vaa20003 escribió (a):
Una vez hubo un cliente decente - sólo sabía lo que quería y explicó cómo debía funcionar. El resto son sobre el "botón rojo..." :)
Aunque parezca ridículo para los programadores, seguro que los clientes también sueñan con un programador ideal. Que no tuvieran que explicar nada, que supieran ellos mismos lo que necesita el cliente. Que tuviera intuición y no pidiera dinero. Como, escribo C++ para la comida.


Bueno, aquí hay muchos videntes y telépatas :-)

Y luego una contrapregunta: si el desarrollador ya lo sabe todo sobre la tarea prevista (y al final del desarrollo es incluso mejor para entender la esencia de la cuestión que el propio programador), entonces ¿por qué necesitamos a ese mismo programador? Por experiencia, mientras no he hecho grandes proyectos por mi cuenta siempre he tenido que buscar literatura especial y estudiar de forma independiente la cuestión planteada, porque el programador rara vez puede dar una respuesta coherente a las preguntas directas (ya que no sabe) y se confunde todo el tiempo.

Y otra pregunta muy delgada: ¿por qué un desarrollador DEBE conocer TODOS los aspectos de una empresa (para permitir la automatización de los procesos) y cobra menos que las personas que trabajan en departamentos especializados responsables sólo de una parte limitada?

¡Oh! ¡Y este es precisamente el problema!
cuando un programador trabaja como telépata y agita la puesta en escena para ver cómo debe ser... y luego la escupe y se sienta a estudiar el proceso tecnológico
y entonces el programador acude a él para pedirle consejo

en su día tuve que aprender contabilidad, por lo que me resultó más fácil hacer una red y elaborar un informe con el formulario 2
en lugar de explicarle a la señora qué botones debe pulsar y por qué cuenta así y qué cuentas del balance están implicadas y por qué aparece ese número

y entonces surgió la pregunta... al final la señora aprendió el formulario 2...

conocí a un buen programador una vez en mi vida! el software tardó dos meses en escribirse según los estándares... se escribió en una semana
me enseñó todo, hasta los formularios en la pantalla, en qué esquina debe estar qué casilla de verificación en qué base de datos debe estar qué campo y cómo rellenar
todos los directorios, lo has adivinado, el tipo es un programador... Básicamente, estaba codificando.

Creo que es casi imposible conocer a un tipo así en el negocio de las divisas.

---
Un desarrollador debe tener un buen conocimiento de las tecnologías, los lenguajes, entender lo que funciona y cómo funciona, y el dominio si no es perfecto.
pero esto no exime al promotor de pensar... formular la tarea, recortar las cosas innecesarias...
y diseñar bien, para que los cambios-adiciones puedan incorporarse al proyecto fácilmente
por supuesto, el diseñador debe entender cómo se construye la máquina y qué puede y no puede hacerse
los mejores programadores siguen siendo programadores... Creo que

una vez un contable me encomendó una tarea.
Le pregunté por las facturas,
¡dice que no los tenemos!
Yo digo, ¿y si?
Dice que no tenemos que abrirlos.
No es un problema para mí
No, no es necesario.
--- para que no tengas que hacerlo.

Dos meses después se abrieron, gracias a Dios sabía que era posible, no usé constantes sino referencias
pero sin embargo tuve que cambiar la lógica de cálculo y cambié las reglas...

pero si me hubiera dicho de inmediato no habría habido problemas
 
YuraZ: Una vez conocí a un buen programador en mi vida! El software tenía que tardar dos meses en escribirse, y en una semana me dijo todo hasta los formularios de la pantalla, en qué esquina debía estar cada casilla, en qué base de datos debía estar cada campo y cómo debían rellenarse todos los directorios, todo el mundo acertó - el tipo es un programador - ya era un jefe... Básicamente estaba codificando.

Soñar... He tenido más suerte que eso, he tenido tres.... ¡¡¡¡en los últimos diez años ;-) y dos de ellos venían de la informática (reciclados), pero qué guay era trabajar con ellos !!!!
 

Moraleja: Si quieres encargar algo grande a un codificador, sería muy deseable que tú mismo supieras codificar y, por supuesto, conocer las limitaciones del lenguaje. Bueno, si no lo eres, entonces tu brillante idea está condenada, porque incluso si se da cuenta de algo, la idea es casi seguro trivial (y simplemente no se puede explicar más al codificador, porque no es capaz) - y por lo tanto no rentable. Pues si intenta descifrar tus oscuros géneros, inevitablemente distorsionará tu idea, convirtiéndola de brillantemente rentable a mediocremente improductiva. Ahora la culpa será suya, ¡del codificador!

 
Es gracioso, es gracioso. Casi desde los primeros posts el hilo pasó bruscamente de "CÓMO conseguir que un programador se interese al 100% en escribir un EA basado en tu IDEA" a "Soy un codificador genial, y el 99% de los clientes son unos pringados".
 
Por cierto, las principales tareas en VBA son de doble contabilidad).
Y sobre el tema del hilo - pregunté a mi DC sobre MTS, y... "llama a la oficina central, allí hay un programador, recién contratado, explica lo que necesitas"
 
Korey:
Por cierto, las principales tareas en VBA son de doble contabilidad).
Y sobre el tema del hilo - pregunté a mi DC sobre MTS, y... "llama a la oficina central, allí hay un programador, recién contratado, explica lo que necesitas"

¿Cómo se llama el DC?
 
Fibo-Forex.com
 
Mathemat:

Moraleja: Si quieres pedir algo grande a un codificador, sería muy deseable que tú mismo supieras codificar y, por supuesto, conocer las limitaciones del lenguaje. Bueno, si no es así, entonces su brillante idea está condenada, porque incluso si se da cuenta de algo, la idea es casi seguro trivial (y simplemente no se puede explicar más a codificador, porque no es capaz) - y por lo tanto no rentable. Pues si intenta descifrar tus oscuros géneros, inevitablemente distorsionará tu idea, convirtiéndola de brillantemente rentable a mediocremente improductiva. Ahora la culpa será suya, ¡del codificador!


Bueno, si vas a sacar el tema del hilo, necesitas un ejemplo de control, y ¿cuál es el ejemplo de control para MTS y EA)).
 
bstone:
Es gracioso, es gracioso. Casi desde los primeros posts el hilo pasó abruptamente de " CÓMO conseguir que un programador se interese al 100% en escribir un asesor basado en tu IDEA" a "soy un codificador genial y el 99% de los clientes son unos pringados".
hmmm... buen punto... pero sin el constructivo "soy un cliente genial y el 99% de los programadores son unos pringados". Tú dices "A", tú dices "B". Abre el tema. Y eso sería lo correcto: mirar la cuestión desde todos los ángulos.
Razón de la queja: