¿Qué debo esperar de mi primer trabajo de programación? [cerrado]


37

¡Acabo de ser contratado para mi primer trabajo de programación! Tengo 25 años y he estado usando Java académicamente durante 6 años.

Ahora que he sido contratado, estoy nervioso porque mis habilidades no serán las que el empleador espera. Me temo que me asignarán a un proyecto y tendré que hacer muchas preguntas que mis compañeros de trabajo sentirán como aficionados.

¿Es este un miedo racional? ¿Cuáles fueron tus primeras experiencias laborales de programación? ¿Qué debo esperar? ¿Qué consejo podrías darme?

Gracias.


16
No te preocupes La mayoría de los empleadores entienden que hay una gran curva de aprendizaje que pasa de la academia a la industria. Me preocuparía que no hicieras muchas preguntas.
Pemdas


¡En mi opinión, lo mejor que puedes hacer es preguntar! Si hay un problema, una pregunta rápida es más eficiente que perder horas al tratar de resolver algo. Al principio, es posible que pregunte un poco más, pero después de un tiempo podrá responder preguntas de colegas "más experimentados". Nadie sabe nada y ningún empleador debe esperar eso. La comunicación saludable es importante para una empresa.
johannes

Respuestas:


57

Hay muchas cosas que no puedes aprender en la universidad . También hay muchas cosas que son específicas de la empresa . En ambos casos, tiene una opción:

  • o les pides explicaciones a tus colegas,
  • o no le pide nada a nadie y se arriesga a cometer un error.

Si contrato a alguien que no tiene una experiencia profesional, no me importaría si ella hace muchas preguntas las primeras semanas o meses. Por otro lado, si teme pedir ayuda y pierde horas resolviendo un problema que otro desarrollador puede resolver en cuestión de segundos o comete errores estúpidos que podrían evitarse fácilmente por alguien más abierto a la comunicación con sus compañeros, me molestará mucho más.

No evites las preguntas. Es una buena manera de aprender cosas y socializar con las personas con las que trabajará. Pero:

  • No hagas preguntas solo para hacerlas.
  • Recuerde que otras personas tienen su propio trabajo que hacer y sus propios plazos. Tienen otras cosas que hacer además de dedicar su tiempo a ayudarlo en cada tarea.
  • No espere que otras personas hagan su trabajo (al igual que nunca es bienvenido pedirle a Stack Overflow que haga su trabajo).
  • Tenga en cuenta que si molesta a un desarrollador, pierde diez o más minutos para concentrarse nuevamente. Por lo tanto, no haga preguntas si puede encontrar una respuesta en segundos en Internet.

Ejemplo de malas preguntas:

  • "Oye, quiero crear una matriz como {1, 2, 3, ... n-1, n} en PHP. ¿Me pueden ayudar?" Aquí, solo demuestra que no solo no sabe cómo usar la documentación de PHP, sino que ni siquiera se molesta en buscar en Google o pensar por un momento. Está bien si no sabes acerca del rangemétodo en PHP. No está bien si no puedes encontrarlo tú mismo.

  • "Estoy tratando de implementar complementos, pero no sé qué es CAS en .NET Framework. ¿Puede explicarme qué es esto?" Sí, es más fácil pedir una explicación, pero ¿qué hay de buscar primero en Google "CAS .NET Framework 4.0"?

  • "¿Por qué me obligas a usar el control de versiones? Siempre trabajé sin él y no entiendo por qué lo necesitaría ahora". Bueno, sus colegas no tienen que explicar por qué debe usarlo. Primero, es una guía de su empresa. No estás aquí para dictar cómo trabajar. En segundo lugar, hay muchos libros, artículos de blog y respuestas en los sitios web de SE que explican por qué todos deben usar el control de versiones. Solo tienes que buscar.

Ejemplos de preguntas que son bienvenidas:

  • "Quiero confirmar los cambios en el control de versiones, pero hay un extraño mensaje de error. Dice: [...]. ¿Quizás sabes qué es esto?" Es probable que su colega haya visto este mensaje docenas de veces antes, por lo que está bien preguntar esto.

  • "Estoy leyendo la página 9 de los requisitos para este proyecto, parte 4.2.1, pero no estoy seguro: ¿es para mí o para el administrador de la base de datos hacer esta parte?" Es mejor preguntar, que pasar tres días para hacer el trabajo que ya ha realizado la dba.

  • "Necesito implementar complementos, pero después de leer esto y esto, todavía no entiendo qué es un sandbox y cómo se relaciona esto con la seguridad. ¿Podrían explicarme esto más adelante cuando estén libres?" Has buscado Hiciste un esfuerzo. No entendiste Está bien no entenderlo todo, y sería mejor pedir una explicación en lugar de pasar un fin de semana buscándola.


18
Me gustaría señalar que si la compañía no usara el control de versiones, el 99.9% de nosotros aquí apoyaríamos tratar de "dictar cómo trabajar" y obtener el control de la fuente.
whatsisname

" ¿Por qué me obligas a usar el control de versiones? Siempre trabajé sin él y no entiendo por qué lo necesitaría ahora ". Respuesta: "Ok, tienes un punto. Trabaja sin él durante unos meses, en nuestra gran base de código en expansión mientras todos los demás lo usan, y hablaremos de eso entonces". Este problema probablemente se solucionará solo.
joshin4colours

1
No haga preguntas solo para hacerlas, de acuerdo. Pero haga preguntas para ampliar su conocimiento. Si no haces eso, no estás tratando de aprender.
Configurador

Estos son criterios realmente buenos, pero también agregaría que algunas cosas que no vale la pena preguntar durante la jornada laboral pueden ser perfectamente aceptables para preguntar durante el almuerzo (si la cultura de la empresa es tal que las personas comen juntas y están de acuerdo con hablar sobre cosas laborales) ) Esto evita el cambio de contexto adicional de responder la pregunta.
Autofagia

22

"La única pregunta estúpida es la que no se hace".

^ En serio Recuerda eso.

Si ha estado en el mundo académico durante 6 años, supongo (y espero ) que tenga una sólida comprensión de los conceptos básicos de ingeniería. A menos que te encuentres en una mala situación con un empleador terrible, deben ser conscientes de que al estar recién salido de la escuela en tu primer trabajo, tendrás una curva de aprendizaje por delante y esperarás que cometas errores en el camino. .

Si sus habilidades no coincidieran con lo que el empleador estaba buscando, no lo habrían contratado. Si te contrataron a pesar de que tus habilidades no coinciden con lo que están buscando, lo más probable es que no quieras trabajar allí de todos modos.

Cuantas más preguntas haga, más rápido se acostumbrará a su nuevo entorno de trabajo. Dicho esto, en general, a los ingenieros no les gusta que los molesten constantemente, ya que les lleva unos 15 minutos volver al ritmo de las cosas. Por lo tanto, tal vez piense en poner todas sus preguntas relevantes en un correo electrónico y enviárselas a alguien en el "saber" al final del día.

Algunas compañías lo emparejan con un mentor, otras no.


+1, preocuparse si su compañero de trabajo va a pensar que una pregunta es estúpida o no cuesta tiempo que podría pasar haciendo la pregunta e implementando.
Nicholas Smith

+1, pero una pequeña nota sobre la parte correspondiente a las habilidades. A veces, un empleador contratará a una persona de nivel de entrada sin las habilidades existentes que muestra un buen potencial para adquirir esas habilidades a través de la capacitación. En cualquier caso, la formulación de preguntas termina siendo la solución.
Joel Etherton


8

Mi primer trabajo de programación fue hacerse cargo de un sitio web que estaba escrito en idiomas que ni siquiera conocía. Yo era el único desarrollador y no tenía a nadie a quien pedir ayuda. Tenía mucho miedo de no durar mucho (si no fuera por los foros, probablemente no lo habría hecho). ¿Entonces qué hice? Hice un montón de preguntas en los foros. Montones. Sentí que estaba haciendo tantas preguntas de "aficionado" que hice que mi avatar "Soy estúpido" (todavía está ahí afuera ... en algún lado).

Mi punto es que el miedo es natural, pero lo superarás y harás muchas preguntas de aficionados. Es la mejor forma de aprender. Al menos en mi caso lo fue, y aún lo es.

Además, cuando estaba en mi entrenamiento de TI en el ejército, pasaron por alto brevemente cada concepto y dijeron que "aprenderás tu trabajo en tu primer lugar de destino ... esto es solo para que estés familiarizado con lo que sea que sea".


2

Si haces preguntas tontas, pero solo haces una vez, tus compañeros no te odiarán. Pero si nunca aprendes, le dirán a tu jefe que te despida.

Tu sich está fuera de tu control. O estarás con gente buena que querrá que tengas éxito, o estarás con maldad que querrá que fracases.

Trate de no estar nervioso y simplemente haga lo que pueda. Y trabaje mucho más aprendiendo el idioma y las aplicaciones de la compañía.



1

Mi primer trabajo de programación fue en un lenguaje y marco / plataforma que nunca había tocado antes (Visual C ++ / MFC, y fui educado en C en Unix con un poco de Java).

Moraleja de la anécdota: cuando no tiene experiencia comercial, el primer empleador que lo contrata generalmente lo ve más o menos como una pizarra limpia. Mirando hacia atrás ahora, incluso si me hubieran contratado para un puesto en C en Unix, el 95% + de la curva de aprendizaje al principio de ese primer trabajo habría sido mucho más sobre habilidades blandas, control de fuentes, política / administración de oficina y otros cosas para las que la experiencia académica realmente no puede prepararte. Desde el punto de vista técnico, generalmente esperan que estés muy tambaleante durante el primer mes o dos: el impacto en el sistema solo por las cosas no técnicas es suficiente distracción. Ellos saben esto, por lo que probablemente no esperan mucho.

MainMa tiene buenos consejos : Básicamente, trata de no molestar a las personas con el tipo de preguntas que son fáciles para Google, y que deberían venir con el territorio para alguien con 6 años de experiencia académica. Una buena regla general es que primero se debe investigar el conocimiento genérico de programación antes de preguntar, mientras que el conocimiento interno específico de la empresa / dominio es mucho más seguro después de una excavación mínima.


1

También me he graduado recientemente de la universidad y he estado desarrollando software profesionalmente durante aproximadamente un año. También temes exactamente lo mismo que yo temía, así que no estás solo. Siento que pasé por lo que estás describiendo aquí. El mejor consejo que puedo darle es el siguiente:

  1. Rodéate de personas más inteligentes que tú y dispuestas a ser mentores. Sea lo más cortés posible, lea a las personas y descubra sus alianzas. No todos estarán abiertos a ayudarlo, pero fácilmente descubrirá quiénes son las "personas adecuadas" y con quienes querrá ser amigo.
  2. Haga preguntas tanto como sea posible si siente que Google no puede responder.
  3. Tenga en cuenta que hay muchos que no han ido a la escuela por un tiempo, y es probable que lo vean como una mente fresca para las ideas. No tenga miedo de sacar ideas, y no tenga miedo de estar en desacuerdo con los demás.

Es una línea delgada, pero descubrirá dónde cruzarla y dónde no. Lo mejor que puede hacer es entusiasmarse por aprender y rodearse de personas que saben más que usted sobre el desarrollo de software.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.