Trabajar con el desarrollo de software es muy agotador hoy en día. Todos los días, se crea un nuevo idioma, biblioteca o marco. ¿Cómo podemos ‘sobrevivir’ en este contexto?

¡Aprende a un nivel superficial!

Digamos que quieres aprender R. Curso Prueba R. Se puede hacer en 1–3 días. HTML? Realice los tutoriales web en línea de W3Schools. W3Schools también tiene CSS, Javascript, jQuery, XML, XPath, XSLT, etc.

¿Pitón? Descargar desde Python.org. ¿Java? De oráculo. C#? De Microsoft Y así.

Pase 1–2 días en lo que quiera aprender. Puede ser un fin de semana

Haz algunos proyectos de “juguete”. Un mantenedor de cuenta bancaria. Una base de datos alumno-profesor-asignatura. Un árbol. Una tabla.

Ahora puedes ponerlo en tu currículum.

Comience con su idioma favorito. Agregue conocimiento de bibliotecas y marcos. Haz algunas aplicaciones REST. Crea algunas API.

Muestra tus habilidades. Póngalo en portales en la nube. Realice front-end en Javascript y back-end en Java (o Ruby). O viceversa.

Ponga sus programas de juguetes en una cartera de Github. Vea qué otras carteras existen y contribuya a sus proyectos favoritos.

Descubra cómo los departamentos de recursos humanos y los reclutadores hacen una lista corta. ¿Qué tendencias en los portales de empleo? Haga un seguimiento y análisis de palabras clave en dichos portales.

Obtendrá una buena idea de las habilidades necesarias y su propio conjunto de habilidades. Luego haga un análisis de brechas y reduzca las brechas.

Siempre sepa un poco sobre muchas cosas y mucho sobre algunas cosas.

Desearía poder seguir mi propio consejo; -0

Sí, eso es agotador, especialmente una vez que envejeces. Pero eso es por lo que se paga a los ingenieros de software, y se les paga bastante bien. Aquí hay algunas técnicas que encontré útiles para mí “sobrevivir” en un entorno tan cambiante:

1. Aprende los fundamentos. Aunque todos los días aparecen nuevos marcos, a menudo se basan en los mismos principios fundamentales. Si comprende bien los fundamentos subyacentes, aprender un nuevo marco se vuelve mucho, mucho más fácil. Es por eso que siempre enfatizo la importancia de una buena educación para los programadores;
2. Aprenda solo lo que necesita para resolver un problema en el que está trabajando ahora. El nuevo marco es enorme y puede hundirse fácilmente en él. Así que sé eficiente. Si necesita aprender ciertas funciones para ofrecer una solución, aprenda estas funciones y no vaya mucho más allá. Suena “no genial” y contra-intuitivo, pero esto me ahorra mucho tiempo y energía mental. De todos modos, este marco puede estar muerto en 2 o 3 años, así que no gastes demasiado tiempo en él. Si tienes tiempo y ganas, mejor aprende más fundamentos;
3. Aprende en el trabajo. Intente elegir proyectos en los que aprenderá algo nuevo, proyectos que lo ayudarán a mantener sus habilidades y conocimientos actualizados. Esto puede ser incómodo a veces, pero no tendrá que aprender en su tiempo libre;
4. Aprende a aprender. Cuanto más aprenda, más eficiente será en él. La capacidad de aprender rápidamente es una habilidad, desarrollarla;
5. Cuida tu salud, especialmente la salud mental. No te quemes. Si va a tener un exceso de trabajo crónico y un estrés excesivo, puede enfermarse. Es poco probable que sea algo serio. Pero muchas cosas que parecen pequeñas e insignificantes, por ejemplo, el insomnio, matarán su productividad dramáticamente.

Linux se creó en 1991. Bash se creó en 1989. Vim se creó en 1991. Python se creó en 1991. Java se creó en 1995. SQL se creó en 1974. Esas son las tecnologías que más uso en mi empresa, y todas de ellos tienen más de 20 años.

Sí, ha habido algunos desarrollos en ciencias de la computación e ingeniería de software que son más nuevos que eso. MapReduce cambió la forma en que las personas procesan grandes cantidades de datos, por ejemplo, y las nubes públicas (como AWS y GCP) cambiaron la forma en que las personas interactúan con la infraestructura.

Pero los cambios fundamentales reales no ocurren todos los días. Los nuevos lenguajes, bibliotecas y marcos son en su mayoría solo sabores del mes, y la forma principal de descubrir cuáles son los verdaderos cambiadores del juego es ver cuáles realmente maduran y cuáles no.

Si conociera a alguien que fuera excelente en los fundamentos de ingeniería de software como modularidad, pruebas, automatización y comunicación y que fuera excelente en tecnologías antiguas y aburridas, los contrataría en un segundo incluso si solo tuvieran un conocimiento superficial de cosas nuevas.

Manejar la respuesta psicológica a la abundancia es una habilidad esencial en muchos aspectos de la vida moderna.

Quizás el ejemplo más destacado de esto es la dieta y el ejercicio. Nosotros, como animales, evolucionamos en un ambiente de escasez, donde poner más calorías en su cuerpo siempre que podía era generalmente una buena idea, para no morir de hambre mañana. El mundo moderno es muy diferente, y las enfermedades relacionadas con la obesidad se están convirtiendo rápidamente en una de las principales causas de enfermedad y muerte, especialmente para personas con profesiones sedentarias como la programación. Algunas personas requieren más esfuerzo y disciplina que otras para mantener una salud óptima, pero todos deben comprender que demasiada comida y muy poco ejercicio pueden causar problemas.

Lo mismo ahora también se aplica para evitar la gula de la novedad trivial, de conocer cada nuevo lenguaje de programación, marco, biblioteca, etc., para que no los necesitemos en el futuro. Estas cosas solían ser escasas, pero están creciendo a un ritmo exponencial. Puede ser adictivo, como apostar, a medida que lee sobre cosas nuevas, quizás encuentre algo que excite sus niveles de dopamina. A medida que la información se vuelve más y más abundante, acumular demasiado en nuestros cerebros se convierte en un exceso de grasa, más un pasivo que un activo. Algunas personas requieren más esfuerzo y disciplina que otras para usar su tiempo de manera productiva, pero todos deben comprender que aprender demasiado y concentrarse muy poco puede resultar en una pérdida de tiempo.

Es esencial priorizar. El conocimiento, como la comida, debe ser un medio para un fin. Todavía puede reservar una fracción de su tiempo o presupuesto calórico para el postre, pero debe medirse y controlarse. Mantenga un registro de lo que come o cómo pasa su tiempo. Mantenga un manifiesto de objetivos que desea lograr: esta cantidad de calorías y esta cantidad de proteínas; tanto tiempo dedicado a aprender nuevos medios, y tanto a lograr fines a través de los mejores medios que ya conoces.

En los últimos meses, algunos de nuestros ingenieros dejaron nuestro departamento de tecnología.

El primer grupo carecía de las habilidades y la persistencia necesarias para el trabajo. El segundo fue para diferentes puestos que proporcionaron un conjunto más amplio de tecnologías y desafíos de ingeniería que pudimos ofrecer internamente.

El desarrollo de software no es agotador si realmente disfruta el oficio. La mayoría de los ingenieros destacados con los que trabajo nunca aceptarían una oferta de trabajo en una corporación empresarial que construya un proyecto Java o .NET que se lanzará dentro de 5 años a partir de ahora. Eso sería simplemente una exageración que llevaría años y difícilmente desarrollaría aún más su talento.

Esa es la razón principal por la que quedan muchos geeks para los lenguajes que permiten un desarrollo rápido, MVP rápidos y un flujo de trabajo ágil que apunta al éxito.

Si encuentra que el aprendizaje es agotador, tal vez el desarrollo de software no sea para usted. Alternativamente, puede encontrar un trabajo corporativo en una corporación multinacional que contrata a miles de desarrolladores que mantienen software de 20 años con poca o ninguna innovación.

Editar: después de algunos comentarios sobre los mundos de Java y .NET, vale la pena señalar que soy un programador certificado de Java con experiencia en desarrollo de producción en Java y C #. La respuesta no pretende avergonzar a las comunidades de desarrollo en el mundo empresarial.

Pero la innovación es más rápida y evoluciona mucho más rápido en el ecosistema de inicio: a menudo las empresas programan en Ruby, Python, Node.js, implementan nuevos lenguajes de programación funcionales, juegan con Go, Dart o ciertos lenguajes compatibles con JVM como Clojure o Scala.

El mundo front-end es vasto y también evoluciona dramáticamente mientras hablamos. Nuevos marcos de JavaScript aparecen cada semana. Las herramientas de construcción y los transpiladores siguen surgiendo para acomodar el crecimiento de la industria. Hay mucho que aprender a diario y es simplemente una parte del oficio.

Y sí, si quiere tomarlo con calma y progresar lentamente, una gran empresa empresarial con miles de desarrolladores probablemente será más acogedora y comprensiva que una pequeña empresa que está constantemente al borde de la supervivencia. Pero el aprendizaje es un proceso interminable, y las tecnologías empresariales se ocupan de otros problemas que aún requieren una lectura en profundidad, I + D y una inmersión profunda en los registros del servidor y errores de compilación.

Lenguajes de programación y marcos

Dependiendo de su rol, puede ser especialista en uno o más lenguajes de programación o generalista en muchos idiomas y especialista en algunos. Puede elegir ser un experto en Java Rockstar o .NET, C o C ++, Ruby on Rail, Python Django, experto en PHP como desarrollador de back-end y HTML, CSS, JavaScript y Node.js para front-end y back-end. Luego React, Angular, JQuery o cualquier otro marco para el front-end.

Lenguaje específico de dominio – DSL

Los lenguajes de programación son generales y para tareas de programación más avanzadas debemos usar DSL para tareas específicas en un dominio específico. El punto central detrás del uso de framework o DSL es la productividad y la simplicidad, para hacer más con menos esfuerzo.

DSL detallado, DSL simplificado y DSL minimizado

Aquí hay un ejemplo de cómo diferentes DSL ayudan a minimizar, personalizar y simplificar el trabajo en cuestión. La construcción de una VPC (Virtual Private Cloud) en AWS requiere +2500 líneas de código en formato JSON, si usa YAML, se convierte en +2000 líneas de código. Con Terraform HCL (lenguaje de configuración HashiCorp), la misma tarea requiere menos de 500 líneas de código. Para algunos casos de uso específicos, desarrollo una aplicación que requirió menos de 100 líneas de configuración para construir más de +30 VPC. Luego tenemos un rango de +2500 LOC (líneas de código) a 100 o 96% menos líneas de código para la misma tarea.

Cómo ponerse al día – Use el código para crear código

Estoy programando en más de 20 lenguajes de programación y DSL, pero no puedo memorizar toda la sintaxis y escribir código sobre la marcha sin consultar la documentación de todos estos lenguajes de programación, hay muchas similitudes pero también hay grandes diferencias.

En algunos casos, podemos escribir una aplicación para crear una buena arquitectura y probar otro lenguaje de programación para simplificar y automatizar las tareas repetitivas.

Una vez que tuve que migrar las tablas de MS-SQL a otras tablas que requieren decenas de miles de líneas de comandos SQL, escribí un marco y una aplicación en menos de 2000 líneas de código para crear estos comandos SQL, el resultado fue un front-end con algunos opciones para crear decenas de miles de líneas de código con un solo clic, luego tuve que extender este script de migración para escenarios más complejos, así que actualicé la aplicación y luego tuve muchas opciones para muchos escenarios de migración, cada una disponible con un solo clic. El uso de esta aplicación no requiere conocer el proceso interno, pero si tiene curiosidad por mi parte, modifíquela y úsela para diferentes proyectos y tareas similares.

Elija la herramienta adecuada: muchas opciones disponibles

Escribí muchas aplicaciones de automatización en PHP, Node.JS y Ruby, pero casi todas podrían escribirse en muchos otros idiomas, el enfoque y la estrategia son los mismos, pero la sintaxis es diferente. La aplicación más loca que escribí tenía más de 10 lenguajes y marcos, era una aplicación de modelado 3D con .NET, PHP, MS-SQL, ActionScript y Adobe AIR para back-end y HTML 5, CSS 3, JQuery, 3d.js , chart.js y Graph.js en el front-end. Pero la pila podría ser cualquier cosa. La base de datos podría ser cualquier SQL o incluso NoSQL. El back-end podría ser Java, Ruby, Python, Node.JS y hoy el modelado 3D en lugar de ActionScript y Adobe AIR podría ser el marco de JavaScript y hay muchas opciones para la visualización de datos y gráficos. HTML 5 y CSS 3 son las únicas partes que permanecen igual, excepto que es una aplicación móvil nativa que no está basada en HTML.

Elija la herramienta adecuada – Opción óptima para infraestructura

En el caso de IaC (Infraestructura como Código) hay muchas opciones. Por ejemplo, en el caso de AWS, podemos usar casi cualquier SDK de AWS para escribirlo en Java, PHP, Node.js, Ruby, .NET o Python Boto, etc., pero terminamos con decenas de miles de líneas de código, es posible pero SDK no es la herramienta correcta, CloudFormation es una recomendación de AWS para Infraestructura que termina teniendo miles de líneas de código en lugar de decenas de miles. Terraform es la opción más adecuada para terminar con cientos de líneas de código.

Elija la herramienta adecuada: opción óptima para la configuración

En el caso de la administración de la configuración nuevamente, podemos usar SDK en el caso de AWS o lenguaje general como Python, Ruby, Bash o PowerShell y terminar con decenas de miles de líneas de código, pero ¿por qué no usar Chef, Puppet, Ansible o SaltStack, que es el preferido? herramienta específicamente diseñada para gestionar la configuración. Si eres desarrollador, entonces Chef es más fácil, Puppet es más difícil pero ambos escritos en Ruby. Si usted es SysAdmin, entonces Ansible o SaltStack tiene más sentido ya que ambos están escritos en Python y usan YAML. Pero puede lograr lo mismo con Python puro, Ruby o Bash y PowerShell para Windows.

Conclusión

Hay muchas maneras de desollar a un gato, pero no todas son óptimas en cuanto a costo, valor y tiempo. Puede apegarse a la funcionalidad central de un lenguaje, pero luego está limitado a su innovación, pero el uso de un marco nos ayuda a simplificar el proceso, enmascarar la complejidad y tener poderosos bloques de construcción en lugar de construir todos los bloques de construcción.

En casos de uso de dominio específico, el lenguaje de dominio específico es más poderoso que el marco o el uso de lenguaje de programación puro: DSL es un tipo de marco específico en torno a casos de uso específicos y es menos general que los marcos generales.

Comience desde “Lenguaje de programación” para conocer las mejores prácticas y conocer el idioma dentro y fuera. Mejore su productividad empleando los marcos correctos y elija los populares y probados, pero no el que nadie escuchó de él. Use SDK para agregar más potencia a sus habilidades de desarrollo y productividad. Use DSL para obtener más productividad en tareas específicas del dominio.

El proceso de mejora es el mismo que la codificación en un editor de texto mínimo como vim o un bloc de notas en lugar de un editor avanzado como Eclipse, Notepad ++, texto sublime, etc. con resaltador de sintaxis, funciones de alcance, autocompletado, etc. Seguro que podemos usar cualquier editor y confiamos en nuestra memoria, pero si queremos desarrollar una aplicación real, necesitamos un editor real adecuado para nuestro idioma de elección, el punto es la productividad y la facilidad de uso.

Ejemplos de DSL : Lenguaje de configuración HashiCorp, Chef Ruby DSL, Puppet Ruby DSL, Libro: Martin Fowler: Lenguaje específico del dominio

No necesitas aprender todo lo nuevo.

Necesita aprender los que son relevantes para lo que hace. Si realiza la programación de la aplicación cliente, puede ignorar Erlang y Rust. Si no está en iOS, puede ignorar Swift. Puede ignorar todos los marcos para todos los idiomas que no usa, o para las plataformas que no usa.

Incluso en la plataforma elegida puede echar un vistazo a muchas cosas y saber que no las necesita. ¿Escribir aplicaciones de iOS? ¡Excelente! ¿Son aplicaciones de eliminación de restaurante? Ok, apuesto a que puedes ignorar HomeKit una vez que descubras que controla las luces y las cosas de la casa. No lo necesitará (a menos que decida que no es espeluznante encender las luces delanteras y desbloquear la puerta principal a medida que se acerca la comida … pista: si cree que es genial, pase más tiempo con humanos normales por un tiempo ) Escribir videojuegos? Apuesto a que puedes ignorar HealthKit.

De los marcos que no puede descartar de un vistazo, puede decidir que si un nuevo marco hace lo que ya está utilizando, no necesita examinarlo demasiado de cerca a menos que el actual tenga problemas.

Ok, ahora se ha reducido a un nivel manejable.

También te está privando de algunas cosas. Ver cómo un nuevo marco trata un concepto puede darle ideas sobre cómo ver los problemas en las interfaces internas de sus propios programas. A veces. A veces, un marco que funciona “suficientemente bien” tiene un reemplazo mucho mejor . A veces, algo que no está relacionado puede ser útil (¡tal vez su juego de realidad virtual es ejercicio, ofrézcase para rastrearlo en HealthKit!).

El uso de lenguajes de alto nivel y marcos potentes ya ha hecho que su vida sea muchísimo más fácil que las eras de la informática cuando escribimos todo nosotros mismos. En cinta de papel. Usar serpientes como punzones de cinta (¡solo un número par de un bit!). Así que use algo de ese “tiempo encontrado” , explore un poco fuera de su zona de confort.

De vez en cuando descubrirás una joya.

Sin embargo, no es necesario que te obsesiones con aprenderlo todo.

Contestaré desde un punto de vista un poco diferente.

Existen diferentes tipos de desarrolladores cuando se habla de frameworks o lenguajes:

– Los que lo usan y no necesitan hablar de eso. Esta suele ser la mayoría de los desarrolladores que utilizan tecnología dada.

– A quienes les guste y lo recomendarán si les preguntas.

– Los que lo aman y le están contando al mundo.

– A los que no les gusta y le recomendarán que lo evite si se lo pregunta.

– Los que lo odian y comparten públicamente su opinión.

Puedes dividir a los que odian / a los amantes en diferentes categorías:

– Pragmático: su opinión se basa en el conocimiento real de los beneficios o límites. Esta es una especie realmente rara.

– Ignorante: su opinión se basa en su conocimiento limitado. Ellos juzgan las tecnologías sin siquiera conocerlas lo suficientemente bien. ¡Esto es realmente peligroso!

– Hipster: siempre optan por tecnologías nuevas y brillantes más por el factor “genial” en lugar de que haya un beneficio real detrás de su elección. Este grupo puede ser muy ruidoso.

–

Entonces, mi recomendación es:

1. ¡No escuches a los demás! Y nunca escuche a las personas a las que no les pide su opinión a menos que sean expertos respetados en el campo dado. Haga su propia opinión y use lo que funcione para usted y no lo cambie porque alguien le está recomendando algo más o alguien le dice que su elección es obsoleta. No tenga malos sentimientos porque cree que su pila de tecnología no es lo suficientemente genial.

2. No sigas el bombo publicitario. Lo nuevo no siempre es mejor y, de hecho, el mundo está impulsado por tecnologías que existen desde hace décadas.

3. Elija tecnologías probadas. ¿Desea que su código funcione dentro de cinco años? No utilice tecnología que no exista durante dos o tres veces más de la vida útil esperada de su aplicación. Además, siempre elija tecnología con API / sintaxis estable y madura y con una gran comunidad.

4. Sea de mente abierta. Esté atento a las tendencias y las noticias, estudie y si algo le atrae, pruébelo.

5. Experimento. Hay proyectos de misión crítica y productos emblemáticos que no es una gran idea para experimentar, pero por lo general, también hay cosas más pequeñas en las que puede probar nuevas tecnologías. Por ejemplo, escribí uno de los sitios web de soporte para un producto usando tecnología completamente diferente solo para probarlo.

6. Use la herramienta adecuada para el trabajo correcto.

“Sobrevivir” es una palabra completamente incorrecta para usar. Su problema es que no se da cuenta de para qué están hechas estas nuevas tecnologías de software. Y en términos generales, están destinados a hacer lo que los frameworks e idiomas más antiguos hacen de manera más efectiva y, a veces, más fácilmente.

Por ejemplo, Swift. Es el nuevo lenguaje de programación de Apple para programadores iOS. Sin embargo, a la mayoría de los desarrolladores les ENCANTÓ Swift cuando se lanzó porque hizo todo lo que Objective-C hizo, pero más rápidamente y con menos líneas de código. (En serio, se parece más al código Python que al código C).

Otro ejemplo: DirectX 12 / Vulkan / Mantle / Metal. Sí, puse demasiados nombres de nuevas API y marcos aquí, pero todos ellos fueron creados para el mismo objetivo: renderizar gráficos de manera más eficiente en el nivel inferior. Esencialmente, son solo actualizaciones de DirectX 11 y OpenGL (Metal es la versión de Apple de OpenGL; Mantle fue el intento de AMD de una API de gráficos de bajo nivel).

Narasimhan dijo que “aprenda a un nivel superficial”. Lo diría de otra manera: mire las nuevas tecnologías superficialmente. Cada vez que salga un anuncio, preste atención a los hechos generales que mencionaron y traduzca diciendo “Oh, es solo una nueva versión de (inserte una API antigua)”. Swift: cree aplicaciones iOS en menos línea de código. “Genial, ahora puedo programar Objective-C en la sintaxis de Phyton”. Oculus Rift: vea sus juegos en 360 grados. “Bien, ahora no necesito 3 monitores curvos cuando tengo un millón de monitores en mi cara”.

Por cierto, 35 años como programador? Eso es muy largo. ¿Ya te has tomado vacaciones? Algunos programadores trabajan solo 5 años antes de renunciar (y luego intentan hacer su propia empresa).

Este es realmente un muy buen punto, y el hecho es que no podemos “sobrevivir”.

El 95% de los lenguajes de programación son realmente iguales: un bucle es un bucle, una matriz, una función. Algunas construcciones pueden ser más capaces, como mapas y tuplas, pero se pueden agregar a cualquier idioma fácilmente. Algunas construcciones están en debate, como las plantillas.

El verdadero “grueso” de la funcionalidad proviene de la infraestructura, en forma de sistemas operativos, servicios en la nube, bibliotecas de terceros, tiempos de ejecución, marcos, etc. Pero, de nuevo, un archivo es un archivo, una tabla de base de datos una tabla, incluso una funcionalidad específica Los gráficos similares y los mapas geográficos son funcionalmente equivalentes entre sí.

En todo caso, la multitud de variaciones hace que la vida sea más difícil para todos, los costos son más altos y la creatividad y el avance reales son más bajos. Deberíamos buscar el próximo concepto de hoja de cálculo, la próxima diversión de Tetris, el próximo análisis de imágenes médicas. No “pelear” sobre cómo escribir la misma funcionalidad de red social por centésima vez y qué idioma es superior.

Mirando hacia un futuro más inteligente …

Básicamente es la diferencia entre un desarrollador de C # / Java / C ++ frente a un ingeniero de software. Los desarrolladores centrados en el lenguaje (quiero decir, realmente centrado, solo usa ese lenguaje) son como tratar de empujar un bloque cuadrado en un agujero circular (y todos esos otros dichos como ese martillo. Creo que era, si tienes un martillo, todo es un clavo?

Un ingeniero comienza con el problema y descubre una solución genérica. Los pasos clave que deben seguirse y luego busca las herramientas y los idiomas que mejor se utilizan para construir cada parte. Supongo que por ingeniero quiero decir como un generalista o un desarrollador en forma de T: amplio conocimiento sobre muchos conceptos generales, sistemas, formas de resolver problemas; quizás muy muy bueno con unos pocos. Pero él / ella sabe lo suficiente como para evaluar los problemas y las diferentes opciones para resolver cada parte. También tienen la base (para aprender rápidamente lo que necesiten).

Según mi experiencia, la mayoría de los idiomas son 90% similares, su sintaxis es simplemente diferente. Hay algunos grupos de lenguajes que siguen diferentes paradigmas, como funcional frente a imperativo. Es más difícil hacer el cambio y llevará tiempo y algo de prueba y error, pero los buenos desarrolladores podrán resolverlo y mejorar con el tiempo.

Te diré mi verdad. No creo que sea posible sobrevivir en el contexto que describiste (y es un contexto demasiado real). Hay dos aspectos:

1. El ritmo del cambio: se introducen nuevos marcos y bibliotecas a una velocidad vertiginosa. Incluso una persona que esté dispuesta a aprender no sabrá en qué enfocarse. Cuando agrega el hecho de que ya puede estar trabajando largas horas en el trabajo y tener compromisos familiares u otros compromisos fuera del trabajo, cada hora que se dedica a lo “incorrecto” es una inversión que se arruinó. En mi larga carrera como profesional de bases de datos, traté de dominar los RDBMS como dBaseIII, DataEase, Powerbuilder. ¿Dónde están ellos hoy? Montón de basura de la historia.
2. Los reclutadores y los gerentes de contratación y las herramientas automatizadas que se utilizan cada vez más para examinar los currículums están equipados solo para reconocer las palabras clave y siglas correctas en un currículum. Entonces, por malo que sea que las herramientas que una persona dominó hace muchos años ahora están obsoletas, es peor que la persona no reciba “crédito” por haberlas dominado; lo que quiero decir con crédito es ser reconocido por la dedicación a aprender esa herramienta y la agilidad mental que demuestra la capacidad de aprender una amplia gama de herramientas en diversas plataformas. Por lo tanto, una persona con 20 años de experiencia solicitando un trabajo que requiere conocimiento de DBMS se considera inútil si no tiene los dbms específicos (y a veces incluso la versión específica) en su currículum.

Algunos de los encuestados a esta pregunta han dicho que existe una gran superposición entre varios marcos. Eso puede ser cierto. Intente convencer a una herramienta de escáner de currículum de eso o a un gerente de contratación que no lo sepa.

Estos factores en su conjunto significan que el mercado laboral está masivamente sesgado a favor de los candidatos más jóvenes. Por supuesto, el hecho de que se les pueda pagar menos también funciona a su favor.

He trabajado en la profesión de TI durante más de tres décadas. Estoy cansado de no ser respetado por la perspectiva y el juicio que adquirí durante tanto tiempo y por haber trabajado en muchas plataformas diferentes. Estoy cansado de tener que competir con personas que saben menos y no saben que saben menos.

Mirando hacia atrás, desearía haber pasado de la programación práctica a una posición aliada hace mucho tiempo.

No soy un desarrollador de software, pero mi experiencia personal puede ser interesante para cualquier persona no profesional que lea, por lo que compartiré de todos modos. Los profesionales pueden omitir esta publicación.

Antecedentes: en la escuela aprendí por primera vez Fortran, Pascal y ensamblaje y un poco más tarde aprendí Scheme y algunos C y C ++. En mi trabajo como ingeniero de automatización de diseño (para diseño personalizado y ASIC) incrementé los scripts de Perl y tcl, csh y bash y luego pasé por una fase en la que intenté aprender un nuevo lenguaje de programación cada año. Era fanático de la programación orientada a objetos y llegué a donde era bastante competente con Ruby, pero también intenté dominar Python, D, Clojure, Lua, Java y C #. Pero todo este tiempo, para mis proyectos personales, seguí usando Scheme (STklos and Chicken), enfatizando el uso de un enfoque orientado a objetos mediante el uso de tinyclos. Luego, hace unos cinco años, me enamoré de la orientación a objetos y convertí la mayoría de mis cosas a orientadas principalmente a la funcionalidad (si es que existe). Lo que noté fue que mi productividad se duplicó, tal vez incluso se triplicó y esto lleva a mi respuesta a la pregunta …

Mi comentario: si encuentras un lenguaje, un paradigma de programación o un marco que realmente disfrutas, creo que deberías llevarlo hasta el fondo y sentirte libre de ignorar el resto. Para mí, un enfoque principalmente funcional es mucho más productivo que el orientado a objetos, a pesar de lo tentador que resulta modelar mi software a partir de objetos del mundo real. Además, no se debe subestimar la productividad y el disfrute que proviene del dominio total de un idioma. Puede ser cierto que para algunas personas “aprender un nuevo lenguaje de programación es trivial, es solo una sintaxis …” pero para la mayoría de nosotros sospecho que hay un gran costo en aumentar un nuevo lenguaje y que la energía se gasta mejor en dominar lo que ya sabes. Hay dos advertencias: 1) hacer una encuesta profunda del campo antes de comprometerse con su idioma o marco de elección y 2) asegurarse de que la elección que haga sea pragmática, en el sentido de que puede hacer una carrera fuera de ella.

Hay mucho que se podría escribir. Pero deberá navegar por la sopa de letras tecnológica. La forma de hacerlo no es a través de “recopilar” habilidades. Es mediante el desarrollo de una comprensión aguda de los principios y las fuerzas de gobierno que subyacen a cualquier problema.

Esta es una era en la que la potencia informática ya no se duplica cada dos años. Entonces, el paralelismo y la concurrencia son habilitadores clave para la velocidad. Por otro lado, las velocidades de disco y de red están en alza. También es la era de grandes volúmenes de datos y aplicaciones móviles. Inevitablemente surgen tres cosas: escala, disponibilidad, complejidad. ¿Cómo los manejas? Hay una cuarta pieza clave: dar sentido a tantos datos.

Diría comenzar por ver cómo las personas han resuelto estos problemas en el pasado y cómo se abordan hoy. ¿Cómo se construyen e implementan las aplicaciones empresariales modernas? ¿Cómo se modelan y almacenan los datos? ¿Se utilizan bases de datos relacionales? ¿Se utilizan los almacenes de datos NoSQL? ¿Se usa el almacenamiento en caché? ¿Es un monolito o hay componentes o microservicios? ¿Cómo se comunican los componentes? Cómo se ingieren los datos en el sistema. ¿Hasta dónde puede escalar esta aplicación? ¿Cuán altamente disponible es la aplicación?

Ahora identifique cómo se abordaron estas preocupaciones, digamos 10–12 años atrás. ¿Cuáles son las diferencias entre entonces y ahora, y por qué necesitábamos cambiar la forma en que lo hicimos? ¿Qué problemas no tuvimos en absoluto que necesitamos abordar hoy? Comprenda que muchas soluciones a estos problemas ya no se cortan y secan, sino que se equilibran en compensaciones que podrían ajustarse. ¿Comprender cómo las diferentes herramientas priorizan estas compensaciones? Eso influiría en sus decisiones de elegir una herramienta en particular: un lenguaje de programación, una base de datos o una cola de mensajes, o algún componente de infraestructura de la aplicación que está escribiendo, o más apropiadamente, el ensamblaje.

Para construir esta perspectiva, deberá escribir código para construir sistemas y también leer literatura contemporánea sobre estos temas. Tendrá que hacer la mayor parte de la curación usted mismo, porque todavía es temprano para este paradigma de autoeducación de software. Los mejores libros pueden estar empezando a publicarse. Por lo tanto, este podría ser un muy buen momento para tomar la iniciativa y educarse.

No siento tal velocidad. Una modesta curva de aprendizaje, como hacer un curso en línea cada 3 meses, hacer algunos ejercicios en el tiempo libre, incluso las contribuciones de código abierto más adelante, hacer un esfuerzo constante durante años vale la pena y, por supuesto, mezclar la experiencia laboral con el hobby. Sin forzarme, excepto raramente, en los últimos años, por ejemplo, llegué bastante lejos en la programación funcional, Scala, programación reactiva con Akka y gran parte del Java del lado del servidor o debería decir ecosistemas JVM, ya sea Spring o Lightbend en microservicios. años. No siento que las cosas cambien dramáticamente o rápidamente. Por el contrario, las ideas para FP se originan como hace 50 años y todavía era una adopción lenta en estos días. Trabajar y pensar para que te entiendas y disfrutes conduce con el tiempo a una gran comprensión y luego puedes correlacionarlos en dominios de programación donde tienes menos experiencia. No hay muchas formas de rueda y patrones como FP, programación reactiva o sistemas reactivos, y muchos otros se aplican ampliamente, tanto en el lado del cliente como en el servidor y quizás incluso en dispositivos (programación integrada). Hay muchas cosas que aprender, estoy de acuerdo. Necesitamos elegir un equilibrio entre generalidad y especialidad. Pero la pasión es el ingrediente más importante. Encontré bastante fácil contribuir a proyectos como Apache Kafka y Lightbend Akka, y podría hacer aún más, y soy bastante promedio. Las cosas no son complicadas, no se mueven tan rápido, deben entenderse para su propósito más profundo, no solo para realizar una tarea o algunas. Por ejemplo HTTP, ¿verdad? ¿Cuántos leen la tesis de doctorado de Roy Fielding? Está incompleto pero de todos modos. ¿O los documentos de Google que están financiando muchos de los algoritmos de Big Data hoy en día? Se necesita una mezcla de práctica y teórica. Hay cientos de cursos en línea. Necesitamos elegir nuestra dirección, eso también depende de los trabajos disponibles, pero también podemos trabajar un poco en nuestro tiempo para prepararnos para los próximos. ¡Disfrutar!

¿Eso es lo que encuentras agotador? Eso es lo divertido. Realmente todo tiende a ser variaciones sobre los mismos fundamentos básicos. Una vez que tenga una comprensión firme de los fundamentos, no pasará mucho tiempo para familiarizarse con nuevos lenguajes, bibliotecas o marcos. Hay muchas implementaciones complejas en estos días, pero reducir todo a elementos simples es mucho de lo que hacemos para otras personas durante todo el día.

Los drenajes más grandes son todos los procedimientos y políticas BS. ¿Cuántas veces cada uno de nosotros tiene que pasar por un entrenamiento por una razón u otra? A menudo, esa capacitación es concebida por una persona no técnica que ni siquiera entiende el tema y no nos está enseñando nada más que faltarle el respeto a la capacitación. Las certificaciones para hacer esencialmente lo correcto, o conocer los conceptos básicos. Esas cosas envejecen y agotan las horas de nuestros días.

El proceso es otro. Hacer que una persona no técnica toque el tambor de un proceso y exija artefactos que puedan recolectar y medir no es productivo y agotador. Si tengo que asistir a reuniones, escribir historias y asignar puntos a algo, comienza a sumar el mismo nivel de esfuerzo que simplemente hacerlo. Claro, el primer ministro tiene gráficos y puede decirle todo, pero un buen líder técnico también podría tenerlo mientras mantiene al equipo productivo.

En mi trabajo de desarrollo web, examinamos las necesidades y los objetivos de cada nuevo proyecto en un vacío tecnológico, sin dejar de considerar nuestro conocimiento desarrollado en ciertas áreas, y luego experimentamos con un conjunto de herramientas que creemos que es adecuado para el trabajo. Y si un proyecto existente y activo es antiguo y se está quedando atrás, examinamos los medios más eficientes para integrar nueva tecnología mientras conservamos la funcionalidad principal.

Supongo que es una cuestión de preferencia y edad temprana, pero me encanta este proceso. Es imposible ser complaciente, imposible “saberlo todo”. Y la habilidad de adaptarse rápidamente a las nuevas pilas es en sí misma algo emocionante para crecer.

Me gusta sobrevivir con estilo. Al diablo con la rutina.

El problema es que hay más “HERRAMIENTAS” para hacer “HERRAMIENTAS” para todos los demás. Esto ha provocado una explosión de nuevos marcos de los que me he alejado. Admito que esto me ha costado en entrevistas de trabajo, pero tienes que elegir tu veneno. Es mucho más fácil crear su propio lenguaje / marcos informáticos de lo que solía ser. Esto ha contaminado el panorama para el desarrollo de software en mi humilde opinión.

Y cuando sale una nueva herramienta / lenguaje / marco, la experiencia de todos ahora es “cero”. Entonces, si trabaja para un lugar que le permite “construir su currículum” en estos nuevos marcos, una vez que sea competente, pagará todo el dinero porque es un “experto” en estas nuevas herramientas / lenguaje / marco (s) y nadie más ha tenido tiempo de recogerlos. No estoy abogando por este comportamiento. Esta es la razón por la cual hay tanta “rotación” en la industria del desarrollo de software con desarrolladores que se mueven y compañías que hacen declaraciones falsas como: “Oye, no podemos encontrar a nadie con las habilidades adecuadas para hacer este trabajo”. Claro que no puedes.

E incluso si “TIENES” la oportunidad de probar ese nuevo lenguaje brillante / marco / fregadero de cocina o lo que sea … descubres que es solo una compensación que hace que “algunas” partes de tu desarrollo de software sean muy fáciles, pero totalmente falla en otros aspectos que solían funcionar “GENIAL” utilizando conjuntos de herramientas maduros. Así que terminas gastando más tiempo escribiendo código para compensar las deficiencias de las nuevas herramientas.

Despotricar sobre

Feliz Navidad !!!!

No tiene que aprender todas las nuevas tecnologías. Para mí, mantenerse actualizado significa que usted sabe cuál es la tecnología, algunos de sus usos y características distintivas.

¿Cómo sobrevivirlo?

Aprende un poco todos los días. No gastes demasiado tiempo en ello. Solo tome 15 minutos al día para hojear los mejores resultados del subreddit de r / programación [1] o Hackernews [2].

Conviértase en un hábito divertido con sus colegas mantenerse siempre al tanto de las cosas.

Artículos relacionados:
Los verdaderos programadores nunca dejan de aprender

Sobrevivir al aprendizaje permanente como programador

Notas al pie

[1] programación • r / programación

[2] Noticias Hacker