¿El desarrollo de software no es para mí? [cerrado]

Empecé a trabajar como desarrollador de software hace unos 7 años. Desde entonces he tenido múltiples posiciones diferentes en diferentes empresas.

Empecé en el departamento de software de una empresa de ingeniería donde el software es una pequeña parte del producto fabricado o simplemente respalda el proceso de fabricación. El primer proyecto en el que trabajé fue un gran programa de un solo hombre que se convirtió en un enorme desastre de software. Mi jefe en ese momento y el anterior "one man" no estaban interesados ​​en cambiar las cosas, ni mi jefe me permitió hacer las cosas de manera diferente. Fue muy frustrante.
Como recién llegado, traté de aceptar el hecho de que así son las cosas y viví con ello durante algún tiempo. Más tarde me comuniqué con el jefe de mi jefe (lo llamaré Tom) sobre la situación en la que me encontraba y le dije que no cumple con las expectativas de cómo quiero escribir software.

En el transcurso de un año tuve varias reuniones con Tom donde yo y un compañero de trabajo (que se unió al equipo mientras tanto) discutimos la situación y qué se podía hacer para mejorarla. De hecho, esperaba que Tom, en algún momento, sacara a mi jefe y reevaluara quién iba a liderar el barco.
Lamentablemente, esto nunca sucedió (al menos no mientras estuve allí; no pasó mucho tiempo después de eso, cuando el compañero de trabajo mencionado y yo renunciamos).
En realidad no pasó mucho en absoluto. Nunca le dije a Tom que esperaba que las cosas cambiaran radicalmente. Que en la revisión debería haber hecho absolutamente.

En algún momento de una charla con Tom me dijo que lo hiciera como yo pensaba, sin discutirlo con mi jefe, y que si había algún problema, simplemente le dijera a mi jefe que así lo discutimos con él. . En este punto me di cuenta de que Tom estaba fallando en sus responsabilidades de liderazgo al obligarme a pasar por alto a mi jefe. Así que renuncié.

Ahora, unos años y algunas posiciones frustrantes muy similares más tarde, estoy nuevamente atrapado en un proyecto que ha crecido durante muchos años, donde tengo la sensación de que soy el único que está interesado en limpiar el desorden paso a paso. mientras que mi nuevo jefe nuevamente no está interesado en ir en esa dirección.
Y nuevamente, las reuniones en las que trato de señalar que debemos comenzar a crear software limpio nunca son seguidas por ninguna acción. Y nuevamente, las reuniones deben realizarse con "Tom" porque no puedo tener una discusión constructiva cuando me comunico directamente con mi jefe.

Ahora empiezo a cuestionar mi elección de carrera. Tal vez no estoy hecho para ser un desarrollador de software. Simplemente no puedo aceptar la decisión generalizada (tal como la encontré) de escribir software malo y arreglarlo más tarde (lo que, por supuesto, nunca sucede).

¿Acabo de tener mala suerte con las empresas a las que me uní, o no dejé lo suficientemente claro que no es así como quiero hacerlo? ¿O lo están haciendo bien y necesito cambiar mi dominio a algo diferente (diseño, gestión de proyectos, lo que sea).

@DarkMatter Leí la publicación hace un mes, y estoy totalmente de acuerdo. No sé si lo escribí de esa manera, pero no tengo absolutamente ninguna intención de reescribir un software desde cero. Quiero que la gente se mueva en una dirección. No dar vuelta en U

Respuestas (3)

Enhorabuena, acaba de descubrir cómo es más del 90 % del software empresarial.

Estabas en el lugar equivocado para aplicar tus habilidades. Estas empresas (que constituyen la mayoría de las empresas, que a su vez constituyen la mayor parte del software en producción) no se preocupan por la deuda técnica porque no contribuye a su resultado final, o al menos no lo ven así. forma.

Puede tratar de persuadir a sus superiores de lo contrario, pero es una empresa ingrata porque probablemente estén entrenados para no pensar de esa manera. Además, tienes un tipo de One Man Software que ha estado allí durante años y ahora estás jugando con su juguete. No te metas con los juguetes de otras personas.

Yo estaba en una posición similar donde vendimos un producto de software que sufría de una deuda técnica equivalente a la deuda fiscal de Grecia, y muy pocos indicios de que las cosas fueran al revés*. El ambiente estable y de bajo estrés lo convirtió en un lugar ideal para jubilarse, pero para un joven desarrollador que recién comenzaba, no era para mí.

Dejé ese trabajo y me uní a una consultoría en la que puedo trabajar en nuevos proyectos cada año más o menos, y podemos usar las últimas y mejores tecnologías siempre que podemos.

Entonces, no, no estás en la profesión equivocada, solo en la compañía equivocada.

* Trajeron fondos de capital de riesgo mientras yo me iba y la nueva afluencia de efectivo, junto con las quejas constantes de la mayoría de los desarrolladores, convencieron a la gerencia de hacer sus productos principales desde cero y poner los productos actuales en modo de mantenimiento con un desarrollo limitado. Me alegró mucho escuchar eso y deseé que el proceso hubiera comenzado mientras estaba allí para poder trabajar en ello, pero no regresaría.

Estas empresas no se preocupan por la deuda técnica porque no se suma a sus resultados . No tienes que dar una razón. Simplemente no les importa. período.

tl;dr Por el contrario, debe comenzar a preguntarse si ser ingeniero de software es la carrera correcta cuando deja de preocuparse por la calidad.

Hay buenos libros sobre cómo lidiar con el software heredado (por ejemplo, el siempre verde Trabajar de manera efectiva con el código heredado ); el punto es que no tienes que PEDIR escribir un buen software como no tienes que pedir probar el código que escribes. Refactorizar y mejorar la calidad del código existente casi siempre es parte del proceso de mantenimiento, ya que escribir pruebas también es parte de la entrega de una nueva función. Relacionado e interesante: Como desarrollador; No tener tiempo para probar, recibir plazos extremos y no ser escuchado por el gerente .

Puede huir cada vez, persiguiendo la quimera perfecta de la compañía con la base de código perfecta (o proyectos siempre nuevos sin ningún legado). Alternativamente, puede aceptar este desafío y agregar su propio valor profesional a la empresa para la que trabaja.

Trabajar en proyectos más antiguos también le enseñará lecciones extremadamente importantes sobre escalabilidad, confiabilidad y mantenibilidad que nunca aprenderá si continúa cambiando a nuevos proyectos cada año más o menos.

Lo que puede mejorar es su enfoque del problema. En primer lugar, debe comprender que la deuda técnica es intrínseca en casi todos los proyectos de software, este es un punto fundamental y no puede cambiarlo. Como ya sabes una deuda técnica puede ser alta por muchas razones:

  • El proyecto comenzó como un prototipo (si no solo como una prueba de concepto) y luego evolucionó con el tiempo. Puede ser por una mala elección de SE o por una elección comercial (no hay tiempo para reescribir algo que más o menos funciona ).
  • El proyecto comenzó como una herramienta simple y evolucionó hasta convertirse en algo demasiado grande para adaptarse a la arquitectura/diseño original. Esto generalmente sucede en pequeños pasos donde el código se sale de control progresivamente.
  • El código fuente fue originalmente escrito o mantenido por alguien con un conjunto de habilidades menos que óptimo.
  • El código fuente ha sido bien escrito pero es antiguo, la tecnología y las mejores prácticas evolucionaron lo suficiente como para que sea "obsoleto" pero aún funcional.
  • Independientemente de la calidad del código fuente original, la presión comercial aplicada (por ejemplo, en un entorno de inicio) obligó a más y más deuda técnica.

Después de abrazar esta revelación, debe comprender cómo manejarla . A veces, una reescritura completa es una opción posible, pero, por lo general, debe explicar a sus gerentes cuál es el valor que esta gran inversión aportará a la empresa. Esto ha sido ampliamente discutido y no lo repetiré aquí, la estrategia correcta es ligeramente diferente para cada uno de los casos mencionados anteriormente. Este es el punto principal: un gerente no técnico (pero también técnico porque desde su posición verá las cosas desde un punto de vista diferente) no está en contra de la calidad pero necesita justificar la inversión , considere:

  • La reescritura es costosa y no proporciona resultados visibles a corto plazo, y es posible que ni siquiera tengan un presupuesto para esto.
  • Es un riesgo porque (seguro) introducirás nuevos errores.
  • Puede fallar, cualquier proyecto no trivial puede fallar (alguien incluso dice que la mayoría de los proyectos de software fallan) y luego tendrán el código base original y X meses de tiempo perdido (o un nuevo código base con el mismo, si no más). , problemas que el original.)

¿Qué hacer? Comience con la comunicación: en primer lugar, explique la situación , pero no se limite a despotricar sobre la calidad del código o nadie lo escuchará:

  • Esté preparado: brinde ejemplos de cuándo la mala calidad del código existente fue la fuente de algún problema de producción importante.
  • Esté preparado: proporcione algunas estimaciones diferentes de tareas simples que requirieron mucho más tiempo del que debería (nuevamente debido a la calidad del código existente).
  • Esté preparado para discutir una arquitectura potencial para la nueva implementación.
  • Esté preparado: proporcione una estimación salvaje (en esta etapa) pero educada.
  • Esté preparado: proporcione una hoja de ruta de cómo se puede llevar a cabo esta transición y qué recursos necesitará. Como señaló Stefan en un comentario , esto no necesita hacerse en un gran salto.

Si no están de acuerdo con dicha reescritura (bien podría estarlo), entonces debe adoptar un enfoque paso a paso como parte de sus deberes diarios.

Lo que puedes hacer es entender que es TU DEBER escribir un buen código con todas las restricciones dadas por tu gerencia (tiempo, presupuesto, recursos). Significa que DEBE:

  • Escribe pruebas cada vez que cambies algo.
  • Aplique técnicas básicas de refactorización local cada vez que agregue una característica o corrija un error.
  • Cuando se requieren grandes cambios, puede extender la refactorización a otros módulos/paquetes manteniéndolos tan pequeños como sea necesario para completar la tarea inmediata.
  • Programe, si es posible, algún tiempo de refactorización dentro del módulo cuando, después de que se haya completado la refactorización local, vea una oportunidad para limpiar un paso anterior.
  • Aplique todo lo anterior a los elementos colaterales (como la documentación, por ejemplo).
  • Repetir.

Itere suficientes veces y su base de código ahora será lo suficientemente buena . A veces, algunos cambios arquitectónicos importantes pueden necesitar aprobación porque son demasiado largos o complejos, pero cuando llegue a ese punto, probablemente ya tenga una base sólida.

Este es un proceso invisible, la calidad está en constante evolución pero no es necesariamente visible desde el exterior. Creo que esto es lo que Tom (el jefe del primer jefe) trató de decirte: "haz tu trabajo (¡paso a paso!) sin molestar a tu jefe, es tu deber y confío en que sabes cómo hacerlo (envíamelo si por el caso no entiende esto)". ¿Debería tener que hablarlo con tu jefe? No puedo decir, pero si haces tu trabajo de una manera no disruptiva, entonces el proceso es invisible y efectivo.

A veces ellos [la gerencia/el jefe] tienen la culpa, pero a menudo se trata de un problema de comunicación . Puede que desee leer Representación y tergiversación: Tufte y los ingenieros de Morton Thiokol en el Challenger y el texto original de Tufte en Explicaciones visuales: imágenes y cantidades, evidencia y narrativa .

Gracias por la respuesta, sé que el departamento técnico es intrínseco. Y no siento que esté huyendo de un código incorrecto, en todo caso, huyo de las personas a cargo que no puedo convencer para invertir tiempo en la calidad del código. No es el código lo que me frustra. Es la voluntad inexistente de arreglarlo.
Lo entiendo, pero USTED (y yo y probablemente casi todos los programadores) podemos entender la razón para invertir en la calidad del código. Mientras el software funcione , a los gerentes (y clientes) no les importa (¿es usted consciente, por ejemplo, de los procedimientos de diseño, y las regulaciones relativas, adoptadas por el fabricante del automóvil que está conduciendo?) Es por eso que tiene para mejorar gradualmente la calidad del código como parte de sus tareas diarias. Algunas veces, el código es tan complicado que es posible que deba volver a escribirlo (y eso deberá ser aprobado por la gerencia), pero generalmente es un proceso invisible.
Creo (pero es solo mi suposición) que esto es lo que Tom (el jefe del primer jefe) trató de decirte: haz lo que creas que debes hacer para cumplir con tu trabajo (porque bueno, él no sabe y no sabe Necesitar). La segunda parte de su oración fue desafortunada, pero debería leerla (en mi humilde opinión) como "en caso de que su jefe directo se queje, porque una tarea simple tomó más tiempo de lo esperado debido a la refactorización, entonces envíemelo, ni siquiera me molesto en explicarlo". él que así es como se deben hacer las cosas".
Con esto no digo que no sería genial si el CEO viene a nosotros y nos dice "Vi su código y se ve hermoso, gracias y este es el bono que se merece", pero la verdad es que solo su líder técnico directo lo sabe. sobre la calidad de su código y siempre se juzga (SIN EXCEPCIONES) junto con su valor comercial.
No estoy de acuerdo, no estoy hablando de "Administración", Tom y mi jefe son desarrolladores de software, deben conocer absolutamente el valor de la calidad. Pero no quieren cambiar nada, o usan algo como "sí, probablemente relanzaremos el software completo en unos años de todos modos". No conseguir que el equipo que no dirijo se mueva hacia él, porque no quiere.
A menos que los deberes de su jefe sean SÓLO técnicos (en este caso estoy de acuerdo, tiene al jefe equivocado), entonces él tiene que lidiar tanto con los requisitos comerciales como con el aspecto técnico. Es un compromiso (y algunas personas son fáciles de olvidar el aspecto técnico incluso si tienen experiencia técnica). Nuevamente, el punto es que no necesita PEDIR sino hacerlo porque es una parte fundamental de su trabajo. Si está trabajando en un equipo en el que todos tienen que centrarse más en la calidad, elija pruebas, números y soluciones. La calidad por sí sola no es una métrica sino una herramienta para lograr algo más.
Experiencia personal: a veces realmente necesitaba (y quería) reescribir algo desde cero (el peor caso posible desde una perspectiva empresarial). Lo primero que me han preguntado cada vez es "por qué" y luego inmediatamente "cuáles son las implicaciones si no lo hacemos" . Si está preparado con argumentos convincentes, entonces hay mejores posibilidades de hacerlo, si sus argumentos son débiles (o las razones comerciales son más fuertes)... entonces necesita ir paso a paso. Tenga en cuenta que incluso puede suceder que realmente no se preocupen por la calidad (¡qué vergüenza!), entonces las razones comerciales son la única herramienta que tiene.
Es solo un problema de comunicación . Incluso si es muy claro para usted, aún necesita convencerlos de que la inversión requerida vale la pena. Con el tiempo irás ganando confianza y será más fácil pero el problema de fondo sigue ahí. ¿Alguna vez leyó lo que Tufte escribió sobre el desastre del transbordador espacial Challenger?
Esto resume bien mi propia experiencia. Me gustaría resaltar que, en lugar de optar por The Big Rewrite, podría proponer mejoras paso a paso. Menos riesgo, más fácil de planificar en unos pocos pasos, obtiene al menos algunas mejoras y se siente mejor. Además, la primera Gran Reescritura suele fallar de un modo u otro. Lo he visto varias veces.
@StefanKamphausen Estoy de acuerdo, lo mencioné en la respuesta. Hacer las cosas paso a paso suele ser más fácil de justificar (incluso si requiere algo más de tiempo) y mucho menos arriesgado.
También vale la pena mencionar que la "compañía perfecta con la base de código perfecta" no existe. Cada decisión de diseño en el software viene con compensaciones. Pasar su tiempo refactorizando significa que no está gastando su tiempo agregando algún otro valor. Un patrón de diseño facilita algunas mejoras y dificulta otras. Su trabajo como ingeniero de software no es escribir un código "perfecto" (no puede), sino reconocer las ventajas y desventajas y hacer su mejor suposición en el equilibrio correcto.
Si desea "arreglar" el código, debe abordar un problema real. ¿Tiene errores que le están costando ingresos o bloqueando su línea de ayuda? ¿Va a hacer futuras mejoras o soporte más caro? ¿Está causando problemas de rendimiento que le están costando tiempo a su negocio? Esos son problemas que hay que arreglar. La calidad del código no es realmente un problema a menos que esté causando problemas. Su gerente quiere que usted resuelva problemas.

Sí, muchas de las empresas más grandes tienen grupos de "intocables" donde ingresa gente nueva y no quieren que rompas un producto "funcional". Lo vi en mi última empresa. Un pequeño grupo de personas desarrolló el software principal de la empresa. Todos ganaron posiciones gerenciales y gozaron de buena reputación con la alta gerencia. Contratan nuevos desarrolladores porque justificaron que necesitaban nuevos desarrolladores para continuar con el crecimiento del producto. Entra gente nueva, y el grupo original que lo hizo simplemente espera que los desarrolladores más nuevos trabajen en el producto de la manera que ellos quieren.

Es bastante común en empresas que entraron en algún nicho de mercado. En mi última empresa, nunca tuvieron ningún software o productos relacionados con TI y una vez que se mudaron a ese mercado, las personas que fueron contratadas originalmente triunfaron ya que se convirtieron en el grupo de referencia una vez que el software maduró. Ninguno de los altos directivos entiende cómo funciona el desarrollo de TI y confía en el grupo original de desarrolladores. Solo se preocupan por los ingresos y si están entrando. Se apresuran a despedir a cualquier nuevo gerente contratado que no cumpla con esta expectativa.

Tendrá que encontrar una empresa que no genere ganancias únicamente o encontrar una empresa bien establecida que siempre haya estado en el campo de TI con ejecutivos de TI y alta gerencia.

Por lo general, puede resolver esto sin preguntar directamente. Simplemente pregúntele al gerente principal cómo llegó a su puesto dentro de la empresa. Si te cuenta una historia como la anterior, entonces sabes qué esperar.

¿El desarrollo de software no es para mí? [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v