Despedido por tercera vez de un trabajo de desarrollo de software. ¿Qué hacer?

Pasé mucho tiempo refactorizando y tratando de eliminar la deuda técnica. Recibí una advertencia verbal por bajo rendimiento antes de irme de vacaciones.

Parece que aquí estabas trabajando en algo que no se pidió. Esto es generalmente muy malo, y puede llevar a la terminación. Si crees que el proyecto necesita ser refactorizado, y confío en que así sea, debes _venderlo a la dirección _antes de poder hacerlo. Si lo hubieras hecho, supongo que la dirección habría actuado de forma diferente.

Puede que te hayas dicho a ti mismo que no puedes completar tu tarea sin que el código esté limpio. La verdad es que el código de la mayoría de las empresas no lo está. Trabajan con el legado, tratan de seguir adelante con lo que tienen…

Me pusieron a trabajar con una tecnología no relacionada con lo que firmé

…y casi todos ellos ocultarán el legado detrás de nuevas tecnologías más atractivas al entrevistar.

No creo que esto sea en sí mismo una señal de que debas cambiar de carrera. Pensaría que no tienes aversión a la ingeniería de software cuando se hace bien. Pero la ingeniería en una empresa es siempre una cuestión de tratar con software hecho mal, con la gestión impulsando hacia adelante. Si quieres durar en una compañía, debes estar listo para aceptar esto.

Actualización : Ya que ha editado su pregunta con detalles más relevantes sobre cómo y por qué fue despedido, necesito proporcionar una respuesta actualizada.

Tanto en el caso 2 como en el 3 sus empleadores tenían grandes expectativas sobre su capacidad de adaptarse a nuevas cosas basadas en su experiencia. En todos los lugares donde trabajé, esto sería insuficiente para motivar el despido de alguien, pero estoy dispuesto a admitir que en algunas culturas de empresa el capital humano no se valora mucho. Esto es una pena y un error estratégico; pero esta es otra historia.

Supongo que deberías leer otras respuestas ya que te proporcionan múltiples salidas creativas ahora. Aquí está lo que considero un consejo valioso:

1. Introspección
2. Reconstruir la confianza… Si elige trabajar como desarrollador de nuevo, elija su gestión de forma inteligente. Recorte sus expectativas salariales si está absolutamente seguro.

Personalmente prefiero las pequeñas empresas, su gestión tiende a ser más humana.

Hoy me han despedido de una empresa de software .. por tercera vez en un año y medio. No hace falta decir que siento que he tocado fondo y que es imposible salir sin cambiar de carrera. ¿Debería cambiar de carrera? ¿Es posible encontrar un trabajo ahora?

Sip, eso es bastante malo. Pero recuerda que no estabas seguro de que nadie te contrataría después de haber sido despedido antes - sin embargo, terminaste con este tercer trabajo.

Creo que debes mirar hacia adentro y determinar por ti mismo por qué está sucediendo esto.

No culpes a la “mala gestión” aquí. Algo está pasando en cada caso que resultó en un pobre desempeño de tu parte. En otras preguntas mencionó que fue despedido por no hacer suficientes preguntas y por no realizar un trabajo de nivel superior. Esperemos que haya cosas que puedas aprender de todo eso.

Puede ser que estés eligiendo mal los trabajos y/o los gerentes. Puede ser que no hayas aprendido a trabajar duro, a concentrarte en lo que es importante, y a desempeñarte bien a pesar de los problemas en el trabajo. Puede ser que estés aspirando a un puesto de nivel demasiado alto y estés más preparado para un trabajo de nivel inferior. O podría ser simplemente que no estás bien adaptado para este tipo de trabajo en absoluto.

Dedica algo de tiempo a la introspección. Intente llegar a una conclusión antes de actuar. Es probable que no puedas permitirte cometer el mismo error de nuevo.

Podrías considerar tomar una puñalada en un trabajo temporal. Esos podrían ser trabajos más fáciles de conseguir en tu situación. Tal vez pueda motivarse para rendir bien cuando los proyectos son pequeños y de tiempo limitado. Tu experiencia pasada parece sugerir que podrías.

Estoy en mis 30 años sin un lugar de descanso, sin familia alrededor y sin muchos amigos.

Eso es algo en lo que querrás trabajar independientemente de tus problemas laborales. Todos necesitamos amigos. Y un buen grupo de apoyo te ayudará cuando tengas problemas en el trabajo.

Sigue intentando ser amistoso y hacer más amigos. Únete a un club. Socializa con gente del trabajo. Al menos inténtelo.

Understand why you’re getting fired

Lo has dicho tú mismo. Te estás centrando en reescribir, cuando no es eso lo que estás ahí para hacer. Tienes un realmente mal caso de síndrome de No Inventado Aquí. En lo que respecta a la gestión, el problema parece ser si estás preparado para hacer lo que te dice tu jefe y hacer tu trabajo, o si vas a jugar con las cosas que crees que te gustaría hacer. Y ante un nuevo desafío, parece que te escapas.

Cuando superes esto, entonces serás empleable. Hasta entonces, francamente sólo estás causando daño a tus empleadores y a tu propia reputación. Tus empleadores normalmente pueden sobrevivir a esto, pero tú no.

Veamos tu currículum…

Caso 1: Despedido de una compañía de Fintech en el segundo mes por no actuar… falta de motivación.

Si sabías que esto no era algo en lo que podías centrarte, ¿por qué aceptaste el trabajo? Y si no lo sabías, ¿por qué no renunciaste con dignidad en vez de perder el tiempo de todos? Este es el que realmente me preocupa.

Caso 2: Despedido de una compañía de plataformas web por no realizar… tecnología no relacionada con lo que firmé…

La naturaleza de un trabajo técnico es que habrá siempre cosas en las que no has trabajado antes. Si no has visto esa tecnología antes, reconoce eso, y asegúrate de que las estimaciones se ajusten en consecuencia.

Pero “no rendir” no suele significar que hayas incumplido los plazos, suele significar que te han pillado holgazaneando en vez de trabajando. En un trabajo técnico, esperaría que alguien se entusiasmara por aprender nuevas habilidades, o al menos que fuera diligente al respecto. Si vas a huir de algo que no conoces, entonces busca una nueva carrera.

Caso 3: … pasó mucho tiempo refactorizando e intentando eliminar la deuda técnica… Tiene tendencia a limpiar el código desordenado, refactorizar y asegurarse de que las cosas están bien probadas…

Y aquí es donde te vemos jugando con cosas que no necesitas. Lo llamas “código desordenado”. El resto de la compañía lo llamó “código de trabajo”. Yo vengo de una formación de ingeniería relacionada con la seguridad. En esta línea de trabajo, la gente puede ser disciplinada por arreglar errores. En serio. El problema de “arreglar” un error es que necesitas probar que tu arreglo no ha roto nada más. En el contexto de volver a probar el motor y la transmisión de un coche, un error menor que puede causar un error del 1% en la alimentación de combustible para un tick de procesamiento después de una hora de funcionamiento es muy probable que sea completamente aceptable, pero el costo en dinero y tiempo de una prueba completa de todo el sistema probablemente no lo es. Eso es antes de que lleguemos a arreglar el código “desordenado”, donde tus cambios supuestamente no funcionales pueden resultar en efectos secundarios debido a una coma o algo igualmente tonto.

En resumen, estás siendo contratado para hacer un trabajo profesional. Hasta ahora, has demostrado que no eres capaz de ser profesional. Cuando puedes ir a una entrevista y presentar esos fracasos como experiencias de aprendizaje que te han ayudado a cambiar tu mentalidad, entonces estás listo para ir.. ¿Puedes hacer eso…?

Tengo la tendencia a limpiar el código de desorden, refactorizar y asegurarme de que las cosas están bien probadas - algo que puede ser visto por muchos como de lento desempeño.

Voy a arriesgarme y asumir que esto es más que el usual boy scouting. Así que:

Tengo una tendencia a elegir a limpiar el código desordenado, refactorizar y asegurarme de que las cosas están bien probadas, cuando están “adyacentes” a algo que estoy escribiendo, y a priorizar esto sobre el envío, sin importar lo que se me haya encargado.

Las pruebas y la refactorización son geniales, pero nunca es 100% una llamada de una persona sobre cuánto énfasis recibe. El código es un medio para un fin… no sólo está ahí para su disfrute, está ahí para servir a las necesidades del negocio, y la gente que trabaja más cerca de esas necesidades (la dirección) está en una mejor posición para establecer prioridades. Además, todo lo que cambias es algo que potencialmente podrías romper, con pruebas o sin ellas, por no hablar de la carga de revisión adicional.

En cuanto a un cambio de carrera, creo que hay dos cosas a considerar. La primera es que si eres consistentemente insubordinado, no importará en qué carrera estés. Los cocineros de línea que “mejoran” las recetas son despedidos también. En otras palabras, estás siendo potencialmente despedido por no concentrarte. Tu impulsividad podría fácilmente seguirte a una nueva carrera, así que el cambio sólo valdrá la pena si te enfocas primero. La segunda es lo que mencionaste sobre la falta de motivación. Lo que podría estar causando la falta de concentración es si quizás no te gusta codificar más allá de limpiar las cosas existentes, lo cual es completamente comprensible. Pero si es cierto, significa que un cuarto trabajo de desarrollo sería simplemente apuntarse a una mayor tortura (asumiendo que es trabajar en un equipo y en una base de código existente).

Pero yo haría de hacer lo que dices que vas a hacer tu máxima prioridad, y seguiría desde ahí. Hecho correctamente, esto también significa no asumir obligaciones que no crees que puedas cumplir. Quién sabe, tal vez descubras que prefieres hornear pan. (Es solo un ejemplo, pero creo que es bueno… es un oficio, implica solucionar problemas, recompensa el perfeccionismo, y generalmente lo haces tú mismo de principio a fin.)

De todas formas, lo importante es que si te piden que hagas un trabajo, y lo aceptas, entonces lo haces. Más tarde, si resulta que no es para ti, entonces te retiras con gracia e intentas algo más. Pero hacer ese “algo más” con el dinero de otra persona, mientras piensan que estás haciendo lo que te pidieron, sólo va a molestar a la gente, en cualquier línea de trabajo.

**No necesitas que te diga que esto no es bueno, así que no voy a insistir en ello, pero vale la pena echar un vistazo a los tres despidos: Caso 1: Despedido de una compañía de Fintech en el segundo mes por no actuar. Esto era correcto ya que tenía una falta de motivación.

Nada que decir aquí - sabes que lo estropeaste. ¡Algo me dice que la falta de motivación no será un problema para ti ahora! Caso 2: Despedido de una compañía de plataformas web por no actuar. Me colocaron para trabajar con una tecnología no relacionada con lo que firmé, así que esto parece una mala gestión por mi parte.

Aunque no es la gestión ideal para poner a los nuevos empleados en tecnología a la que no están acostumbrados, no me atrevería a culpar de todo esto a eso - se necesitan dos para bailar el tango como se dice y me sorprendería si no hubiera más que podría haber hecho para evitar esto como un despido, pero llamémoslo 80-20 su culpa.

Caso 3: Despedido en el 6º mes por mal desempeño. Durante la libertad condicional recibí una respuesta positiva. Después de eso cambié de proyecto y pasé mucho tiempo refactorizando y tratando de eliminar la deuda técnica. Recibí una advertencia verbal por bajo rendimiento antes de irme de vacaciones. En los 4 días que tuve traté de arreglar eso quedándome horas extras y terminando todo el trabajo debido. Sin embargo, cuando volví de las vacaciones recibí una carta de despido.

Lo siento, pero esta es toda tuya - la refactorización a medida que avanzas no es mala en sí misma, y puede ser una forma muy eficiente de limpiar una base de código sin detener completamente el desarrollo futuro durante varios meses. Pero hacerlo cuando no tienes la dirección o al menos la aprobación para hacerlo (incluyendo el tiempo adicional que lleva) no es una buena idea. Desde el punto de vista del empleador, parece que trabajaste para pasar la prueba y luego te descuidaste después (me doy cuenta de que eso no es lo que hiciste - pero eso es lo que parece).

Generalmente el problema, tal y como yo lo veo, es que tengo tendencia a limpiar el código desordenado, refactorizar y asegurarme de que las cosas están bien probadas - algo que puede ser visto por muchos como un rendimiento lento.

Has identificado la causa probable de las opiniones de “mal rendimiento” pero parece que no has llegado hasta ahí al darte cuenta de que esto realmente es un mal rendimiento. Fallar constantemente en hacer estimaciones (asumiendo que esas estimaciones son realistas) no es sólo “visto” como de lento desempeño, es, por cualquier definición del término de lento desempeño! Si una historia de usuario/ticket/cualquier cosa tiene una estimación de 6 horas para completarse y te lleva 12 horas porque pasaste 6 horas adicionales haciendo la actividad X, entonces realmente no importa qué es la actividad X, si estabas refactorizando o viendo videos de gatos en tu tubo todavía te llevó 6 horas más hacer tu tarea asignada de lo que se esperaba.

La buena noticia es que básicamente tienes las habilidades y el talento que necesitas para tener éxito en la codificación - sólo necesitas apuntalar un par de cosas en tu enfoque. ¿Descubrir algo que se beneficiaría de un refactor cuando estás trabajando en una tarea? ¡Grandioso! Esa habilidad se puede convertir en su ventaja más que en una espina clavada - todo lo que tiene que hacer es hablar con su gerente/líder de equipo o con quien sea que gestione la planificación y la asignación de recursos y decir lo que ha encontrado, qué beneficios cree que puede aportar al negocio y cuánto tiempo cree que le llevará hacerlo.

Si están de acuerdo en que vale la pena la inversión de tiempo que pueden contabilizar para el tiempo extra, no te pasas de la estimación, y pareces una estrella de rock por ser proactivo en ayudar a la empresa.

¡Me encanta tener codificadores que me informen que hagan eso!

Sin embargo..

Tienes que aceptar que a veces van a decir “No” o “No ahora” a estas peticiones - eso es porque consideran que los plazos para completar la tarea original son más valiosos ahora mismo, y como digo tienes que aceptar esa respuesta porque no hay nada malo en que hagan esa llamada, porque para eso les pagan.

A menos que estés 110% seguro de que no implementar tu propuesta de refactorización inmediatamente tendrá consecuencias nefastas para la compañía, entonces no te eches atrás, no discutas. Haces lo que se te paga para hacer, si la empresa explota más tarde, francamente es responsabilidad de la persona que decidió no hacerlo… ¡De nuevo, para esto se les paga!

*¿A dónde vas desde aquí? * No creo que necesites cambiar de carrera ahora mismo, como digo, suena como si tuvieras las habilidades y aunque tu reciente historial de trabajo es, para ser franco, bastante condenatorio, no es irreparable y con un poco de trabajo duro y un poco de suerte puedes enderezar el barco y volver al rumbo como si nunca hubiera pasado.

Esto es lo que yo haría en su lugar:

• Ir a contratar (esta sería mi recomendación) - el historial de trabajo importa menos que tener las habilidades en la palabra de contrato, y la gente es más probable que tome una batea enalguien para un contrato entonces están para un puesto permanente ya que es más fácil dejarlos y conseguir a alguien más si toman una mala decisión de contratación. Tienes una fantástica reserva de ahorros que te dará tiempo para intentarlo. Fíjate una fecha límite: si no puedes encontrar (y tener éxito) un contrato en 3 meses, puedes ampliar tu búsqueda para incluir las posiciones permanentes. Hasta ahora no me ha llevado más de tres semanas asegurar un puesto de contrato, y estoy aplicando en las entrevistas, ¡así que puedes hacer esto! ¡Un buen contrato de 6 meses y muy pocas personas se preocuparán por tus últimas tres permanentes! Y encima de todo eso, incluso si tienes que mirar a la parte baja del mercado en términos de tarifa diaria para tus primeros contratos, probablemente estarás ganando muy buen dinero en términos reales.

o si contratar realmente no es algo que quieres hacer:

• Permanece permanente - da un paso hacia abajo en la escala salarial

En este momento, tener un buen historial de trabajo en tu haber es más importante que maximizar los salarios. Calcula la cantidad más baja realista que necesitas para vivir y empieza a solicitar trabajos en ese rango. Siempre hay empresas cuya ambición de contratación excede su presupuesto, y tienden a ser menos exigentes. Incluso si te recortan 5.000 libras de tu potencial, podrás recuperarlas a largo plazo con sólo aguantar durante dos años y tener un buen rendimiento. No digo que sea divertido o fácil, pero sería muy efectivo.

No te rindas, puedes hacerlo!

Me doy cuenta de que ya hay 16 respuestas aquí, muchas de ellas excelentes, pero no parecen haber abordado que hay una pequeña posibilidad de que podría haber otras razones para ser despedido.

Podría ser que estas hayan sido excusas convenientes para su despido. Nunca es agradable señalar esto, pero vale la pena examinar si estás encajando a nivel personal.

He conocido (de) algunas personas que han pasado por varios trabajos en poco tiempo y no pueden ver por qué. Para mí (y otros) ha sido obvio - tienen un hábito o rasgo que se enreda en la gente que los rodea. Para uno de los chicos, este era un hábito de aclararse la garganta todo el tiempo, junto con no tomar la indirecta cuando la gente quería terminar una conversación. Trabajé en la misma oficina que él y puedo decirte que el ambiente después de que se fue fue fue mucho más agradable. Otro tipo, era un problema de higiene. Ambos fueron despedidos por lo que sonaba razonable, pero sabías en el fondo de tu mente que estos otros rasgos definitivamente eran un factor.

No estoy diciendo que tengas alguna de estas características, incluso podría ser un choque de culturas, no algo que es incluso tu culpa, pero como otras respuestas sugieren, un período de introspección es muy valioso aquí. Me gustaría ampliarlo para mirar cosas como los hábitos y rasgos personales para comprobar si podrían ser la causa oculta.

Supongo que no escuchar es un problema clave. No sólo escuchar las palabras, sino entenderlas y tomarlas en serio.

Esto me salta a la vista:

Generalmente el problema, tal y como yo lo veo, es que tengo tendencia a limpiar el código de desorden, refactorizar y asegurarme de que las cosas están bien probadas, algo que puede ser visto por muchos como de lento desempeño.

“Eso puede ser visto por muchos como de lento desempeño” no es la parte importante. Su compañía le dijo que es de lento desempeño, porque lo despidieron. Si tu jefe te dice que hagas algo, lo haces. Si tu jefe te dice que no hagas algo, no lo haces. Si no estás seguro, entonces pregúntale a tu jefe y haz lo que te diga.

Como novato en el mundo de los negocios, no te corresponde decidir lo que la empresa debe hacer. Cuando decides por tu cuenta ir a hacer limpieza de códigos, les dices a la compañía que conoces mejor que ellos. No hagas eso.

Como desarrollador durante 32 años, sé que puede ser frustrante dejar deudas tecnológicas, dejar código desordenado o indocumentado. Pero si eso es lo que la compañía quiere que hagas, entonces hazlo.

Siempre puedes enseñar informática en el instituto si crees que tu carrera en la industria es limitada. Hay otras cosas que puedes hacer como la gestión de proyectos también.

Pero cuando solicites otro puesto, no expliques tus despidos como problemas de gestión. Incluso si el gerente fue completamente responsable de lo que ocurrió, darás la impresión de que no eres capaz de evaluar tus propios errores y debilidades.

Escribe una corta carta de presentación con tus nuevas solicitudes y explica lo que ocurrió. Asuma la responsabilidad de ello independientemente de las razones. Explique por qué las cosas serán diferentes.

Puede que tenga que aceptar contratos por un tiempo. Créeme, he visto a contratistas ir y venir mucho.

Una vez que te hayas reestablecido, puedes empezar a construir tu carrera como un empleado exitoso.

NUNCA pienses que tus opciones están limitadas porque esto sólo limitará tus opciones. Es un cliché, pero tienes que mantener una actitud positiva.

Conozco la sensación de querer pasar mucho tiempo mejorando la calidad del código para aumentar la velocidad de desarrollo. Pueden ahorrar absolutamente cantidades masivas de tiempo, hasta e incluyendo hacer proyectos complejos realizables en primer lugar. Sin embargo, yo tendría cuidado de introducir estos lentamente cuando se inicia un nuevo trabajo.

Espera que tome meses para construir suficiente contexto (tanto de los desarrolladores, usuarios y administradores como del código) para aprender dónde están los mayores puntos de dolor (no sólo los grandes). Una vez que tengas un sólido entendimiento de estos deberías ser capaz de presentar un caso a tu manager para trabajar en uno de ellos durante un corto período de tiempo para mejorar masivamente algún aspecto del código. Y cuando clavas uno de estos realmente muestras por qué deberían mantenerte. No tienes que ser un desarrollador fantástico para hacer esto - todo el mundo con un poco de experiencia tiene habilidades de las que el resto del equipo carece.

Antes de todo eso, sin embargo, me centraría en hacer las cosas del día a día. He trabajado en lugares donde el control de calidad de los desarrolladores era tan pobre que pasábamos casi todo el tiempo apagando incendios. No es divertido, pero a menos que puedas hacer que el dinero ruede en _más rápido-la gerencia no va a estar interesada en limpiar las cosas.

Como nota final he tenido varios trabajos malos como desarrollador de software, pero otros han sido muy divertidos. Personalmente recomendaría instituciones de investigación y empresas más pequeñas, ya que en mi experiencia son flexibles en su forma de trabajar y al menos están algo interesadas en el control de calidad.

Voy a estar completamente en desacuerdo con las otras respuestas aquí

Por lo tanto, vine aquí para encontrar todas las respuestas que te dicen que te comportes, mantén la cabeza baja, acepta la crítica, trabaja en las tareas asignadas y mejora la comunicación.

En primer lugar - absolutamente debes mejorar tus habilidades de comunicación. Es algo en lo que puedes trabajar y mejorar y yo consideraría hacerlo si fuera tú.

Entonces vi tu perfil de GitHub

Esto me hizo cambiar de opinión. Su código es de hecho muy superior a la media e indica que usted llega a ser muy quisquilloso. Para ser claros - tu perfil no es asombroso, pero ciertamente te coloca por encima de la media de los desarrolladores que vienen a las entrevistas cuando entrevisto a los candidatos en mi libro.

No necesitas justificar el ser despedido 3 veces

La industria del software está en un lugar donde tener un perfil GitHub como este te consigue entrevistas de trabajo y ofertas incluso si fuiste despedido 3 veces.

Puedes decir que los lugares en los que trabajaste eran malos encajes culturales porque no valoraban la excelencia técnica tanto como tú (lo cual es cierto) y entrevistarte en lugares que _valoran la excelencia técnica.

Muchos desarrolladores no pueden permitirse esto, pero tú sí puedes.

Lo ideal sería que trabajaras en lo que te dijo tu jefe, lo cual es algo bueno, pero es totalmente posible que encuentres un lugar con valores que se alineen con los tuyos.

Averigua qué _quieres realmente

Suena como si los últimos 3 lugares fueran todos malos para ambos lados. Desde que tienes que ser quisquilloso yo buscaría un lugar que:

• Trabaje con nuevas y modernas tecnologías que te exciten
• Tenga una cultura de valores que te importen
• Resuelva los problemas que encuentres interesantes

En vez de enfocarte en cómo explicar por qué fuiste despedido - enfócate en lo que realmente quieres lograr en tu trabajo.

La programación te excita lo suficiente como para hacerlo en tu tiempo libre - ¿qué te excita?

Encuentra un lugar que encaje bien

Conozco algunos programadores en tu situación (que fueron despedidos 3-4 veces en un año) hasta que encontraron un lugar que era capaz de contenerlos. Son bastante obstinados, algo ruidosos y realmente se preocupan profundamente por usar los estándares modernos y hacer las cosas de la manera correcta.

Todos ellos están felizmente empleados ahora en lugares que pueden contenerlos.

Mucho de lo que normalmente diría ya se ha dicho. Pero hay al menos un camino abierto para ti que no creo que nadie haya dado como respuesta todavía.

Considera la contratación / autoempleo.

Muchas de las otras respuestas se han centrado en cómo puedes venderte a tu próximo empleador, cómo puedes explicar tu corta estancia en tus últimos tres roles, y qué podrías hacer de forma diferente para mantener tu próximo trabajo. Todo esto es cierto, pero encontrar otro empleador no tiene por qué ser la única opción. ¿Qué pasaría si tu próximo empleador fuera… tú?

Pros:

• No necesitas explicar nada ni justificar lo que le pasó a nadie más.
• Si eres realmente bueno en lo que puedes hacer, tus habilidades estarán en demanda, a un precio gratificante.
• Ya tienes seis meses de ahorros - eso es suficiente para encontrar clientes y empezar.
• Una vez que tengas unos pocos clientes, puedes elegir en qué quieres trabajar (es decir, qué clientes contratar), en lugar de lo que tu empleador te diga que trabajes.

Desventajas:

• Tendrás que dirigir tu propio negocio y gestionar tus propios impuestos, así como desarrollar software.
• Si no eres tan bueno como crees, o si no encuentras motivación para hacer lo que quieren los clientes, o si pierdes todo el tiempo haciendo un código limpio sin deudas técnicas cuando el cliente sólo quiere software que funcione, podrías quemar todos tus ahorros y acabar exactamente donde estás ahora, excepto que tus ahorros se han esfumado. **Esto es un riesgo real. Tendrás que mirarte al espejo antes de tomar esta ruta. Pero sospecho que tendrá que hacerlo sin importar lo que pase.

Aguante. Mucha gente llega a los 30 años y descubre que las cosas no han salido como esperaban. No es demasiado tarde.

Me parece que tu problema es que haces las cosas a tu manera. Tienes este patrón de comportamiento en el que la forma en que haces las cosas es “la forma correcta” y cualquier cosa que indique que necesitas cambiar rebota en eso. Afortunadamente, tu manera es en realidad bastante buena, tienes una fuerte ética de trabajo, buenas formas de trabajar y no te equivocas en que es la manera correcta. El tema es cuando esto choca con las prioridades de tu empleador.

Tu primer despido fue por tu propia admisión una falta de motivación, FinTech es un material bastante seco, ciertamente no puedo culparte por perder el interés en él, estoy seguro de que no aguantaría el mío. No le preguntaré por qué lo aceptó en primer lugar, estaba solicitando un trabajo en FinTech cuando estaba solicitando mi actual lugar de trabajo, un trabajo es un trabajo.

Llámelo un mal ajuste y lección aprendida.

Su segundo despido se debió a que le pidieron hacer cosas para las que no fue contratado originalmente (al menos por su comprensión de su contrato) y a que no estaba contento con eso.
Esto no es raro, he tenido que lidiar con trabajos en los que una gran parte de mi tiempo no se dedicaba a hacer el material para el que estoy entrenado y capacitado, esto es definitivamente una mala gestión. Sin embargo, si se requiere que aprendas un nuevo conjunto de habilidades o herramientas en el trabajo, eso es parte del trabajo.

Estoy seguro de que no necesito decirte que la industria del software está constantemente fluctuando y mantenerse al día con las últimas cosas es vital para el éxito. Sólo este año he tenido que aprender Desarrollo Web desde cero y he aprendido Vue.js, JQuery y Bootstrap desde cero, el año pasado aprendí Xamarin y me convertí en Desarrollador de Aplicaciones. Antes de eso estaba construyendo juegos para móviles y Facebook en Unity3d y Flash. He trabajado en Agile y Scrum, de forma independiente y en equipos de modelos de cascada. Lo que necesito, lo aprendo. Si actualmente no puedes hacer eso, necesitas aprender a ser adaptable a si quieres tener éxito en la industria del software.

Tu tercer despido es el que más escribes, el problema es mucho más claro ahí. Sabías que la forma correcta de escribir código era hacerlo bien la primera vez, pasar el tiempo por adelantado y ahorrar tiempo y dinero después. No te equivocas en absoluto. Buen trabajo en eso.

Como sea que se te haya dado (asumo) una tarea clara y porque pasaste tiempo fuera de la tarea, fallaste en entregar consistentemente el trabajo que se te pidió.

Ir fuera de la tarea para arreglar el código relacionado es algo que hago todo el tiempo, sin embargo es crítico no perderse en la madriguera del conejo. Recuerde que el último 10% de un problema toma el 90% del tiempo. Abre el código del problema, parchea la parte que está causando el problema, añade un //TODO para arreglarlo correctamente, escribe una nota en algún lugar que necesite más atención más tarde y muevete. Normalmente el 90% es suficiente.

Tu tarea número uno es siempre entregar el material que se te dijo que hicieras, y como recién contratado, tienes mucha menos autoridad unilateral de la que te gustaría. Yo mismo me he metido en problemas por este mismo asunto y a veces es difícil pasar por los aros para hacerlo según el libro.

Este es probablemente tu mayor problema. Necesitas hacer las cosas como tu empleador quiere que las hagas. Si crees que tu empleador subestima la importancia de algo, explícaselo en términos de tiempo y dinero y si todavía no están de acuerdo. Acéptalo. El empleador es tu cliente, y como dice el refrán, el cliente siempre tiene la razón.

En conclusión, no te rindas. Claramente tienes las habilidades y la capacidad de ser un gran programador, sólo necesitas encontrar un trabajo que te interese y mejorar en la resolución de problemas mientras prestas atención a las prioridades de tu equipo.

En estos días, el empleo en el mundo de la tecnología es una especie de juego.

Voy a adivinar que su empresa sigue la metodología de AGILE.

La clave es no hacer lo que te apetezca sino hacer lo que se te asigne.

Y no seas tímido a la hora de pedir más puntos, y pedir más tiempo.

Es MUCHO mejor exigir más tiempo y obtener más puntos por tus tareas AL PRINCIPIO que resbalar.

La dirección tiene 0 pistas sobre la dificultad de tus tareas… sólo se basan en las estimaciones iniciales.

si no luchas por los puntos al principio… estás jodido.

Ninguna respuesta hasta ahora parece considerar la posibilidad de que hayas tenido muy mala suerte y tengas 3 trabajos horribles seguidos. Definitivamente hay algunos trabajos realmente horribles y gerentes poco razonables por ahí. He tenido varios, pero no tantos seguidos. A veces son muy difíciles de detectar durante la entrevista; en algunos casos, las descripciones de los puestos y las cosas que se dicen en las entrevistas son totalmente inexactas y engañosas. Por lo tanto, es POSIBLE que esto no sea culpa tuya; pero sólo tú tienes suficiente información para poder juzgarlo.

Al final, sin embargo, lo más probable es que tengas un mal trabajo con el que empezar (tedioso, mala gestión, baja paga). Sólo tienes que tolerarlo durante unos pocos años, así que piensa cuidadosamente en lo que estás dispuesto a aguantar en un trabajo, y tal vez bajar tus expectativas.

Me parece que su único problema es no poder hacer las tareas que se le han encomendado. En todos los trabajos de los que te despidieron, declaras que no hiciste la tarea que te asignaron y te enfocaste en hacer otra cosa (refactorización, etc.). A menos que saques a relucir estas cosas antes de que llegues al punto de no cumplir con los plazos, no lo haría.

Recuerda siempre que la gente piensa lo peor en cada situación negativa. Por lo tanto, si no cumples con la fecha límite, y haces que cambien varios archivos (aunque te cueste menos que eso), no van a pensar nada bueno al respecto. Asegúrate de comunicar los problemas que veas y de obtener los permisos para hacer otra cosa de tu gerente antes de hacerlo. No empieces a hacer otra tarea.

Creo que si sigues ese consejo, tendrás una carrera exitosa. En algún momento, todo el mundo confiaría en tu experiencia y se centraría en mejorar el código. Pero como el chico nuevo, al que nadie conoce por no hacer una tarea simple y refactorizar un código no relacionado, eso no funcionará.

Sé que ya hay demasiadas respuestas a esta pregunta pero sólo quería compartir mi experiencia basada en la sugerencia de Joe Strazzere de que considere el trabajo temporal/contractual.

Usted dijo que está basado en el Reino Unido, el mercado de los contratistas está en auge allí ahora mismo. En Londres puedes ganar alrededor de 500 libras al día. Lo bueno de esto es que nunca te cansarás del lugar donde trabajas y empezarás a arrastrar los talones, cada 3-6 meses necesitarás encontrar un nuevo contrato.

Esta podría ser una solución pero igualmente podría no ser adecuada para el rápido ritmo de trabajo de los contratistas. Personalmente lo disfruté mucho y después de mis primeros 6 meses contratando para la BBC tuve suficientes ahorros para trabajar totalmente por cuenta propia y desde casa.

En última instancia, lo que deberías buscar es conseguir buenos clientes y trabajar a distancia. Entonces tienes completa libertad para refactorizar tu código siempre y cuando estés entregando los proyectos a tiempo. Personalmente nunca estuve más motivado que cuando dirigía mi propia empresa. Trabajaba 12 horas diarias, 6 días a la semana.

Pero también tengo la sensación de que no estás 100% satisfecho con tu carrera, tal vez es hora de tomar un descanso?

Tienes ahorros, ¿por qué no te vas de viaje y pasas 3-6 meses pensando en tu próximo paso? Una forma increíble de viajar es usando el workaway, he sido voluntario en España y Japón usándolo. Conocerás a mucha gente. https://www.workaway.info/299958546294-en.html

Tienes problemas para mantener el enfoque y la motivación cuando tratas con el código de otras personas.

Simpatizo con esto - Es difícil seguir sacando nuevas características por la puerta sin limpiar la casa y todavía sentir que estás contribuyendo a algo de lo que puedes estar orgulloso.

Pero, desafortunadamente, eso será cierto para la gran mayoría de las organizaciones que te contratarán para escribir código. No voy a decirte que “lo superes” - me imagino que, a menos que seas profundamente malo en la auto-reflexión, esta opción ya se te ha ocurrido.

En su lugar, te sugeriría que consideres usar tus conocimientos técnicos para una carrera en el desarrollo de software que no implique escribir código de aplicación como un enfoque central.

Puede que encuentres más disfrute, satisfacción y un enfoque más fácil como Ingeniero de Control de Calidad y/o DIT. Seguirás escribiendo código y resolviendo muchos de los mismos tipos de atractivos rompecabezas, pero tu enfoque y responsabilidad NÚCLEO es mejorar la calidad del producto. Eso parece más acorde con la iniciativa que has mostrado aquí.

Es mi experiencia que en este tipo de roles, normalmente tienes un equipo más pequeño, una sección más pequeña de la base de código de la que eres responsable, y por lo tanto mucha más latitud para refactorizar agresivamente. Además, si haces bien tu trabajo, no sólo escribes código con el que puedes estar contento, sino que también ayudas a mejorar la calidad de lo que realmente llega a la producción.

También es comparativamente fácil vender esa transición a un empleador potencial en esos términos - Tuviste dificultades como desarrollador de software porque pasaste demasiado tiempo centrándote en lo que esencialmente equivale a control de calidad, así que decidiste cambiar el enfoque a sólo hacer control de calidad.

Le aconsejo que se tome un descanso y trabaje en sí mismo. Especialmente la falta de un círculo de amigos positivos y una vida social inactiva parece ser un gran factor que contribuye a tu vida. ¿Te sientes quemado o solo? ¿Has intentado contactar con un terapeuta o un mentor para comprobar si sufres algún tipo de depresión o TDA? ¿Se siente cómodo trabajando bajo la autoridad? ¿Ha pensado en trabajar por cuenta propia o a tiempo parcial? Mucha gente llega a una meseta a los 30/40 años. Y la codificación puede ser un trabajo que chupa el alma a veces. Intenta explorar tus hobbies o un campo relacionado cercano a tu dominio de experiencia.

El problema parece más pertinente a tu personalidad que a tu campo de trabajo. Te aconsejo encarecidamente que te tomes un descanso y hagas un examen de conciencia hasta que encuentres la motivación para formar parte de otro equipo.

Como desarrollador que también valora el código limpio y bien probado, y desprecia la deuda de código, puedo entender su punto de vista. Sin embargo, se le paga para completar las tareas asignadas. El trabajo no consiste en hacer lo que quieres hacer, sino en hacer lo que tu empleador espera de ti. Es un bono cuando puedes encontrar placer en hacer las cosas por las que te pagan. Tener una buena ética de trabajo requiere el desarrollo de la autodisciplina para centrarse en la tarea asignada y hacerla a satisfacción de tu empleador, tanto si disfrutas haciéndola como si no, tanto si encuentras satisfacción en hacerla como si no. Las recompensas que puede obtener de esto son: (1) recibir un sueldo, (2) tener cierta seguridad de que seguirá trabajando, (3) tal vez aprender algo nuevo y útil, (4) fomentar el respeto en la organización que podría aprovechar para hacer eventualmente cosas más a su gusto y/o satisfacción.

Si cree que se están dejando tareas importantes sin hacer (refactorización, reducción de la deuda de código, mejora de la cobertura de las pruebas), por todos los medios menciónelo a su supervisor. Si se puede hacer en el curso de la realización de una tarea asignada sin retrasar la finalización del trabajo asignado, estupendo. Si sólo puede hacerse a expensas de la tarea asignada, déjelo.

Otra cosa a considerar: las decisiones empresariales se toman en función de si aumentan los ingresos o disminuyen los costes, y generalmente tienen un horizonte corto. No es raro que las empresas se centren en los resultados del trimestre actual o del próximo. Mucho dinero de inversión se mueve en base a los resultados trimestrales; esto es lo que dirige las decisiones de los negocios. Las mejoras que se sienten motivados a hacer a la base de código son una inversión a largo plazo sin un beneficio cuantificable. Ambos sabemos que es algo bueno, y para un negocio que está en el negocio a largo plazo, es lo ** correcto**. Sin embargo, los negocios no toman decisiones basadas en lo que es correcto o mejor a largo plazo, sirven a sus amos - los inversionistas.

Si decides que quieres continuar como promotor, y siento que lo haces, ya que demuestras orgullo por tus logros fuera de estos tres trabajos, toma medidas concretas para hacer frente a tus limitaciones, para que tus fortalezas finalmente empiecen a brillar para tus empleadores.

En primer lugar, ¿puedo sugerir que tu falta de concentración es causada por la falta de organización diaria? En su próximo trabajo, asegúrese de conocer las tres prioridades principales que su jefe le ha asignado (y su importancia relativa) en todo momento. Al comienzo de cada día de trabajo escriba sus prioridades actuales, y al final del mismo resuma lo que ha logrado en contra de ellas. No seas verborreico, haz que la descripción de cada prioridad y logro sea tan corta y dulce como sea posible con sólo el mínimo detalle requerido. Algo así como…

Comienzo del día

1. Implementar la nueva característica A
2. Escribir pruebas de unidad para A
3. Construir nueva versión A con documentación para los probadores.

Fin del día

1. Implementar nueva característica A
2. Escribir pruebas unitarias para A
3. Implementar nueva característica A
4. Escribir pruebas unitarias para A
5. Escribir pruebas unitarias para A
6. Escribir pruebas unitarias para A
7. Escribir pruebas unitarias para A
8. Escribir pruebas unitarias para A
9. Escribir pruebas unitarias para A
10. Escribir pruebas unitarias para A
11. Escribir pruebas unitarias para A
12. Escribir pruebas unitarias para A Escribió las pruebas de unidad para A, y arregló los errores para que pasara todas las pruebas.
13. No fue capaz de liberar A, ya que pasé dos horas apoyando a Ventas en un problema prioritario del cliente con el producto.

Y al día siguiente su primera prioridad sería probablemente

1. Construir la versión A y escribir la documentación para los probadores.
2. …

Todos los lunes por la mañana hacer algo similar para la semana. Primero escriba sus metas/prioridades planeadas para la semana, y luego refiérase a ellas cada mañana cuando escriba las prioridades diarias para que estén en sincronía con sus compromisos semanales.

También recapitule y resuma lo que ha logrado la semana anterior, usando sus notas de fin de día de la misma. Luego envíaselo a tu jefe como tus objetivos/realizaciones semanales para que sepan lo que hiciste y lo que planeas hacer. De esta manera ellos pueden ofrecer correcciones de curso si usted está equivocado o las prioridades han cambiado. Y cuando empiece su nuevo trabajo, las primeras semanas podría incluso enviarle a su jefe sus prioridades diarias matutinas con el resumen del día de ayer para que confíe en usted aún más rápido.

Asegúrese de no hacer demasiado agresivos los objetivos semanales, no querrá perder constantemente ningún compromiso que su jefe vea, incluso si son compromisos artificiales que usted se ha fijado. Divídelos en “Compromisos” que estés muy seguro de que cumplirás, y “Metas de estiramiento” que comuniques que esperas alcanzar si la semana va bien.

Al auto-organizarte de esta manera, te ayuda a lograr varias cosas importantes.

1. El comienzo de cada día se centrará en sus prioridades y compromisos asignados, haciendo más fácil resistirse a la refactorización y a hacer otros trabajos no asignados.
2. Obligarse a recapitular los logros al final de cada día deja muy claro cuándo ha retrocedido, ayudando de nuevo a reenfocarle en sus prioridades asignadas.
3. Compartirlos con tu jefe les ayuda a verte como un miembro del equipo fiable y predecible que les hace quedar bien con su jefe y les ayuda a alcanzar sus propios objetivos.

De hecho, yo mismo hago el informe semanal para mi jefe cada semana, y le encanta. De hecho, ha reducido la cantidad de comunicación que necesitamos ya que ha desarrollado mucha confianza en que sabe lo que estoy haciendo y puede redirigirme fácilmente si las prioridades cambian.

No hago la planificación/recapitulación del día laboral diario, pero lo recomiendo porque después de leer su post me doy cuenta de que ambos lo necesitamos. Como tú, tengo la tendencia a ser mal dirigido en el código de refactorización y a arreglar problemas que no son necesariamente de alta prioridad para la compañía. Y una semana es mucho tiempo, es fácil olvidar algunos objetivos clave a mitad de la semana y sólo darse cuenta de que se perdieron al recapitular la semana el lunes. Así que mientras les escribía esto, también me asigné la tarea de repetir los recordatorios diarios para hacer ambas cosas.

Por último, si mis recomendaciones no parecen funcionar para mantenerlos enfocados en las prioridades correctas todos los días, está bien. Pero asegúrate de encontrar otro sistema que lo haga. Incluso si se traslada a otro campo, centrarse en las expectativas de su jefe y de la empresa todos los días es un factor clave para tener éxito en cualquier carrera que elija.

Cuando tengas que explicar por qué no tuviste éxito en tus trabajos anteriores en tus próximas entrevistas, una gran respuesta es que soy un perfeccionista que tuvo problemas para mantenerse enfocado en las prioridades correctas, así que me he dedicado a convertir esa debilidad en una fortaleza organizándome rigurosamente, y así es como lo hago ahora y lo haré por ti.

¡Por último, vas a tener éxito! Ya ha demostrado que tiene lo que se necesita haciendo el autoanálisis que le llevó a escribir este post. Tienes el deseo, tienes la habilidad, sólo tienes que añadir el enfoque y la organización. El problema se está aclarando para ti y tienes la habilidad de resolverlo. Espero que tengan éxito en el futuro y espero que publiquen actualizaciones para que todos podamos compartirlo.

Mejores deseos,

Randy

Edición: Nunca olviden que Steve Jobs fue despedido de Apple y las lecciones que le enseñó lo hicieron un mejor CEO la segunda vez. Edison fue despedido de Western Union, y falló mil veces antes de perfeccionar su bombilla. Walt Disney fue despedido por el KC Star por no ser “lo suficientemente creativo”, así que empezó su propio negocio y se fue a la bancarrota. Aún es muy joven, toma las lecciones que ha aprendido y las usa para tener éxito.

Vale, entonces podemos estar de acuerdo en que has tocado “el fondo” de tu carrera. ¿Y qué? Sólo hay una dirección a la que puedes ir desde allí, ¡que es hacia arriba!

El continuar o no en tu actual elección de carrera depende enteramente de si realmente lo disfrutaste.

Si no lo disfrutaste: Te recomiendo que no continúes esta trayectoria profesional. Deberías tomar un pequeño trabajo en otro lugar (incluso uno de baja categoría) para acumular fondos para perseguir algo que te interese más.

Si realmente disfrutaste tu trabajo: Estás en el “fondo”, ¿verdad? ¡Así que pulsa reset! Empieza de nuevo desde abajo, y esta vez hazlo correctamente. Empieza a solicitar trabajos de software como desarrollador de nivel Jr. (o incluso como interno, si es necesario) en cualquier compañía de software. Esta vez, trabaja duro para reconstruir tu reputación y tu currículum, así como para impresionar a tus nuevos empleadores.

En cualquier caso, te recomiendo que ni siquiera menciones esos trabajos de software anteriores en tu currículum, no te están haciendo ningún favor. Lo mejor es un reinicio completo! Y no hay que avergonzarse de intentarlo de nuevo y trabajar duro en ello!

Hay una tonelada de respuestas realmente buenas aquí, pero tengo ideas adicionales que tal vez quieras tener en cuenta cuando encuentres o mantengas el próximo trabajo.

En primer lugar, nunca te rindas con tus sueños. Has invertido una gran cantidad de tiempo, y dinero supongo que para entrar en esta carrera; renunciar en este momento no es lo correcto.

Lo mejor que puedes hacer ahora es apuntar todo esto a la experiencia, y hacerlo mejor la próxima vez. Una creencia común entre los desarrolladores novatos es que sus habilidades de programación son superiores a las de sus predecesores. Esto puede ser cierto en algunos casos, pero incluso si eso fuera cierto, otros programadores más veteranos se enorgullecen mucho de lo que han creado, y se ofenden cuando un tipo nuevo llega y empieza a destrozar sus programas.

En el mundo de los negocios, el desarrollo de software se toma muy en serio, y hay consecuencias reales al sacar un mal producto. Los negocios dependen de que sus productos sean confiables, y un pequeño defecto podría caer en cascada, causando enormes problemas aguas abajo. No quieres ser ese tipo. En el mundo financiero, un pequeño error podría costar millones, e incluso llevar a la quiebra a una compañía. Así que… los dueños de negocios son típicamente muy protectores de su código, y no quieren que nadie juegue con algo que se supone que no deben tocar.

Trata de enfocarte sólo en las tareas específicas que tienes a mano y ten una clara comprensión de las expectativas. No intente ir más allá de lo que se espera de usted, al menos hasta que la prueba haya terminado. Sólo preséntese todos los días a tiempo, haga su trabajo sin afectar a los demás, y tenga una buena relación con sus compañeros de trabajo, y no será despedido. Recuerda, no te contratan sólo por tus habilidades de programación, eso sólo te lleva a la puerta. Si quieres tener éxito, entonces también debes trabajar en tus habilidades de programación. Tu éxito depende de tener una buena actitud, y de llevarte bien con los demás.

No se rinda!

Para añadir a lo que otros han sugerido: Imagine que usted estuviera trabajando X años en una compañía y un nuevo empleado apareciera y empezara a indicar (a través de palabras y acciones) que el trabajo existente (en el que usted y sus compañeros de trabajo habían estado trabajando durante años) era “descuidado”/“inútil”/“tenía que cambiar para que el nuevo empleado se sintiera cómodo”, ¿cómo cree que usted (y sus compañeros de trabajo) responderían cuando los gerentes les pidieran su opinión sobre el nuevo empleado? No me imagino a nadie respondiendo con: “Sí, me encanta trabajar con él, y seguro que sabe lo que hace”. Me imagino que el feedback es más: “Arrogante, sabelotodo, no parece capaz de integrarse en el equipo”

Siempre me he acobardado cuando escucho a un nuevo empleado decir algo parecido a: “Tu código/producto/proceso existente es una mierda/maldad/equivocado. Mis ideas/métodos son mejores. Sé distinguir el bien del mal, pero tú no. Puedo hacerlo bien, donde tú no pudiste”. Siempre tengo la sensación de que el nuevo empleado no va a superar ningún período de prueba (& rara vez me he equivocado).

Hay muchas razones para que el código sea como es, incluyendo traer el trabajo heredado, limitaciones de tiempo, programadores descuidados, adaptarse a las especificaciones cambiantes, trabajar con sistemas heredados de HW/SW, etc. El código es, sin embargo, el producto de ese grupo/empresa y tendrán algún orgullo de propiedad y probablemente incluso alguna prueba empírica de que funciona “lo suficientemente bien” como para hacerlos ganar $. Incluso podría estar desestimando los esfuerzos de otros miembros del grupo (o incluso del gerente). Puede que incluso sea puntual en su evaluación, pero eso puede ser totalmente irrelevante. La programación en puestos permanentes también se trata de trabajar juntos como grupo (y ese grupo incluye a tu gerente).

Si quieres trabajar como permanente en grupos similares, considera lo que puedes cambiar (en el fondo mentalmente) para que los otros miembros del grupo le den a tu gerente una retroalimentación que confirme su decisión de contratarte, e indique que harás que el grupo mejore con menos sorpresas desagradables evitables (tanto para tu gerente como para la empresa).

Esta es una respuesta amplia con muchas sugerencias:

1. Intenta bajar tus expectativas, debe haber un puesto de trabajo adecuado para ti en IT.
2. Tal vez deberías cuestionar tu acuerdo de responsabilidades a la primera.
3. 1. Comuníquese cuando haya problemas de bloqueo. Diga lo que piensa sin dejar de ser profesional. Cuando no esté suficientemente motivado, este es generalmente su problema, así que intente solicitar breves descansos para las vacantes dispersas a lo largo del año, en lugar de tomar pocas vacantes largas (esto puede ayudar, o no).

4. Puede probar los trabajos a tiempo parcial sabiendo que tiene ahorros hasta por 6 meses, luego podría extenderse a más ! manteniendo el espíritu competitivo, y un currículum actualizado.

5. Cambiar de rol, en las grandes empresas es a veces más fácil, si fuera un caso posible para ti, esto podría ser muy motivador.

6. No conozco tus antecedentes y perfil, pero hay misiones en TI que envuelven menos técnica como la promoción de productos de TI, la organización de sesiones de sensibilización sobre nuevas tecnologías para otras universidades, la redacción de documentación, la limpieza de código antiguo (para desarrolladores), el establecimiento de nuevas pruebas de conceptos, ideas de proyectos, la participación en desafíos y tratar de estar en la cima para el nombre de tu grupo . .. etc etc, ver que hay muchas cosas que un desarrollador por ejemplo puede hacer en IT.

Esta es una lista de más opciones de libertad que puedo imaginar por ahora.

1. Te diste cuenta de que el código era malo.
2. Actuaste en él tratando de mejorar el código.
3. Los gerentes no apreciaron esto.

Bueno, en algunos lugares tu verdadera ayuda no será apreciada y sólo quieren que resuelvas problemas inventados sólo para alimentar su sentido de logro. Esta podría ser una de estas situaciones, no lo sé con seguridad. Si ese es el caso, entonces no hay mucho que puedas hacer. Te das cuenta de que es una tontería y eliges intentar hacer lo mejor que puedas para beneficiar a la compañía.

Yo diría que sigas con ello. Hasta que encuentres un lugar donde eso sea apreciado. Tales lugares existen.

Parece que tienes una tendencia a no seguir la dirección, y/o a empantanarte en detalles que no importan, para hacer lo que preferirías estar haciendo. Eso resulta en falta de trabajo en equipo y mala administración del tiempo.

Solía tener un compañero de trabajo que era contratado para un puesto que no quería. Pude ver en el proceso de entrevista que tenía una aversión a ciertas tecnologías heredadas y plataformas estándar en las que trabajaría. Tenía fuertes prejuicios. Incluso su currículum indicaba que iba de un sitio a otro. La dirección no me escuchó. Lo contratamos de todos modos.

No sólo no quería hacer sus tareas asignadas para las que no estaba dispuesto a aprender, sino que intentó encontrar otras tecnologías y código base para reemplazar lo que teníamos, o incluso a veces trató de hacerse cargo de las tareas de otras personas.

Quería “arreglar” el código de todos los demás y decirnos cómo “debería” hacerse. Quería hacer perder el tiempo a todos con revisiones de código en proyectos ya en producción, para poder mostrarnos una codificación adecuada y una sintaxis limpia (o la falta de ella). Era excesivamente perfeccionista y, como resultado, perdía su tiempo.

Tal vez estas características no se aplican a ti. Tal vez simplemente no te gusta hacer lo que se te ha encomendado, y necesitas un cambio. Pero si te identificas con estos puntos, no durarás mucho en ningún sitio.

Irónicamente, mi antiguo compañero de trabajo consiguió un mejor trabajo como resultado de la experiencia de trabajar en la tecnología/plataforma que él odiaba. Así que a veces tienes que forzarte a hacer el trabajo que no te apetece hacer.

Algunas empresas tienen tasas de rotación muy altas, con más de la mitad de sus empleados cambiando cada año. Cuando algunas compañías tratan de trabajar en el problema, entender las razones, cambiar algo en su propio lado, otras pueden disparar inmediatamente después de detectar incluso signos débiles de algo que tienen la política de no tolerar.

Desafortunadamente estas compañías de “alto rendimiento” también contratan a la mayoría, incluso si no están creciendo - para mantener el tamaño del equipo. Sus anuncios de empleo nunca salen de los tablones de anuncios de los portales de empleo más populares. Si no miras por donde vas, hay posibilidades razonables de golpearlos una y otra vez, incluso si no son la mayoría.

Intenta encontrar la compañía que sea notable pero no tan activa con reclutamiento permanente. Comprenda las razones de ser despedido (aunque parezcan más bien débiles). Evitar comportamientos similares que puedan desencadenar una reacción preprogramada tan pronto como sean reconocidos.