Tiempo difícil en el primer trabajo de ingeniería de software [cerrado]

Recientemente me gradué con una Maestría en Matemáticas/Ingeniería (título doble) y fui contratado como ingeniero de software junior/novato en una empresa de consultoría, trabajando en la industria del software financiero. Fue una oportunidad increíble y me fue bien durante la entrevista telefónica, pero les informé sin rodeos sobre mi falta de experiencia y fui más que honesto con ellos sobre mi experiencia en programación. He realizado algunos proyectos en GH y he hecho codificación en la Universidad, pero no vengo de un entorno de informática y he sido muy honesto en mi evaluación personal. A pesar de eso, me contrataron y pensaron que podrían entrenarme para desarrollar cualquier cosa/todo lo que necesitaría saber.

Para resumir, ha sido difícil. Me contrataron a mediados de agosto, pero no comencé a ensuciarme las manos (programando...) hasta septiembre porque hubo problemas con mis credenciales. Me dieron asignaciones y temas de programación de nivel menor/medio, y aunque los completé todos, algunos me tomaron un poco de tiempo. Al principio, esto era aceptable; ahora que han pasado 2 meses, el tiempo que estoy tomando está empezando a irritar los nervios de mi supervisor. Está muy ocupado la mayor parte del tiempo y aunque ha reservado tiempo para entrenarme, a veces le pregunto cómo hacer algo más de una vez, lo que a veces puede molestarlo. El sistema con el que estoy trabajando es relativamente complejo y ya he desarrollado más de 20 documentos sobre cómo solucionar problemas a través de algunos errores/pasos comunes, soluciones de código y depuración básica. Pero todavía me faltan los fundamentos y las habilidades básicas de codificación, en las que he estado trabajando, pero a veces lucho con problemas introductorios básicos con los que no debería tener problemas en este momento. Pronto me mudaré a otro entorno donde se espera que haga mucho, mucho más y que pueda resolver todos los problemas en unos pocos minutos. También me están preguntando y él me está defendiendo ante los supervisores, pero no quiero que después se pongan grandes expectativas sobre mí.

Estoy aprendiendo más y más todos los días, pero no es lo suficientemente rápido. Le he preguntado, sin rodeos, si soy adecuado para la empresa o no; También le pregunté si no me estaba moviendo lo suficientemente rápido y me dijo que debería, necesito, moverme mucho más rápido. A veces, me toma un tiempo procesar la información para saber exactamente lo que necesito hacer y he sido así desde la universidad (incluso si obtuve el 100% en mis exámenes de ingeniería/matemáticas, yo era el que normalmente usaba TODOS los tiempo y rara vez, si es que alguna vez, me fui temprano).

¿Cómo debo proceder? Quiero tener éxito en el campo de la ingeniería de software, pero no sé qué hacer. Estudiar en casa es útil, pero parece que no es suficiente porque simplemente no tengo suficiente experiencia. En las próximas semanas, ¿qué puedo hacer para mejorarme? A veces, cuando habla muy rápido o realiza una serie compleja de pasos en 2 o 3 minutos, trato de pedir una aclaración pero, de nuevo, a veces tengo la impresión de que está molesto y siente que debería saberlo después de que lo diga una vez. .

¿Cuál es el problema real del espacio de trabajo? Según su historia, parece haber esbozado el problema y buscado una solución preguntando a su supervisor "a quemarropa", y obtuvo una respuesta. Al final concluyes que simplemente "no tienes suficiente experiencia" y parece obvio que si sigues haciendo lo que estás haciendo, este problema desaparecerá con el tiempo. "¿Cómo debo proceder?" no es responsable.
Relacionado con su pregunta implícita de ingeniería de software: Cómo codificar más rápido (sin sacrificar la calidad)
Bienvenido nuevo usuario, ¿quizás debería acortar drásticamente la pregunta para obtener mejores respuestas?
Por cierto, ¿qué es GH? Oh, Google Hangouts :/
@Fattie Más probable GitHub
Peor aún :/ la marca de un aficionado. QA algo relacionado .. Workplace.stackexchange.com/q/122055/22844
@Brandin Creo que hay una respuesta, en el software, el "pecado más grande" es básicamente pedir ayuda o aclaración. "Hacer software" se trata literalmente de "asumir" el problema; es una contradicción inherente volver por "ayuda". Esta es la razón por la que nada es más molesto en el software que alguien que regresa en busca de "ayuda", "consejos" o "consejos". Entonces eso es lo que OP debería dejar de hacer.
Hay muchos cursos que puede tomar, libros que puede leer o tutoriales con los que puede trabajar si siente que le falta su lenguaje de programación. Algunos son mucho mejores que otros, pero estás en el lugar equivocado si buscas una recomendación. Pero unas pocas semanas es bastante corto. En cuanto a no poder seguir lo que dice tu jefe, probablemente deberías tomar notas y resolverlo más tarde (o, si no puedes, pedir una aclaración en ese momento).
@Fattie Habiendo pasado los últimos cuarenta años de mi vida haciendo software en varios lugares, nunca he visto la actitud que mencionas. Es responsabilidad del desarrollador hacer el trabajo, pero no pedir ayuda cuando es necesario no hace el trabajo. “Asumir” un problema no significa tener que resolverlo completamente solo, sino aceptar la responsabilidad.
Simplemente no lo sé, @DavidThornley. De hecho, el OP está describiendo literalmente lo que estoy diciendo. Considere, es (de lejos) el negocio más agresivo, orientado al dinero y orientado a los resultados, no es como jugar en una tienda en la nube o en una red social; acaban de contratar a un tipo completo de Masters (!); el gerente en cuestión quiere resultados y nada más que resultados, no quiere hablar. Además, ¿por qué ese tipo podría ayudar? Si tú y yo contratamos a un tipo para... construir un puente... le damos un montón de $ para construir un puente... él sigue regresando a EE. UU. con preguntas como, ¿es esto una viga?
... estaríamos en estado de shock, mirándonos como "¿viga?" y asumimos que tendríamos que encontrar a alguien más... alguien que simplemente pueda "hacer el trabajo" :)
Soy un ingeniero de software jubilado. Mi especialidad en la universidad fue Matemáticas. La única razón por la que pude trabajar hasta que me jubilé fue porque trabajé muy duro cuando comencé mi carrera. Solía ​​trabajar 80 horas a la semana. Era joven. Pude hacer eso. ¿Cuántas horas trabaja cada semana?

Respuestas (1)

No estoy de acuerdo con algunos aspectos de la respuesta de Fatties.

No tienes que empezar a programar a los 13 o 14 años para convertirte en un buen programador, solo tienes que comprimir la experiencia de programación en un tiempo más corto.

Y estoy absolutamente en desacuerdo con la afirmación.

Precisamente, en el software cuando estableces una tarea para alguien, la definición de fracaso es cuando hacen preguntas.

Si no haces las preguntas correctas , cometerás los mismos errores que cometen todos los principiantes. Te llevará la misma cantidad de tiempo (léase: varios años) convertirte en un "buen" programador.

Quieres/necesitas absorber años de experiencia en programación e interiorizarlos en poco tiempo. No será posible en 3 semanas y debe indicar claramente su falta de experiencia al hablar de sus futuras responsabilidades. Pero la falta de experiencia no es razón para rendirse, es un incentivo para aprender.

  • Google, google y google. Si tiene un problema que no es específico del producto, las interfaces internas o las políticas de su empresa, es casi seguro que alguien haya tenido el mismo problema antes. Preguntar a un colega "cómo escribo un bucle" involucra a 2 personas, toma 5 minutos, pero también saca al colega de su modo productivo. Si a su colega le toma 20 minutos volver a su productivo tren de pensamiento, suma 30 minutos. Buscar en Google solo involucra a 1 persona, por lo que siempre que no necesite 30 minutos para comprender un bucle, buscar en Google es más eficiente.
  • Si siente que buscó durante demasiado tiempo pero aún no encontró una solución, pregunte a sus colegas si conocen una solución en lugar de cuál es la solución. Si sus colegas no saben la respuesta por sí mismos, incluso una hora de googlear por su cuenta es más eficiente que involucrar a más personas despistadas en la búsqueda.
  • Si no obtiene los resultados de búsqueda correctos, puede ser más eficiente pedir a sus colegas mejores términos de búsqueda que soluciones. Encontrar los términos de búsqueda correctos para un problema y conocer el nombre correcto de tecnologías y métodos también requiere experiencia.
  • Si tiene preguntas que Google no puede responder, no se concentre solo en su supervisor. Si hay otros programadores y necesitas ayuda con un concepto bastante básico, pregúntales. Si resuelven el problema en un minuto, pídales que le expliquen cómo abordar un problema para encontrar la solución tan rápido como lo hicieron ellos.
  • Otra buena idea es preguntar a los colegas dónde encontraron el mismo problema o dónde resolvieron un problema similar antes. Si pueden indicarle una dirección aproximada en el código, profundice en él para encontrar la solución existente. No espere que sus colegas señalen la línea de código correcta, debe encontrarla usted mismo.
  • Leer libros y otros materiales es un buen comienzo pero no una solución. A menudo contienen décadas de experiencia de algunos de los mejores programadores que existen. Intenta internalizar sus enfoques, pero ten en cuenta que la lectura por sí sola no te convertirá en un buen programador. Mi consejo personal es aprender sobre "código sólido" en lugar de "codificación para tontos".
Para aclarar. (1) Nunca vuelvas al gerente y preguntes nada porque (como señalo) eso es perder por completo el objetivo de la programación, que es resolver problemas. (2) Por todos los medios constante y agresivamente buscar información en línea/etc. SÍ. Nunca reinventar la rueda. (3) Claro, cuando su gerente esté literalmente informándole, por supuesto, haga "preguntas tontas" para simplemente aclarar el trabajo ("¿Quiere decir ESTE servidor?!") NO pregunte "cómo" resolverlo. Lo más irritante en S/W es cuando alguien a quien le has encomendado una tarea... te pregunta cómo hacerlo. Instantáneamente los marca como internos .
@Fattie Esto no fue un ataque a su respuesta, sino una segunda opinión. Creo que su respuesta mejoraría mucho si incorporara este comentario (especialmente el número 3). La forma en que se lee ahora es realmente engañosa...
Claro, lo edité, gracias. La dura realidad es que el OP (1) "no puede programar" y (2) trabaja como programador en (3) simplemente el campo de software más exigente, duro y de alto valor. Mi respuesta básicamente dice "Se necesitan décadas para aprender y tendrás dificultades". Atraerá votos negativos de cualquiera que quiera un final feliz :)
"siempre y cuando no necesites 15 minutos": diría que debería estar más cerca de una hora (si no un poco más). Hacerle una pregunta a alguien lo distrae de lo que estaba haciendo y puede llevar algún tiempo volver a ser productivo. Y resolverlo usted mismo significará que probablemente lo entienda mejor para la próxima vez, y probablemente mejore su capacidad para resolver las cosas por sí mismo.
Al igual que los comentarios confusos debajo de mi respuesta impopular ("¡No es así! ¡Trabajé en empresas!"), Tenga en cuenta que el OP dice literalmente, palabra por palabra, lo que estoy describiendo. ¿Una hora? ¿15 minutos? "habla muy rápido o realiza una serie compleja de pasos en 2 o 3 minutos , trato de pedir una aclaración pero, de nuevo, a veces tengo la impresión de que está molesto y siente que debería saberlo después de que lo dijo una vez". De todos modos.
Tiempo difícil en el primer trabajo de ingeniería de software [cerrado]
RespuestasAquíPolítica de privacidad1y, 0v