¿Algunos programadores conocen algunos secretos que otros no? [cerrado]


8

No te molestaré con detalles de mi discusión, así que lo presentaré en forma de una breve instancia.

Un chico de Java ha estado siguiendo artículos y publicaciones de un famoso programador (una especie de Martin Fowler de mi país). Él dice que está compartiendo algunos secretos que otros programadores famosos no comparten.

Nunca creo que haya algunos secretos como los magos en el área de programación. Pero algunos programadores que aún no son buenos en esta área piensan que otros programadores famosos son exitosos porque saben algunos secretos que nosotros no.

Estoy totalmente en desacuerdo con esto y lo discutí con alguien y finalmente me dijo que tienes 2 años en esta área y que él (java guy) es 20 años programador profesional, por lo que sabe mejor que tú.

Quería estar seguro de que no estoy equivocado. Por eso quería saber esto.


8
Contestaré después de que vengas a mi casa a tomar una copa. Ah, y trae un poco de cera contigo.
Trabajo

58
Sabemos de ese tipo. Manténgase alejado de él o puede meterse en problemas. ¡Los secretos de nuestro arte sagrado deben mantenerse ocultos a toda costa! ¡El Gremio de programadores veteranos castigará a ese traidor pronto! :-p
Péter Török

15
El gran secreto para una buena programación es "escribir la menor cantidad de código claro con un mínimo de complejidad para resolver adecuadamente el problema".
dietbuddha 05 de

19
¿20 años de experiencia en Java? ORLY?!?
SK-logic

8
Eso sería 1 año de experiencia en Java, repetido 19 veces ...
Martin Blore

Respuestas:


54

Casi diría que es todo lo contrario ...

He trabajado con gente a la que le gustaba ser complicado por cualquier razón. De acuerdo, en realidad eran muy buenos programadores, cuando se tomaban en el vacío, pero el código que producían a menudo era bastante obtuso y difícil de mantener para otros. No tiene sentido hacer algo inteligente que ahorre unas pocas pulsaciones de teclas, cuando dos años más tarde alguien que mantiene el código va a desperdiciar un día cuando el truco los deja perplejos.

De hecho, si tuviera que nominar una cosa más importante que aprendí en mis diez años de experiencia comercial como programador, es que la mantenibilidad es importante . Es muy superior a conocer algunos trucos y trucos oscuros que pueden ser útiles en situaciones raras, pero que seguramente harán que la base de código sea más difícil de mantener a largo plazo.

Para ser honesto, iría tan lejos como para decir que toda la codificación debe hacerse de tal manera que cualquier nuevo graduado con un conocimiento básico relativamente básico en el idioma / plataforma dado pueda aprenderlo y trabajar con él. Si es tan complicado y oscuro que necesita a alguien con 20 años de experiencia en el lenguaje / plataforma que conozca cada pequeño truco interno, entonces el proyecto está en una grave deuda técnica.


66
+1, también los compiladores cambian con el tiempo, mientras que los hacks que ya no son necesarios permanecen en su lugar.
Trabajo

¿Obtuso? ¿Quieres decir oscuro?
webbiedave

99
@Bobby: me he encontrado con este tipo de codificación. Lo escuché descrito como un estúpido uso de la inteligencia.
webbiedave

1
@ Kevin - No estoy tan seguro. Algo que un recién graduado podría entender no es lo mismo que algo que el recién graduado podría realmente escribir. El código excelente debe ser tan fácil de entender, dado que el graduado tiene un conocimiento básico del marco y utiliza un depurador. La mayoría del código decente es bastante fácil de entender, mientras que generalmente es la lógica de negocios lo que puede ser un desafío para un recién graduado. Lo más probable es que esta persona tenga conocimiento de dominio cero, lo que puede ser difícil de alcanzar.
Morgan Herlocker

2
@Kevin: Un maestro de karateka usa solo un puñado de movimientos básicos, pero ha aprendido cómo aplicarlos en una variedad infinita. Un maestro carpintero usa solo un puñado de herramientas elegidas, pero ha aprendido a aplicarlas en combinación perfecta. Cuanta más experiencia gane, más creo que es lo mismo en programación. No es que a veces no necesites algo esotérico, solo que rara vez es el caso.
Joeri Sebrechts

42

los programadores con más experiencia saben más cosas

que son no secretos

¡Parece que está tratando de venderte algo!


21
¡+1 por "está tratando de venderte algo!" ¡ciertamente lo es!
Chani

28

"finalmente me dijo que tienes 2 años en esta área y él (java guy) es 20 años programador profesional, así que él sabe mejor que tú".

<rant>

La primera vez que me encontré con una mierda así hace más de 30 años. Me molestó entonces y me molesta aún más ahora. Se llama Argument from Authority (AKA Proof by Authority ) y es pura, no adulterada bullsh * t. Todas las personas que he conocido y que han intentado reclamar esto por sí mismas han tenido un grave problema con la autoestima ... y a menudo sabían mucho menos sobre el tema de lo que pretendían saber.

Personalmente he conocido a varios programadores asustadizos que todavía estaban en la escuela secundaria y que solo habían estado codificando durante uno o dos años. Solo 2 ejemplos: el sistema de foros original fue escrito en 1973 por un joven de 15 años, y la primera implementación de mensajería instantánea multiusuario fue escrita en 1974 por un joven de 13 años que bebía leche mientras los otros ingenieros estaban teniendo una cerveza el viernes por la tarde.

También conozco algunos dinosaurios que no han adquirido una nueva tecnología en 10 o 15 años. Muchos de ellos admitirán no rastrear lo que está sucediendo en el tiempo presente, pero hay algunos que ven esto como una insignia de honor. No es.

</rant>

Una vez sacado eso de mi sistema, me gustaría ampliar un punto hecho en las respuestas de @Bobby Tables y @Developer Art: usar "secretos", escribir "código inteligente" o hacer cualquier cosa en el código que sea una "prueba "de cuán oscuro puedes hacer que algo esté mal . Período. Es el acto de una persona inmadura y absorta en sí misma que no tiene en mente los mejores intereses del proyecto / empresa. Están colocando minas terrestres de mantenimiento que explotarán en algún momento en el futuro, probablemente después de que se hayan mudado a otros empleadores víctimas .

Lo opuesto a "inteligente" es escribir un código claro y conciso que use bien el lenguaje de programación; usa estándares de nombres consistentes; comentarios apropiados de fin de línea; buenos comentarios en bloque para explicar las secciones principales; está documentado (con ejemplos cuando corresponda); y probado Eso es lo que ofrece un verdadero programador profesional .

Y cuando terminan, se dan la vuelta y son mentores de la próxima generación de programadores profesionales.


8
No olvide el puntaje de prueba por reputación
edA-qa mort-ora-y

+1 para una actitud que me gusta.
David Thornley

Los argumentos de la propia autoridad de un individuo (que lo reclaman para sí mismos) son, como dijiste, generalmente huecos. Sin embargo, los argumentos de la autoridad de un individuo con experiencia en el tema probablemente sean válidos. No son demostrables lógicamente, por eso están menospreciados en sus enlaces, pero ciertamente es respetable.
Kevin Vermeer

3
@Kevin: No estoy diciendo que una persona con más experiencia (real) no sea más probable que tenga razón, pero eso es simplemente una probabilidad. Si estuviéramos lidiando con una ciencia blanda, podría estar más preparado para admitir el punto, pero estamos lidiando con una de las ciencias duras más difíciles que hay. Eso significa que no quiero una opinión o un "confía en mí", quiero hechos fríos, duros y comprobables. Hace muchos años encontré un error bastante grave en el compilador de Sun's C. Cuando traté de informarlo, un "experto" de Sun trató de sorprenderme con: "Ese tipo de error nunca podría pasar nuestro control de calidad". Le dije: "Habla con el mensaje de error".
Peter Rowell

1
Cuanto más experiencia obtengo y más aprendo, más me doy cuenta de cuánto no sé y más humilde me vuelvo. Ahora estoy completamente seguro de que no puedo escribir Ehlo Wordl correctamente
RobD

25

No estoy seguro de cómo alguien puede hablar con el conocimiento hipotético de otra persona, pero mi experiencia es que no hay ningún "secreto" para la programación de computadoras. De hecho, es un dominio casi definido por la apertura y el intercambio de conocimientos. Algunos de los proyectos más complejos (aquellos que posiblemente se beneficiarían más de tales "secretos") son de código abierto, como el kernel de Linux.

Me parece absurda la idea de que los programadores acaparan secretamente técnicas especiales, pero es bastante difícil demostrar un resultado negativo, especialmente cuando es puramente hipotético.


22

Los únicos secretos que conozco son:

  • Nada es tan fácil como parece. Lo que no ves son todos mis intentos fallidos.
  • Nunca debes dejar de aprender.
  • No hay sustituto para el buen trabajo duro .

Estoy de acuerdo contigo. Pero él estaba hablando de algunos secretos como las mejores prácticas, patrones ... etc.
Freshblood 05 de

¿Cómo sabes que algo es lo mejor, sin probar primero el resto? Estoy con barrem23 en este caso. +1.
lightsong

1
Es cierto, por cada 10 buenas líneas de código que escribe y confirma, probablemente hay 90 líneas de código que ha escrito y eliminado para llegar a esas soluciones de 10 líneas.
Lie Ryan

@abhiii: ¿Cómo lo sabes? Preguntar aquí (o en SO) es un buen comienzo.
Donal Fellows

Estoy en desacuerdo con ese último aforismo. Digamos que un programador, que busca reconocer todos los caracteres que no sean la 'a' minúscula, pasa un día escribiendo una clase de caracteres que contiene todos los demás caracteres que pueden encontrar en su teclado. Este es un trabajo duro . Al día siguiente, un programador senior, bostezando, lo reemplaza con cuatro caracteres: [^a]no solo hace que la expresión sea más rápida, sino que también incluye una serie de caracteres extendidos / Unicode que el original omitió. Digo que, al menos cuando se trata de programación, el trabajo duro no tiene sentido. No hay sustituto para el buen trabajo.
Stuart P. Bentley

9

Sé de un secreto que los programadores más jóvenes no tienden a conocer o aceptar. Una vez que uno está lo suficientemente avanzado como para entender esto, por lo general se da cuenta por sí mismo.

<TheSecret> Todo el código apesta. Especialmente el tuyo. El mío también. El código de todos los programadores geniales del mundo --- sí, también apesta. Acéptelo y haga el trabajo lo mejor que pueda. </TheSecret>


¡Oye! ¡MI código no apesta! Oh espera. Lo siento. Me equivoqué de negativo. Si, tienes razón. Todo el código apesta. La única diferencia radica en el grado de succión. Esto va desde agujeros negros galácticos hasta aspiradoras rotas.
SOLO MI OPINIÓN correcta

2
Cuando me enseñaron por primera vez sobre las pruebas, el profesor nos hizo escribir todas las pruebas que pudiéramos pensar para una función básica que calculara el área de un triángulo dada la longitud de 3 lados como parámetros. Estaba seguro de que había encontrado una solución de cobertura de prueba completa con mis ~ 11 pruebas ... hasta que mostró el número real de pruebas válidas más cercanas a ~ 111. Me di cuenta de que incluso mi código trivial nunca sería perfecto.
Morgan Herlocker

9

Tengo 50 años de experiencia. He aprendido muchas cosas que los programadores más jóvenes aún no han aprendido. Estoy perfectamente dispuesto a compartirlos, y lo intento de muchas maneras.

Aprender es algo que debes querer hacer.

A menudo escucho que la mantenibilidad es realmente importante, y estoy completamente de acuerdo. Sin embargo, no es gratis. Puede requerir más o menos una curva de aprendizaje por parte del mantenedor.

Un programador nuevo con una maestría en Ciencias de la Computación miraría mi código y diría que es imposible de mantener y está lleno de secretos. De hecho, él o ella simplemente no ha terminado de aprender cosas nuevas.

Los pilotos tienen un dicho cuando pasa las pruebas requeridas y se le entrega el "boleto" de su piloto. Dicen que es una licencia para aprender.

La educación no se detiene cuando obtienes un diploma. Solo ha comenzado.


2
Si un recién llegado a su código con una cantidad razonable de comprensión básica (que la mayoría de las personas calificaría como maestría en CS) dice que su código no se puede mantener, lo es. La capacidad de mantenimiento es la medida de comprensión requerida desde una base de cero . Todo el código es "mantenible" si lo define como "cualquier cosa que pueda entenderse, dado el tiempo y el mundo suficientes".
Stuart P. Bentley

1
@Stuart: Si solo puedo dar un ejemplo. En 1985 me topé con el método de ejecución diferencial . Es una forma de crear un lenguaje específico de dominio donde el dominio es interfaces de usuario complejas. Ahorra aproximadamente un orden de magnitud del código fuente, y una vez que aprende cómo funciona, la mayoría del mantenimiento (cambios de código en respuesta a los requisitos modificados) son ediciones de código fuente muy simples. A eso me refiero. La mantenibilidad tiene el precio de una curva de aprendizaje.
Mike Dunlavey

7

Conocer pequeños secretos ocultos de ciertos lenguajes de programación o marcos tiene poco o ningún valor práctico.

La mayor parte del desarrollo de software práctico no encuentra estas características ocultas en su práctica. Aún más, una de las mejores prácticas sugiere que evites deliberadamente aventurarte en áreas ocultas de las tecnologías que usas porque hace que el código sea menos mantenible y más propenso a errores ya que la mayoría de los programadores no conocerán estos "secretos".

En lugar de perder / perder tiempo (elija uno) para aprender los secretos de una tecnología específica, generalmente es mejor expandir el rango de conocimiento y aprender herramientas adyacentes o mejorar aún más sus habilidades de no programación o aprender más del negocio en el que se encuentra .

Con la velocidad del cambio en nuestro campo, la inversión profunda en una herramienta específica no vale la pena: el conocimiento será obsoleto pronto.

Ahora, solo si se posiciona como un experto en tecnología y tiene la intención de ofrecer sus servicios de consultoría en este campo específico, tiene sentido invertir en profundidad. De lo contrario, es un esfuerzo perdido.


3
+1 por señalar que los "secretos" son secretos por una razón. Un buen ejemplo sería la API de Windows "indocumentada", cuyo uso hace que sus aplicaciones no se puedan mantener.
user16764

El hecho de que C ++ tenga casos de esquina y comportamiento indefinido no me molesta mucho, porque de todos modos no me acerco a esas cosas. Sin embargo, saber estas cosas ayuda a depurar código mal escrito.
David Thornley

5

Le están vendiendo una lista de bienes aquí. Alguien está tratando de emplear el concepto de Mysterious Secrets ™ que lo convierte en un Elite Programmer ™ con el objetivo de hacer que pague por esos Mysterious Secrets ™. El siguiente paso es que alguien le ofrezca enseñarle esos misteriosos secretos ™ en forma de videos o discursos o podcasts o libros mal impresos por el bajo y bajo precio de solo <inserte lo que el vendedor piense que estará dispuesto a pagar>.

¿Cómo puedo estar seguro de esto? He estado programando desde los años 70 y conozco una tonelada más de lenguajes de programación que solo Java. He visto programación (profesional y académicamente) desde el más pequeño de los pequeños (sistemas integrados con cientos de bytes, es decir, bytes de RAM) hasta grandes piezas de Big Iron ™.

Hay un secreto para ser un buen programador y solo uno: debes trabajar para mejorar constantemente. Cualquiera que te diga lo contrario es un mentiroso y / o un tonto.


4

El único secreto que los programadores jóvenes no conocen es que los programadores no son tan inteligentes como piensan .

Una vez que sabe eso, deja de escribir código que no entenderá el próximo mes, comienza a apreciar el control de versiones, no arregla el código que ya funciona, documenta su código, no interpreta las especificaciones, no lo hace ' Funciones de código t que podrían ser útiles algún día en el futuro, no rechaza el código heredado, ...

En otras palabras, el secreto es la experiencia.


3

Obviamente, alguien con 20 años de experiencia tendrá más, bueno, experiencia que alguien con solo 2 años. Pero no hay secretos : ¿cuál sería el punto?

(Por supuesto, alguien que trata de guardar un secreto sería decir que ...)


1

Si bien la experiencia importa, podemos aprender de las experiencias de los demás. Acabo de leer "The Clean Coder", donde Robert C Martin (tío Bob) comparte los errores que ha cometido y las lecciones que ha aprendido. Muchos de los cuales figuran en las respuestas aquí, como seguir aprendiendo.


1

Todo lo que solo unos pocos saben puede considerarse un secreto.

Todo lo que sabemos hoy fue descubierto una vez.

Así que todo una vez fue un secreto.

Algunos conocimientos se propagan rápidamente y otros se propagan lentamente.

Algunos programadores nunca descubren nada por sí mismos (pero pueden aplicar secretos de otros con mucho éxito).

Algunos programadores (por ejemplo, John Carmack, Ken Perlin, Donald Knuth) parecen tropezar con un nuevo secreto todos los días.

Entonces, sí, hay programadores que conocen algunos secretos que otros no conocemos ... todavía.


1

El conocimiento por sí solo no es poder, te lo concederé. Sin embargo, alguien puede haber desarrollado sus habilidades más allá que usted, lo que puede significar que tiene consejos y estrategias que pueden ayudarlo a avanzar. Tenga en cuenta que hay un par de "mayo" en la última oración, ya que no es una certeza de que realmente lo moverán. Por lo tanto, existe la posibilidad de que esto no sea nada nuevo o impactante para usted.

Al mismo tiempo, hay varias prácticas y estrategias que a la vez pueden haber parecido radicales, aunque hoy las damos por sentado. El control de la fuente, la integración continua y las pruebas unitarias fueron nuevas en algún momento, ¿verdad?


1

Es posible que usted y la mayoría de las personas que responden esta pregunta se estén centrando demasiado en la palabra 'secreto'.

Si eliminamos la parte 'oculta', entonces sí, es muy posible que este famoso programador tenga algunos consejos y trucos útiles o el conocimiento obtenido a través de la experiencia que lo beneficiaría de alguna manera. Estoy hablando de conocimientos como los que encontrarías en libros clásicos de SE o CS, como Rapid Development o The Pragmatic Programmer . Esto combinado con el trabajo duro puede ayudar absolutamente.

Entonces, en ese sentido, el famoso programador exitoso puede estar en posesión de un conocimiento que otros simplemente aún no tienen.

Pero no hay ningún tipo de recetas secretas que conviertan a un "programador no tan bueno en esta área" en uno famoso con mucho éxito.


0

No hay pequeños secretos. Solo código complicado ... eventualmente se convirtió en código eficiente simplificado.


0

El secreto radica en el tipo de problema, el área del problema y cómo lo resuelve. Por ejemplo, escribí un programa php para abrir un archivo y leer sus datos y convertir los datos en xml y luego usé ese xml para presentar datos en diferentes elementos html, es decir, cuadro de opciones, etc. Después de 1 año tuvimos un nuevo programador junior para unirme al El equipo y él eran buenos en algoritmos, por lo que resolvió el problema matemáticamente, lo que hizo que el código se viera difícil con izquierdas de cambio y dividiendo las matrices, etc.etc. pero el tiempo de ejecución se redujo hasta un 40% de lo que escribí. Su enfoque para escribir las declaraciones de php me sorprendió. Así que creo que hay ciertos trucos que no existen; Una cosa más es la cantidad de alternativas que puede pensar en su mente.


0

Lo siento si me falta algo, pero no pude encontrar esto arriba, al menos no se indica explícitamente.

El secreto es usar las herramientas adecuadas para el trabajo. De hecho, son las herramientas que los viejos programadores aprecian y no divulgan tan fácilmente. Le hablarán sobre sus errores de CONCRETO, pero rara vez le sugerirán qué herramienta podría ayudarlo a evitarlos. Sus herramientas son uno de los principales secretos de su productividad.

Dando solo un ejemplo, uno puede memorizar un libro de 600 páginas sobre servicios web, comprender las complejidades de la especificación WSDL (lo intenté yo mismo una vez ... para comprender las complejidades), y aún no ser capaz de comprender qué funciona mal con la API utiliza cuando intenta hacer una llamada a un servicio web existente.

Por otro lado, uno puede tener poco conocimiento de la especificación (pero una idea general clara) y usar Wireshark.

Uno puede recordar todo C ++ (oh my ..) y aún no entender qué falla con su código escrito con vi, y compilado con gcc (sin advertencias ..). Pero un IDE gráfico con un depurador podría ayudar ...

Y luego Google. El mayor secreto de todos hasta la fecha.


El gremio vendrá después de ti por compartir el secreto de Google con el mundo. La primera regla del gremio es no hablar de Google.
Ramhound

Bueno, si el gremio vendrá después de mí, será más bien por mencionar vi en vano ...
John Donn
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.