¿Cuál es el mito más absurdo sobre los problemas de programación?


101

Para decirlo de otra manera ... ¿Cuál es el malentendido más común y frustrante sobre programación que has encontrado?

¿Qué mitos / conceptos erróneos generalizados y de larga data encuentran difíciles de disipar / corregir para los programadores ?

Por favor, explique por qué esto es un mito.


24
Me gustaría ver a Mythbusters asumir algunos de estos.
Spong

8
¿Alguien quiere un canal de YouTube Mythbuggers? :-)
Tamara Wijsman

1
Ooooh, MythBusters y condiciones de carrera! Meesa como!

¡@TomWij sería genial tener un sitio web con ese nombre!
Junior M

Respuestas:


272

Eso porque eres un programador, sabes cómo reparar la máquina montada en virus de [persona].


34
Cláusula de analogía / salida del automóvil: "Soy un piloto de carreras, no un mecánico".
Peter Boughton

15
Este cómic es relevante: theoatmeal.com/comics/computers
lunixbochs


21
@Tim si puede cocinar, comience a ofrecerla como voluntaria para atender las fiestas de sus amigos
Steven A. Lowe

19
No es que no sepa cómo ... Es que no quiero perder horas arreglando su máquina que de todos modos romperá en 2 semanas.
ChaosPandion

267

Una cosa común de recursos humanos que me vuelve loco cuando busco trabajo: la suposición implícita de que todas las habilidades de codificación son específicas del lenguaje, que no hay experiencia en ingeniería de software que trascienda los conjuntos de comandos. Esa experiencia de diez años en Java y otros cinco en Perl significa que sería completamente inútil en un proyecto que usa, por ejemplo, C #.

"Sí, hay una curva de aprendizaje. Pero he hecho transiciones más difíciles que esta. Te haré un trato, me pagarás el 80% durante el primer mes y al final de ese tiempo si no estoy ... oh , espera, en realidad no estamos teniendo esta conversación, porque tu mono de recursos humanos simplemente eliminó mi aplicación ".


9191
+ INF para mono HR.
Rusty

67
He tenido un tipo de recursos humanos que me rechazó por un papel porque sabía cómo C #, pero estaba buscando a alguien que pudiera codificar en dotNet.
burnt_hand

11
@burnt_hand: Sí, lo sé dotNet. También conozco Excel e Internet Explorer. ¿Puedo hacer un contrato ahora?
Alan Plum

Si bien estoy de acuerdo en que hay grandes superposiciones con la sintaxis, la estructura, el SDLC, etc., entre Java y C #, si le dan alguna prueba de C # razonablemente complicada en su entrevista, ¿cómo le irá?
JBRWilkinson

2
@ Kyralessa - Creo que ahora sé lo suficiente sobre la teoría subyacente de la informática y las funciones de las computadoras para no cometer errores básicos en ningún lenguaje de programación. Puedo leer la documentación. Sin embargo, algo que un lenguaje específico contrata con habilidades de ingeniería / voluntad / acción limitadas es cometer errores básicos en la estructura, diseño, corrección, escalabilidad, confiabilidad y mantenibilidad del programa que potencialmente costará grandes cantidades de reparación. Si no pierdes a todos tus clientes debido a la baja calidad del software mientras tanto (suponiendo que tu proyecto realmente llegue a alguna parte).
flamingpenguin

261

Si no estás escribiendo, no estás trabajando.

Creo que las miradas de zombis en blanco y los paseos por el café son esenciales para que los programadores organicen cosas en sus cabezas.


99
Página arriba, página abajo ... página arriba, página abajo ...
Adolf ajo

139
No me pagan por escribir, me pagan por pensar. Proporciono mecanografía como un bono.
Kevin Laity


11
Esta es la razón por la que no considero muy bien los mercados independientes en línea que ofrecen grabación de "tiempo de trabajo" con un capturador de pantalla y una cámara web. WTF? Si crees que mi presupuesto es bueno, ¿por qué te importa exactamente lo que hago en el momento en que cobro?
Alan Plum

10
"Si tuviera más tiempo para codificar, escribiría menos líneas". - Quítate la cita de Abe Lincoln.
JeffO

158

que puede acelerar un proyecto tardío, simplemente lanzando más personas.


28
Ah, del mes del hombre mítico. en.wikipedia.org/wiki/The_Mythical_Man-Month
spong

2
En realidad, puedes. -1 (sí, ¡he aquí un portador de mitos!)
P Shved

63
Usamos un dicho colorido que dice "No puedes poner a 9 mujeres en una habitación y hacer un bebé en un mes".
Walter

10
La semana pasada agregamos 4 personas sin experiencia en proyectos para "ayudar" a cumplir un cronograma poco realista. El informe de esta semana del proyecto condujo a listas de alta gerencia: "Deslizamiento del programa Causa: Reducción de la eficiencia debido a la curva de aprendizaje de los nuevos miembros del equipo" y "Plan de recuperación: Continuar agregando más personas donde exista la oportunidad". Increíble
AShelly

77
@Walter, pero puedes tener 9 bebés en 9 meses y un equipo de béisbol de ligas menores en 7 años.
Huperniketes

132

Ese software de escritura es fácil.

¿De qué otra manera explican todos estos proyectos que se ejecutan a lo largo del tiempo y por encima del presupuesto y las personas (políticos, los medios de comunicación, etc.) todavía están sorprendidos, y los clientes se quejan cuando les dice que su "pequeño sitio web" (o lo que sea) realmente tomará 6 meses para desarrollar y costar varios miles de dólares (libras, euros, [insertar moneda de elección])

Con requisitos difusos y siempre cambiantes, a veces pienso que es sorprendente que cualquier software se termine.

Sé que es un poco más complicado que eso;)


11
Y esto es cuando intentan llevar el desarrollo a alternativas costa afuera más baratas. Solo para descubrir mucho más tarde que resultó ser aún más caro. Y menos de lo que realmente necesitaban, debido a los desafíos de separación física y comunicación entre el equipo de desarrollo y el cliente.
7wp

1
Esto no es solo un problema entre los gerentes, sino también entre los programadores. El verdadero problema tiende a ser que el tiempo que no se dedica a escribir código a menudo se pierde (posiblemente debido al mito generalizado de cuantificación de productividad LOC).
Alan Plum

3
No es que los requisitos hayan cambiado, simplemente no es lo que pensaban que querían.
JeffO

1
Hice que alguien descartara la programación como "solo un montón de declaraciones 'si'". OK, tal vez lo sea ... en ese caso, la poesía es "solo un montón de palabras" ... la producción de películas es "solo un montón de escenas", etc.
JoelFan

2
He trabajado para el tipo de gerente que pensaba que la parte de programación era la parte fácil del trabajo. Y no, él mismo no tenía experiencia en programación.
Capitán Sensible

114

La complejidad de la aplicación es directamente proporcional a la complejidad de la interfaz de usuario. Con este razonamiento, deberías poder construir Google o Twitter durante un fin de semana.


2
Esto es cierto, podría construir Twitter y Google en un solo fin de semana. No es su software lo que es complejo; para Google, es su algoritmo de búsqueda (que es más comparable a una biblioteca de códigos o controlador de base de datos), y Twitter (hasta los últimos 1,5 años) fue extraordinariamente simple, con problemas de escalabilidad y de base de datos complejos. Ahora que es más complejo (requiere más empleados), también tiene una interfaz de usuario mucho más compleja y muchas más interfaces de usuario.
orokusaki

3
Creo que lo leí en el blog de Joel Spolsky, pero el artículo menciona que solo se muestra como progreso de la GUI en relación con el progreso del back-end. De esa manera, puede dar una estimación realista del progreso a los hombres de cabello puntiagudo que son demasiado tontos para comprender que la mayoría de los programas consisten en mucho más que un dulce visual.
Evan Plaice

3
1+ Hubo un momento en que demostré un proyecto relacionado con SharePoint (un complemento multilingüe) a mi antiguo jefe, después de pasar horas trabajando en el complejo código de fondo. El resultado final fue que no se hizo mucho en la interfaz de usuario, lo que llevó a mi jefe a creer que no se había hecho mucho en el proyecto. Eso me molestó. No era el que estaba sentado frente al teclado durante horas tratando de sortear las rarezas de SharePoint, así como la lógica de reemplazo de texto.
Jason Evans el

1
No odies cuando se
formula una

Me pregunto qué he estado haciendo los últimos años. Todos esos proyectos en los que trabajé a tiempo completo deberían haberse terminado en muy poco tiempo, porque no tenían ninguna interfaz de usuario. :-)
Bart van Ingen Schenau

95

Todos los programadores son buenos en matemáticas. :-)


Comentaristas: los comentarios están destinados a buscar aclaraciones, no para una discusión prolongada. Si tiene una solución, deje una respuesta. Si su solución ya está publicada, favor de votarla. Si desea discutir esta pregunta con otras personas, utilice el chat . Consulte las preguntas frecuentes para obtener más información.

Creo que las capacidades en matemáticas están de alguna manera relacionadas con las habilidades de programación.
Diego

@ Diego: Aunque eso no necesariamente significa que todos los programadores sean buenos en matemáticas.
Omega

95

Cualquier niño adolescente que piratee con computadoras es equivalente (o superior) en habilidad a un programador veterano de trabajo.

Mi sobrino de 14 años es bueno con las computadoras y le estoy pagando $ 10 / hora para cortar el césped. ¿Por qué debería pagarle seis cifras para escribir el próximo FaceBook?


55
Probablemente se encuentren en su propio entorno, es decir, trabajando por su cuenta según sus propios estándares. Póngalos en un equipo donde tengan que comunicarse y ahí es donde sufren.
Adolf ajo

36
La contra-pregunta podría ser: "¿Qué le pagarías para construir tu casa?"

77
Un niño sin calificaciones pero escribe un código limpio puede vencer al Sr. Spaghetti cualquier día.
Zaz

13
MAK

66
Cuando comencé, esperaba que lo que me había enseñado y aprendido en la universidad sería solo el comienzo, y estaría trabajando con personas más experimentadas que eran mejores programadores y desarrolladores más informados, y aprendería Muchos de ellos. La experiencia me enseñó lo contrario. Es absolutamente importante, pero sin habilidad y pasión, la experiencia es solo tiempo perdido.
Peter Boughton

69

Eso en tiempo real significa rápido.

Indicando "Los paquetes deben procesarse en tiempo real". no tiene valor y el gemelo malvado ... respondiendo "¿Qué tan rápido debe pasar X?" con "Tiempo real" es posiblemente menos que inútil ... rayando en estúpido en lugar de ignorante.

En tiempo real significa que, en pocas palabras, esa función Y siempre tomará X cantidad de tiempo y que cualquier desviación indica un error grave. La duración de X no define "en tiempo real", podría ser de seis microsegundos o seis días. Que usted pueda determinar que la función Y tomará X el tiempo define "tiempo real". Los sistemas en tiempo real son deterministas según esta definición.

Así que déjalo.


tiempo real = casi a tiempo
brian chandley

44
Siempre pensé que el tiempo real significaba que lo que estaba sucediendo estaba sucediendo según lo requieres, no una referencia al tiempo empleado.
burnt_hand

14
Este es probablemente uno de esos casos en los que un concepto mal nombrado contribuye a la confusión.
JohnFx

2
@JohnFx Bien dicho. Los conceptos necesitan contexto.
Rusty

2
@ Richard: De hecho, iTunes siempre tarda unos minutos antes de reproducir cualquier cosa. Oh, eso no es lo que quisiste decir?
configurador

69

¿Por qué simplemente no lo escriben bien la primera vez, en lugar de pasar tanto tiempo escribiendo código con errores y luego leyendo el código tratando de encontrar los errores?

:-) :-) :-) :-)


34
Francamente, esa es una buena pregunta. El momento más fácil para que el código sea bueno es cuando se está escribiendo por primera vez.
DJClayworth

10
Tenemos una configuración en la configuración de la aplicación: <add Key = "Bugs" Value = "true" />
burnt_hand

1
@DJClayworth: eso no siempre funciona. En algunos casos, el problema es tan grande, mal definido o simplemente difícil que acercarse incluso a "lo correcto" la primera vez es demasiado esperar. En tal caso, es mejor escribir un "primer corte" que no esté totalmente equivocado, que pasar días / semanas / meses diseñando y rediseñando sin cesar en un intento de hacerlo bien la primera vez.
Stephen C

Esta podría ser la versión simple de "¿Por qué no están haciendo TDD?" Lo cual, para ser justos, es una muy buena pregunta, si es demasiado simple para el desarrollo del mundo real.
Dan Ray

1
@Stephen C: sí, pero hay una diferencia entre hacerlo bien en su mayoría (en lugar de hacerlo perfectamente) en lugar de hacer casi todo lo que sea a la izquierda y a la derecha para que funcione. Sé que esto no es lo que dijiste, pero sigo pensando que hay que decirlo.
n1ckp

65

Si no has ido a la universidad, no eres apto para el trabajo


27
Además: un programador con un título es mejor que un programador sin él y debe pagarse en consecuencia. Lo mismo probablemente ocurre con el ageismo y el sexismo. Este tipo de tonterías me enfurece: si no sabes cómo escribir un buen código, no podría importarme menos dónde fuiste y qué hiciste. Este puede ser otro caso de cultura de programador / nerd (habilidad == autoridad) chocando con cultura corporativa (rango == autoridad).
Alan Plum

1
Y, sin embargo, las personas que enseñan en la Universidad también parecen pensar que pueden generalizar el comportamiento de los programadores y proyectos al observar cómo operan los estudiantes cuando se unen. Las comunicaciones de la ACM son buenas para 4-6 de estos artículos al año.
MIA

1
@Billy ¿Qué tal por aquí, donde un diploma universitario significa gato, pero un diploma universitario te lo otorgará todo? Ambos van a la escuela, ambos son posiblemente mejores que el otro, pero hay una diferencia sociológica
Tarka,

44
@Billy: en Canadá, la universidad te otorga un título y las universidades te otorgan diplomas. Las universidades son más como "escuelas donde aprendes cosas prácticas". Piense en un colegio comunitario en los EE. UU. Frente a un colegio / universidad normal Aquí suelen tener programas aplicados especializados de dos años. No puedes obtener una licenciatura (maestría, etc.) de una universidad. Básicamente, irías a la universidad para estudiar cómo escribir software y a la universidad para estudiar informática. Los títulos universitarios tienen una preferencia mucho más fuerte en la contratación.
Adam Lear

44
Las universidades enseñan al menos una cosa importante: la mentalidad . Esto es muy importante, pero aquellos que no lo saben ... bueno, no lo saben.

61

Esa optimización prematura significa que no debes optimizar en absoluto. He visto bases de datos más terriblemente malas porque nadie quería considerar el rendimiento (crítico para cualquier sistema de base de datos) en el diseño, ya que era una optimización prematura que cualquier otro problema de diseño de la base de datos. Basura, hay conocidos asesinos de rendimiento, deja de usarlos como tu primera opción.

Otro mito, es demasiado difícil refactorizar la base de datos. No, pero debe considerar cómo refactorizar en la fase de diseño para hacerlo de manera efectiva. Y, por cierto, cuanto más espere para solucionar ese molesto problema de rendimiento basado en el diseño, más difícil será solucionarlo.

Otro mal mito, el diseño de la base de datos debe reflejar los principios de OOP. No, las bases de datos están diseñadas para funcionar con conjuntos, no con principios OOP. Algunas cosas de OOP causarán problemas de rendimiento horribles y otras son simplemente tontas en términos de bases de datos.

Finalmente, debe hacer cumplir la integridad de los datos en la aplicación. Las bases de datos van a durar más allá de la aplicación y perderían las reglas cuando se reemplaza la aplicación, múltiples aplicaciones van a acceder a ellas y a menudo será necesario ejecutar consultas directas para arreglar cosas que no pasan por la aplicación. Nunca he visto una base de datos que se niega a hacer cumplir la integridad de los datos en la base de datos que tiene buenos datos.


+1 en particular para los comentarios sobre las verificaciones de integridad de la base de datos.
Frank Shearar

+1 Especialmente para el último párrafo. He golpeado ese tambor más de una vez.
Binario Worrier

55
+1 para el primer párrafo. La optimización temprana es la raíz de todo mal; escribir código incorrecto sin motivo sangriento es aún peor.
Configurador

3
"Algunas cosas de OOP causarán problemas de rendimiento horribles y otras son simplemente tontas en términos de bases de datos", ¿podría decir cuál? Sé sobre POO, pero no mucho sobre bases de datos, y estoy interesado en saber hasta dónde puedo llevar las ideas de un lado a otro.
Tom Anderson el

@HLGEM También me interesarían los ejemplos que @Tom se pregunta ...
Armand

53

Que hay una fuente mítica de mejores prácticas absolutas.

Ninguna desviación puede justificarse.

Ningún documento que afirme definir algo como una mejor práctica puede ser cuestionado.


1
mejor miembro de un equipo que tus gerentes ...
Bill

55
¿Me puede enviar ese documento?
AShelly

1
Totalmente de acuerdo. ¿A quién le importa si mezclas pestañas y espacios en código Python?
Zaz

44
@Josh: alguien que tiene que ver su código fuente utilizando una cadena de herramientas que tiene una idea diferente de dónde están las posiciones de las pestañas.
Stephen C

1
Interpreto "es la mejor práctica" como "no puedo justificar esto". Ciertamente lo uso así.
Tom Anderson el

51

El hecho de que el marketing parece pensar que agregar una tonelada de características pequeñas es menos trabajo que agregar una característica única, pero bastante pesada. Lo que probablemente sea un caso más específico de la idea errónea de que "el cambio de tareas no tiene sobrecarga".


12
Y lo más divertido es que el marketing no tiene idea de qué características son fáciles y cuáles son casi imposibles.
derobert

44
@derobert Exactamente, a menudo he tenido la experiencia de que algunas de las personas de marketing más consideradas de hecho tienen miedo de preguntar sobre alguna característica simple / fácil que pensaron que era muy difícil de implementar. Aunque experimento lo contrario con mucha más frecuencia: aquí hay un lote de X características "fáciles" que ya hemos vendido al cliente, por favor, háganlo para ayer ...
Giel

50

Ese código de comentario es innecesario, o ese "buen código no necesita comentarios". A veces necesitas explicar qué está haciendo un código complejo. Además, comentar secciones de código lo ayuda a leer más rápidamente.


14
@DisgruntledGoad - Sin embargo, es cierto. El malentendido en este "mito" proviene del hecho de que muchos programadores consideran que su código monolítico confuso es "bueno". if user.is_logged_in: print('Welcome')no necesita un comentario
orokusaki

3
@orokusaki No todos los algoritmos son tan simples.
Jouke van der Maas

25
@orokusaki está confundiendo "un buen código no necesita comentarios" con "un código simple no necesita comentarios". Un buen código no siempre es simple.
DisgruntledGoat

3
@Jouke van der Mass: por supuesto. Pero no importa cuán complejo sea el algoritmo, el objetivo es expresar el algoritmo simplemente. es decir, un buen código expresa algoritmos complejos, reglas, optimizaciones, de una manera simple e inequívocamente comprensible. Expresar cosas simples simplemente es relativamente fácil. Expresar cosas complejas simplemente es donde reside la habilidad.
flamingpenguin

2
@orokuskai: un buen código es simple. Las cosas que está haciendo pueden ser complejas, pero la simplicidad (elegancia) del código es lo que lo hace bueno en mi opinión. Por supuesto, el código hace muchas otras cosas, y el código de basura puede hacerle ganar mucho dinero. Pero mi objetivo es escribir código simple incluso en situaciones complejas.
flamingpenguin

50

El peor mito: si está programando durante mucho tiempo, puede ser un administrador de proyectos fácilmente.

Y que debería convertirse en gerente de proyecto si ha estado programando durante mucho tiempo.


3
O peor aún, si nunca ha programado o gestionado un proyecto de programación, leer algunos libros y mágicamente hará que el software suceda. He estado en ese camino con un primer ministro anterior y no me importa repetirlo mientras viva.
Evan Plaice

44
Peor aún: dado que todos los grandes programadores del equipo prefieren escribir código en lugar de escribir informes, debemos promocionar al programador mediocre a Project Manager. La idea es que será "lo suficientemente técnico". El hecho es que termina siendo un filtro de desinformación entre el equipo y la gerencia superior.
AShelly

2
Además: si eres el mejor programador, obviamente deberías convertirte en el gerente del proyecto y, a partir de ese momento, ¡dejar de hacer tú mismo la programación real! No, muchas gracias, pero igual aceptaré el aumento. Nota: No estoy hablando de convertirme en un programador principal o algo similar, estoy hablando de los gerentes que piensan que es una idea inteligente promover a todos a su nivel de incompetencia suficiente.
Alan Plum

1
También conocido como Principio de Peter. en.wikipedia.org/wiki/Peter_Principle
Spoike

bien dicho de hecho
Michael Easter

50

Si utilizamos algo distinto de Java, C # y C ++ en nuestro proyecto, no encontraremos ningún programador que lo soporte.


Nunca había escuchado sobre eso, pero es válido. Por supuesto, si usa un lenguaje oscuro, sucedería.
Maniero

55
@bigown, "oscuro"? ¿Qué tan oscuro? ¿TCL es oscuro? Haskell? Pascal (Delphi)? ¿Pitón? Creo que no son oscuros. Muchas personas piensan que sí, y solo se permite un conjunto muy limitado de lenguajes (C ++, C # y Java) en el desarrollo "serio".
P Shved

55
@bigown: oh, ¿te refieres a oscuro como COBOL? : p
AnonJr

2
Una vez trabajé para una pequeña empresa haciendo código Objective-C en Linux. El CEO, que no era ingeniero pero tenía algunos conocimientos técnicos, no podía creer que hubiera programadores de ObjC o que alguien más lo usara. De hecho, nunca tuvieron problemas para contratar buenos desarrolladores.

44
He leído un argumento que dice exactamente lo contrario: para lenguajes que son oscuros (o al menos comercialmente insignificantes) pero geniales, divertidos e interesantes (que en ese contexto significaban Python y Ruby), hay más programadores que trabajos. Además, todas son personas que tienen un lenguaje interesante, divertido e interesante, por lo que deben ser inteligentes. De hecho, trabajar en Python significa que le resultará más fácil contratar programadores inteligentes que si trabaja en Java. ¡No sé si lo creo, pero es al menos tan plausible como la idea ortodoxa!
Tom Anderson el

42

Java es solo C ++ con diferentes clases.


57
+1 Una vez un entrevistador me preguntó: "¿cuál es la diferencia entre C ++ y Java?" Entonces enumeré algunas diferencias. Compilador nativo versus JVM, estándar ANSI versus propietario, recolección de basura, cargadores de clases, etc. Rugió, "¡INCORRECTO! ¡No hay diferencia! ¡Son idénticos!" No era un estudiante, era el gerente de ingeniería.
Bill Karwin

11
@Bill, mi respuesta sería entonces, "¿entonces por qué referirme a ellos con nombres completamente diferentes?"
Jesse C. Slicer

2
@Bill, ¿fallaste la prueba y te contrataron?

20
Mi respuesta sería "Adiós".
Foole

66
@Foole ¿No te refieres a System.exit (1)?
Barry Brown el


33

Probablemente el más peligroso que he visto, porque se acepta tan fácilmente, es que poder escribir código rápidamente es bueno y, por lo tanto, cuanto más rápido pueda codificar [insertar función aquí] en un idioma determinado, mejor será el idioma es.

Este es un ejemplo serio de optimización prematura, ya que se necesita mucho más trabajo para mantener el código que para crearlo. Esto significa que es mucho más importante escribir código que sea fácil de leer, comprender y depurar que el código que es fácil de escribir rápidamente, y facilitar un código fácil de leer es una medida mucho más útil de la calidad del lenguaje.


14
esto es precisamente lo que le sucedió a uno de los productos de la empresa para la que trabajo; El desarrollo apresurado fue visto como brillante. El producto se veía bien y el desarrollador fue muy elogiado por la alta gerencia. A otro desarrollador junior se le encomendó la tarea de corregir un error "pequeño", y después de una semana de tratar de entender el código, se rindió y buscó la orientación de un senior ... que no podía creer lo basura que era el código. La alta gerencia se negó a aceptarlo como un problema importante durante dos años, después de lo cual finalmente acordaron que era un montón de basura y que debían codificarse nuevamente desde cero, y esta vez
Sk93

44
Existe un mito bien establecido entre los gerentes técnicos de que sus desarrolladores expertos son diez veces más productivos que los desarrolladores no calificados. El resultado directo de este mito es que cualquier desarrollador que pueda producir código rápidamente , sin importar cuán defectuoso o difícil de mantener, recibe elogios y promoción.
rtperson

3
Usted NECESITA un lenguaje de gran alcance. Vea la discusión de Paul Grahams sobre los idiomas y lo que le permite hacer: paulgraham.com/power.html

44
@ Thorbjørn: He leído ese artículo y Paul Graham se equivoca. Es un defensor de Lisp, por lo que convierte los hechos en argumentos egoístas para que Lisp se vea bien. Tal vez ni siquiera conscientemente, ya que realmente no requiere mucho esfuerzo. Hay mucha superposición entre la legibilidad y la concisión, como señala hacia el final del artículo. Pero las conclusiones que saca están completamente fuera de sincronía con el estado del desarrollo de software en el mundo real. Sí, necesitas un lenguaje poderoso, pero él está midiendo el poder según los criterios equivocados, y es perjudicial creer lo que dice.
Mason Wheeler

3
@rtperson: Que la productividad puede variar en un factor de diez no es un mito. Que las personas que terminan rápido son necesariamente más productivas es.
David Thornley

31

Las lecciones de fabricación se pueden aplicar al proceso de desarrollo de software.


66
Depende de las lecciones. Cuando trabajé en una fábrica de colchones, aprendimos que el cambio de tareas era perjudicial para nuestra producción. Un poco importante ya que nos pagaron por la cantidad de colchones hechos y no por hora ... y una lección que también se aplica aquí por muchas de las mismas razones.
AnonJr

Este es un mito tan persistente cuando trabajas en un lugar que principalmente fabrica hardware. Los aros que saltar a través de nuestro software para adaptarse a 'construir' en el mismo modelo como el hardware 'parte' son increíbles ...
AShelly

55
La cosa es que el software de fabricación es trivial. Es fácil hacer copias y no cuesta tanto hacer millones de copias. Esto lleva a las personas a ignorar por completo la parte de fabricación, e intentar aplicar la fabricación al proceso de diseño.
David Thornley

+100 por esto, especialmente las personas que estudiaron economía piensan esto
Kugel

1
Todos deberían leer Jack Reeves: developerdotstar.com/mag/articles/reeves_design_main.html : este es el origen (o al menos una declaración temprana y poderosa) de la idea de que el código fuente es un diseño, no un producto . Los programadores son como los diseñadores en la sala de dibujo, no como los maquinistas en la fábrica, y la gestión de la programación debe ser como la gestión de otros tipos de diseño de ingeniería, no de fabricación.
Tom Anderson el

31

que, como programador, sabes todo sobre las últimas tendencias de hardware, overclocking, mod de casos, etc. amigos y familiares te consultan cuando compran sus equipos.


55
Solía ​​estar al tanto de algunas de estas cosas en la escuela secundaria, pero hoy en día encuentro que son generalmente irrelevantes para lo que hago y, aunque algunas están ordenadas, preferiría pagarle a alguien que sepa sus cosas y usar el tiempo que guardar haciendo lo que me gusta (es decir, escribir código). Tal vez otro malentendido "bueno con las computadoras".
Alan Plum

2
+1, o una tangente ligeramente única: debido a que usted es un programador, tiene un ventilador de 300 LED súper frío refrigerado por agua que parpadea en la parte superior de la gama recién enviado desde la planta de fabricación antes de su lanzamiento. Erm no realmente! Es una máquina bastante rápida, está en una caja negra muy barata. Realmente no importa más allá de eso!
Codificador quirúrgico

Ríete, hay un asistente de PM en el trabajo que tiene una plataforma de juego todopoderosa en casa, siempre se da la vuelta al área de desarrollo para preguntar si debe comprar (Producto A) o (Producto B) ... en una nota no relacionada, él también asume el equipo de desarrollo todo el rato en 4chan, (que realmente hace.) - suspiro
ocodo

+1 palabra. Esto es perfecto. Soy desarrollador de software y me han pedido que configure la conexión a internet de alguien muchas veces y, básicamente, todo lo que hago es prueba y error más búsquedas en Google. Me gusta más cuando algo se rompe por completo después de haberle hecho un favor a alguien y luego es tu culpa.
Anne Schuessler

30

Que cuando los programadores dicen que es muy difícil de hacer / simplemente imposible, RR.HH. piensa que son flojos y desmotivados


2
Incluya también la administración
Prasham

Cuando dices que no, piensan que eres simplemente una persona difícil de trabajar.
Capitán Sensible

+100, y con suficiente "motivación", pueden cambiar tu respuesta. O diríjase a otro desarrollador [menos experimentado] y deje a un lado la mitad de los detalles para que diga que sí, solo para terminar a la mitad del desarrollo y toparse con el problema exacto sobre el que les advirtió.
wildpeaks

28

Debe haber un programa de código abierto para mi negocio. ¿No puedes simplemente descargarlo y ajustarlo a mis requisitos?


2
+1. Oh, sí, lo que sea que tengamos que hacer ya debe estar en código abierto.
Sharptooth

77
muchas veces hay ... al menos eso es cierto para el desarrollo web.
WalterJ89

@ WalterJ89: Puede estar allí, pero eso no significa que sea una buena idea usarlo. El código abierto no significa automáticamente un buen código.
Alan Plum

cierto ... pero en el caso de Wordpress, Drupal, jQuery, ... puede haber áreas en las que lo gratuito no sea excelente, como el comercio electrónico, pero la mayoría de las veces la web es muy abierta, y creo que disfruto trabajar con un comunidad de código abierto mucho más que una mesa de ayuda propietaria.
WalterJ89

77
Lo contrario también es un mito. Que no puede usar FOSS para satisfacer sus necesidades comerciales.
término

27

Más de una persona me ha preguntado cómo es programar solo para darse cuenta a la mitad de la conversación que realmente piensan que programamos directamente en binario o usando símbolos matemáticos.

No sé si quiero disipar ese mito, ¡me hace ver muy inteligente!


66
No ayuda que la mayoría de las personas ni siquiera sepan qué es realmente la programación ... tienen la vaga idea de que está creando software ... pero realmente no tienen una idea clara de qué es el software ...
Spudd86

77
"Escribimos recetas de tejer". Las abuelas tienden a entender eso.

Conozco personas que escribirán un programa en C y luego rehacerán las partes más críticas para el rendimiento en la Asamblea.
Zaz

1
@Josh: a menos que haya un problema de rendimiento, eso parece una pérdida de tiempo.
JohnFx

1
@oosterwal: el ensamblaje no es binario ni utiliza símbolos matemáticos.
JohnFx

26

Creo que el error más grande es que es más importante poder escribir el código fácilmente que poder leerlo y comprenderlo.


55
* v (int) (void) ++
Rusty

1
@Rusty: Puedo encontrar ejemplos mucho, mucho peores si ni siquiera tengo que ser sintácticamente correcto.

44
Ahh, sí, "sólo escritura" código ...
Paddyslacker

24

La programación es como el trabajo en línea de montaje. Estás trabajando en un producto por un tiempo determinado (tal vez con compañeros de trabajo) y finalmente lo envías. Es como construir una casa de ladrillos.

Contra: la programación contiene mucha creatividad y planificación. Es arte. Al igual que el albañil, también un programador sabe la diferencia entre dar forma a un ladrillo y planificar una catedral entera.


66
Estoy de acuerdo con la diferencia del trabajo en la línea de montaje, pero en muchos sentidos no creo que sea muy diferente de construir una casa.
Billy ONeal

24

Portar un programa a C ++ automáticamente lo hará correr más rápido.


Me extendería a otros idiomas de bajo nivel. Es posible obtener lo contrario cuando el programador no sabe lo que está haciendo.
Maniero

2
Otra variante común es cambiar a una arquitectura cliente-servidor. "¡Actualizar a SQL hará que mi aplicación sea mucho más rápida!" No necesariamente.
JohnFx

Sí, es todo lo contrario muchas veces. Las bases de datos de tipo SQL son buenas para ser ACID o casi eso, tiene un precio. Y podría ser peor, pensar mal sobre las técnicas de SQL podría ser perjudicial para el rendimiento.
Maniero

66
Portado a C ++ / C para aquellos escritos en Python / Perl / Ruby / etc. Portar a asm para aquellos escritos en C / C ++: P. Me pregunto a qué te llevarías. diseñándolo en el hardware?
MAK

1
@MAK - echa un vistazo a en.wikipedia.org/wiki/Handel-C
flamingpenguin

21

Cualquier entorno de programación con un diseñador visual de algún tipo hará que los usuarios comerciales puedan "escribir" el programa y no se necesiten programadores reales.


99
Ah, sí. Siempre es divertido cuando alguna compañía crea una nueva herramienta de autoría para hacer que los programadores sean redundantes y luego todos los que la adoptan siguen adelante y contratan especialistas altamente remunerados para utilizarla. Caso en cuestión: Joomla! y todo ese sin sentido.
Alan Plum

HA HA HA HA HA HAAA HA +1 :)
Billy ONeal

Cobol ya lo intentó :)
Carra

20

OOP reutilizar. Es la mayor falacia comercializada en la programación.


1
Bien. El HP XL WESM es aproximadamente un 85% igual que el Symbol WS5100 (hay OEMming en marcha). ¿Me gustaría copiar y pegar ese porcentaje de mi código de monitoreo y configuración para que haya el doble de errores, o preferiría que lo reescriba desde cero y tome cuarenta veces más tiempo y haya cinco veces más? ¿O simplemente está presionado por una administración tonta que cree que es una de las varias panaceas mágicas para hacer que $ project sea más rápido?

1
La reutilización en el pequeño se resolvió hace 40 años y más. La reutilización en general es difícil y aún no se ha resuelto en mi humilde opinión. Al igual que Robert Glass dice en Hechos y falacias de la ingeniería de software
MarkJ
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.