¿Cuáles son algunas cosas que los programadores pueden pensar que saben, pero en realidad (probablemente) no?

Answer 1

Un número preocupante aparentemente no tiene idea de que algo como:

a = {}

Asigna un bloque de memoria en el montón y asigna un valor entero a ‘a’ que indica a través de una o más capas de indirección la dirección en la que comienza ese bloque de memoria. El lenguaje desreferencia el puntero automáticamente para que parezca que ‘a’ es un objeto y muchas personas creen que eso es realmente lo que está sucediendo.

Un número similar no sabe qué es un marco de pila, por lo que imaginan que tener más RAM le permite usar la recursión con un abandono salvaje, hasta que golpean EStackOverflow, y se confunden, porque hay 8Gb de RAM libre.

Luego están las personas que aparentemente no se dan cuenta de que OOP y FP son solo azúcar de sintaxis, como si el compilador estuviera creando instrucciones especiales de CPU OOP / FP en lugar del ASM puramente procesal que todo el código es en realidad.

Cierres: ¡característica de lenguaje súper mágico! Errr … no … es solo una estructura con un puntero de función y un bloque variable ambiental capturado. Sin magia, sin revolución de cambio de paradigma, solo una vieja estructura aburrida llena de punteros.

Funciones anónimas: lo único “anónimo” sobre ellas es que el compilador no le da acceso al puntero de función que está creando para usted bajo el capó. Azúcar de sintaxis que no cambia nada además de complicar la depuración.

Así que ahí está la respuesta: punteros. Muchos programadores discuten sobre patrones y cierres y funciones anónimas y parecen tener poca idea de que todo lo que realmente están discutiendo es malabarismo de puntero cubierto por una capa de azúcar de sintaxis.

Answer 2

Como programador profesional, hay muchas cosas que no sé. Podrías escribir libros sobre cosas que no sé. Mi autobiografía se llamará ‘ Moray Taylor: una vida sin saber nada. ‘

No soy un experto universal, incluso en mis dominios profesionales, sé que no lo soy.

Sin embargo, no tengo que ser,

El conocimiento es fácil, el conocimiento es gratuito y accesible. La capacidad de usar el conocimiento es la parte difícil.

Saber sobre cosas no es realmente tan valioso, debe ser convertible en acción .

Tengo confianza en mi capacidad de averiguar cuándo debo hacerlo.

La diferencia entre un buen programador y uno malo …

Jefe: “¿Podemos hacer esto para abril?”

Mal programador: “Mierda, yo, eh … tal vez …”

Buen programador: “No sé, pero lo descubriré”.

Answer 3

Ningún buen programador que conozco piensa que él / ella es un experto universal. Es posible que tenga la impresión de que los principiantes sufren mucho el efecto Dunning-Kruger, pero los programadores experimentados saben lo poco que saben.

Soy plenamente consciente de que no sé nada sobre vastas áreas de programación y ciencias de la computación, creo que la mayoría de los programadores son así después de un par de décadas de no saber nada.

Si ve a alguien que se considera un experto universal, puede estar seguro de que es todo lo contrario.

Answer 4

Aquí está mi lista de lo que los programadores piensan que saben pero en realidad no.

1. Cómo escribir código perfecto

1. Nadie puede escribir código perfecto

Razonamiento basado en patrones

1. La mayoría de los programadores me dirán que conocen patrones, pero luego les pido que busquen el patrón en estos requisitos y no pueden

Matemáticas

1. la mayoría de los programadores ni siquiera usan las matemáticas para resolver problemas, pero me dicen que las matemáticas son buenas

Cómo estructurar el código correctamente

1. He visto tantas líneas de código que están mal estructuradas, termino reescribiéndolo y no tengo objeciones sobre la nueva estructura cuando hago esto

Pruebas

1. Dios mío … la cantidad de desarrolladores que no saben cómo probar las partes más importantes de su código me sorprende, y lo que es peor, algunos dicen que no voy a probar eso, es el trabajo de los probadores

Answer 5

Lo que a menudo me gustaría saber; y generalmente pierdo mucho tiempo tratando de resolver, son las consecuencias de algunos de los códigos que he escrito. ¿Ha valido realmente la pena el proceso de aplanar una función iterativa, o vale la pena el esfuerzo de volver a ensamblar la colección después de que se haya completado el procesamiento?

¿Cuál es el efecto de lanzar de un tipo a otro? Lo que sucede cuando hago una función que sé que funciona bien secuencialmente; realizar cuando hago que se ejecute en múltiples hilos o a través de la directiva AsParallel.

A menudo es fácil pasar por alto estas cosas, y cuando los sistemas no funcionan como esperamos que les arrojen más recursos o arrojen un concepto para corregir el resultado (el almacenamiento en caché es mi favorito aquí). En un mundo de cortar y pegar, a veces es bueno saber cuál es el código que estamos jugando tan cómodamente.

Answer 6

• La sobrecarga de usar las características de C ++ cuando se usa un buen compilador.
• Suponiendo cómo las diferentes formas de codificación afectarán la velocidad de ejecución sin medir.
• Asumiendo que más nuevo significa mejor.
• Suponiendo que, si algo es complicado o requiere un esfuerzo para comprender, no puede haber un beneficio neto de ello.

Answer 7

Estadísticas 😉