Una lista de programadores que son geniales escribiendo códigos de pago y que no se andan con chiquitas - página 12
Está perdiendo oportunidades comerciales:
- Aplicaciones de trading gratuitas
- 8 000+ señales para copiar
- Noticias económicas para analizar los mercados financieros
Registro
Entrada
Usted acepta la política del sitio web y las condiciones de uso
Si no tiene cuenta de usuario, regístrese
Lo siento, no estoy haciendo un gran escándalo, estoy en contra de la lista sin fundamento. Querías y pusiste a una persona en la lista, y crees que está bien. Escribí que hay que argumentar a favor de la inclusión, pero este es un enfrentamiento ruidoso. No es un argumento objetivo.
Creo que un buen argumento sería el número de guiones publicados. Creo que un buen programador compartiría algo.
¿Y cuáles son sus éxitos (de la lista anterior) en los campeonatos mundiales de autocomercio?
Me refiero a la práctica, en condiciones reales. Me gustaría saber con quién está tratando.
Me interesan los expertos-escritores y los teóricos sólo para los principiantes.
Me interesan los principiantes que puedan ser atraídos por los hermosos dibujos que hacen los pavos.
No, la rentabilidad de los EAs definitivamente no es un criterio. Ninguna de las "mega leyendas" de los foros en lengua rusa ha llegado a estar entre los tres primeros. Espero que nadie se ofenda si he subestimado a alguien inadvertidamente.
Además, las condiciones estaban lejos de ser reales.
No, la rentabilidad de los EAs definitivamente no es un criterio.
La rentabilidad por sí misma no es un criterio. Exactitud y minuciosidad del código en los detalles: este es un criterio más importante, pero, por desgracia, sólo... otro programador :) La rentabilidad está en la idea, el EA está en el código. Son cosas diferentes.
Además, los programadores pueden tener buenas razones para no presentar sus EA a los concursos.
Creo que el número de guiones publicados es un buen argumento.
La cantidad no es la calidad. He visto algunos EAs con errores aterradores... me quedé con la boca abierta.
Creo que el mejor criterio sigue siendo la opinión del cliente. El cliente puede evaluar los siguientes puntos por sí mismo:
1. ¿Se hizo el trabajo a tiempo?
¿El código estaba anotado y era legible?
3. ¿Se han tenido en cuenta todos los deseos factibles del cliente?
4. Si algún deseo no se cumple o no es factible, ¿ha podido el ejecutante explicar el motivo al cliente de forma comprensible?
5. ¿El intérprete ha ayudado al cliente a entender el uso del asesor proporcionado (indicador, guión...), acompañado de palabras de despedida, consejos?
Todo esto es lo que necesita el cliente.
"1. El trabajo está hecho a tiempo" - cuántos casos en los que parece estar de acuerdo y luego el cliente es otra cosa contribuye ... y el plazo se mueve.
"2. ¿El código está comentado y es legible? "Si el cliente no entiende la codificación, no le interesa.
La discusión de los TdR por sí sola puede ser más larga que la codificación. Se necesita tiempo para comprender lo que realmente quiere. A veces hay que usar pinzas.
"4. Si alguna petición no se cumple o no se lleva a cabo, ¿el ejecutante fue capaz de explicar al cliente la razón a un nivel comprensible?" - y a la p.5. está claro que todo normal. proger explica ( a veces es necesario explicar para que el cerebro hierva)
Dale una calificación de 0 a 10 y no te preocupes.
1. Hay veces que el plazo se pospone de mutuo acuerdo por necesidades del cliente. Pero no es de eso de lo que estamos hablando aquí, sino de un descarado dilema.
2. Puede que no entienda de codificación. Pero, "sobre el fastidio" - no estoy de acuerdo. En primer lugar, puede tratarse de un fenómeno temporal: no lo entiende ahora y lo entenderá después. En segundo lugar, el código puede actualizarse varias veces en el futuro y debe ser adecuado para ello. Por lo demás, hay un par de programadores en mi departamento que, cuando miran el código que escribieron hace medio año, al principio exclaman durante una semana: "¡Santo cielo, qué he escrito aquí!" Pero hay que trabajar, no se puede evitar.
4. Yo mismo soy un programador muy experimentado, lo sé. Sin embargo, un buen programador se diferencia de uno malo en que puede explicar sobre el aro qué es qué. Mientras que uno malo sólo tiene un argumento: "no se puede, porque no se puede". En otras palabras, el cliente debe estar satisfecho (no enfadado), aunque no haya conseguido lo que quería. Por supuesto, no me refiero a casos de psicopatología por parte del cliente, eso también ocurre. Pero, en general, los clientes suelen ser personas cuerdas y, si se les explica adecuadamente, lo entenderán.
En cuanto a la calificación de 0 a 10 - por supuesto. Sólo he dado los criterios por los que el cliente puede evaluar el trabajo de un programador.
Recomiendo escribir un conjunto de reglas para comunicarse con nosotros a la lista de programadores.
El programador debe explicar por qué es así y por qué no.
Aunque en mi práctica de peritaje, evalúo la rentabilidad o no de la idea del cliente sólo leyendo los TDR, si la idea no es complicada, si es complicada, entonces haré un par de comprobaciones y también diré el resultado aproximado. Si el cliente ha reflexionado sobre la información lista para pedir el desarrollo, comience a discutir los detalles de la TOR.
A menudo los clientes no sólo desconocen los conceptos, sino que no distinguen una orden de una posición. Y a veces utilizan tal terminología que hay que buscar las palabras en los diccionarios.
Nuestros clientes, expresan sus pensamientos de forma clara y comprensible, y utilizan el menor número posible de coloquialismos.
Un ejemplo de cadenas de TOR que el programador no entiende.
Esta es una señal vino, por lo que abrir, detener y donde el beneficio se va a cerrar tengo que ajustar a mí mismo en las opciones. Todos han entrado en el mercado y esperan. Hay que esperar y esperar, y luego el experto tiene que cerrar el negocio rentable por sí mismo.
De esta manera, ninguno de los programadores entenderá exactamente, por qué reglas abrir un trato, qué esperar, cómo cerrar....
"Como si entrara una señal, entonces abrimos, paramos y donde se cierran los beneficios tengo que configurarlo yo mismo en los ajustes. Todo el mundo ha entrado en el mercado y espera. Esperamos, esperamos, y luego la exposición cierra el negocio rentable por sí misma.
Así es como ninguno de los programadores entenderá, por qué reglas abrir un trato, qué esperar, cómo cerrar....
En esta pregunta en mi perfil el enlace al libro en Ozono (Estructura de la Magia).
4. Yo mismo soy programador, con una experiencia muy larga, lo sé. Sin embargo, un buen programador se diferencia de uno malo en que puede explicar sobre el aro qué es qué. Pero un mal programador sólo tiene un argumento: "no se puede, porque no se puede". En otras palabras, 1. el cliente debe estar satisfecho (no enfadado), aunque no haya conseguido lo que quería. Por supuesto, no me refiero a casos de psicopatología por parte del cliente, esto también ocurre. Pero, en general, los clientes suelen ser personas cuerdas y, si se les explica adecuadamente, lo entenderán.
Con respecto a la calificación de 0 a 10 - por supuesto. Acabo de citar los criterios por los que el cliente puede evaluar el trabajo del programador.
Con este enfoque por parte del cliente debemos pensar en cómo garantizar que el programador también esté satisfecho. Normalmente hay un 80% de psicoanálisis y sólo un 20% de programación y el constante "qué no está claro aquí"("un simple pavo gratis"). Las instrucciones no se leen crónicamente.