research - methodology types
Supuestos de programación incorrectos y de larga data (30)
Estoy investigando los errores comunes y las suposiciones deficientes de los 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 entero no es un estándar y, en cambio, depende del idioma y el destino. Un poco embarazoso de decir, pero ahí está.
Ser franco; ¿Qué creencia firme tenías y aproximadamente cuánto tiempo mantuviste la suposición? Puede tratarse de un algoritmo, un lenguaje, un concepto de programación, pruebas o cualquier otra cosa relacionada con la programación, los lenguajes de programación o la informática.
"On Error Resume Next" fue algún tipo de manejo de errores
Creía que crear programas sería exactamente como lo que se enseñó en clase ... te sientas con un grupo de personas, repasas un problema, encuentras una solución, etc. En cambio, el mundo real es "Aquí está Mi problema, lo necesito resuelto, vaya "y diez minutos más tarde obtendrá otro, sin tiempo real para planificar su solución de manera eficiente.
Durante los primeros años que programé no detecté que 1 Kbyte es técnicamente 1024 bytes, no 1000. Siempre me quedé un poco perplejo por el hecho de que los tamaños de mis archivos de datos parecían estar ligeramente fuera de lo que esperaba. ser.
Durante mucho tiempo asumí que todos los demás tenían este dominio de todos los conceptos de programación (patrones de diseño, el nuevo lenguaje más reciente, complejidad computacional, expresiones lambda, lo que sea).
Leer blogs, y programar libros siempre parecía hacerme sentir que estaba detrás de la curva en 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 de un solo individuo, y eso es un obstáculo bastante alto para cualquier persona. 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 de las cuales son débiles o completamente ignorantes.
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 estos días.
Esa condición se verifica como:
if (condition1 && condition2 && condition3)
Se realizan en un orden no especificado ...
Esa optimización == reescritura en lenguaje ensamblador.
Cuando entendí por primera vez 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 el ensamblaje. Tomó varios años darse cuenta de que los compiladores pueden ser muy buenos en la optimización y, especialmente, con las CPU con predicción de bifurcación, etc. probablemente puedan hacer un mejor trabajo que un humano en un tiempo razonable. También es probable que dedicar tiempo a optimizar el algoritmo le brinde una mejor ganancia que pasar el tiempo de conversión de un lenguaje de alto a bajo. También esa optimización prematura es la raíz de todo mal ...
Esa programación es imposible.
No bromeando, siempre pensé que la programación era algo imposible de aprender y siempre me mantenía alejado de ella. Y cuando me acerqué al código, nunca pude entenderlo.
Entonces, un día me senté y leí algunos tutoriales básicos para principiantes, y seguí mi camino desde allí. Y hoy trabajo como programador y amo cada minuto de ello.
Para agregar, no creo que la programación sea fácil, es un desafío y me encanta aprender más y no hay nada más divertido que resolver un problema de programación.
Ese XML sería un formato de datos verdaderamente interoperable y legible por humanos.
Ese software de programación requiere una base sólida en matemáticas superiores.
Durante años, antes de comenzar a programar, siempre me decían que para ser un buen programador tenía que ser bueno en álgebra avanzada, geometría, cálculo, trig, etc.
Diez años después, y solo una vez tuve que hacer algo que un alumno de octavo grado no pudo.
Ese software libre de errores fue posible.
Las personas inteligentes son siempre más inteligentes que yo.
Realmente puedo castigarme cuando cometo errores y, a menudo, me dicen que me autodesprecie. Solía admirar a muchos desarrolladores y a menudo asumía que, como 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 muchas veces, aunque saben más que yo en un tema en particular, no son necesariamente más inteligentes que yo / tú.
Moraleja de la historia: nunca subestime lo que puede traer a la mesa.
Las variables miembros privadas eran privadas para la instancia y no para la clase.
Pensé que debería avanzar hacia la abstracción tanto como sea posible. Me golpearon en la cabeza con esto, debido a demasiadas pequeñas partes de funcionalidad entrelazadas.
Ahora trato de mantener las cosas tan simples y desacopladas como sea posible. Refactorizar para hacer algo abstracto es mucho más fácil que predecir cómo debo abstraer algo.
Por lo tanto, pasé de desarrollar el marco que los regula a todos, a fragmentos de funcionalidad que hacen el trabajo. Nunca miré atrás, excepto cuando pienso en el momento en que ingenuamente pensé que sería el que desarrollaría la próxima gran cosa.
Pensé que la escritura estática estaba muy quieto en tu teclado.
Pensé que los patrones de diseño principales eran impresionantes, 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 limpias. Más tarde descubrí la programación funcional (a través de Mozart / Oz, OCaml, más tarde Scala, Haskell y Clojure), y luego comprendí 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 patrón, pero están en un nivel más alto en lenguajes expresivos. Ahora he estado haciendo algunos códigos profesionales en Java, y realmente siento dolor cuando tengo que usar una convención como visitante o comando de patrones, en lugar de la comparación de patrones y las funciones de orden superior.
Que C ++ era de alguna manera intrínsecamente mejor que todos los otros lenguajes.
Esto lo recibí de un amigo un par de años antes que yo en la universidad. Lo mantuve conmigo durante un tiempo vergonzosamente 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 por lo que eran.
Nadie, y nada, es perfecto, siempre hay espacio para mejorar.
Que cualquier otra cosa que no sea la inserción / tipo burbuja era simplemente magia oscura.
Que debería tener solo un punto de salida de una función / método.
Que la calidad del software genere mayores ventas. A veces lo hace pero no siempre.
Que la gente supiera lo que quería.
Durante mucho tiempo pensé que hablaría con la gente, describirían un problema o flujo de trabajo y lo pondrían en código y lo automatizarían. Resulta que cada vez que sucede eso, lo que pensaban que querían no era en realidad lo que querían.
Edit: Estoy de acuerdo con la mayoría de los comentarios. Esta no es una respuesta técnica y puede que no sea lo que buscaba el interrogador. 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 cortos años que he estado haciendo esto. Estoy seguro de que fue pura ingenuidad por mi parte, pero la forma en que mi cerebro está / fue conectado y las enseñanzas y experiencias que tuve antes de ingresar al mundo de los negocios me llevaron a creer que haría lo que respondía; que podría usar el código y las computadoras para solucionar los problemas de las personas.
Supongo que esta respuesta es similar a la de Robin acerca de 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 mono de 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 es solo 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 representante.
Que las mujeres encuentren sexy a los programadores de computadoras ...
Que los no programadores entiendan de lo que estoy hablando.
Que mi programación sería más rápida y mejor si la ejecutara sola.
Que puedes entender completamente un problema antes de comenzar a desarrollar.
Que todos los idiomas son (en su mayoría) creados iguales.
Durante un buen rato, me di cuenta de que el lenguaje de elección no representaba una gran diferencia en la dificultad del proceso de desarrollo y el potencial de éxito del proyecto. Esto definitivamente no es cierto.
Elegir el idioma correcto para el trabajo es tan importante / crítico como cualquier otra decisión de proyecto individual que se tome.
Que una proporción grande de comentario / código es algo bueno.
Me tomó un tiempo darme cuenta de que el código debería ser auto documentado. 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 gastar ese comentario en el cambio de nombre de las variables. Es más limpio, más claro y los comentarios no se "desincronizan" con el código.
Que yo sepa donde está el problema de rendimiento sin perfilar.
Yo diría que almacenar el elemento del año de una fecha como 2 dígitos fue una suposición que afectó a toda una generación de desarrolladores. El dinero que se gastó en Y2K fue bastante horrible.
- Que los ejecutivos de la empresa se preocupen por la calidad del código.
- Que menos líneas sea mejor.