Disfruto codificando la mayoría de mis proyectos universitarios, pero odio codificar proyectos en el trabajo. ¿Que pasa conmigo?

Answer 1

*Aplausos*

¡Bienvenido al mundo real! Diría que no te pasa nada, pero tienes que aprender algunas cosas. Ya has trabajado en varios proyectos en la escuela, y eso es genial. Pero debes darte cuenta de cómo los proyectos del mundo real son diferentes.

Siempre es más romántico diseñar tu propia solución e implementarla (lo que haces en la escuela) en comparación con entender el enfoque de otra persona y apreciarlo. Además, esa otra persona no es solo una persona, sino muchas personas diferentes que han trabajado en ella. Demasiados chefs estropeando la sopa para ti, ¡eh!

Cuando digo que no hay nada malo en ti, quizás también te falte una habilidad importante. Debe comenzar a apreciar las decisiones de diseño de otros y luego tratar de descubrir por qué se diseñó de esta manera y no a su manera. Comience a hacer preguntas, comience a desafiar el diseño y compárelo con el suyo. Apreciar cuando sea necesario y criticar constructivamente. Ahí es cuando también disfrutarás trabajando en los proyectos de la industria.

Para ser un buen programador, no solo necesita saber cómo codificar, también necesita saber cómo trabajar en equipo y comprender el código de los demás. El código es algo así como una huella digital, puede ser único pero similar. Debes comenzar a encontrar cosas del código de otras personas y aprender algo por ti mismo.

La razón por la que no disfruta codificar en la industria es porque pierde interés. Es muy simple hacerlo cuando no es su diseño el que está depurando. Ningún comentario (creo que tienes mala suerte aquí) es doloroso. Lo menos que puede hacer es poner algunos comentarios basados ​​en su comprensión del código y su contribución personal. Haz la vida más simple para el próximo chico al menos. Aprenda a disfrutar esto y superar la intoxicación de diseñar sus propias soluciones y puede que le resulte interesante trabajar en los proyectos de la industria.

Algunos proyectos en la industria están realmente bien realizados. Siguen un estilo consistente y están debidamente documentados. De lo contrario, es posible que deba comenzar la tendencia de tener código de higiene en ese proyecto. Intenta trabajar en algunos proyectos de código abierto fuera de la escuela. Mira el kernel de Linux. Todo esto seguramente lo ayudará a comprender que no todos trabajan de la misma manera, los cinco dedos tienen diferentes longitudes. Luego comience a aprender de ellos y tal vez desarrolle esa habilidad de apreciar lo bueno de lo malo y encontrarse interesado en lo que sus empleadores le lanzan.

Espero que el consejo ayude … si no solo lo comenta * guiño guiño *

Answer 2

Aquí hay algunos pensamientos no mencionados por otros.
1) La ingeniería de software tiene mucho más que la codificación. Si codificar sus propias cosas es la única parte que le gusta, entonces quizás no debería seguir una carrera, sino un pasatiempo en el campo del software.
2) Los empleadores difieren dramáticamente. Parece que se ha encontrado con un par de los desafortunadamente muchos empleadores que tienen un enfoque altamente no profesional para el desarrollo de software, convirtiéndolo en una especie de fábrica de explotación. No utilizan enfoques profesionales, no documentan su trabajo, etc. Tienden a producir software de segunda categoría rápidamente. Mire más cuidadosamente cuando se gradúe y busque un trabajo permanente.
3) El software está desarrollado para resolver el problema de alguien y generalmente es parte de un sistema más grande. Por ejemplo, puede desarrollar el software para operar el tren de aterrizaje en un avión o para administrar la base de datos en un sistema de nómina corporativo. Le recomiendo que encuentre los dominios de aplicación que le interesen, los estudie (en cursos electivos o menores) y vea las habilidades de software como herramientas para usar en un dominio de aplicación en lugar de terminar en sí mismos. Como ejemplos, conozco personas que estudiaron medicina veterinaria, diseño de aviones y administración de empresas y cómo tienen carreras exitosas que escriben sistemas de software en esos dominios. A mí mismo me encantaba escribir código cuando tenía 20 años, pero mi carrera me llevó mucho más allá y no he escrito código en 30 años, excepto por corregir errores en html y desarrollar hojas de cálculo complejas. Mi conocimiento de programación subyace en todo lo que hago, pero en estos días es más probable que evalúe un diseño de software o planifique el sistema y la integración del software para un sistema principal o evalúe los problemas de seguridad asociados con el software para un avión.

Answer 3

Los chicos aquí ya te dieron respuestas increíbles, pero, déjame agregar una cosa:

Hay una gran diferencia entre trabajar en cosas que crees que valen y trabajar en cosas que no crees.

La forma en que debe seguir para no aburrirse de la codificación en el trabajo es conseguir un trabajo en una empresa que le guste la idea, la cultura, etc. Algo en lo que cree.

Answer 4

¡Bienvenido al club!

Comencé una pasantía mientras estaba en la universidad que se suponía que serviría como un mentor para toda la teoría con la que comencé a ser bombardeado. Rápidamente aprendí que un “mentor-barco” puede significar cosas diferentes para diferentes personas. La idea de mi empleador de una mentoría era hacerme mirar el antiguo código heredado y encontrar una manera de mejorarlo. Mi definición es y fue completamente diferente. El único código que realmente había visto en ese momento era mi propio código simple pero mal escrito. Esta fue una aplicación empresarial completa. Mi mentor me dijo que hiciera tantas preguntas como fuera posible, pero rápidamente se cansó de mi molestia.

Este fue un momento muy difícil para mí. Estaba extremadamente emocionado de estar en el mundo del desarrollo solo para darme cuenta de que pasaría mis 9 horas al día leyendo códigos que no entendía. Afortunadamente, pude trabajar en un proyecto por mi cuenta hacia el final de mi pasantía y si no hubiera sido por eso, me habría ido. El proyecto duró unos meses, pero cuando terminó, volvió a descifrar el código antiguo y descubrió una forma de mejorarlo. Realmente sentí que esto era abrumador y demasiado difícil de entender sin alguien que me acompañara.

Dejé esa compañía poco después y tuve la suerte de obtener otro trabajo de desarrollo. Al principio pude desarrollar mis propias aplicaciones, aprendiendo y aplicando nuevas tecnologías. Después de unos meses, me dieron la tarea de corregir errores para una de nuestras aplicaciones empresariales. Lo mismo había sucedido allí también. El código está mal documentado, las bibliotecas que se están utilizando toman tiempo para aprender, sin mencionar que la base del código es la más grande con la que he trabajado. Y tenía un plazo estricto para terminar. Me encontré frustrado de nuevo.

El punto de esta respuesta extremadamente larga es que el “mundo real” es muy diferente de la universidad. Pasará su tiempo en el código de otros y probablemente se espera que contribuya a ello en algún momento. El truco, me parece, es la comunicación constante. Debe involucrar a las personas que contribuyeron con el código para ayudarlo a comprender lo que estaban pensando en ese momento dado y lo que está haciendo todo. No puede suponer que estaban pensando en cierta cosa, especialmente si el código no está documentado. No tenga miedo de hacer preguntas, y no tenga miedo de irse si no les gusta responder esas preguntas. Mi sugerencia es intentar encontrar una empresa que valore la calidad del software. Nada de esto te convierte en un mal ingeniero, solo uno preocupado.

Answer 5

Estaba en tu situación. Encontré una solución que funciona para mí: hacer trabajo de investigación.

Answer 6

¡Es la silla de la oficina, amigo!
¡Las sillas de oficina son pendejos! : – \