Solo .NET Programmer se muda a un equipo [cerrado]

He sido programador .NET en solitario para una pequeña startup durante los últimos 8 años. He reunido un software bastante decente, y siempre me he esforzado por mejorar y adaptarme 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 cuando se trataba del software, yo era la única programación. Me encanta el arte de la programación y me encanta aprender cosas nuevas para agudizar mis herramientas.

En 2 semanas comenzaré un nuevo trabajo en un equipo de 20 desarrolladores .NET. Mi posición será de nivel medio y trabajaré con algunos programadores con antecedentes increíblemente impresionantes. Nuevamente, el aspecto del equipo en el desarrollo será nuevo para mí, por lo que estoy buscando algunos consejos generales de "chico nuevo" que me ayudarán a ser lo más efectivo y fácil de llevar desde el primer momento.

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

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 pierdas el primer día personalizando tu escritorio o cualquier otra cosa que te aísle del equipo. Conozca 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 vagos también rápidamente. Evita los vagos tanto como sea posible, cada equipo los tiene y no quieres ser clasificado como uno.

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

Escuche y escriba las cosas, pida a sus compañeros que repitan las descripciones de los procedimientos que les molestará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 en los procedimientos / arquitectura / etc. Funcionarán de manera diferente para usted, y algunos elementos pueden ser pobres, 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.

• ¡Aprender! Conocer nuevos programadores es una excelente manera de aprender nuevos trucos. Verlos escribir te enseñará algunos trucos del editor y mirar su código te dará nuevas ideas.

• No molestes a tus colegas cada cinco minutos, pero si estás realmente atrapado, no dudes en pedir ayuda. Demasiados programadores están atrapados en un programa durante dos días en los que preguntarle a su vecino lo habría resuelto en una hora.

• Las guerras de códigos son guerras religiosas. La sintaxis puede ser algo diferente allí (¿agrega corchetes a las declaraciones de línea singe?) Pero rara vez vale la pena pelear.

• Socializar. Si están tomando un trago todas las semanas, asegúrese de unirse. Esto puede ser tan simple como comer juntos .

Jugando a Devil's Advocate y voy a decir que asegúrese de que sus compañeros de equipo sean competentes. Nada es peor que trabajar en un equipo en el que nadie, excepto usted, hace algo de la manera "correcta", porque siempre son superados en número en personas que quieren hacer las cosas mal.

Menciona trabajar con desarrolladores con antecedentes impresionantes, por lo que suena prometedor y, en ese caso, le animo a que aprenda lo que pueda, pero nunca olvide lo que ya sabe 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.

Además de Jonno, diría:

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

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

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 progreso está haciendo en el aprendizaje del código por las preguntas que haga. Probablemente tengan una lista mental de preguntas que esperan.

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

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

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

Haga preguntas y escuche las respuestas. Piense en las respuestas a las preguntas anteriores antes de hacer la siguiente para poder anticipar una respuesta.

Esfuércese por hacer el mejor trabajo posible. Acostúmbrese a preguntarse qué pensará otra persona del equipo sobre su 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. Asuma la responsabilidad de implementar una solución cuando señale un problema.