La mayor parte de mi trabajo en los últimos tres años se ha centrado principalmente en el mantenimiento de sistemas heredados que debían repararse o la renovación ocasional antes de ser vendidos nuevamente.
Entiendo el papel crítico que los programadores de mantenimiento dedicados tienen que desempeñar en empresas con una gran cantidad de proyectos y desarrolladores limitados disponibles.
Pero cuando juzgo el progreso de mi carrera actual y miro a mis compañeros; contratistas y desarrolladores corporativos por igual; Siento que me estoy quedando muy atrás ya que he ganado una gran amplitud en términos de las áreas que he tocado pero no mucha profundidad. Comencé a abordar esto al comenzar un blog, trabajar en mis propios pequeños proyectos de git-hub y reprogramar mi vida para tener tiempo para hacer codificación personal después del trabajo de forma regular.
Siento que si me entrevistara en otras compañías para escapar del trabajo de mantenimiento, tendría que representarme a mí mismo como un nivel bastante bajo de habilidades, ya que no tendría la profundidad del nivel de conocimiento requerido de una persona con tres años de experiencia centrada en un particular camino en el desarrollo de características lo haría. Por lo tanto, la mitad de mi experiencia laboral actual no contaría para nada a largo plazo.
Pero esto me lleva a mis preguntas principales, disculpas si esto se siente demasiado centrado en mi dilema personal:
¿Los roles de programación de mantenimiento dedicados terminan siendo perjudiciales para una carrera temprana? ¿Tienen razón otros programadores para evitar roles como estos? ¿Hacer esta línea de trabajo lo encerra en tareas similares a menos que esté preparado para comenzar de nuevo como junior?
fuente
Respuestas:
En primer lugar, debes saber que te consideran junior durante bastante tiempo. Es posible que reciba promociones arbitrarias porque es bueno y esta es la única forma de darle un salario decente, pero aún así se lo considerará un junior mientras se dirige a su próximo trabajo.
En segundo lugar, si estoy contratando a alguien con 2-4 años de experiencia, realmente no me importa si su trabajo fue puramente de mantenimiento. Si ha pasado 10 años en mantenimiento y estoy contratando para un proyecto greenfields, puedo tener preguntas pero, durante los primeros años, honestamente lo espero.
Por otro lado, si estoy contratando a alguien que NUNCA ha trabajado en mantenimiento, voy a ser más sospechoso. He tenido muchos candidatos para trabajos que han pasado sus primeros 4 años saltando de un trabajo "bueno" a otro y cada uno no ha aprendido nada sobre lo que hace que el código sea mantenible. Y, no se equivoque, si estoy contratando para un proyecto greenfields con el que pretendo mantenerme, no me importa si USTED va a mantener el código, me importa que sepa cómo dejarlo para que los desarrolladores futuros puedan mantenerlo.
Estos otros programadores que mencionas, que evitan trabajos como estos, generalmente los evitan porque son menos divertidos, no porque obstaculicen su carrera.
Finalmente, debe saber que un porcentaje muy grande (supongo conservadoramente alrededor del 80%) de los trabajos de desarrollo de software son más del 50% de mantenimiento.
Entonces, para cortar todo eso y responder a su pregunta: No, no creo que vaya a obstaculizar su carrera. A menos que te quedes allí demasiado tiempo. La regla general común es "una vez que empiezas a sentir que estás obteniendo el mismo año de experiencia cada año, es hora de irse". Si siente que, cada año, es un mejor desarrollador que el año pasado, está bien (y eso va para mí, 20 años en mi carrera, tanto como usted).
fuente
En cualquier trabajo, la experiencia que obtiene es específica de lo que está haciendo, lo que limita su rango de posibilidades al solicitar otros trabajos basados en esa experiencia. No es específico para el mantenimiento. Creo que otras preguntas son más relevantes que si algo es mantenimiento o desarrollo de software nuevo:
Sin embargo, no estaría demasiado preocupado. Una cosa que dices es:
No piense en esto como un problema, ya que puede usarse para su ventaja. Tener una amplia experiencia significa que hay una amplia gama de cosas a las que puede decir "sí, lo he hecho". Muchos trabajos requieren experiencia en diferentes tecnologías y tareas. Es probable que tenga una ventaja sobre un desarrollador que tiene una experiencia muy profunda en una tecnología.
Además, muchos trabajos implican una mezcla de mantenimiento y nuevos desarrollos. Si desea realizar más nuevos desarrollos, puede utilizar su experiencia de mantenimiento existente para hacer la transición a un rol mixto que le brindará más experiencia de desarrollo.
En conclusión, su currículum es probablemente mejor de lo que cree. Mucho de esto se reducirá a lo bien que analice las fortalezas de su experiencia, y luego comunique esas fortalezas en el proceso de solicitud y entrevista.
fuente
Más a menudo que no - SÍ, suponiendo:
Esto no significa que siempre sea así.
Raramente se alienta a las personas que mantienen el software (ver EDITAR a continuación) para que investiguen, rara vez pueden conectar una nueva biblioteca o base de datos y pasar unos días descubriendo cómo funciona. Es (generalmente) un trabajo estable que requiere cambios mínimos en la base de código existente y, por lo tanto, "da forma" a la forma en que aborda los problemas más adelante. Puedo nombrar algunas compañías que tienen una política para mantener el software que establece explícitamente "menos cambios en el código = mejor", a pesar de las cosas malas que esto puede traer.
Conozco muy buenos mantenedores a quienes les gusta su trabajo y no quieren solicitar otra cosa precisamente porque es cómodo donde están. No a todos les gusta aprender cosas nuevas de vez en cuando. Por lo tanto, evítelo o búsquelo según sus preferencias.
Más a menudo que no - SÍ. Porque ya tienes experiencia haciendo eso, porque ya "conoces las cuerdas", etc. Pero el cambio definitivamente es posible y puede suceder sin solicitar un puesto junior. Ya empezaste a hacer las cosas a un lado, ¡sigue así! En realidad, eso es muy valioso y puede reducir la "brecha de habilidades" que notó.
EDITAR: Dan ha señalado (con mucha razón) que las tareas de mantenimiento a menudo se pueden hacer CON investigación. Eso es verdad. He cambiado la respuesta anterior en dos lugares para abordar mejor esto.
Tales tareas seguramente PODRÍAN hacerse de esta manera y si lo son, ¡genial! Sin embargo, AFAIK, la mayoría de los mantenedores DEDICADOS de los sistemas LEGACY tienen políticas o expectativas de gestión y plazos que, nuevamente, la mayoría de las veces , los obligan a resolver el problema con el menor cambio posible. A menudo, la presión es lo suficientemente alta que, incluso si puede hacerlo de esta manera, es posible que no desee hacerlo. Especialmente si no es SU código: sin la teoría (según Ryle y Naur) detrás de él, corre el riesgo de dañar más de lo que arregla.
Sin embargo, debe tenerse en cuenta: no tengo datos globales duros, hablo desde mi propia experiencia: trabajé en una situación como OP, recluté personas con 4 a 10 años de experiencia como mantenedores, hablé con muchos mantenedores y yo Conocer personas que trabajan como mantenedores dedicados . No solo las personas que codifican cosas nuevas sino que también codifican para mantener un proyecto: mantenedores dedicados, cuyo único trabajo es hacer errores y parches y ni siquiera una nueva característica, porque es un proyecto antiguo y ahora solo está en "modo de mantenimiento".
fuente
Correcto. No podría decir "3 años de experiencia diseñando sistemas desde cero usando X, Y y Z", tendría que decir "3 años de experiencia MANTENIENDO sistemas desde cero usando X, Y y Z" a menos que desee a la derecha miente en tu CV.
Si quieres decir "diseño y construyo sistemas desde cero", entonces sí, tendrías que clasificarte como junior.
Lo que es bastante común en TI (y no digo que esto sea lo que está haciendo) es que las personas asuman que porque han estado trabajando durante X años, tienen X años de experiencia y después de {número indeterminado de años} debe considerarse un desarrollador Senior {Widget}.
Ahora, no me malinterpreten, no hay nada de malo en el trabajo de mantenimiento, todos tienen que hacerlo en algún momento u otro, pero de lo que se han dado cuenta es que estar atrapado haciendo eso durante demasiado tiempo probablemente lo dificultará. alejarse de ese papel en el futuro. Esto a menudo va de la mano con estar "atascado" y no aprender nuevas tecnologías / herramientas / métodos.
Idealmente, desea una combinación de "nuevo" trabajo del sistema y trabajo heredado.
En una nota positiva, presumiblemente has visto muchas arquitecturas diferentes (buenas y malas), diferentes enfoques, cómo las malas decisiones pueden hacer que los programadores heredados trabajen mucho más tarde. Todos estos son aspectos positivos que pueden acentuarse.
¡Buena suerte!
fuente
Mirando esto desde un ángulo diferente, creo que venderte como un experto en mantenimiento es una oportunidad comercial.
Como propietario de una compañía de software que tiene múltiples proyectos en marcha, uno de los mayores riesgos que tengo que minimizar es el de los desarrolladores que abandonan el sistema y el mantenimiento posterior de su código.
Asumiendo que eres capaz de apasionarte por el trabajo de mantenimiento (lo cual supongo que es el caso, ya que estás preparado para bloguear sobre tu experiencia), si vienes a mí ofreciendo tus servicios como gurú de mantenimiento, garantizando pulir todo de los diversos proyectos de mis desarrolladores refactorizando, optimizando y documentando su código para una mantenibilidad a largo plazo, y tenía un historial para respaldar su garantía, lo contrataría en un instante.
Mi consejo sería intentarlo adecuadamente. Posicione como un experto en mantenimiento y cultive su blog. Puede que estés en algo.
fuente