¿La programación como profesión está en una carrera hacia el fondo? [cerrado]

Creo que has hecho una pregunta muy conmovedora.

La creación de herramientas de codificación GUI hace que los programadores dejen de trabajar tanto como los robots hacen que los trabajadores de la línea de ensamblaje dejen de trabajar. En mi opinión, si bien hay una pérdida de empleos, también hay un cambio en dónde están los próximos empleos.

La tecnología para realizar una tarea cambia, pero la tarea aún debe completarse: los automóviles aún deben hacerse / ensamblarse antes de poder conducirlos; El código / la lógica de negocios aún debe unirse para que la aplicación funcione.

Cambios en la tecnología opciones actuales para los programadores: Aprenda programación basada en GUI o programe herramientas GUI ... o ... algo completamente distinto.

Puede haber una desalineación entre las habilidades de los empleados y los intereses del empleador, pero no por mucho tiempo, especialmente si el empleador es inteligente. Por lo tanto, es en el mejor interés tanto del empleador como del empleado que persigan lo que es para su beneficio mutuo. Pero uno inevitablemente estará por delante del otro. Esperemos que sea usted (-:

Mis mejores deseos,

KM

A las tendencias que mencionas, yo añadiría una más, lo cual, en mi humilde opinión, las explica:

Hay muchísimos más programadores (necesarios) que nunca.

La cantidad de tareas que requieren o incluyen programación aumenta cada vez más, y en una tasa aún mayor que la cantidad de programadores. Hoy en día hay varios microchips en un auto promedio. En 5 años puede haber un chip en su nevera y su tostadora. En 10 años, ¿tu ropa interior? ... Y alguien necesita producir todo ese software para que esto funcione. Por lo tanto, se hacen todos los esfuerzos posibles para automatizar lo que sea automatizable y para mejorar la "productividad" (sin embargo, está definido). Y se reclutan más y más cerebros frescos.

Esto implica que la mayoría de los programadores activos de hoy en día no tienen experiencia y / o están mal preparados para su trabajo. Se requieren varios años para llegar a un nivel adecuado de experiencia y se requiere un aprendizaje constante para mantenerse allí. La conclusión es, cada vez más y más de los trabajos de programación son cada vez menos desafiantes. Pero todavía hay suficientes desafíos para cualquiera que los esté buscando .

Déjame jugar al defensor del diablo en contra de tus puntos anteriores:

  

No se toma el tiempo para implementar las mejores prácticas

Mucha gente no, mucha gente lo hace. Hace diez años, cuando descubrí las pruebas de unidad y el enfoque ágil, ninguno de mis colegas tuvo la menor idea de lo que era. Hoy en día es un material casi estándar en las universidades, por lo que muchos recién graduados ya lo entienden.

  

Usar el código de personas de otros tanto como sea posible (código personalizado como responsabilidad)

¿A diferencia de qué? ¿Reinventando la rueda? ¿O usar el código de otras personas para evitar eso?

Creo que es importante tener en cuenta que se nos paga (principalmente) para resolver problemas, y escribir código no es el fin, solo los medios para eso . Si un problema se puede resolver sin escribir una sola línea de código, el cliente todavía está contento. Especialmente si de esta manera conseguimos producir una solución más confiable, más rápida y más barata. No veo ningún problema con eso.

  

Uso de lenguajes cada vez más altos para mejorar la productividad

¿A diferencia de codificar todo en ensamblador? ;-)

  

"Herramientas" de desarrollo basadas en GUI que simplifican enormemente la "programación" y no requieren que las personas entiendan la tubería detrás del código

IMHO cualquier herramienta puede ser mal utilizada. Lo que no quiere decir que los constructores de GUI fueran necesariamente perfectos o incluso buenos: la mayoría (o al menos algunos) de ellos son utilizables dentro de sus límites. Pero si alguien no conoce esos límites, ¿es un problema de la herramienta o de su usuario?

En general, creo (aunque no tengo pruebas que lo demuestren) que en los días de tarjetas perforadas y códigos de máquinas, casi la misma proporción de código existente era horrible como ahora, solo ambas

• la cantidad total de código, y
• las posibilidades de que los forasteros vean tal código

era mucho menos.

Ahora, con Internet y el Daily WTF, nos exponemos a los peores ejemplos día a día. Es un poco como ver todas las noticias sobre terrorismo y terremotos y divorciarse de celebridades, y gritar lo peligroso e inmoral que se convirtió este mundo.

Resumes la situación correctamente, pero malinterpretas completamente el significado.

A medida que el software se vuelve más poderoso, las tareas que se llevan a escala con él. Entonces, puede que no sea necesario en la actualidad ser un programador de bases de datos para crear una base de datos de contactos telefónicos cuando puede usar Access. Y puede que no sea necesario ser un programador web para configurar un blog cuando solo puede ir a wordpress. Pero, mientras que hace 15 años sería necesario ser un programador para hacer esas cosas, lo que los programadores hacen ahora es un orden de magnitud mayor que lo que se podría hacer hace 15 años.

Déjame ponerlo de esta manera, dentro de 100 años, será trivial configurar un sistema tan complejo como Facebook o Google. No estoy hablando de sus páginas web, me refiero a sus centros de datos. Cualquiera podrá hacerlo. Se integrará en los teléfonos, suponiendo que aún los utilicemos. PERO, todavía habrá programadores, y mientras no estén trabajando en sistemas 'triviales' dentro de 100 años, estarán trabajando en sistemas mucho más complejos y sofisticados que nadie aquí puede comenzar a comprender su alcance y escala. Y esos sistemas, como los de ahora, estarán lejos del alcance del empleado de oficina promedio porque algunas personas, llamadas programadores, elegirán especializarse para llevar la tecnología de esa era a sus extremos.

He leído ese tipo de cosas durante cuarenta años, y no estaba al principio de las predicciones. No ha sucedido todavía.

COBOL fue la herramienta de desarrollo original destinada a eliminar la necesidad de los programadores de negocios, y era un lenguaje de mucho más nivel que el ensamblador. Las bibliotecas de códigos (para evitar tener que escribir el propio código) son de una antigüedad similar.

De vez en cuando, surge algo que permite a los no programadores hacer algo más parecido a un trabajo de programación. Estaban los "lenguajes de cuarta generación" de la década de 1980, hojas de cálculo sofisticadas como Excel, generadores de informes y similares. Lo que han hecho de manera uniforme, si han tenido éxito, es eliminar parte del trabajo de programación y permitir a los programadores hacer otras cosas más interesantes.

Este patrón no durará para siempre, pero voy a necesitar algo más que argumentos teóricos y predicciones para convencerme de que la programación en realidad va cuesta abajo.

El problema de COBOL a las herramientas de desarrollo modernas es que no reemplazan la capacidad de tomar una especificación inexacta y convertirla en algo preciso y útil. Esa es la capacidad fundamental de los programadores, y por qué no nos vamos a ir por mucho tiempo.

Los programadores de ensamblajes y FORTRAN probablemente dijeron lo mismo cuando la programación estructurada y los intérpretes generalizados aparecían en escena.

Al final del día, el software es una creación destinada a automatizar algo que previamente se había hecho a mano. Un departamento de contabilidad en una corporación moderada habría requerido previamente a docenas de personas, ahora todo ese trabajo se puede lograr con el trabajo de uno o dos. Como resultado, los postes de objetivos se han movido y ahora esperamos que un contador con capacidad estándar adicional.

Pixar tarda más en renderizar películas que nunca. A pesar del enorme aumento en la velocidad de computación, junto con ello, los animadores han exigido cada vez mayor complejidad y detalle en sus escenas. La animación del calibre de Toy Story no es aceptable en 2010 como lo fue en 1995. A medida que sus herramientas han avanzado, también lo han hecho sus capacidades y expectativas.

Cuando los métodos de arrastrar y soltar u otras metodologías de programación son comunes, el mundo exigirá soluciones a problemas aún más complejos y desafiantes, y necesitarán programadores que usen esas nuevas y sofisticadas herramientas para resolverlos. Las porterías se moverán.

Aunque estoy de acuerdo con la mayoría de las respuestas que señalan que todavía habrá mucho trabajo por hacer, le daré una respuesta diferente para que la tenga en cuenta:

Sí, lo es, y DEBERÍA ser

Estoy aquí para diseñar una solución a problemas que otros no pueden. Cualquier cosa en el conjunto de herramientas que me quite el tiempo de resolver problemas para lidiar con todos los pequeños detalles de cómo implementar mi diseño es un desperdicio.

La única razón por la que temería ir a un lenguaje de nivel superior o una herramienta más simple y abstracta es que esas herramientas a menudo hacen suposiciones que se interponen en mi camino y requieren mi tiempo para solucionar las suposiciones para obtener la implementación deseada.

Siempre hay más problemas que resolver que buenos solucionadores de problemas. Incluso si toda la cadena de desarrolladores se volviera tan simple, los preescolares podrían usarla, la mayoría de las soluciones diseñadas serían insuficientes o ineficientes, por lo que la gente pagaría por una mejor solución porque la mayoría de las personas son malas en ver la solución correcta a los problemas con todos los casos de vanguardia y qué pasa si usted necesita considerar para hacer una buena solución.

Nuestro trabajo es resolver los problemas mejor que la mayoría del resto, la complejidad de la cadena de herramientas no es tan relevante en la vista general, siempre que se salga del camino y te permita construir y construir algo bueno.

A pesar de que las tecnologías de programación pueden cambiar, la complejidad subyacente de un producto de software sigue ahí. Si el software se puede escribir completamente usando diagramas o diagramas de flujo (o alguna otra forma 'simple'), toda la complejidad del software aún debe ser entendida y abordada. Por esa razón, es importante que los empleadores cuenten con programadores que conozcan los productos de la empresa de adentro hacia afuera para actualizarlos o agregar nuevas funciones. Y los empleados pueden tardar bastante tiempo en aprender un producto de software.

No importa lo que pueda automatizar o sacar del estante, la mayoría del software empaquetado se divide en dos categorías:

1. Es fácil de usar, pero no coincide exactamente con lo que realmente necesita el negocio
2. Es altamente personalizable, pero se necesita un especialista para comprender y aprovechar la personalización

Supongo que olvidé el tercero Es el software de productividad estándar (correo electrónico, navegador, word proc, etc. El software de la categoría uno lleva a las empresas a contratar desarrolladores de software para personalizar el software disponible (si es posible). La categoría 2 software, bueno, también podrían contratar un desarrollador porque la persona que conoce el sistema personalizable por dentro y por fuera es muy codiciada (piense en SAP, PeopleSoft, etc.) o en una raza moribunda (piense en cualquier sistema similar a SAP y PeopleSoft que no lo haga). No tengo la misma penetración en el mercado).

Siempre habrá una necesidad para los desarrolladores. Lo que estoy viendo es que más de lo que solía ser el trabajo manual, tedioso y repetitivo se ha automatizado (piense en escribir un código para el acceso de datos a mano en lugar de usar una O / RM). Esto permite a los desarrolladores entregar más valor al negocio con menos esfuerzo.

No tomo tus argumentos:

  

1. No se toma el tiempo para implementar las mejores prácticas
  

excepto eso.

  

1. Usar el código de personas de otros tanto como sea posible (código personalizado como responsabilidad)
  

La reutilización de código es una buena práctica. Se prueba el código usado. Por supuesto, debe usar código de buenas fuentes, que es mantenido y usado por muchos.

  

1. Usar lenguajes de nivel cada vez más alto para mejorar la productividad
  

La productividad no es mala per se, ¿verdad?

  

1. "Herramientas" de desarrollo basadas en GUI que simplifican enormemente la "programación" y no requieren que las personas entiendan la tubería detrás del código.
  

Si la herramienta hace el trabajo: úsala. Si no, recházalo. Si la promesa se cumple, y la gente realmente no necesita entender el código, ¡bien hecho! ¿Pareces decir que esta es una promesa que no se cumple?

(Los números aquí se devuelven automáticamente de forma incorrecta. :))

La programación visual no es menos válida o merece menosprecio que la programación basada en texto.

Hay ciertas deficiencias y desafíos al programar visualmente, pero la plomería del componente subyacente es potencialmente peligrosa cuando se ignora no está monopolizada por los componentes visuales y, más relevante, los diseñadores visuales. La tubería subyacente que se ignora es un riesgo para cualquier desarrollo.

Si tienes la oportunidad de probar Labview, es posible que veas el potencial (o incluso una variante especializada en el entorno de Lego NXT). Si bien no está exento de defectos o deficiencias, existen beneficios hereditarios. Ver es creer.

Las prácticas de programación no solo aumentan la productividad y reducen los costos para ciertos tipos de desarrollo (su carrera hasta el final), sino que aumentan las capacidades de las aplicaciones y las expectativas del cliente (fomentando así una carrera hacia la cima). Sea testigo de las bonificaciones que Goole y Facebook están pagando para obtener los mejores tecnólogos.

No hay otra profesión que se ocupe de la ingeniería de existencia que se esfuerza por cambiar tanto como la programación. Tan pronto como simplifica algo, solo abre una lata para nuevos problemas que generan nuevas ideas.

Por lo tanto, no arruinaría los esfuerzos de otras personas para compartir códigos y soluciones con el fin de ayudarnos a avanzar hacia nuevos desafíos, ideas y experiencias de los usuarios con las malas prácticas, los malos hábitos y los modales carentes del humanista.

Si tomamos las prácticas de:

• No tomar tiempo para implementar las mejores prácticas
• Usar el código de personas de otros tanto como sea posible (código personalizado como responsabilidad)

WTF? ¿Querías que esta lista fuera inconsistente? Las listas deben provenir del mismo lado para cada elemento en lugar de alternar sin previo aviso. Por lo tanto su lista debe leer:

Si tomamos las prácticas de:

• No tomar tiempo para implementar las mejores prácticas
• No utilizando el código de personas de otros tanto como sea posible (código personalizado como responsabilidad)