¿En qué se equivocan los programadores pero se niegan a admitir?

Answer 1

Cuando algo falla. En mi experiencia, esto no suele ser un problema. Algo que falla ha fallado.

Sin embargo, puede suceder que un error informado se deba a datos o un error del usuario, no a la programación. O debido al sistema. Tenía muchos casos y verificaba los datos si el código no hubiera producido el error informado. Solo después de confirmar que los datos estaban bien, estaría seguro de que era un fallo del programa.

Con problemas de mayor escala es más complejo. Si una buena idea parece estar fallando, ¿debería uno abandonarla o seguir adelante? Uno podría encontrar muchos ejemplos que justificarían ambas opciones, donde la persistencia dio sus frutos o donde solo multiplicó los costos.

Answer 2

Cuánto tardarán las cosas. Pero nos negamos a admitir esto casi conscientemente como una defensa contra las fuerzas de la oscuridad que nos rodean.

Para trabajar profesionalmente como ingeniero de software y tener éxito, debe ser optimista casi hasta el punto de la locura, de lo contrario, toda la actividad será estresante en todo momento. A pesar de que, ocasionalmente, los proyectos se vuelven locos y toman un orden de magnitud más largo de lo esperado, uno tiene que olvidarlo al comenzar uno nuevo.

Caminar en un campo minado no es estresante a menos que te des cuenta de que es un campo minado. Una vez que sobrevives a unos pocos campos minados, no puedes simplemente cerrarte y negarte a caminar más en los campos minados y no puedes decir que caminaré por ese campo minado si me das un robot y un año para manipularlo pulgada a pulgada . Tienes que decir: “Parece que eso debería tomar aproximadamente una semana. Estoy seguro de que tomará aproximadamente una semana” …

Answer 3

La hora en que el compilador le recuerda errores misceláneos. En algunos casos, algunas advertencias deben incluirse también.