¿Programador o ingeniero?
¿Cuál es la diferencia?
Algunas personas llaman a sí mismos "programadores" y otros llaman a sí mismos "ingenieros de software". "Ingeniero" parece tener más prestigio en nuestra sociedad, para que más personas tratan de llamar a ingenieros (incluso si no lo son). Por supuesto, nadie puede llamarse lo que quieran - para lo que las personas llaman a sí mismos no hace mucha diferencia, sin embargo, existe una clara diferencia entre los dos.
Con el fin de explicar las diferencias, tengo que caricaturizar tanto al extremo - para el contraste. Darse cuenta de que la mayoría de la gente son una combinación de ambos atributos - pero al menos puede obtener algunas ideas sobre lo que debe buscar, si usted sabe los extremos.
Hay necesidades de ambos (ingenieros y programadores) - y las diferentes tareas requieren más de una o la otra. La mayoría de las tareas requieren sólo unos pocos ingenieros y bastante unos pocos programadores. El problema es que muchos gerentes no entienden la diferencia, o contratar a las equivocadas para un puesto de trabajo.
La programación no es difícil - es tedioso. ¡Tienes que ser capaz de romper las cosas complejas hacia abajo, en una serie larga de pasos sencillos. Eso es todo. ¿Cómo acercarse a ese problema será definir si usted es un programador o un ingeniero. Así que la mayor diferencia entre los dos es filosófica - y como la mayoría de las diferencias filosóficas, puede conducir a la tensión. Tipos arrogantes (a cada lado) puede llegar a estos complejos de superioridad poco ego que conducen a las tuercas del otro lado, y algunos pretenden que los "otros" son unos idiotas. No son idiotas - que acaba de tener diferentes objetivos, diferentes motivaciones y diferentes filosofías.
Los ingenieros tienen más experiencia (maduro (1)) que los programadores (especialmente en el software y la teoría del diseño), pero eso no quiere decir que son los que usted necesita para una tarea (o que siempre son mejores). Los ingenieros son los "diseñadores", los que han existido por años y entiende un montón de diferentes conceptos, o entender algunas especialidades muy bien. La mayoría de los ingenieros de un conocimiento no es aplicable a la tarea a realizar directamente, sino que se basan en su experiencia y la educación para resolver los grandes proyectos - al mismo tiempo evitar los errores. (En los sistemas complejos hay muchos escollos, y algunos pueden costar proyectos de "años" y millones de dólares).
(1) No se debe confundir la edad con la madurez - muchas personas no crecer nunca. El hecho de que un tipo es un programador de 50 años de edad codificador /, no significa que creció más allá del "hacker" fase - y hay un buen número de ingenieros de 20 años de edad. Así que busque en su personalidad y filosofía, así como su experiencia y educación, para saber que es probable que sean.
Los ingenieros son los que quieren (o al menos entender la necesidad de) diseñar, documentar, crear procesos y procedimientos para evitar problemas futuros. Ellos quieren tener un proyecto de principio a fin (con todos los pasos intermedios). Ellos tienden a ser más "anal" tipos, que quieren centrarse en los detalles (en la ingeniería del diablo está en los detalles). Los ingenieros a menudo son más académicos (voluntad de hacer más investigaciones antes de atacar un problema). Los ingenieros saben cómo establecer los horarios, y les siguen. Falla más grandes ingenieros sin experiencia es que a veces se "sobre-ingeniería" una solución, y tratar de resolver las cosas que nunca pueden ser los verdaderos problemas (que se gastan tiempo y dinero resolver problemas que no será un problema real de una década, y entonces los objetivos de tecnología o la empresa han cambiado lo suficiente que no habría sido un problema de todos modos). Los ingenieros también están los que hacen más lenta de un proyecto en las fases iniciales (pasar más tiempo en la investigación, diseño, análisis, documentación y debate) con el fin de evitar peligros potenciales (y ahorrar tiempo y dinero) en las últimas etapas de un proyecto . Esto es grande para los costos del proyecto a largo plazo (y que te dan la espalda tiempo / dinero) -, pero tenemos un montón de corto plazo, los pensadores de la sociedad (y negocio). Los ingenieros son los maduros "virtuosos", que tendrá un proyecto hecho y evitar sorpresas (por el pensamiento a todos antes de empezar) - y se aseguran de que su diseño y la documentación es tal que un proyecto será fácil de mantener. Metas a largo plazo (pensadores) - que hacen "inútiles" las cosas como poner en el código de pruebas automatizadas, crear "las normas de codificación", o quiere hacer revisiones de código (que a menudo resultan ser buenas ideas en el largo plazo). La mayor parte de las sorpresas (y costos) en el desarrollo de software se debe a que no había suficientes ingenieros (o no eran buenos ingenieros suficiente), o la gente no estaba escuchando.
Los programadores son los tipos más abajo y sucio. Que solían ser llamados "hackers", pero que ahora tiene un nuevo significado (2). Ahora los días son más propensos a referirse a sí mismos como codificadores o Código Jockeys. Los programadores no tienen que saber todo lo primero, simplemente disfrutar de la emoción de la solución de los problemas que se vienen. Son más los artistas excéntricos del mundo de la informática. A menudo pasan días sin dormir y vivir en la comida chatarra y Mountain Dew, sólo "hacer" - Go, Go, Go! Por supuesto, que a menudo pasan las semanas la solución de problemas que se han resuelto antes (si es que acababa de leer un libro e investigar los problemas antes de la mano) -, pero a veces (a veces) que resuelven los problemas de toda una nueva (e ingenuo) formas (y mejor que las soluciones enlatadas), o resolver problemas que no han sido resueltos antes. Son los jóvenes impetuosos del mundo - que la energía utilizada y el vigor para tratar de compensar la falta de experiencia y el diseño (y éxito). Ellos no saben lo que no pueden hacer, así que a veces lo imposible.
(2) hacking usa para significar (en los años 70 y principios de los 80) los programadores que se sumergía en un problema (sin documentación o una comprensión completa del problema, etc) y sólo el programa de su salida. No hay mucho pensamiento pasó de diseño (ya que pueden pensar y ejecutar más rápido de lo que podían de diseño). Que no era necesario "no manuales apestoso", que no hicieron la documentación (el código se explica por sí mismo), que acaba de resolver problemas a su manera. Sin embargo, ese nombre adquirió una connotación diferente, cuando muchas personas con esta "piratería" de la personalidad, que comenzó a utilizar la persistencia de romper la seguridad, o para encontrar la manera de violar la compañía telefónica en 16 formas diferentes. (Esta forma de pensar la fuerza bruta es muy bueno para romper la seguridad). Ahora los "hackers" se refiere a que los pequeños sub-conjunto de los piratas informáticos que a menudo se hacen los actos delictivos, como la piratería en los lugares (en lugar del código de hacking).
Los programadores se sumerge en algo antes de que entiende completamente las ramificaciones, y con frecuencia va a costar un montón de dinero porque las empresas de que la falta de experiencia (conocimiento), y los "errores" o el desperdicio de energía. Los ingenieros les gusta decir "trabajo inteligente, no es difícil". Muchos programadores encanta programar tanto que van a trabajar más duro, simplemente porque les gusta la programación y no como las otras cosas (diseño, documentación, soporte, añadiendo en el código de prueba, el marketing, las políticas corporativas, la mayoría de la humanidad, etc.) Los programadores no suelen gustar los horarios (los que son para los contadores de frijoles), y ellos la promesa del mundo (y descubrir más tarde que ellos no pueden ofrecer, o se matan tratando de entregar). La calidad de sus resultados es por todo el tablero (de mierda a excelente, a menudo con elementos de ambos) - pero por lo general, sus productos se pueden utilizar, pero de mantener sólo por ellos. Cuando los programadores de salir de una empresa que es programador pesados (y lo hacen), o pasar a la siguiente cosa nueva (que es siempre más interesante que lo que están haciendo), le costó una fortuna para arreglar o cambiar cada vez que "la vieja" producto nuevo (ya que nadie entiende qué diablos está pasando en su código, y no hay documentación o de diseño para ayudar)
¿Qué se necesita?
Así que uno (los programadores o ingenieros) que necesita depende de la tarea. Lo ideal es tener un equilibrio en un proyecto, con unos pocos ingenieros haciendo el diseño arquitectónico de un proyecto y dar algunas orientaciones y evitar los problemas (y la documentación exigentes) - y unos pocos programadores, que son enviados en direcciones (bajo el control de ingenieros) para poner en práctica como un loco, y tenazmente a resolver los problemas que puedan surgir. Los programadores suelen briosos caballos que necesita un piloto experimentado (Ingeniero) para controlar y guiar a ellos - pero una vez que se señalan en la dirección correcta, el hombre puede correr. Los ingenieros a menudo no son los mayores productores de código (cantidad), o en el mejor depuradores - que prefieren el diseño de los problemas (y código) en el primer lugar. Los ingenieros se gritaba "diseñar, documentar, implementar". Los programadores se gritaba, "¡Deja de hablar de eso! Permite Código Código Código".
Se puede imaginar que es difícil encontrar a personas de un tipo que puede tolerar el otro tipo (o más raro encontrar personas que son un buen equilibrio de ambos) - Es sorta como el Congreso. Pero si lo hace a equilibrar, los resultados pueden ser lo mejor de ambos mundos. Empresas más triste no tener un equilibrio. Consiguen un líder de un tipo (o la otra), que no ve valor en el estilo de oposición - y por lo tanto la unidad a todos los que no piensan como ellos hacia fuera. O más común, la empresa no tiene ninguna pista acerca de las diferencias y no le importa - la política que permite que el que suceda lo mismo. Los resultados de cualquiera de los extremos puede ser feo, sin embargo, los ingenieros de muchos son lentos (er), muchos programadores pueden matar a una empresa o un producto.
Nuevas empresas y pequeñas empresas a menudo favorecen a los hackers / programadores. Estos chicos bofetada algo juntos (rápidamente), y tratar de venderla. A menudo funciona (apenas) por lo que se vende en la primera encarnación. Luego, una bofetada más en algunas de sus funciones, y se vende todavía. Luego, el plomo programador hojas (se aburren haciendo lo mismo durante más de 2 años), y las espirales del proyecto en código infierno. No se puede mantener el proyecto, y la empresa no va a invertir el dinero para "rediseñar". Así que a ningún lado, tratando de insectos de la calabaza, y todas las características que añaden (o bug que arreglar) crea nuevos errores. Pasan diez veces el dinero (y tiempo) tratando de arreglar las cosas como lo hizo en desarrollo en el primer lugar, y que solía pasar el tiempo o el dinero para hacerlo bien. Si estas empresas son un barco que se hunde, sino que va a contratar para rescatar los cuerpos de agua, sin embargo, no arreglar las goteras. La mayoría de las empresas están en este modo el programador pesada - y la mayoría no ingeniero de su salida (porque no entiende de ingeniería). En cambio, las empresas tratan de comprar su salida de los problemas (con los organismos) y ocultar los síntomas, en lugar de permitir que el producto (y problemas) que se fije, que suele conseguir algunos ingenieros y la creación de algún tipo de proceso (y curar la enfermedad).
Lo contrario de ese extremo son las empresas que favorecen a todos los ingenieros - como el aeroespacial, Gobierno, algunas grandes corporaciones.. Por supuesto, parte de eso es debido a los riesgos (y que muchas vidas a menudo la mano en el equilibrio de sus diseños). Estos tipos de diseño, documento, discutir, perfeccionar, volver al inicio, más de la ingeniería a los diablos de algo, y crear algo que sería un gran producto -, pero se necesitarán 10 años para crear. Procesan las cosas a la muerte, y requieren de 27 formularios a ser completados para usar el baño. Que el producto tendrá una arquitectura maravillosa, que puede durar hasta el próximo siglo - y que van a generar la documentación suficiente para matar a un bosque, y el producto será tan sobre-hecho que tendrá 5 años adicionales antes de la computación-caballos de fuerza ponerse al día (o el precio de las computadoras se reduce lo suficiente) para que el producto será realmente viable. Sin embargo, estos productos suelen tener una vida útil mucho más larga, y puede crecer durante mucho tiempo. A menos que fueron diseñados por un comité - y entonces será tan funcional como una mesa de dos patas. Por no mencionar el hecho de que todos los ingenieros en el mundo no puede compensar la mala (estúpido) requisitos - que causa mucha fricción entre los ingenieros y la comercialización (ya que ambos piensan que tienen todas las respuestas, y que ninguno de ellos).
La Industria
Apple y Microsoft se "hacker" pesados en los años 70 y 80 (a pesar de que mejoró con el tiempo). IBM era el más "sobre-ingeniería" de estrategia. Lo que solía ser en broma que el proceso de IBM consistió en "Ready .. Objetivo ... Objetivo ... Objetivo ... Objetivo ...", donde, como proceso de Manzanas" fue "¡Fuego, Objetivo, ¿Listo?" Microsoft no haría, y prefieren ver otros tiradores disparar primero - entonces sólo se disparaba el tirador con el mejor resultado, y luego tomar el crédito por su trabajo.
Algunas compañías utilizan una estrategia que yo lo llamo "el diseño a través de adquisiciones". Ya que no se puede hacer "bien" a sí mismos (porque no entienden la ingeniería), que acaba de comprar-a quien los está superando a la vez, y luego el mercado a los diablos de esos productos. Ellos hacen tibios intentos de "arreglar las cosas" en los productos que han adquirido, pero a menudo sólo tienen las versiones posteriores de mal en peor (más funciones y más bugs). Symantec y Novell han hecho esto unas cuantas veces. Muchos de los "líderes del mercado" utilizar esta estrategia como una forma de compensar el hecho de que se olvidaron de lo que les hizo el líder en el primer lugar - por lo que sólo tratan de colgar a sus posiciones (de modo que de directivos senior pueden obtener sus programa de bonos) sin realmente ganando o perdiendo cuota de mercado - pero rara vez tienen éxito por mucho tiempo. Por lo general, alguien más hábil se acerca y "come su almuerzo".
En general, creo que la mayoría de las empresas de juego (y la mayoría de los arranques) son demasiado pesados hackers (pero eso está cambiando). El sector aeroespacial es demasiado pesado de ingeniería (agravada por la burocracia). Las grandes empresas (Fortune500) es por todo el lugar, pero por lo general envuelto en el proceso, con la política (y quién está haciendo qué a quién) dictando un extremo u otro. Software comercial es un gran programador poco (pero varía según la empresa). BioMed fue el mejor equilibrio que he visto (pero que pueden haber sido las empresas que tratan). Todas las empresas varían, y varían en el tiempo (primero se cometen errores en un extremo y luego el siguiente) - y es raro encontrar un buen equilibrio, pero puede existir en cualquier industria.
La conclusión
Recuerde que en el mundo, a menudo se obtiene lo que paga (y lo que pides).
Si desea que un niño de impulso que puede abofetear un código junto a usted en ningún momento - y que van a hacer exactamente eso. Usted va a pagar por esa decisión por año (en mantenimiento) - pero usted consigue un producto en una fracción del tiempo.
Si usted pone el dinero y el tiempo (e ingenieros), para diseñar un producto adecuado, entonces usted consigue algo que te llevará muy lejos en el futuro - pero hay que esperar que sus competidores no le ganó de mano (con agua caliente-shot niños), y lo que necesita para asegurarse de que usted no está tratando a un exceso de resolver los problemas (y perder el tiempo / dinero).
Lo mejor de ambos mundos es de mezclar y combinar bien. Ponga en caliente disparos en las cosas a corto plazo - y luego usar esa ventaja de tiempo a hacer las cosas bien. (El desarrollo paralelo). O usted puede poner tanto en los mismos proyectos (si trabajan bien juntos) - y tiene el control de los ingenieros de los programadores (si es que puede hacerlo sin aplastarlas). Balance de los dos proyectos de manera que las tomas en caliente se conduce a los ingenieros a implementar más rápido, y los ingenieros están reduciendo los programadores hacia abajo (para que sepan cuáles son los costos a largo plazo son para muchas de sus decisiones, minimizar los riesgos, y para que puedan documento sobre la marcha). La madurez y la unidad. A veces se puede encontrar a personas que son un buen equilibrio de ambos - la mayoría de la gente tiene sus fortalezas y debilidades y se inclinan a un lado o del otro. De cualquier manera, entender las diferencias y las unidades son el primer paso para tomar las decisiones correctas. Esperemos que este artículo te ha dado una mejor comprensión de las cosas mejor.
Por: David K. Cada una adaptación de http://www.igeek.com/
