Programador Solo .NET moviéndose a un equipo [cerrado]

12

He sido programador de .NET para una pequeña empresa en los últimos 8 años. He reunido un software bastante decente y siempre me esforcé por mejorar y ajustarme a las mejores prácticas, incluido el control de código fuente (SVN / TFS). Trabajé muy de cerca con un equipo de ingenieros de otras disciplinas, pero en lo que respecta al software yo era el único programador. Me encanta el oficio de la programación y me encanta aprender cosas nuevas para afilar mis herramientas.

En 2 semanas comenzaré un nuevo trabajo en un equipo de 20 desarrolladores de .NET. Mi posición será de nivel medio, y trabajaré bajo algunos programadores con fondos increíblemente impresionantes. Una vez más, el aspecto de desarrollo del equipo será nuevo para mí, por lo que estoy buscando algunos consejos generales para "personas nuevas" que me ayudarán a ser tan eficaz y fácil de tratar como sea posible desde el principio. >

Todo vale, incluyendo consejos de alto nivel y pequeñas cosas cotidianas sobre la comunicación.

    
pregunta 219558af-62fa-411d-b24c-d08dab 21.06.2011 - 17:39

6 respuestas

19

Principalmente sentido común, pero mi consejo sería:

Pase la mayor parte de la primera semana con personas en lugar de con la tecnología. No pierda el primer día personalizando su escritorio o cualquier otra cosa que lo aísle del equipo. Conoce a tantos compañeros como sea posible lo más rápido posible.

Trate de averiguar quiénes son los caballos de trabajo y quiénes son los vagabundos rápidamente también. Evita a los vagabundos tanto como sea posible, cada equipo los tiene y no quieres que te clasifiquen como uno solo.

Asista a cualquier evento social en las primeras semanas, aunque solo sea una cerveza después del trabajo o el almuerzo.

Escuche y escriba las cosas, pídales a sus compañeros que repitan las descripciones de los procedimientos que les contestarán.

Pase los primeros 3-6 meses familiarizándose, a menos que se le pregunte específicamente sobre un problema específico, no recomiende cambios a los procedimientos / arquitectura / etc. Trabajarán de manera diferente a usted y algunos elementos pueden ser deficientes, pero habrá razones para ello y rara vez se deben a negligencia o ignorancia.

Dudo que el lado de la programación sea realmente un problema.

    
respondido por el Jonno 21.06.2011 - 17:51
8
  • ¡Aprende! Conocer a nuevos programadores es una excelente manera de aprender nuevos trucos. Al verlos escribir, aprenderá algunos trucos de editor y mirar su código le dará nuevas ideas.

  • No moleste a sus colegas cada cinco minutos, pero si está realmente atascado, no dude en pedir ayuda. Demasiados programadores están atascados en un programa durante dos días, donde preguntar a su vecino lo habría resuelto en una hora.

  • Las guerras de códigos son guerras religiosas. La sintaxis podría ser algo diferente allí (¿agregas corchetes a las declaraciones de una sola línea?) Pero rara vez vale la pena luchar por ellas.

  • Socializar. Si están tomando una bebida cada semana, asegúrese de unirse a ella. Esto puede ser tan simple como comer juntos .

respondido por el Carra 21.06.2011 - 17:55
3

Jugando a Devil's Advocate y voy a decirte, asegúrate de que tus compañeros de equipo sean competentes. No hay nada peor que trabajar en un equipo en el que nadie, excepto usted, hace nada de la manera "correcta", porque siempre es superado en número en las personas que quieren hacer las cosas mal.

Mencionas que trabajas bajo desarrolladores con un fondo impresionante, por lo que suena prometedor y en ese caso te aliento a que aprendas lo que puedas, pero nunca olvides lo que ya sabes por el bien de la "mentalidad de rebaño". Si todos los demás hacen algo mal y usted lo hace bien, no se comprometa.

    
respondido por el Wayne Molina 21.06.2011 - 18:12
2

Además de Jonno, yo diría:

Esté preparado para los cambios. Cada equipo trabaja diferente. Los buenos equipos de SW tienen reglas de codificación. Prepárese para aceptarlos, aunque inicialmente parezcan extraños.

Prepárate para mucha más comunicación. Cuando trabajas solo, hay mucha información detallada en tu cabeza. Tan pronto como trabaje en equipo, estos detalles (al menos algunos de ellos) deben compartirse y comunicarse, y para ello se requiere tiempo.

    
respondido por el wolfgangsz 21.06.2011 - 17:56
2

Escucha más de lo que hablas.

Haga más preguntas de las que intenta responder (a menos que las preguntas se dirijan a usted). Los "veteranos" del equipo sabrán cuánto está progresando en el aprendizaje del código mediante las preguntas que haga. Probablemente tienen una lista mental de preguntas que están esperando.

Escriba su código para que coincida con el estilo que prevalece. Esto se aplica a donde se colocan espacios, llaves, mayúsculas, longitud de los nombres de las variables, tamaño promedio de los métodos, densidad de los comentarios y todo lo demás que no debería importar. Si tiene una buena razón para hacer las cosas de manera diferente, pregunte a uno de los veteranos por qué el equipo tiene el estilo dado. Puedes aprender algunas cosas interesantes sobre la historia y las personalidades del equipo. Lo que me lleva al siguiente punto.

Aprende la tradición del equipo. Lo más probable es que ninguna parte de la tradición esté escrita en ninguna parte, pero es de conocimiento general en el equipo. La tradición del equipo incluye la historia de cómo el proyecto llegó a su estado actual, los errores cometidos en el pasado, los éxitos logrados en el pasado, las lecciones aprendidas en el camino. Se menciona en breves declaraciones como "suena como el error de Frobnitz nuevamente". Cuando vea / escuche que los miembros del equipo están de acuerdo con un comentario críptico que alguien hace, probablemente haya una tradición de equipo involucrada. Pregúntale a alguien.

No critique el código hasta que conozca las personalidades y la historia involucrada. No sabes a quién podrías ofender.

    
respondido por el jimreed 21.06.2011 - 18:40
1

Haz preguntas y escucha las respuestas. Piense en las respuestas a las preguntas anteriores antes de formular la siguiente para que pueda intentar anticipar una respuesta.

Esfuércese por hacer el mejor trabajo posible que pueda. Acostúmbrate a preguntarte qué pensará alguien más en el equipo de tu código si tiene que modificarlo el próximo mes.

Si ve un problema que debe abordarse, haga todo lo posible para tener una solución razonable lista para ofrecer antes de expresar su preocupación por el problema. Asumir la implementación de una solución cuando señala un problema.

    
respondido por el Rick Liddle 21.06.2011 - 19:11

Lea otras preguntas en las etiquetas