¿Es posible que esté dañando mi empleabilidad a largo plazo al quedarme en una empresa con una estructura terrible?

Trabajo como desarrollador de software, actualmente en mi primer trabajo fuera de la escuela. He estado trabajando aquí durante unos 15 meses. Para todos los efectos, nuestro "departamento" de software está en un caos absoluto. No tenemos tal cosa como calidad, revisión de código o pruebas de ningún tipo. No hay apariencia de un ciclo de vida del software. No hay nada como SCRUM ni nada parecido.

Esencialmente, donde habría varios equipos o al menos varias personas que abarcan diferentes puestos, considero cada puesto concebible relacionado con este proyecto de software. Se me consideraría desarrollador líder, gerente de proyecto y control de calidad; Me encargo del lanzamiento del producto y de la atención al cliente a partir de entonces. También tomo todas las decisiones de diseño generales para el software y las nuevas partes del software. La única persona que mira o administra el código de este proyecto soy yo. En un momento, para un proyecto algo separado, tuve un pasante universitario (pagado) trabajando debajo de mí, por lo que pude delegar algunas tareas.

Entonces, mi pregunta es, considerando que estoy trabajando en un entorno de software estructurado de manera muy incorrecta, ¿es posible que pasar mucho tiempo en este puesto haga que mis habilidades parezcan incompatibles con los lugares que están estructurados correctamente?

¿Suena mal para un empleador potencial si digo efectivamente que abarqué todos esos roles en mi puesto anterior? Sospecho que para una persona de recursos humanos que no esté demasiado familiarizada con el software, sonaría bien que yo fuera el único líder de todos esos puestos. Para otra persona en software, sospecho que puede sonarle negativamente.

Dado que algunas personas han preguntado, solo quería agregar que es una empresa pequeña, de unos 50 a 100 empleados, y el producto principal no es el software. También hay 3 divisiones en la empresa; Trabajo para uno de los 3, el más pequeño, en cuanto a empleados, pero casi igual en ventas. También, gracias a aquellos que se tomaron el tiempo para responder.

¿Por qué no tienes ninguna de esas estructuras en su lugar? Si usted es el único desarrollador, no parece que haya nada que le impida probar, usar SCRUM, etc., aparte de su propia falta de voluntad para hacerlo. Supongo que, como mínimo, prueba la nueva funcionalidad y corrige errores antes de dársela a los usuarios.
@Móż, ¿cuál es el sonido de una mano aplaudiendo? Hay mucho que una sola persona puede hacer. El OP no debe intentar cargar el culto a algo como scrum como una banda de un solo hombre. Tales prácticas tienen que ver con la coordinación de un EQUIPO en lugar de un individuo.
@ teego1967 mi punto es que, como desarrollador en solitario, puede hacer todas las cosas puramente internas del "equipo de desarrollo" que no implican gastar directamente el dinero de la empresa, e interactuar con la gerencia/clientes usando un enfoque SCRUM... si así lo desean. En mi opinión, al SCRUM que solo mira hacia adentro le falta la mitad de la imagen, pero obviamente no todos están de acuerdo.
¿Este trabajo es en una startup? Si no, ¿entonces es una pequeña empresa? De lo contrario, no tiene sentido que se espere que esté en tantas áreas con tan poca experiencia previa.
Al estar casi siempre en proyectos en los que soy el único desarrollador, mi posición es bastante cercana a la tuya. Entonces, para convertir esto en algo bueno con respecto a la motivación y su carrera, intente aprovecharlo al máximo: es la oportunidad perfecta para probar cosas nuevas como pruebas automáticas y detección de errores, evaluación comparativa de rendimiento, generación de documentación, control de versiones eficiente y cosas por el estilo. Aprenderás mucho y al final se trata más de lo que hiciste con esta situación que de cuál fue la situación.
@Móż Sí, ciertamente hago todas las pruebas que puedo hacer yo mismo antes de lanzar algo a un cliente y, en su mayor parte, he podido lanzar software sin errores. Lo he discutido con mi gerente varias veces y él alienta la colaboración cuando es relevante, pero, en realidad, los otros desarrolladores no tienen conocimiento de mi proyecto y yo no tengo conocimiento del suyo, por lo que la ayuda que podemos ofrecer cada uno otro es generalmente limitado. Como algunas personas han preguntado, es una pequeña empresa de unos 50-100 empleados. Lo he añadido a la publicación principal también.
No sé por qué esto está tratando de ser cerrado. No es "pedir consejo sobre qué hacer", simplemente pregunta si una percepción puede o no ser típica y probablemente con qué fin, si es clara y obvia.
Un poco fuera de tema, pero ¿usa el control de versiones ? Si no, eso es algo que puede hacer hoy para mejorar el estado de su departamento y adquirir una habilidad esencial para cuando cambie a un nuevo trabajo. ( Git es el más popular, se usa para mantener la base de código para el kernel de Linux, entre muchas otras cosas, aunque prefiero Mercurial ).
@iamnotmaynard Sí, desarrollo en Visual Studio y usamos TFS para el control de versiones.
Esto no es en absoluto una estructura poco común para una pequeña empresa. Y no, no te estás volviendo desempleado. Solo asegúrese de ser claro y honesto en su currículum sobre todo el trabajo que hizo y qué tan bien se desempeñó. Puedo decirte que habiendo trabajado como desarrollador en todo tipo de empresas, incluso dos empresas del mismo tamaño y con mucho dinero pueden tener estructuras de gestión y flujos de trabajo completamente diferentes.
Los stand-ups son geniales cuando eres la única persona en un proyecto. Puedes fingir que estás protagonizando Fight Club .

Respuestas (12)

No, no está arruinando sus posibilidades de ser empleable. De hecho, estás aumentando tus posibilidades. Si su lugar de trabajo está tan fuera de lo normal, ¿por qué no intenta implementar algunas de las cosas que dijo que le faltan a este lugar? No estoy hablando de usted, implementando sin ayuda un proceso SCRUM, pero un proceso de revisión de código entre pares no está demasiado fuera de discusión, independientemente del poco valor que aporte en dicho entorno.

Estas cosas pueden parecerle pequeñas, pero sacar a una organización de un caos total y ayudarla a llevarla a un nivel operativo, que cumpla con algunos estándares, es algo que puede poner con orgullo en su currículum y a los futuros empleadores les gustará que se haga cargo. actitud debido a esto.

Si vas con el flujo y reflujo y no haces nada, simplemente apareces, haces el mínimo absoluto para cobrar tu cheque de pago, entonces puedes temer por futuras oportunidades de empleo, ya que actuar así no contribuirá a tu desarrollo profesional.

En algunos puntos le comenté directamente a mi gerente que creo que el equipo de software trabajando más como un equipo nos beneficiaría a todos. Estuvo de acuerdo en que era una buena idea en general, pero no está del todo claro cómo llegamos allí. Solo tenemos 4 desarrolladores, 2 de los cuales han estado aquí por más de 20 años, por lo que su interés en cambiar el proceso es mínimo o inexistente. En realidad, esto se mencionó en una de mis revisiones de desempeño como algo positivo. Aunque lo tendré en cuenta para el futuro. Gracias por la respuesta.
@pay: si puedo darte un consejo: no solo hables sobre el cambio (a tus gerentes/colegas), hazlo. La gente siempre puede discutir sobre la ineficiencia teórica de lo que sugieres, pero es mucho más difícil de hacer cuando realmente demostraste que las cosas funcionaron. Además, cuando trato con personas que han existido durante mucho tiempo y no "quieren" un cambio, un truco que usé en el pasado es preguntarles (en forma aislada): "Oye, Bob, ¿cómo cambiarías eso?" para halagarlos. Luego puede referirse a la idea públicamente como "Bob y yo hemos hablado de esto y sentimos que podría tener valor hacerlo de esa manera, ¿verdad Bob?".
Estoy totalmente de acuerdo, pero me gustaría agregar algunas cosas. Cuando eres la única persona que dirige todo, aprendes mucho sobre todas esas cosas. No puedes hacerlos todos realmente bien, pero puedes hacerlos. Los comentarios de jack of all trades en las otras respuestas son ciertos. Pero lo que más se aprende es funcionar bien bajo presión . Esa es una habilidad invaluable que es realmente difícil de aprender, pero la tienes, porque eso es todo lo que sabes. Puede sonar terrible, pero en realidad te aburrirás en otras empresas. Este desorden caótico te está enseñando mucho. Sé agradecido, pero sigue adelante cuando estés demasiado cansado.
@pay, mi consejo (como alguien que ha cambiado los procesos de su empresa), es comenzar con la fruta al alcance de la mano, descubrir qué molesta a los poderes existentes (o está causando problemas graves actualmente) y recomendar las soluciones modernas para esos problemas. Hazlo poco a poco y, con el tiempo, la empresa aprenderá que tienes buenas ideas y los antiguos tendrán tiempo para adaptarse a cada cambio. Tómese su tiempo para aprender realmente lo que está defendiendo para que pueda ser un recurso para su empresa y explicar adecuadamente los porqués y los cómos.
@Pay, gracias por la pregunta, tengo la misma situación aquí. Comencé implementando la metodología yo mismo, incluida la escritura y la documentación de los requisitos al principio, un sistema simple de seguimiento de cambios/errores en las páginas wiki y un archivo de Word y también insistí en que otros compañeros de trabajo se reunieran regularmente en el proyecto, especialmente una gran reunión antes del inicio y otro casi cuando termine. Es muy difícil ser el niño bueno entre todos los traviesos y vagos.
@MelBurslan, ¡gracias por la buena respuesta y por haberme levantado la moral durante la semana! Por favor, mi comentario de arriba!
Ahora la pregunta más importante es ¿cómo resaltar esto en un currículum?
@Alex Sí, esa es en realidad una pregunta de seguimiento que tengo ahora. ¿Cuál es la mejor manera de representar este conjunto de habilidades a mis próximos empleadores potenciales? Tal vez debería hacer otra pregunta...
@Alex, de lo que estamos hablando no es particularmente un conjunto de habilidades sino más bien logros. En el proceso de entrevista de hoy, encontrará más y más preguntas como "Díganos cuáles son sus mayores logros en este puesto en este empleador. Esto le dará la oportunidad de promocionarse. En el currículum, bajo este empleador en particular". , puede crear una subsección titulada, gran sorpresa, logros y enumerar lo que hizo bajo este encabezado.
"un proceso de revisión de código entre compañeros no está demasiado fuera de discusión" ¿Va a pretender ser su propio compañero y revisar su propio código?
la revisión por pares, incluso para un equipo pequeño, le brinda una mirada fresca que simula su propia apariencia en su propio código en un futuro lejano. Te ayudará a arreglar los WTF mientras aún tienes el código base fresco en mente. Te sugiero que lo intentes. Simplemente algo como tener un colega en el que miren el código de los demás regularmente puede hacer maravillas.

No te harás daño a largo plazo a menos que empieces a beber el Flavor-Aid. (Algunos lo llamarán Kool-Aid. No han leído su historia ).

Todos tenemos "Ese trabajo" en nuestra historia en el que nada se configuró correctamente, no teníamos apoyo administrativo ni autoridad para lograr nada, pero de alguna manera logramos avanzar y lograr algo.

Eso es realmente una ventaja, a los ojos de muchas personas (incluido el mío). Hay muchas personas que tienen poca o ninguna habilidad y se esconden en la burocracia. Estas son las pesadillas de los gerentes de contratación. Usted desperdicia su presupuesto, no tiene mejoras en la productividad y la moral se hunde, sin embargo, contribuyen lo suficiente y siguen el procedimiento al pie de la letra hasta el punto de que no puede deshacerse de ellos. Cuando estoy contratando, esas son las personas que me dan pesadillas.

Usted, por otro lado, puede demostrar que logró sus tareas TOTALMENTE por su cuenta, e incluso con obstáculos significativos. Eres a quien quiero ver. No me preocupa tu productividad. Puede que tenga cierta preocupación sobre qué tan bien puede tomar la dirección, pero ese es un problema mucho menor que alguien que no quiere hacer nada.

Si les dices a las empresas para las que estás postulando que quieres ser parte de un equipo y que la rutina del "lobo solitario" no era lo que te hacía feliz, entonces saben que tienen lo mejor de ambos mundos: alguien que PUEDE hacer las cosas por su cuenta, pero QUIERE ser parte del equipo.

Ojalá estuviera contratando, ahora mismo. Le pediría que enviara su currículum.

"Sin apoyo administrativo, ni autoridad para lograr nada": debería haber mencionado que no diría que mi gerente es malo, en realidad es una parte tan importante de este sistema como yo, y no es una persona de software. En cuanto a la autoridad, también debería haber mencionado que efectivamente me dieron la autoridad de control total del producto. También soy responsable de todas las decisiones y cambios de diseño de software. En lo que a mí respecta, demasiada responsabilidad por la primera posición de alguien, sin embargo, estoy descubriendo que puedo manejarlo. Sin embargo, tu punto es correcto, realmente deseo trabajar en un verdadero ...
un equipo de software que intente hacer las cosas correctamente, y una empresa en la que el producto principal sea el software también estaría bien. Sin embargo, aprecio el impulso de confianza y la respuesta, gracias.
Sí, cuando estoy contratando, me gusta que los candidatos hayan trabajado en al menos una pequeña organización donde fueron analistas, diseñadores, programadores, probadores, implementadores, mantenedores, etc. ciclo completo de desarrollo de software" se supone que significa.
en realidad: "Las imágenes filmadas dentro del complejo antes de los eventos de noviembre muestran a Jones abriendo un cofre grande en el que se ven cajas de Flavor Aid y Kool-Aid". wikipedia
Sí, pero el lote final fue Flavor-Aid. Eso ha sido documentado.

Nadie va a creer seriamente que te has convertido en un experto en todos esos roles. ¿Los hiciste? Sí. ¿Los hiciste todos durante ocho horas al día? No. Por ejemplo, si su vía principal es el desarrollo, sería una tontería (y una pérdida de tiempo) solicitar un trabajo de control de calidad como "experto".

Su empleabilidad no se está dañando per se . Pero su moral caerá en picado cuanto más tiempo permanezca en esa posición llevando una carga tan pesada solo. Hacer cosas como actualizaciones de la plataforma en los principales sistemas resultará cada vez más difícil con el tiempo porque usted es el único que hace el trabajo. Es de su interés, a largo plazo, llegar a una posición en la que haya una división del trabajo más limpia, porque algún día, NECESITARÁ unas vacaciones en las que no lo llamen para solucionar problemas de producción (como nadie más puede hacerlo).

Cuidate".

Todo lo que dices es cierto, pero hay que tener en cuenta una cosa: todo lo que describe este póster original entra en la categoría de "primer trabajo fuera de la escuela". Lo que significa que esta posición apesta, pero no es sorprendente, es un desastre. Su consejo de moral también es correcto, pero el OP ha estado en el concierto durante 15 meses. Es decir, es hora de actualizar el currículum y solicitar trabajos para que el OP pueda aterrizar en un lugar mejor.
En 15 meses, le habría costado mucho adquirir experiencia en una sola área que menciona, pero solo en todas. Podrías identificar qué área disfrutas más y considerarte el mejor. Luego solicite trabajos donde esa habilidad sea la principal y mencione que las otras son habilidades adicionales.
Esto no es del todo exacto, porque las capacidades dependen de la persona, no de qué y cuánto tiempo estuvo haciendo. Una persona inteligente puede convertirse en poco tiempo en un experto en múltiples campos, mientras que otra persona (estúpida) no se volverá experta en un solo campo en toda su vida. Las empresas pagan cantidades increíbles de dinero por personas capacitadas en múltiples campos y luego se convierten en gerentes. Concéntrese en un solo y terminará en la parte inferior, experto o no experto.
Estoy de acuerdo en que no me consideraría un experto (todavía) realmente en la mayoría de estas áreas, pero he podido producir resultados efectivos con recursos mínimos para hacerlo. Además, a veces se hacen necesarias soluciones alternativas menos que deseables, por lo que, como algunos han dicho, el aprendiz de todos los oficios y el maestro de nada probablemente tenga sentido. Estaría feliz con una amplia gama de puestos, siempre y cuando me mantenga involucrado directamente en el proceso de desarrollo, ya que disfruto de la codificación.

Te preguntaría una cosa. ¿Cómo es vista la compañía por otros dentro de la industria?

Solía ​​contratar gente todo el tiempo dentro del área metropolitana de Washington DC para algunos de los sitios más exigentes en términos de habilidades y profesionalismo. Era bien sabido que algunas empresas no producen buenos empleados, independientemente del carácter del individuo. Lo siento. Pero es verdad. La reputación de algunas de las empresas locales en cuanto a estructura y entorno era mala debido a las personas que habían sido contratadas de esas empresas. Hablamos de consistencia y no de unos pocos. No toma mucho tiempo para que una mala reputación circule de esta manera. No tiene nada que ver con el individuo. Tiene que ver con la exposición de las personas a un entorno de trabajo profesional y su capacidad para entrar en un entorno estructurado y profesional y tener éxito. Las personas con habilidades y experiencia no trabajarían para estas empresas, y aquellos que cometieron el error de tomar un trabajo, se fueron rápidamente y pudieron salvar su carrera. No era raro escuchar a la gente comentar que no podían conseguir otro trabajo y tenían que quedarse con las malas compañías.

Tenga en cuenta que se trataba principalmente de empresas contratistas del gobierno que no pagaban nada bien y preferían el número de empleados a las habilidades para la facturación. Infierno. No era raro que pudieras hacer BS durante la entrevista, eso era suficiente. Puedes averiguarlo una vez que llegues allí. A la empresa no le importaba el cliente ni usted. Si acertó o fracasó, no importaba. Uno que conocía bien fue ascendido rápidamente a través de las filas debido a su habilidad en las habilidades de BSing y una vez que ya no le sirvió, se convirtió en el chivo expiatorio. También tenga en cuenta que no siempre se trata de contratación gubernamental o empresas más grandes. Algunas pequeñas empresas emergentes tienen una mala reputación por el negocio que realizan y el empleado también puede desgastar esa mancha.

Contraté a una persona de una de estas malas compañías que tuvo un gran éxito. Lo contraté porque decidió buscar otro trabajo cuando lo enviaron a su programa de capacitación gerencial y luego comprendió rápidamente por qué su gerente era tan pobre. Aparte de este individuo, todos los demás contratados por la empresa fallaron con bastante rapidez.

Quedarse demasiado tiempo puede perjudicarlo dependiendo de cómo otras empresas vean su empresa. De hecho, es posible que nunca tenga la oportunidad de demostrar que están equivocados. No era raro que las personas con XYZ en cualquier parte de su currículum fueran descartadas de inmediato. ¿Por qué? Porque la historia era siempre la misma. Triste.

Si bien puede adquirir habilidades en un entorno más pequeño, también puede hacerlo en un entorno más grande. Una empresa global a la que consulté alentaba habitualmente a las personas a adquirir habilidades y asumir desafíos fuera de su alcance. En el camino, los expertos y mentores estuvieron al alcance y se aseguraron de que el empleado tuviera éxito. La empresa tuvo tanto éxito que desafiaron a un empleado de soporte de escritorio bastante pobre para que se hiciera cargo de las redes y buscara las certificaciones de Cisco. En un año, se había convertido en el mejor ingeniero de redes que tenía la empresa. En serio. Despertó algo dentro del empleado que tomó el desafío muy en serio y se esforzó por ser lo mejor que podía ser. Tuvimos reuniones semanales en toda la empresa buscando específicamente las habilidades que faltaban en los proyectos y los empleados en otros proyectos que buscaban asumir el desafío y aprender algo nuevo. Otros se ofrecieron como voluntarios para ayudar a guiar al empleado hacia el éxito. Al final, todos los empleados de la empresa estaban expuestos a muchas cosas y, como resultado, eran mucho más valiosos y podían participar rápidamente en un proyecto cuando era necesario. ¡El concepto funcionó!

Conozco el problema de parecer tener demasiadas habilidades. Ahora estoy jubilado, sin embargo, era un ingeniero interno de sistemas con experiencia en codificación en todos los niveles, experiencia en diseño de hardware, junto con experiencia en productos y plataformas que hicieron que mi lista de umbrales fuera extremadamente larga. Si bien algunos dudaron de que esto fuera posible, otros lo consiguieron y me contrataron para escenarios de extrema responsabilidad y pude demostrar mi experiencia. Es una espada de doble filo. Lo mantendrá fuera de los trabajos en entornos limitantes y le abrirá las puertas en entornos expansivos. Pude consultar en los lugares más altos y hacer lo aparentemente imposible en muy poco tiempo, incluido ser pionero en nuevos usos de la tecnología con Bell Labs, DEC Labs, BT Labs, etc. No alardear. Solo le estoy diciendo que hay una ventaja en tener habilidades sólidas en el currículum, siempre que realmente pueda hacer las cosas que ha enumerado. Al final, las habilidades engendran habilidades y tendrás más demanda.

¡Esta es una excelente respuesta! Sin más información sobre su empresa actual, sospecho que podría tener la reputación de ser un desastre. Entonces, a menos que le guste ser un experto en todos los oficios, saltando de una crisis a otra, podría comenzar a concentrarse en un área para desarrollar su experiencia y comenzar a buscar cambiar de trabajo para una empresa más enfocada que tenga una mejor reputación.
Este es un enfoque muy interesante, gracias por la respuesta. En cuanto a cómo otros verían a esta empresa en la industria, bueno, los productos con los que trabajamos son extremadamente específicos, y la probabilidad de trabajar para otra empresa en esta área es mínima o nula. En cuanto a la percepción comercial general, la compañía se estableció en esta ciudad durante más de 30 años y ciertamente tiene una buena reputación, sin embargo, es probable que cambie de ciudad de todos modos. Cuando eso suceda, es probable que cualquier empresa con la que me entreviste nunca haya oído hablar de esta.
También habla sobre el aprendizaje y el crecimiento en un puesto, y en realidad he tenido la suerte de tener la oportunidad de aprender algunas tecnologías nuevas. Node.JS, Socket.IO, mucho más competentes con JavaScript ahora, etc. Esto se debió a que elegí estas tecnologías para un determinado proyecto específicamente para poder aprenderlas, así que, en ese sentido, he estado tratando de crear mis propias oportunidades para aprender.
Si bien esta es una excelente respuesta (+1), no descalificaría automáticamente a nadie de esa empresa (me doy cuenta de que no lo hizo). Probablemente descalificaría a cualquiera que solo haya trabajado para esa empresa. Pero aún valdría la pena considerar a alguien con mucha otra experiencia que se dejó engañar por un breve período allí.
@Mawg La mala reputación y la larga lista de personas que parecían fallar una y otra vez, aunque me doy cuenta de que no era el individuo, desafortunadamente, era una regla universal: no contrate a nadie de XYZ o ABC. Esto hizo que fuera casi imposible que alguien de estas empresas consiguiera un trabajo. En el mercado de DC, hubo muchas oportunidades para elegir la oportunidad equivocada. Me gustó elegir los destacados de todos modos. Ellos existieron. Sin embargo, con requisitos tan altos de mi parte, tuve que pasar por alto a las personas de estas empresas la mayor parte del tiempo, si no todo el tiempo. Triste. Muy triste. Todo se reduce a opciones.
@pay Parece que estás en una buena posición. Las habilidades pueden ser bastante fáciles de adquirir cuando te das cuenta de cuánto de lo que hacemos está relacionado. Por ejemplo, C, C+, C++, C#, Perl, PHP, Java, JavaScript, etc. están todos basados ​​en C o uno de sus derivados. ¿Protocolos? La misma cosa. ¿Controladores de dispositivo? Ellos tambien. Estaba dispuesto a saltar a áreas sin experiencia y, como resultado, hacer un trabajo profesional. Tuve la suerte de comenzar temprano como ingeniero interno de sistemas para una de las bases de instalación más grandes que existen. Mi nombre estaba en todas partes en la unidad del sistema operativo. Me ayudó a prepararme para el resto de mis 30 años.

Existe ese dicho que dice: "Aprendiz de todo y maestro de nada..." que se aplicaría a su escenario.

Es posible que esté haciendo todas las tareas que describe, pero incluso si es muy bueno haciéndolas todas, será difícil demostrárselo a un futuro empleador potencial.

Ahora, ¿eso significa que deberías abandonar el barco? Diablos no. En este punto, si este es su primer trabajo fuera de la universidad y solo tiene 15 meses en el puesto, lo está haciendo bien. La realidad es que casi todos los primeros conciertos recién salidos de la escuela son horribles, dispersos y desorganizados.

Dicho esto, 15 meses es el momento adecuado para que te concentres en las habilidades que quieres que sean el punto muerto en tu próximo puesto. Y una vez que sienta que tiene control sobre eso, entonces debe comenzar a solicitar puestos en otros lugares.

La realidad es que cualquier reclutador/persona de recursos humanos verá que eres bastante nuevo en el campo y te perdonará por tener un trabajo que está "en todo el mapa". Pero la clave de esto es cuando te entrevistas para otros puestos (diablos, incluso cuando estás preparando tu carta de presentación) debes dejar muy claro que quieres pasar a un nuevo rol que se centre en algún aspecto de tu habilidad.

Risita... "¿Tu primer trabajo fuera de la escuela?" Bueno, hay cosas que simplemente no te dicen en la escuela, y esta es una: "cómo los lugares de trabajo reales pueden estar (des)estructurados y (des)organizados". Pero se han escrito libros enteros sobre el tema. (No es coincidencia que muchos de ellos tengan la palabra Muerte en sus títulos).

No obstante: adáptese, lo mejor que pueda, a la (des)organización tal como actualmente (in)opera, y observe cuidadosamente. Le sugiero que mantenga sus ideas bastante cerca de su pecho, ya que, si bien tiene educación, aún no tiene mucha experiencia. Si comienza a "dejar caer ideas a diestro y siniestro", perderá credibilidad y paciencia, sin importar cuán bien intencionado pueda ser.

De vez en cuando... y lo reconocerá cuando lo vea... se le presentará una oportunidad genuina de hacer una sugerencia constructiva para una pequeña mejora del status quo. Algo que en realidad, de manera factible, puede ser implementado por el grupo. Elige algo pequeño y demuéstralo . A medida que gane el respeto de sus compañeros de trabajo y gerentes, tendrá la oportunidad de ser más un agente de cambio. Y, también es muy probable que te asciendan.

Verá, por desorganizado y caótico que le parezca su lugar de trabajo, esa organización está "haciendo su trabajo". Además, existe en un entorno más amplio (la empresa en general...), la mayoría de los cuales actualmente no está en condiciones de ver. Es por eso que usé cuidadosamente la palabra "observar". Como dicen, "se aprende mucho mirando".

Una última cosa a tener en cuenta es la cuestión del " riesgo comercial". Todos los gerentes están capacitados para minimizar el riesgo comercial, especialmente en TI. Comprenda que cada cambio implica una cierta cantidad de riesgo. (Y también lo hace el statu quo). Observe cómo su jefe toma decisiones y cómo las justifica, si elige explicarlas o justificarlas ante el grupo.

En mi opinión, "lejos de dañar su 'empleabilidad a largo plazo'", los asuntos de los que hablo son cosas que demasiados empleados nunca se molestan en aprender. Quienes lo hacen ... quienes entienden el lado humano y comercial de la tecnología de TI, así como el aspecto técnico en constante cambio, están "muy por encima del resto" en términos de empleabilidad. Son las personas difíciles de encontrar que se buscan.

La mayoría de los empleadores buscan personas en forma de T. Al tocar todos estos temas, está desarrollando la base amplia que necesita para ser un miembro eficaz del equipo.

En un momento determinado, también necesitará profundizar su conocimiento sobre un tema específico. Cuando haya encontrado su pasión, puede ser el momento de dejar a su empleador actual.

Mi consejo desde una posición similar:

Aprende a hacer preguntas.

¿Por qué frobnosticamos el widget?

Muy a menudo, en las organizaciones burocráticas más grandes, o incluso en las más pequeñas y mal administradas, hay una gran cantidad de inercia. Si trata de interponerse en el camino, se sentirá aplastado, frustrado, arrollado y agotado. No hagas eso.

En cambio, haga preguntas en cada oportunidad, pero practique sus preguntas primero, para que pueda sonar genuinamente inquisitivo. También practique ser capaz de decir: "Huh. Eso es interesante. ¡Está bien, gracias!" de una manera que no revele por su tono de voz o lenguaje corporal que usted piensa que la respuesta es totalmente idiota.

Una forma de hacerlo es fingir que en realidad no sabes nada durante la conversación y que sinceramente quieres saber. En algunos casos, terminarás sorprendido porque hay muy buenas razones para lo que sea que estén haciendo. Por supuesto, la mayoría de las veces será simplemente institucional.

Pero simplemente haciendo preguntas

¿Hemos considerado hacer que nuestra herramienta de implementación sea un proceso de un solo clic? ¿Sería posible guardar el diseño del proyecto y luego poder llamarlo con algo como http://deploy.example.com/job/42?target=dev ?

Puedes empezar a plantar semillas. Al plantar estas semillas, puede cambiar lentamente el curso de su organización.

Pero también prepárate para el hecho de que muchas cosas no cambiarán hasta que te hayas ido por muchos años. Practica ahora, y aprende todo lo que puedas, porque así cuando vayas a un lugar nuevo que ya tiene espíritu de aprender y mejorar, ya estarás en actitud de aprender.

Realmente me gustan algunos de los consejos aquí. Curiosamente, ya me he acostumbrado un poco a hacer algo de esto, particularmente fingir que no sé nada cuando alguien está explicando algo. Realmente parece que las cosas fluyen más fácilmente. ¿Y en la inercia? Sí. El jefe de la división en la que trabajo está constantemente en modo activo. ¿Vender algo que aún no existe? Eso está bien, ¡el pago puede hacerlo rápido!
En esos casos, asegúrese de que el jefe principal priorice su trabajo: la característica A tomará N minutos/horas/días, la característica B tomará M. Puedo completar la característica A o la característica B esta semana, ¿cuál le gustaría aplazar? ¿hasta la próxima semana? (y asegúrese de recibir esa confirmación por correo electrónico. Si se acercan para comunicarse verbalmente, envíeles un correo electrónico de seguimiento, Gracias, Head Honcho, según nuestra conversación verbal de esta mañana, comenzaré con la Función A y pospondré la B hasta la próxima semana.

Estoy en una posición bastante similar como desarrollador, pero las cosas han mejorado en los últimos tres años y creo que hay algunas cosas que puedes hacer:

  • Lo primero y más importante: entender el problema . Si tienes problemas que resolver, necesitas conocer su estructura y sus orígenes más profundos. En mi caso, las cosas estaban desorganizadas solo porque nadie sabía cómo hacerlo mejor, porque los propietarios de la empresa eran ingenieros de automatización con poca o ninguna experiencia en ingeniería de software moderna. Ni siquiera podían articular o reconocer los problemas que estaban a punto de enfrentar (debido a la escalabilidad, la rigidez, el código podrido, etc.);
  • Estudia un montón. Busque libros que hablen sobre los problemas que enfrenta. Y también para libros de superación profesional. El que creo que deberías leer primero es "The Clean Coder", de Bob Martin, en concreto los capítulos sobre "cómo decir SÍ y cómo decir NO profesionalmente". Estos consejos me habían cambiado para siempre, con un impacto inmediato en los procesos de mi empresa, ¡y ni siquiera lo sabían!
  • Con estos consejos de "cómo decir no" en la mano, puede comenzar a demostrar a sus empleadores que están tirando dinero a la basura y al mismo tiempo ejercer una presión significativa al proponer actitudes muy pragmáticas para revertir la situación. En mi caso, eso significó mucha evangelización hacia una orientación cada vez más ágil de nuestro proceso de desarrollo de software, incluido el presupuesto para un consultor y la contratación de un desarrollador más a quien ayudé a entrevistar.

La profesionalidad está en ti, no en tu entorno. Si puede demostrar de alguna manera que su presencia en un entorno hace que la entropía desaparezca, ¡apuesto a que cualquier empleador para el que valga la pena trabajar lo considerará un guardián inmediato!

La ventaja de su situación que no veo mencionada todavía es que está adquiriendo una base de habilidades más amplia y más habilidades que de otro modo tendría. No solo sabe cómo escribir código, lo que hacen todos los desarrolladores de software (o al menos afirman poder hacerlo en sus currículums), también tiene habilidades de liderazgo de equipo, control de calidad, gestión de proyectos, gestión de productos y atención al cliente que el la mayoría de sus pares no tienen y no reclaman, que puede usar para diferenciarse de su competencia cuando sea el momento de seguir adelante.

Hablando de diferenciadores, poder hacerlo como una operación de un solo hombre es importante, como se menciona en otra respuesta . Demuestra que realmente puede obtener resultados y no está aprovechando el trabajo de otros, y vale la pena resaltarlo en su currículum. Soy un fanático de poner "único [puesto de trabajo]" en mi currículum / CV para demostrar ese punto.

Creo que también vale la pena señalar nuevamente que tiene la oportunidad de cambiar las cosas para mejor en su entorno actual, lo cual no es común ni fácil en entornos grandes y establecidos, y se ve muy bien en un currículum. Piense en su próximo trabajo por un momento y considere que cualquiera que sea un candidato serio para un puesto de desarrollo tendrá (o reclamará) habilidades básicas de desarrollo. Poder agregar que creó un proceso de revisión de código y un sistema de control de calidad, etc., en su empleador actual es algo que lo diferenciará de la mayoría de los demás candidatos.

Lejos de perjudicar su futura empleabilidad, este puesto es probablemente un impulso para su carrera. Después de algunos años allí, además de las habilidades básicas que tiene y mejorará, tendrá logros diferenciadores y habilidades de apoyo que la mayoría de sus colegas no tendrán.

Sugeriría buscar un nuevo empleador de inmediato. Cualquier empresa (en cualquier industria, de cualquier tamaño) que permita que tanta responsabilidad recaiga sobre alguien que "fuera de la escuela" durante un período sostenido obviamente está muy mal administrada. Se refleja muy mal en quien tomó esa decisión y en todos los de arriba y abajo de la cadena que la han seguido durante 15 meses.

Las analogías de la industria automotriz a menudo son útiles: diría que usted es un mecánico recién egresado de la escuela que se espera que diagnostique y repare todas las fallas en todos los automóviles sin supervisión o un manual de servicio, verifique la seguridad de su propio trabajo e incluso maneje todos las interacciones con los clientes.

¿Llevarías tu auto a que lo revisen en ese taller?

Obviamente tienes algo de potencial, así que tómalo de alguien en el otro extremo de su carrera: la vida es demasiado corta para desperdiciar la mayor parte de tus horas de vigilia trabajando en una organización tan mal administrada.

Mi primer trabajo como desarrollador fue muy similar. Yo era el desarrollador y tuve que usar muchos sombreros diferentes.

Nadie lo verá negativamente por eso, muchos empleadores lo verán como algo positivo.

Sin embargo, dices:

nuestro "departamento" de software es un desastre absoluto. No tenemos tal cosa como calidad, revisión de código o pruebas de ningún tipo. No hay apariencia de un ciclo de vida del software. No hay nada como SCRUM ni nada parecido.

Sigues diciendo:

Doy cuenta de todos los puestos imaginables relacionados con este proyecto de software. Se me consideraría desarrollador líder, gerente de proyecto y control de calidad; Me encargo del lanzamiento del producto y de la atención al cliente a partir de entonces. También tomo todas las decisiones de diseño generales para el software y las nuevas partes del software. La única persona que mira o administra el código de este proyecto soy yo. En un momento, para un proyecto algo separado, tuve un pasante universitario (pagado) trabajando debajo de mí, por lo que pude delegar algunas tareas.

Parece que implementar cosas como Scrum y revisiones de código depende de usted. ¿Has considerado, por ejemplo:

  • Decirle a su gerente que desea que el equipo tenga una reunión de pie todos los días
  • Implementar algún tipo de software de administración de tareas y pedirles a sus colegas que lo usen (yo uso Asana)
  • La próxima vez que obtenga un pasante, tómese el tiempo para hacer revisiones de código con ellos.

Potencialmente, usted podría ser la persona que tome este caos y aplique alguna estructura, y eso se vería genial para los futuros empleadores.

No se preocupe por las personas que dudan de su conjunto de habilidades, y si realmente hizo X, Y y Z. Solo concéntrese en ser realmente bueno en esas habilidades, y siempre será empleable.