¿Qué errores de programación no debe evitar un programador? [cerrado]

7

La gente comete errores, incluso en la vida real ... ¿Qué debemos evitar, los programadores geek?

    
pregunta Tom Wijsman 18.09.2010 - 23:00

17 respuestas

31

Aprende que lo que constituye "un grado aceptable de precisión" para ti es "Molestionante maldición" para la mayor parte del mundo.

    
respondido por el BlairHippo 09.09.2010 - 20:00
29

Aprenda a escuchar a las personas (o usuarios de su producto).

Demasiados programadores son rápidos para saltar a "este usuario es un idiota" en lugar de escuchar lo que la persona o el usuario tiene que decir. Hay algo que aprender de todos en este mundo.

    
respondido por el Brian R. Bondy 09.09.2010 - 19:51
17

El error de programación más grande que he visto:

No está aprendiendo a comunicarse de manera efectiva, tanto oralmente como por escrito.

Tome dos programadores de igual habilidad de programación, uno con buenas habilidades de comunicación y otro sin. El primero irá más lejos, más rápido cada. soltero. tiempo.

    
respondido por el user819 09.09.2010 - 22:53
14

Alejar a las personas normales de cualquier detalle técnico innecesario. A ellos no les importa.

Y no babees con tus compañeras.

    
respondido por el Carlos 09.09.2010 - 20:39
10

Ergonomía. Obtenga un profesional real para evaluar su estación de trabajo y recomendar la colocación del monitor, el teclado y la silla.

Estire suavemente sus manos, muñecas y brazos antes de comenzar una sesión extensa con el teclado. Presta atención a tu postura también.

Comencé a tener mucho dolor de muñeca en 1998 y tuve que cambiar algunos de mis hábitos. Hasta el día de hoy, uso muñequeras mientras trabajo en la computadora (uso IMAK SmartGlove).

No juegues demasiados videojuegos, eso aumenta las horas que pasas torturándote las manos y las muñecas.

También, beba mucha agua y haga ejercicio regularmente. Dejar los refrescos.

    
respondido por el Bill Karwin 13.09.2010 - 16:51
9

No estoy aprendiendo tanto sobre el dominio empresarial, los usuarios, el contenido para el que está escribiendo software.

    
respondido por el JeffO 13.09.2010 - 16:31
8

Nunca comas nada más grande que tu propia cabeza

    
respondido por el Ryan Roberts 09.09.2010 - 19:52
8

Los programadores y desarrolladores geeky deben evitar decir lo que realmente piensan acerca de los gerentes de proyecto, evaluadores de control de calidad, DBA y otros no programadores.

En esencia, sé agradable .

    
respondido por el spong 09.09.2010 - 19:54
6

Tratar a todos los demás que conoces como un programador. Tienes que entender que no todos a tu alrededor se preocupan por las computadoras tanto como tú. Es una píldora difícil de tragar, pero desafortunadamente es muy real.

    
respondido por el Kyle Ballard 09.09.2010 - 19:58
4

Tenga en cuenta que si se encuentra en un entorno de desarrollo en cascada, los documentos de requisitos, los BRD, etc. son, en general, cuentos de hadas. Los requisitos y los proyectos de software en general están en un estado de flujo constante y es extremadamente raro tener un conjunto de requisitos que no cambien a lo largo del ciclo de vida del proyecto. Los empresarios son meticulosos y les gusta cambiar mucho de opinión. Dicho esto, la mayoría de las tiendas de software todavía operan con una mentalidad de cascada. Existe un movimiento creciente que apoya las metodologías ágiles (el cambio es inevitable y debería ser aceptado), pero personalmente, nunca he visto ni oído hablar de un proyecto moderno de desarrollo empresarial que tuviera requisitos concretos, prácticas, etc. durante toda su vida. La clave para llevar es que las cosas casi siempre cambian. En mi experiencia, el grado probable de cambio de las cosas es directamente proporcional a la duración del proyecto ... que también está en un estado de flujo constante.

    
respondido por el Casey 19.09.2010 - 01:30
3

"¡Funciona en mi máquina!" Es una excusa que solo puede llegar tan lejos. Asegúrese de considerar múltiples entornos imparciales. ¡Su máquina de desarrollo, desafortunadamente, está bien construida para ejecutar cualquier programa que tenga en ella!

    
respondido por el Clint V. 02.11.2011 - 19:51
2

Aprende a admitir lo que no sabes. Si no sabes la respuesta, dilo. No trates de hacer algo solo para que puedas dar una respuesta. Eso te pondrá en problemas a largo plazo.

    
respondido por el Tyanna 19.09.2010 - 01:12
2

Pensando que serás recompensado bastante por tus esfuerzos. En otras palabras, puede pensar que será recompensado por trabajar duro y hacer un buen código y que será castigado por pasar todo el día en el intercambio de pila.

Pero este no es el caso. En muchos casos, trabajará con / para personas despistadas que simplemente adivinarán cuánto trabaja, cuál es su valor y lo condescendemos.

    
respondido por el Joe 02.11.2011 - 21:20
1

Aprende a estimar.

    
respondido por el Victor Hurdugaci 09.09.2010 - 19:55
1

Un 'error de no programación' que veo que la gente comete (especialmente el que está en el espejo) es "golpearte el dedo del pie".

Con esto, quiero decir, excitarme demasiado por un pequeño error, como apuñalarte el dedo del pie. Entonces tomando una reacción negativa excesiva. La frustración en última instancia, bolas de nieve y un montón de pequeños problemas terminan causando dolor de corazón masivo y tristeza. Cuando algo sale mal, toma un breve descanso, respira y luego vuelve a conectar.

  • Atascarse en un error, tomar un descanso.
  • La aplicación funciona en 3 servidores, pero no en el cuarto, toma un descanso de 5 a 15 minutos.
  • El IDE se bloquea aleatoriamente, toma un descanso.
  • Los niños no dejarán de rebotar en las paredes, tomarán un descanso. (tal vez reducir el azúcar en la dieta también)

En la primera década de mi carrera, esto me sucedió todo el tiempo. Yo era mi peor enemigo la mayoría de las veces. Todavía caigo presa de esta trampa, pero con mucha menos frecuencia.

    
respondido por el DevSolo 02.11.2011 - 20:14
1
  

"La suposición es la madre de todos los f ** kups".

- Under Siege 2: Dark Territory (1995)

    
respondido por el tcrosley 02.11.2011 - 20:30
1

Evita ser demasiado dramático cuando ocurren errores. Un error tipográfico no es el fin del mundo. El hecho de que una tarea haya tardado un poco más de lo estimado inicialmente no es lo peor. La historia de Norden Bombsight sería un ejemplo en el que, si bien alguien tuvo una buena idea y buenas intenciones para hacer una nueva dispositivo, puede haber varias otras cosas que suceden para reducir la efectividad de lo nuevo creado. Definitivamente un cuento de advertencia ya que espera obtener la charla sobre la salsa de espagueti a sus espaldas desde febrero de 2004.

    
respondido por el JB King 02.11.2011 - 21:24

Lea otras preguntas en las etiquetas