¿Son mis experiencias negativas de pasantías representativas del mundo real? [cerrado]

Tengo curiosidad por saber si mis experiencias actuales como pasante son representativas de la industria real.

Como antecedentes, pasé por la mejor parte de dos especialidades en computación y una especialización en matemáticas en una universidad importante; He mejorado todas las clases y las he adorado todas, así que me gustaría pensar que no soy terrible en la programación. Obtuve una pasantía en una de las principales compañías de software y, a mitad de camino, ahora estoy sorprendido por la extraordinariamente baja calidad del código. Los comentarios no existen, todo es código de espagueti y todo lo que podría estar mal es aún peor. He hecho un montón de tutorías / TA, así que estoy muy acostumbrado a leer códigos incorrectos, pero los principales productos de la industria que he visto superan todo eso. Trabajo 10-12 horas al día y nunca siento que voy a llegar a ningún lado, porque ' s horas interminables de tratar de descubrir una API indocumentada o determinar el comportamiento de alguna otra parte del producto (completamente indocumentado). He dejado el trabajo odiando el trabajo todos los días hasta ahora, y deseo desesperadamente saber si esto es lo que me depara el resto de mi vida.

¿Saqué un trago corto en las pasantías (los cheques de pago absurdamente grandes implican que no es una posición de baja calidad), o es así como es el mundo real?

Lo llaman el Mundo Real ™ por una razón.

El 99% de lo que encontrará en el mundo corporativo real se considerará basura, y por una buena razón lo explicaré. El 1% que no se considera basura se convertirá en basura eventualmente.

# 1 Escribir código, # 2 ????, # 3 Beneficio!

En primer lugar, las empresas existen para obtener ganancias, no existen para generar montañas de código académico impecablemente diseñado y perfectamente teórico, alojado en depósitos dorados de perfección. Ni siquiera cerca, ni siquiera los que están en el negocio de vender el código fuente que producen.

En el mundo de los negocios, el código es un medio para un fin . Si algún código resuelve un problema comercial y genera más dinero del que cuesta crear y mantener, entonces es deseable para el negocio. Emplearlo para escribir código es solo una forma para que la empresa obtenga el código.

Teoría 0 - Práctica ∞

Idealmente, el mantenimiento debería ser más preocupante, pero generalmente no lo es, porque a corto plazo no gana financieramente. A largo plazo, el software generalmente tiene un ciclo de vida relativamente corto, especialmente las aplicaciones basadas en la web, se vuelven obsoletas rápidamente y se reescriben con mayor frecuencia.

Las aplicaciones internas de la línea de negocios son las que funcionan como lo que se percibe como un sinfín de proyectos de zombies debido a muchas razones basadas en el impulso. Estos proyectos son en realidad éxitos que continúan porque continúan haciendo que el negocio sea una ganancia.

En teoría no hay diferencia entre teoría y práctica. En la práctica hay. - Yogi Berra

En teoría, las bases de códigos impecables perfectamente diseñadas con una cobertura del código del 100% deberían ahorrarle dinero a las empresas, en la práctica ni siquiera se acerca a entregar algo cercano a un retorno válido de la inversión.

Física del ciclo de vida del software

También existe una fuerza de entropía súper poderosa en el mundo del software. Es un agujero negro de inevitabilidad que condena a todo el software a degenerar en una Gran Bola de Barro .

Cuanto más empiece desde un BBM , mejor, pero todos los sistemas de software llegarán allí con el tiempo suficiente. La rapidez con que se acerque al 100% de entropía está determinada por el punto de partida y la rapidez con la que acumula la deuda técnica y qué tan alto es el interés en ella.

Los sistemas de software se degeneran y se pudren debido al mantenimiento, no a la falta de este. Un sistema que lleva años funcionando sin cambios de código por definición cumple con todos sus requisitos y objetivos y es un éxito.

Los sistemas que requieren un cambio constante porque comenzaron más cerca de la entropía máxima son los que se tocan y empujan constantemente, y es el mantenimiento el que acelera el cambio negativo.

Lo suficientemente bueno es lo suficientemente bueno

Los sistemas de ciclo de vida corto, como los sitios web que cambian constantemente, no se benefician del costoso diseño inicial del 100% de cobertura del código en las pruebas unitarias, porque el tiempo de amortización es demasiado corto para recuperar los costos.

Los sistemas de ciclo de vida largo como la línea interna de aplicaciones comerciales mencionadas anteriormente, tampoco se benefician realmente de las inversiones masivas de las pruebas unitarias de cobertura de código del 100%, porque la tasa de cambio a lo largo de la vida del proyecto se aproxima a una constante que es casi cero en un moda no lineal.

Es por eso que los planes para el final de la vida son más importantes y los sistemas de reemplazo deben planificarse justo cuando se está lanzando algo, no cuando ha pasado su mejor momento por algunos años y no es compatible, por lo que se debe poner en marcha un nuevo sistema.

Hasta donde yo sé, no enseñan sobre BBM, nunca me he encontrado con un recién graduado de CS que supiera lo que era, y mucho menos por qué sucede.

Es por eso que lo suficientemente bueno es lo suficientemente bueno , cualquier cosa más o menos no lo es.

Software Slumlords

Hay señores de los barrios marginales de bienes raíces por una razón, obtienen ganancias con los edificios de chabolas que poseen. Ganan más de lo que gastan en el mantenimiento incremental de la propiedad deteriorada. Si no lo hicieran, derribarían el edificio y lo reemplazarían. Pero no lo hacen, porque los costos incrementales son mucho menores que la revisión o la sustitución de todo el edificio. También hay clientes (inquilinos) que están dispuestos a pagar por la propiedad deteriorada.

Ningún propietario del edificio, señor de los barrios marginales o no, va a gastar dinero en una propiedad solo por alguna noción académica de perfección que no se traduce en una ganancia sustancial sobre el costo asociado.

Ningún cliente pagará las actualizaciones de un sistema de software que les funcione de manera aceptable. Ningún negocio va a gastar dinero solo en escribir y reescribir código sin obtener ganancias sustanciales.

Microsoft es el slumlord de software más dominado y exitoso que existe. Windows no comenzó a recibir reescrituras fundamentales importantes hasta hace muy poco. Y todavía no han eliminado todo el código heredado del núcleo. Para ellos no tiene sentido comercial, las personas están más que dispuestas a aceptar el bajo nivel de expectativas que han establecido en la última década.

Pronóstico

Este ha sido un patrón durante más de 20 años en el desarrollo de software. No va a cambiar en el corto plazo. Esta no es la forma en que la gente quiere que esté fuera de algún sistema de creencias, es una realidad de fuerzas externas en un negocio. El negocio impulsa la toma de decisiones, las ganancias no son malas, pagan su salario, la visión a corto o largo plazo es irrelevante, esta es una industria a corto plazo de cambio constante por definición. Cualquiera que defienda lo suficientemente bueno como para obtener ganancias no entiende los negocios.

Pasé 15 años consultando y aprendí muy rápido que lo suficientemente bueno era eso, cualquier otra cosa me estaba costando dinero. Sí, quería que las cosas fueran perfectas, pero a menos que esté vendiendo una base de código, que el 99.99999% del tiempo está vendiendo una solución , todo ese código perfecto, limpio, organizado y elegante se pierde y simplemente pierde su tiempo, nunca se le reembolsará .

Progreso y esperanza

Las metodologías ágiles son un buen paso en la dirección correcta, al menos filosóficamente. Abordan el caos y el cambio constante como ciudadanos de primera clase y lo aceptan. Rechazan las prácticas dogmáticas, reconociendo que las metodologías y prácticas deben cambiar, así como los requisitos y las tecnologías.

Ellos aceptan la entropía que se introduce por la falta de tiempo o cambios en los requisitos, el personal y el cambio de la vida de la conexión de un sistema de software con el concepto de la deuda técnica.

Pero Agile no es una panacea, no va a cambiar las leyes fundamentales de la física y las bases del código se pudrirán de todos modos. Depende de la gerencia planificar lidiar con la podredumbre antes de que se salga completamente de control y no se pueda manejar.

Ágil cuando se hace correctamente, ayuda a gestionar la entropía, ralentizarla, rastrearla, medirla y tratarla de manera planificada. ¡No lo detendrá!

Desición de carrera

Si este es un problema filosófico real para usted, probablemente debería considerar otras opciones de carrera, porque la forma en que funcionan las cosas tiene un mérito comercial válido. Los proyectos de código abierto no tienen un mejor historial, y en muchos casos el código es aún peor que la mayoría del código corporativo que he visto.

Tengo curiosidad por saber si mis experiencias actuales como pasante son representativas de la industria real.

No, no es. Es representativo de su nivel de carrera y experiencia. Todo es parte del aprendizaje sobre cómo funcionan las empresas desde una perspectiva interna de control de calidad.

Como antecedentes, he superado la mejor parte de dos especialidades en computación y una especialización en matemáticas en una universidad importante; Asistí a todas las clases y las adoré, así que me gustaría pensar que no soy terrible en la programación. Obtuve una pasantía en una de las principales compañías de software y, a mitad de camino, ahora estoy sorprendido por la extraordinariamente baja calidad del código.

Sus habilidades, su experiencia, su educación no tienen impacto en la calidad del trabajo realizado por otros. Simplemente porque no tiene la autoridad para cambiar esas prácticas. No importa si eras bueno o malo en la universidad. Eso no cambia la forma en que opera la compañía para la que trabaja actualmente. Entonces, aunque es genial, tienes todo este trasfondo. Es realmente para su propio beneficio y no el de ellos. Por eso es importante estudiar lo que amas.

Obtuve una pasantía en una de las principales compañías de software y, a mitad de camino, ahora estoy sorprendido por la extraordinariamente baja calidad del código. Los comentarios no existen, todo es código de espagueti y todo lo que podría estar mal es aún peor. He hecho un montón de tutorías / TA, así que estoy muy acostumbrado a leer códigos incorrectos, pero los principales productos de la industria que he visto superan todo eso.

Lo que he aprendido en mis muchos años de programación es que hay una diferencia entre "calidad de código" y "código aceptable". La verdad es que, o alguien con autoridad encuentra el código fuente en condiciones aceptables, o lo encuentra inaceptable pero necesario. Si bien sería bueno que todos pudiéramos limpiar los proyectos en los que nos involucramos. A menudo no está en el interés o presupuesto de las empresas asignar recursos para hacer ese trabajo. Se pueden hacer argumentos lógicos hasta que salga el sol al día siguiente por qué esto sería bueno arreglarlo, pero cuando la gerencia ha decidido que el estado actual es "aceptable", entonces se puede hacer poco. Todo está directamente relacionado con quién dirige las cosas. O valoran la buena calidad interna o no. Claramente lo valoras y, por lo tanto, este estado actual te molesta.

Encontrará ejemplos de este tipo de problemas en cualquier industria que dependa del control de calidad interno. Desde el desarrollo de software hasta la fabricación. Debe aprender a ver esto no como un problema, sino simplemente como la condición actual de su código fuente. Así es como es, toma X cantidad de minutos encontrar algo, toma X cantidad de minutos arreglar algo.

Al negocio no le importa este tiempo extra o lo considera aceptable.

Trabajo de 10 a 12 horas al día y nunca siento que llegue a ninguna parte, porque son horas interminables de tratar de descubrir una API indocumentada o determinar el comportamiento de alguna otra parte del producto (completamente indocumentado). He dejado el trabajo odiando el trabajo todos los días hasta el momento, y deseo desesperadamente saber si esto es lo que me depara el resto de mi vida.

¿Por qué era aceptable que pasaras largas horas en la universidad para estudiar una asignatura, pero ahora no es aceptable dedicar largas horas para estudiar el código fuente? Estoy seguro de que la razón por la que el empleador lo contrató fue porque pensaron que podría manejarlo.

Déjame darte un consejo. Los buenos desarrolladores saben cuándo pedir ayuda a sus compañeros de equipo. No pienses que las respuestas siempre están en el código. Me he ahorrado horas de tiempo simplemente haciendo algunas preguntas a las personas. Parece que necesitas ayuda para llegar a la velocidad.

En segundo lugar, no conocemos las condiciones de trabajo. Trabajar largas horas es una realidad en muchas industrias. Que debes resolver por tu cuenta, pero te puedo decir. Odiar tu trabajo nunca es una buena señal. Debes lidiar con ese sentimiento y llegar a la raíz del mismo. Lamento que encuentre esta experiencia negativa.

¿Saqué un trago corto en las pasantías (los cheques de pago absurdamente grandes implican que no es una posición de baja calidad), o es así como es el mundo real?

Le iba muy bien en la escuela, pero ahora tiene una pasantía y no le va tan bien. Parece que ya estás en el mundo real. Eso es parte de la vida. La pregunta es, ¿qué vas a hacer al respecto? Que mi amigo, es lo único que importa. No podemos decirte qué hacer. Tienes que tomar tu propia decisión.

Puedo decirle que parece que su experiencia a su edad fue mucho mejor que cualquier oportunidad que tuve. La vida para mí en los años 90 fue una lucha para pagar el alquiler y encontrar mi próximo contrato. Considérate afortunado.

Después de 25 años y una variedad de empresas e industrias, puedo decir:
Sí, es bastante común.
Esta es la razón por la cual a los ingenieros se les paga bastante bien, por lo general, tienen que ser buenos para encontrarse con desordenados problemas y aún así poder hacer cambios mientras se resisten al deseo apremiante de refactorizar todo el asunto y descubrir qué demonios se supone que es realmente haciendo. Lancé la emoción por ti allí: ¡es normal sentir lo mismo por el código que encuentras!

El código que ve a menudo habrá pasado por infinitas iteraciones de diferentes programadores con diferentes enfoques y estándares y diferentes convenciones de nomenclatura, etc.

Sin embargo, lo que sucede es que la presión $ siempre está activa. Siempre es tentador describir cómo y por qué un mejor código es la única forma a largo plazo, pero en una gran cantidad de trabajos, el tiempo corre para una solución de solución rápida a corto plazo. Solo lleva 1 ingeniero poco tiempo destruir los estándares en un proyecto. Se necesita un gerente muy bueno que sepa cómo prevenir esto y defender el enfoque correcto (cuando sea razonablemente posible) para abordarlo realmente.

Una cosa es segura, el término "buen código" es demasiado subjetivo para ser útil. No es subjetivo para usted, por supuesto, puede enumerar los motivos / artículos específicos. Sin embargo, otras personas se enumeran diferentes elementos y prioridades, algunos ni siquiera técnica, que se cree son importantes, y por lo tanto es subjetiva.

Al igual que Drekka, esto está empezando a sonar deprimente, así que déjame intentar ser un poco más positivo, porque ciertamente es cierto que:

• Hay organizaciones, a menudo con los componentes técnicos más grandes que están haciendo lo correcto.
• Cuanto más nueva es la compañía ... y el código ... más limpio tiende a ser. el espagueti crece debido al tiempo y a las personas.
• Algunas personas hacen TDD y BDD, otras no. El rango es enorme.
• Después de aproximadamente 10 años, actualmente, toda la base tecnológica cambia para que aquellos que permanecen en la industria puedan tener dificultades para mantenerse al día como lo hacen los novatos.

Finalmente, como señala Anthony Blake, siempre hay 3 factores: tiempo, costo y calidad.
Me gusta la expresión relacionada: "elegir 2" !

Hay muchas opiniones sobre esto porque las experiencias de cada persona son diferentes.

Lo mío es que aproximadamente la mitad de los desarrolladores que encuentro están bien intencionados, pero tienen una habilidad promedio. Hay un pequeño grupo de personas brillantes en la parte superior, y un pequeño grupo en la parte inferior que lo intenta pero que básicamente debería hacer algo más porque realmente no lo entiende. Desafortunadamente, también hay otro pequeño grupo de tontos incompetentes que piensan que son mucho más inteligentes que los demás y que generalmente no saben cómo debería seguirlos.

En cuanto al proyecto, he realizado muchos trabajos e inmediatamente me pidieron que "cuide" algún proyecto establecido, generalmente uno que la empresa acaba de descubrir que realmente necesita después de perder al último desarrollador. Por lo general, encuentro exactamente lo que ha esbozado anteriormente: espagueti indocumentado, sobredimensionado y con errores. A veces puedo arreglarlo, a veces solo comienzo de nuevo. Ni siquiera tiene que ser un código antiguo, he encontrado esto en nuevos proyectos en los que también me han pedido que "ayude".

Tienes que alegrarte del hecho de que la mayoría de las empresas van a dar a los pasantes los trabajos malos. Los más divertidos vienen después de que hayas hecho dos cosas: 1 - probándote a ti mismo y 2 - hiciste algo de tiempo para trabajar en otras cosas además de corregir los errores de otras personas. En otras palabras, tienes que mostrar habilidad e iniciativa.

El verdadero truco para manejar un código incorrecto es descubrir qué es recuperable y qué no. Esto proviene de la experiencia y la investigación.

La otra opción profesional que tiene es dejar de trabajar para empresas establecidas y buscar trabajar en nuevas empresas. Entonces no habrá código heredado de basura para mantener, por lo que tendrá la oportunidad de ayudar a construir algo mejor. La desventaja es que la presión para entregar puestos en proyectos de inicio a menudo significa que se usan atajos y piratas informáticos cuando no deberían.

Los programadores con demasiada frecuencia están dispuestos a asumir deudas tecnológicas para realizar entregas anticipadas o puntuales. Desafortunadamente, el impacto de esta deuda tecnológica a menudo se pasa por alto, minimizado, ignorado o descartado por los desarrolladores y la administración hasta que es demasiado tarde y están en problemas.

Lo siento si esto suena deprimente. Estoy seguro de que alguien más puede hacer una pieza más positiva. :-)

Aquí hay algunas respuestas geniales, pero permítanme agregar mi parte;

Bienvenido al mundo real, desafortunadamente esto es muy común.

Hacer referencia al diagrama de abajo;

Con el software corporativo, solo puede elegir 2 o lo anterior, y debe sacrificar uno.

Como parece haber descubierto, la mayoría del mundo corporativo va con rapidez y precio.

No es totalmente indicativo de la industria, pero de mi experiencia limitada de más de 5 años. Trabajaría en tu pasantía y tomaría tantas lecciones como puedas de la experiencia. Busque marcas distintivas e indicadores. Por ejemplo, para su próximo puesto, sin duda tendrá que pasar por una serie de entrevistas. Este proceso es un camino de dos vías y le brinda la oportunidad de familiarizarse con una empresa. Esto es de vital importancia y probablemente conducirá a su propia felicidad y bienestar.

Para resumir las cosas, detecte las señales de cuento;

• ¿Quién dirige la empresa? ¿Es un solo gerente, el equipo de marketing (si es así, manténgase alejado), el equipo de desarrollo, etc. Este ángulo significa que puede obtener más o menos influencia para los proyectos, el tiempo dedicado a los proyectos, etc.
• ¿Hay una apreciación técnica? Mire cómo la gerencia, el supervisor y los miembros del equipo se tratan entre sí. He estado en una entrevista donde los gerentes han estado haciendo todo tipo de movimientos de cejas una vez que el líder técnico comenzó a hablar. Después de eso y aprendiendo que no usaron el control de fuente, no podía mostrarme la puerta lo suficientemente rápido.
• ¿Objetivo comercial? ¿La empresa vive día a día, como en los objetivos financieros diarios, o tiene un plan a largo plazo del que usted forma parte? El desarrollo de software generalmente se realiza durante meses, por lo que tener una empresa con naturaleza esquizofrénica generalmente lleva a un software desordenado.
• Excave mucho - cuando haga preguntas técnicas y vea si las personas barajan. Control de origen, control de documentos, proceso de publicación, informes de errores, estilo de gestión, T&C, etc.

Así que vive y aprende, y piensa en tu próximo papel. Tener una mala experiencia no es tan malo, porque estarás mejor educado sobre el mundo del trabajo y los negocios.

Bueno, estoy llegando a mi segunda década en el negocio, y puedo decirte que el código limpio perfecto rara vez ocurre, y cuando sucede, no permanece así por mucho tiempo. En general, se encontrará constantemente tratando de reparar los errores del pasado, mientras (tristemente) se ve obligado por limitaciones de tiempo y un liderazgo deficiente a cometer los errores del presente.

A menos que se encuentre en un tipo de negocio de software muy específico, la presión para obtener un producto funcional en la puerta anula todas las demás preocupaciones, y la optimización más allá de cierto punto se considera inútil. Si el programa se ejecuta en 5 minutos, y solo necesitamos que se ejecute en 5 minutos, nadie le dará algunas semanas para reducir el tiempo de ejecución a 2 minutos.

Si, por algún milagro, tiene esa confluencia perfecta de gestión competente, un objetivo claro, dinero, talento y tiempo, y produce un producto limpio y excelente ... La única forma en que se mantendrá así es si nunca toca de nuevo . El mantenimiento y la extensión casi siempre reciben una prioridad muy baja, los cambios siempre son necesarios con un aviso cero efectivo y terminan siendo incorrectos.

Estaba pensando en este proyecto ayer. Fue un sueño imposible para mí, que reboté una mierda realmente mínimamente funcional por la puerta. Lo vi como una pérdida de tiempo y recursos.

Bueno, sorpresa, sorpresa, a todos les encantó y funcionó bien. Entonces volví a la mesa de dibujo y lo hice bien. ¡Y la nueva versión fue increíble! Pero luego hubo una rotación en la gestión y todo se desechó en favor de una "nueva dirección comercial".

La segunda iteración tuvo un despliegue realmente mediocre dentro de la empresa, y nunca escuché nada más al respecto, lo cual es divertido porque sé que al menos ~ 10 unidades comerciales todavía lo están utilizando (el software que estamos encargando para hacer el trabajo) tiene casi 2 años de retraso) y aparentemente nunca se rompe.

Esto nos lleva a mi punto final. Incluso si produce algo milagroso, el hecho de que funcione tan bien significa que NADIE estará familiarizado en lo más mínimo, y cuando se rompa (generalmente porque hicieron algo estúpido) entonces maldecirán su nombre más de lo que lo harán. alguna vez maldijas a ese idiota que escribió esa cosa que se rompe cada tercer martes.

Es difícil decir qué considera un código de baja calidad, pero sí, pocos programadores son muy buenos (por definición). A medida que el software evoluciona, las personas cometen errores. Con el tiempo, estos se acumulan y la presión empresarial (y la pereza / ignorancia del programador) hace que la refactorización ... sea poco común.

Realmente no puedo hablar por todos, pero esto es lo que puedo decir.

No he trabajado más de 30 años en el dominio, pero vi lo suficiente como para decir algunas cosas. Un proyecto tiene una vida muy parecida a la de un humano. El diseño inicial puede no ajustarse a las necesidades actuales de, digamos, un proyecto después de 20 años de desarrollo. Dicho esto, en esa cantidad de tiempo, muchas personas cambiaron el código y agregaron cosas que al principio no se suponían posibles.

No es realmente difícil imaginar código feo en proyectos heredados o proyectos bastante antiguos. No podemos esperar que todos entiendan completamente los diseños iniciales. Es triste pero así son las cosas.

Dicho esto, debe tener en cuenta que refactorizar un proyecto heredado no siempre es posible y en ocasiones ni siquiera se desea. Trabajé en una empresa donde estaban desarrollando el reemplazo para el proyecto en el que estaba trabajando. No se me permitió refactorizar demasiado mi proyecto por temor a que funcionara mejor que el nuevo proyecto. Estoy bastante seguro de que no hay forma de que este proyecto pueda funcionar mejor que uno nuevo. la frase era un poco como "No lo hagas mejor, solo haz que funcione".

Eventualmente no tendrás ese tipo de proyecto a menudo, ya que a menudo leo y escucho. Debes tratar de encontrar trabajo con startups en lugar de grandes corporaciones. Las startups son bastante interesantes y eventualmente puedes avanzar rápidamente si ves que no está yendo de la manera que también quieres.

También una cosa que puede hacer, realmente no prometo nada, pero si siente que el código es realmente tan malo y necesita refactorización. Compártelo con el equipo. Tenga en cuenta que las personas que escribieron ese código feo podrían estar trabajando con usted. No se trata de herir los sentimientos de las personas, pero si ves que el proyecto en el que estás trabajando colapsará después de algún tiempo y la gente pasará más tiempo entendiendo lo que hace en lugar de mejorarlo. Es mejor hablar y comunicar el problema que guardarlo para usted. Si tienes la suerte, podrías terminar refactorizando el proyecto.

Si terminas refactorizando el proyecto, ¡podrías terminar siendo la persona señalada por malas elecciones de diseño! Y entonces podría entender por qué la refactorización no ocurre tan a menudo. Con suerte, si todo el equipo tiene que refactorizar, entonces nadie será señalado. Simplemente despedirán a todos =)

Intentaría resumir la respuesta a estas preguntas con una simple cita:

All code turns to crap given enough time and hands.

El resto son solo historias ...

La calidad del código depende principalmente de dos factores.

Lo primero es siempre el dinero. Las empresas que tienen una alta presión de supervivencia generalmente pagan salarios bajos, contratan a desarrolladores menos experimentados, tienen horarios ajustados y ni tiempo ni dinero para aprovechar a sus desarrolladores.

El segundo es la gente. En primer lugar, aquellos que deciden sobre los presupuestos deben optar por gastar en calidad de código, luego tienen que involucrar a las personas que quieren "vivirlo". Como puede imaginar, puede resultar difícil convertir a un programador de Delphi de arriba a abajo de cincuenta años bien pagado (sin intención de estereotipos, lo siento) en un Desarrollador Java actualizado que hace CI Builds y produce código vagamente acoplado. Muchos desarrolladores tienen una aversión a las lecciones de los compañeros (quizás más jóvenes), no les gusta que alguien pesque en su estanque o haga sonar su trono.

Dicho esto, y también teniendo en cuenta el hecho de que tienes un código heredado en cada empresa, diría que obtienes mucho de eso en la vida real. Lo que podrías hacer es comportarte como un boycout: ir al bosque, recoger algo de basura y limpiarlo. La próxima vez tendrás menos problemas para pasar.

¡Bienvenido al código con un presupuesto! Hay una gran diferencia cuando el desarrollo se ve impulsado por la administración a realizarse demasiado pronto, sin planificación y con atajos. Tuve una experiencia similar de conmoción en el mundo real cuando obtuve mi primer trabajo de programación fuera de la universidad. No hay documentación! Con el tiempo aprendí muchas veces, escribir y mantener actualizada la documentación formal es solo una pérdida de tiempo. Por suerte para mí, ese fue un equipo increíble. Fue dirigido por un tipo que sabía lo que estaba haciendo y los otros miembros del equipo realmente se preocuparon por escribir el código de la manera correcta. Desde entonces, mis experiencias han sido similares a las tuyas. Un montón de código horrible, mucho código malo, muchos "desarrolladores" despistados. Por cada buen desarrollador, parece haber 100 malos.

No estás condenado a odiar tu trabajo para siempre. Solo tiene que encontrar una empresa lo suficientemente inteligente como para reconocer los beneficios a largo plazo que esté dispuesto a invertir un poco por adelantado. Me las arreglé para demostrar que hacer las cosas de la manera correcta en lugar de la manera más rápida es beneficioso y me he vuelto muy respetado y confiable por eso en las empresas en las que he trabajado. Con el tiempo, el código de espagueti se arregla o se vuelve obsoleto y su código se hace cargo. Solo prepárate para comprometerte. A veces, la forma más genial o más robusta de programar algo es simplemente exagerar y está bien hacerlo de manera rápida y sucia.

Obtuve una pasantía en una de las principales compañías de software

No todas las empresas son iguales. Encontrarás equipos y bases de códigos de software en la mayoría de las empresas. Pero también puedes encontrar grandes equipos y excelentes bases de código.

Creo que los muchachos de Solaris hicieron una descripción muy buena y honesta del tipo de bases de código que encontrarás en grandes empresas: http://hub.opensolaris.org/bin/view/Community+Group+on/dev_solaris

He dejado el trabajo odiando el trabajo todos los días hasta el momento, y deseo desesperadamente saber si esto es lo que me depara el resto de mi vida.

No, llevo más de 15 años codificando y todavía me encanta.

Eso no quiere decir que todo haya sido perfecto. He visto algunas bases de código horribles y también algunas excelentes. El truco es encontrar el lugar adecuado para ti.

Una empresa grande es muy diferente de una pequeña. Dentro del mismo equipo de la empresa A, a veces es muy diferente del equipo B. Encuentre el que tenga el equilibrio adecuado para usted (por ejemplo, proyectos desafiantes, una cultura que le guste, buen sueldo, etc.)

¡Buena suerte!

He visto cosas similares a ti. Tengo dos experiencias de casos cuando ocurre.

1. Cuando el desarrollo es demasiado impulsado por el proyecto. Lo único que importa es entregar la funcionalidad a tiempo, luego cerrar sesión. El siguiente cambio lo realizará otra persona, algún otro equipo / gerente de proyecto con un nuevo presupuesto.
2. Cuando solo unas pocas personas mantienen un software durante un largo período de tiempo, los desarrolladores tienden a ser flojos, ya que de todos modos conocen su software. Los principios académicos están muy lejos.

Es triste, pero así es en algunos lugares.

Vea si puede hacer un pequeño cambio para mejor, acostumbrarse o cambiar a otra compañía y pedir que se muestre un código en la entrevista :-)

Esta será una respuesta corta.

La educación es muy útil para hacerte sentir calificado e idealista. Esto es algo bueno y debes tratar de aferrarte al idealismo.

Si eres objetivo y puedes mirar hacia atrás en tu propio trabajo en el futuro, no será una experiencia muy satisfactoria. A menos que te mientas a ti mismo o no aprendas nada, verás muchas maneras de mejorar lo que has hecho.

En general, todo el mundo está haciendo esto a tu alrededor. Entonces, cuando miras el trabajo del pasado, dejando de lado las excepciones, parecerá inferior y necesita mejorar. Si no se siente así, significa que está haciendo el trabajo incorrecto, o está pagando demasiado bien.

La buena noticia es que puede beneficiarse de los errores de otros y de la comparación con el pasado. Si todas las aplicaciones funcionaran bien y fueran fáciles de mantener, no serían necesarios nuevos desarrolladores. En mi opinión, mantener algunos otros desarrolladores cruft es una experiencia de aprendizaje útil y debería ser un elemento de capacitación obligatorio para todos los desarrolladores de blue sky.

Su experiencia negativa es muy típica de las grandes y conocidas compañías de marca que muchos desarrolladores aprenden a abordar con mucha más precaución y temor que la primera vez que tuvieron la oportunidad de trabajar en una sola. Básicamente, cuantas más capas de gestión tenga, más defensa de la mediocridad. Los gerentes intermedios no informan a los gerentes superiores sobre la calidad del código. Informan sobre las características entregadas en X cantidad de tiempo y dan presentaciones de powerpoint sobre la función de interfaz de usuario de Neato que esperan que funcione el tiempo suficiente para llevarlas a cabo. Si todo se derrumba sobre sí mismo un mes después, generalmente es un problema de otra persona y lo saben.

Entonces, sí, los desarrolladores que viven en esos lugares tienden a no preocuparse demasiado. No podrían sobrevivir allí si lo hicieran. He oído decir de Silicon Valley, que si quieres ser flojo, trabaja para uno de los grandes nombres. Si desea un trabajo emocionante, busque una startup más reciente que aún no sea un nombre familiar. Trabajo en Chicago y puedo responder por un fenómeno similar aquí.

Como regla general (con muchas excepciones, estoy seguro), encontrará una mayor apreciación por el código de calidad en compañías más pequeñas y administradas o propiedad de personas que también continúan escribiendo código. La compensación es a menudo menor, pero el trabajo es a menudo mucho más gratificante en mi opinión.

Como desarrollador de nivel de entrada, es probable que no tengas mucho control sobre para quién trabajas al principio, pero diré que tener un gran nombre en tu currículum durante un año o más definitivamente definitivamente entusiasma a los reclutadores y a los recursos humanos. Además, puede aprender un poco que de otro modo no aprendería trabajando para alguien completamente horrible en los primeros seis meses más o menos, y también lo ayuda a comprender mejor qué mejores prácticas realmente importan y por qué y cuáles son solo técnicas. manía.

Y, por supuesto, cuando trabaje con más herramientas corporativas populares de la corriente principal, tenderá a descubrir que los niveles medios de talento serán bastante malos. Si sus habilidades principales son una combinación de Java y C #, expanda sus horizontes un poco. Puede encontrar un nicho más feliz en el nivel medio escribiendo Erlang o Python o: o JavaScript.

Y no dejes que nadie te diga algo diferente. Es posible que no tenga otra opción en cuanto a cómo proceder, ¡pero el código basura es caro!

Su pregunta se centró en pasantías. Nunca tuve una de programación, pero hice una pasantía en una estación de radio, no realmente aplicable aquí.

Su pregunta también mencionó sus experiencias durante sus pasantías. Sus experiencias de pasantía y las respuestas que ha recibido hasta ahora resumen todas mis experiencias, después de lo que ahora son veintisiete años de software de escritura (comenzó a mediados de junio de 1985).

Nunca lo creí en la escuela cuando nuestros instructores dijeron que hay más pensamiento que escribir código. Tenían razón Y, si está tratando de descifrar el código de otra persona, es peor sin comentarios y casi tan malo con los comentarios. Intente mantener un sistema local de recaudación de impuestos municipales sin comentarios, sin documentación, sin compilación formal y sin control de código fuente.

Siempre que pueda hacerlo bien sin que sea una violación directa de las órdenes estándar, hágalo bien. Siempre recuerde, es más fácil disculparse por hacer algo que no solicitó permiso que pedir que no se le otorgue el permiso e ir en contra de una orden directa.

No olvides los estándares que te enseñaron en la escuela. No son inútiles, pero lo más probable es que esos estándares sean las asíntotas en los límites de cálculo. Siempre puede intentar acercarse a ellos, pero es posible que nunca alcance su valor.

Buena suerte.