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

52

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?

Gyurme
fuente
Creo que la tecnología con la que trabaja al principio de su carrera es (mucho) más importante que si está realizando trabajos de mantenimiento o un nuevo desarrollo. Si realizó un nuevo desarrollo en un idioma interno o en un idioma antiguo con poca demanda, probablemente sería mucho peor que no hacer un nuevo desarrollo en un idioma de mayor demanda.
Stoj
66
Ciertamente construye carácter.
quant_dev

Respuestas:

70

¿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?

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).

pdr
fuente
25
+1 Hacer mantenimiento hace que alguien sea un mejor desarrollo.
8
+1 Hacer el mantenimiento por su cuenta o en el proyecto de otra persona lo obliga a apreciar y aprender de las consecuencias de las decisiones que se tomaron anteriormente en el proyecto.
Ophidian
Si bien tener experiencia con el mantenimiento es ideal, mi opinión es que lo que se aprende al desarrollar un proyecto exitoso> lo que se puede aprender al mantener el proyecto de otra persona. El mantenimiento puede enseñarle qué no hacer, pero como Jason Fried dijo mejor: aprender del fracaso puede decirle qué no hacer la próxima vez, pero eso no le dice qué hacer la próxima vez .
Korey Hinton
@KoreyHinton: Estoy seguro de que Jason Fried, un emprendedor exitoso, cree lo que está diciendo, en términos de ser emprendedor. Yo diría que a) en realidad no sabe qué podría estar haciendo mejor, porque las cosas le han ido muy bien, b) respaldar a DHH y Rails fue el 90% del éxito de 37 señales y esa es una apuesta que no pagaría 90% de las veces, y c) incluso Jason probablemente no afirmaría que los consejos sobre ser emprendedor se traducen necesariamente en aprender de tener que armar software mal escrito.
pdr
@pdr Tienes razón, las dos cosas no se traducen exactamente. Como todavía soy estudiante, hablé desde la opinión más que desde la experiencia. Supongo que personalmente prefiero escribir código nuevo en lugar de mantener el código escrito por otros, pero parece que el mantenimiento es algo que voy a hacer mucho en este campo.
Korey Hinton
13

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:

  • ¿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 otro lugar, eso limitaría sus futuras oportunidades profesionales (pero también lo haría desarrollar un nuevo software para un sistema / plataforma / tecnología que no se usa ampliamente).
  • ¿Cómo te equipa tu trabajo actual para el trabajo que quieres hacer en el futuro? El trabajo de mantenimiento, como usted señaló, es importante y siempre estará presente. No hay nada de malo en tener una carrera enfocada en este tipo de programación; siempre habrá muchas posibilidades para los encargados del mantenimiento del sistema. Pero tal vez no es lo que quieres hacer. Es preocupante si su trabajo actual no lo está preparando para lo que le interesa.

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

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

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
+1 En la amplia experiencia . Después de haber realizado 15 años de desarrollo y el último año en mantenimiento, puedo decir por experiencia personal que he tocado muchos más lenguajes y plataformas de los que habría permanecido en desarrollo. Como profesional independiente, tener una gran amplitud (generalista) me da una sensación reconfortante de que no es probable que se quede sin trabajo pronto. Quizás esto sea a expensas de la posibilidad de ganar más dinero cuando se especialice (especialista), pero prefiero reducir el riesgo.
Lieven Keersmaekers
2

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

Más a menudo que no - SÍ, suponiendo:

  • esa 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.
  • ese "mantenedor dedicado" (ver EDITAR, más adelante) significa que no codifica para mantener y codifica cosas nuevas, pero que casi siempre codifica para mantener o incluso trabajar en un proyecto en modo de mantenimiento: no se requieren características nuevas, menos cambios en el código para corregir el error.

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.

¿Tienen razón otros programadores para evitar roles como estos?

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.

¿Hacer esta línea de trabajo lo encerra en 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 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".

LAFK dice reinstalar a Mónica
fuente
@ dan1111, ¿qué partes no lo son? A pesar de ser un duplicado, con mucho gusto mejoraré mi respuesta.
LAFK dice Reinstate Monica
Gracias Dan. Ampliaré un poco mi respuesta para resaltar partes que creo que contienen la respuesta a tu comentario.
LAFK dice Reinstate Monica el
+1 por el trabajo adicional en la respuesta. Particularmente, explicar el alcance de su propia experiencia es útil para establecer la credibilidad de la respuesta.
"Las personas que mantienen software ... rara vez pueden conectar una nueva biblioteca o base de datos y pasar unos días descubriendo cómo funciona". Esa no es realmente mi experiencia. Los programadores de mantenimiento deben ser buenos para sumergirse en algo desconocido y comprender rápidamente su esencia (ya sea un programa o una biblioteca). Al menos, ese es el caso si mantiene cosas diferentes; si mantiene lo mismo todo el tiempo, durante años, entonces los aspectos negativos que vienen con eso no son causados ​​por el "mantenimiento", son causados ​​por trabajar en lo mismo durante demasiado tiempo (independientemente de dónde se encuentre) El ciclo de vida).
user1172763
Hola @ user1172763. Debo decir que su definición de mantenimiento es bastante extraordinaria. Creo que la parte que he agregado para Dan aborda casos de mantenimiento más interesantes, como el suyo. Sin embargo, no creo que sea un mantenimiento estándar. Solo para verificar: ¿el motivo del voto negativo es porque su experiencia no coincide con mi respuesta? Luego, indique sus fuentes, como dije en la mía, para que otros puedan leer y decidir.
LAFK dice Reinstate Monica el
1

Tendría que representarme a mí mismo como bastante joven en el nivel de habilidad ya que no tendría la profundidad del nivel de conocimiento requerido de una persona con tres años de experiencia centrada 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 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.

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

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!

ozz
fuente
0

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.

Kosta Kontos
fuente