¿El trabajo de mantenimiento dedicado obstaculiza la carrera de un programador? [cerrado]

  

¿Los roles de programación de mantenimiento dedicados terminan siendo perjudiciales para una carrera temprana? ¿Es correcto que otros programadores eviten roles como estos? ¿Hacer esta línea de trabajo lo obliga a hacer tareas similares a menos que esté preparado para comenzar de nuevo como junior?

Primero, debes saber que eres considerado un junior por bastante tiempo. Es posible que obtengas promociones arbitrarias porque eres bueno y esta es la única forma de darte un aumento de sueldo decente, pero aún serás considerado un junior cuando vayas a tu próximo trabajo.

Segundo, 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 de zonas verdes, es posible que tenga preguntas pero, durante los primeros años, sinceramente lo espero.

Por otro lado, si estoy contratando a alguien que NUNCA ha trabajado en mantenimiento, seré más sospechoso. He tenido muchos candidatos para trabajos que han pasado sus primeros 4 años saltándose 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 que pretendo seguir, no me importa si USTED va a mantener el código, me importa que sepa cómo dejarlo para futuros desarrolladores.

Estos otros programadores que mencionas, que evitan trabajos como estos, generalmente los evitan porque son menos divertidos, no porque obstaculice su carrera.

Finalmente, debe saber que un porcentaje muy grande (supongo que aproximadamente el 80%) de los trabajos de desarrollo de software son más del 50% de mantenimiento.

Entonces, para cortar todo eso y responder a tu pregunta: No, no creo que vaya a obstaculizar tu carrera. A menos que te quedes allí demasiado tiempo. La regla general es que "una vez que empiezas a sentir que obtienes el mismo año de experiencia cada año, es hora de ir". Si te sientes, cada año, como si fueras un mejor desarrollador que el año pasado, estás bien (y eso va para mí, 20 años en mi carrera, tanto como tú).

En cualquier trabajo, la experiencia que obtiene es específica a lo que está haciendo, lo que limita su gama 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:

• ¿Qué tan extendidas están las tecnologías específicas con las que está trabajando? Si mantiene algo que está obsoleto y que rara vez se usa en otros lugares, eso limitaría sus oportunidades profesionales futuras (pero también lo haría desarrollar un nuevo software para un sistema / plataforma / tecnología que no se utiliza ampliamente).
• ¿Cómo le equipa su trabajo actual para el trabajo que desea hacer en el futuro? El trabajo de mantenimiento, como usted señaló, es importante y siempre estará disponible. No hay nada de malo en tener una carrera centrada en este tipo de programación; Siempre habrá muchas posibilidades para los mantenedores de sistemas. Pero tal vez no es lo que tú quieres hacer. Es una preocupación si su trabajo actual no lo está preparando para lo que le interesa.

Sin embargo, no estaría muy preocupado. Una cosa que dices es:

  

He ganado mucha amplitud en términos de las áreas que he tocado   pero no mucha profundidad.

No pienses en esto como un problema, ya que puede ser usado en tu beneficio. Tener una amplia experiencia significa que hay una amplia gama de cosas a las que puede decir "sí, lo he hecho". Muchos trabajos piden experiencia en diferentes tecnologías y tareas. Es probable que tenga una ventaja sobre un desarrollador que tenga una experiencia muy profunda en una tecnología.

Además, muchos trabajos implican una combinación de mantenimiento y nuevo desarrollo. Si quisiera hacer más desarrollos nuevos, podría usar su experiencia de mantenimiento existente para hacer la transición a un rol mixto que le dará más experiencia en desarrollo.

En conclusión, tu currículum probablemente sea mejor de lo que crees. 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.

  

¿Los roles de programación de mantenimiento dedicados terminan siendo perjudiciales para una carrera temprana?

Más a menudo que no, sí, asumiendo:

• que carrera aquí significa experiencia en muchas habilidades técnicas diferentes.
• que pasas más de X años allí, donde X es suficiente para "establecer" tus formas de pensar.
• que no hagas nada a un lado.
• que "mantenedor dedicado" (ver EDITAR, a continuación) significa que no codifica para mantener así como codifica cosas nuevas, sino que casi siempre codifica para mantener o incluso trabajar en un proyecto en el modo de mantenimiento: no hay nuevas funciones, se requieren menos cambios en el código para corregir el error.

Esto no significa que sea siempre el caso.

Las personas que mantienen software rara vez son alentadas (vea EDITAR, a continuación) para investigar, rara vez pueden conectarse a 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, "moldea" 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 dice explícitamente "menos cambios en el código = mejor", a pesar de las cosas malas que esto puede traer.

  

¿Son correctos otros programadores para evitar roles como estos?

Conozco muy buenos mantenedores a quienes les gusta su trabajo y no querría solicitar otra cosa precisamente porque es cómodo donde están. No a todos les gusta aprender cosas nuevas de vez en cuando. Entonces, evítalo o búsquelo según sus preferencias.

  

¿Hacer esta línea de trabajo lo obliga a hacer tareas similares a menos que esté preparado para comenzar de nuevo como junior?

Más a menudo que no, sí. Porque ya tienes experiencia haciendo eso, porque ya "conoces las cuerdas", etc. Pero el cambio es definitivamente posible y puede suceder sin solicitar una posición junior. Ya empezaste a hacer las cosas a un lado, ¡sigue así! Realmente vale la pena y puede reducir la "brecha de habilidades" que notó.

EDITAR: Dan ha señalado (muy acertadamente), que las tareas de mantenimiento a menudo se pueden realizar CON la investigación. Eso es verdad. He cambiado la respuesta anterior en dos lugares para abordar mejor esto.

Esas tareas PODRÍAN HACERSE de esta manera y si son: ¡genial! Sin embargo, AFAIK los mantenedores más DEDICADOS de los sistemas LEGACY tienen políticas o expectativas de gestión y plazos que, una vez más, la mayoría de las veces , los obligan a resolver el problema con los menos cambios posibles. A menudo, la presión es lo suficientemente alta como para que incluso si puedes hacerlo de esta manera, es posible que no quieras hacerlo. Especialmente si no es TU código: sin la teoría (según Ryle y Naur) detrás de él, te arriesgas a dañar más de lo que arreglas.

Sin embargo, debe tenerse en cuenta: no tengo datos globales sólidos, 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 los mantenedores y yo sabemos que las personas que trabajan como mantenedores dedicados . No solo las personas que codifican cosas nuevas, sino también las que se encargan de mantener un proyecto: mantenedores dedicados, cuyo único trabajo es hacer errores y parches, y ni siquiera una característica nueva, porque es un proyecto antiguo y ahora está solo en "modo de mantenimiento".

  

Tendría que representarme a mí mismo como bastante inferior en el nivel de habilidad, ya que no tendría el nivel de conocimiento requerido de una persona con tres años de experiencia enfocada en un camino particular en el desarrollo de características

Correcto. No podría decir "3 años de experiencia diseñando sistemas desde cero con X, Y y Z", tendría que decir "3 años de experiencia MANTENIMIENTO desde cero con X, Y y Z "a menos que quieras mentir correctamente en tu CV.

  

Siento que si fuera a entrevistarme en otras compañías para escapar del trabajo de mantenimiento, tendría que representarme a mí mismo como bastante subalterno en el nivel de habilidad, ya que no tendría el nivel de conocimiento necesario para una persona con tres años de experiencia enfocada en un camino particular en el desarrollo de características sería

Si quieres decir "Yo diseño y construyo sistemas desde cero", entonces sí, deberías clasificarte como junior.

Lo que es bastante común en TI (y no estoy diciendo que esto sea lo que estás haciendo) es que la gente asuma que, debido a que han estado trabajando durante X años, tienen X años de experiencia y después de {número indeterminado de años} deben considerarse un desarrollador senior {Widget}.

Ahora, no me malinterpretes, no hay nada malo con el trabajo de mantenimiento, todos tienen que hacerlo en algún momento u otro, pero te has dado cuenta de que estar estancado haciendo eso durante demasiado tiempo probablemente lo hará difícil. para que te alejes de ese papel en el futuro. Esto a menudo va de la mano con estar "atascado", no aprender nuevas tecnologías / herramientas / métodos.

Idealmente, desea una combinación de "nuevo" trabajo de sistema y trabajo heredado.

En una nota positiva, es probable que haya visto muchas arquitecturas diferentes (buenas y malas), diferentes enfoques, cómo las malas decisiones pueden hacer que los programadores heredados trabajen mucho más en el futuro. Estos son todos los aspectos positivos que se pueden acentuar.

¡Buena suerte!

Mirando esto desde un ángulo diferente, creo que venderse como un experto en mantenimiento es una oportunidad comercializable.

Como propietario de una compañía de software que tiene múltiples proyectos en movimiento, uno de los riesgos más grandes que tengo que minimizar es el de los desarrolladores que se embarcan, y el mantenimiento posterior de su código.

Asumiendo que eres capaz de sentirte apasionado por el trabajo de mantenimiento (que creo que sería el caso, ya que estás preparado para publicar un blog sobre tu experiencia), si vienes a ofrecerme tus servicios como gurú de mantenimiento, garantizando para pulir todos los diversos proyectos de mis desarrolladores refactorizando, optimizando y documentando su código para su mantenimiento a largo plazo, y usted tuvo un historial para respaldar su garantía, lo contrataría en un instante.

Mi consejo sería que pruebes esto. Posicionate como un experto en mantenimiento y cultiva tu blog. Usted puede estar en algo.