Supuestos de programación incorrectos de larga data [cerrados]

Estoy investigando algunos errores comunes y suposiciones pobres hechas por ingenieros de software junior (y quizás senior).

¿Cuál fue su suposición más antigua que finalmente se corrigió?

Por ejemplo, entendí mal que el tamaño de un número entero no es un estándar y, en cambio, depende del idioma y el objetivo. Es un poco embarazoso decirlo, pero ahí está.

Ser franco; ¿Qué creencia firme tenía y aproximadamente cuánto tiempo mantuvo la suposición? Puede tratarse de un algoritmo, un lenguaje, un concepto de programación, pruebas o cualquier otra cosa sobre programación, lenguajes de programación o ciencias de la computación.

Durante mucho tiempo supuse que todos los demás tenían este súper dominio de todos los conceptos de programación (patrones de diseño, el último lenguaje nuevo, complejidad computacional, expresiones lambda, lo que sea).

Leer blogs, Stack Overflow y programar libros siempre me hizo sentir que estaba detrás de la curva de las cosas que todos los programadores deben saber intuitivamente.

Con el tiempo me he dado cuenta de que estoy comparando efectivamente mi conocimiento con el conocimiento colectivo de muchas personas, no con un solo individuo, y eso es una barra bastante alta para cualquiera. La mayoría de los programadores en el mundo real tienen un caché de conocimiento que se requiere para hacer su trabajo y tienen más de unas pocas áreas que son débiles o completamente ignorantes.

Que la gente supiera lo que quería.

Durante mucho tiempo pensé que hablaría con la gente, ellos describirían un problema o flujo de trabajo y lo pondría en código y lo automatizaría. Resulta que cada vez que sucede, lo que pensaban que querían no era realmente lo que querían.

Editar: estoy de acuerdo con la mayoría de los comentarios. Esta no es una respuesta técnica y puede que no sea lo que el interlocutor estaba buscando. No se aplica solo a la programación. Estoy seguro de que tampoco es mi suposición más antigua, pero fue lo más sorprendente que he aprendido en los 10 años que llevo haciendo esto. Estoy seguro de que fue pura ingenuidad de mi parte, pero la forma en que mi cerebro está conectado y las enseñanzas y experiencias que tuve antes de ingresar al mundo de los negocios me hicieron creer que estaría haciendo lo que respondía; que podría usar código y computadoras para solucionar los problemas de las personas.

Supongo que esta respuesta es similar a la de Robin sobre que los no programadores entienden / se preocupan por lo que estoy hablando. Se trata de aprender el negocio como un proceso ágil, iterativo e interactivo. Se trata de aprender la diferencia entre ser un código de programación y ser un desarrollador de software. Se trata de darse cuenta de que hay una diferencia entre los dos y que para ser realmente bueno en el campo, no se trata solo de la sintaxis y la velocidad de escritura.

Editar: Esta respuesta ahora es community-wiki para apaciguar a las personas molestas por esta respuesta que me da rep.

Que sé dónde está el problema de rendimiento sin perfilar

Que debería tener solo un punto de salida de una función / método.

Que los no programadores entiendan de lo que estoy hablando.

Ese software libre de errores fue posible.

Que las variables miembro privadas eran privadas para la instancia y no para la clase.

Pensé que la escritura estática estaba muy quieta en tu teclado.

Que puede comprender completamente un problema antes de comenzar a desarrollar.

Las personas inteligentes siempre son más inteligentes que yo.

Realmente puedo vencerme cuando cometo errores y, a menudo, me regañan por autocrítica. Solía ​​mirar con asombro a muchos desarrolladores y a menudo asumía que, dado que sabían más que yo en X , sabían más que yo.

A medida que continúo ganando experiencia y conociendo a más personas, comencé a darme cuenta de que a menudo, aunque saben más que yo en un tema en particular, no son necesariamente más inteligentes que tú / yo.

Moraleja de la historia: nunca subestimes lo que puedes traer a la mesa.

Durante mucho tiempo pensé que la mala programación era algo que sucedía al margen ... que hacer las cosas correctamente era la norma. No soy tan ingenuo en estos días.

Pensé que debería avanzar hacia la abstracción tanto como sea posible. Me golpearon en la cabeza principal con esto, debido a demasiados bits de funcionalidad entrelazados.

Ahora trato de mantener las cosas lo más simples y desacopladas posible. Refactorizar para hacer algo abstracto es mucho más fácil que predecir cómo necesito abstraer algo.

Por lo tanto, pasé de desarrollar el marco que los gobierna a todos, a fragmentos de funcionalidad que hacen el trabajo. Nunca miré hacia atrás, excepto cuando pienso en el momento en que ingenuamente pensé que sería yo quien desarrollaría la próxima gran cosa.

Que las mujeres encuentren a los programadores de computadoras sexys ...

Que la calidad del software conducirá a mayores ventas. A veces lo hace, pero no siempre.

Que todos los idiomas son (en su mayoría) creados iguales

Durante un buen rato pensé que el lenguaje elegido realmente no marcaba una gran diferencia en la dificultad del proceso de desarrollo y el potencial para el éxito del proyecto. Esto definitivamente no es cierto.

Elegir el idioma adecuado para el trabajo es tan importante / crítico como cualquier otra decisión de proyecto individual que se tome.

Que una buena relación comentario / código es algo bueno.

Me tomó un tiempo darme cuenta de que el código debería auto documentarse. Claro, un comentario aquí y allá es útil si el código no se puede aclarar o si hay una razón importante por la que se está haciendo algo. Pero, en general, es mejor pasar ese tiempo de comentarios cambiando el nombre de las variables. Es más limpio, más claro y los comentarios no se "sincronizan" con el código.

Esa programación es imposible.

No es broma, siempre pensé que la programación era algo imposible de aprender, y siempre me mantuve alejado de ella. Y cuando llegué cerca del código, nunca pude entenderlo.

Entonces, un día, simplemente me senté y leí algunos tutoriales básicos para principiantes, y trabajé desde allí. Y hoy trabajo como programador y me encanta cada minuto.

Además, no creo que programar sea fácil, es un desafío y me encanta aprender más y no hay nada más divertido que resolver algún problema de programación.

"On Error Resume Next" fue algún tipo de manejo de errores

Ese software de programación requiere una base sólida en matemáticas superiores.

Durante años antes de comenzar a codificar, siempre me dijeron que para ser un buen programador había que ser bueno en álgebra avanzada, geometría, cálculo, trigonometría, etc.

Diez años después y solo una vez tuve que hacer algo que un alumno de octavo grado no podía hacer.

Esa optimización == reescritura en lenguaje ensamblador.

Cuando entendí realmente el ensamblaje (proveniente de BASIC), parecía que la única forma de hacer que el código se ejecutara más rápido era reescribirlo en ensamblador. Tomó varios años darse cuenta de que los compiladores pueden ser muy buenos en la optimización y especialmente con CPU con predicción de ramificaciones, etc., probablemente puedan hacer un mejor trabajo que un humano en un tiempo razonable. Además, pasar tiempo optimizando el algoritmo probablemente le dará una mejor ganancia que pasar tiempo convirtiendo de un lenguaje de alto nivel a uno de bajo nivel. También que la optimización prematura es la raíz de todo mal ...

• Que los ejecutivos de la compañía se preocupen por la calidad del código.
• Que menos líneas es mejor.

Diría que almacenar el elemento de año de una fecha como 2 dígitos fue una suposición que afligió a toda una generación de desarrolladores. El dinero que se gastó en Y2K fue bastante horrible.

Que cualquier otra cosa que no sea inserción / burbuja fue simplemente magia oscura.

Ese XML sería un formato de datos verdaderamente interoperable y legible por humanos.

Ese C ++ era de alguna manera intrínsecamente mejor que todos los demás lenguajes.

Esto lo recibí de un amigo un par de años antes que yo en la universidad. Lo guardé conmigo durante un tiempo embarazosamente largo (me estoy sonrojando en este momento). Fue solo después de trabajar con él durante 2 años más o menos antes de que pudiera ver las grietas de lo que eran.

Nadie, y nada, es perfecto, siempre hay margen de mejora.

Creí que crear programas sería exactamente como lo que se enseñó en clase ... te sientas con un grupo de personas, revisas un problema, encuentras una solución, etc. etc. En cambio, el mundo real es "Aquí está mi problema, lo necesito resuelto, ve "y diez minutos después obtienes otro, dejándote sin tiempo real para planificar tu solución de manera eficiente.

Pensé que los patrones de diseño convencionales eran increíbles, cuando se introdujeron en una clase de CS. Había programado unos 8 años como pasatiempo antes de eso, y realmente no tenía una comprensión sólida de cómo crear buenas abstracciones.

Los patrones de diseño se sentían como magia; podrías hacer cosas realmente buenas. Más tarde descubrí la programación funcional (a través de Mozart / Oz, OCaml, luego Scala, Haskell y Clojure), y luego entendí que muchos de los patrones eran simplemente repetitivos, o complejidad adicional, porque el lenguaje no era lo suficientemente expresivo.

Por supuesto, casi siempre hay algún tipo de patrones, pero están en un nivel superior en lenguajes expresivos. Ahora he estado haciendo codificación profesional en Java, y realmente siento el dolor cuando tengo que usar una convención como visitante o patrón de comando, en lugar de la coincidencia de patrones y las funciones de orden superior.

Durante los primeros años que estuve programando no entendí que 1 Kbyte es técnicamente 1024 bytes, no 1000. Siempre estaba un poco perplejo por el hecho de que el tamaño de mis archivos de datos parecía ligeramente diferente de lo que esperaba ser.

Esa condición se verifica como:

if (condition1 && condition2 && condition3)

se realizan en un orden no especificado ...

Que mi programación sería más rápida y mejor si la realizara sola.