El tiempo vuela, ¿verdad?

Mi carrera comenzó en 2012, con la primera pasantía en C ++. Honestamente, no tenía idea de lo que estaba haciendo (de hecho, nada ha cambiado). Sin embargo, he aprendido algunas lecciones.

Descargo de responsabilidad: no habrá código en este mensaje.

Pregunta: ¿Cuál es el lenguaje más importante en la programación?

Esto es ingles O español, chino, polaco. Cualquiera que use para comunicarse con colegas.

Hablar con la gente es mucho más importante que hablar con los autos.

La programación es un deporte de equipo. Rara vez hay un producto brillante creado desde cero por una persona ( CodeSandbox es un gran ejemplo, aunque Ives ha contratado recientemente a un par de empleados), pero en la gran mayoría de los casos se necesita un equipo.

Las habilidades de comunicación pueden salvar o enterrar un proyecto. No te preocupes, el problema no es solo tuyo, incluso la NASA sufre por esto .

Las habilidades profesionales y de comunicación pueden ser más importantes para el éxito del proyecto que las puramente técnicas. A quién le importa que hayas contratado a los cinco mejores expertos en bases de datos del mundo si se niegan a hablar entre ellos, y terminas con cinco instancias diferentes de MySQL, Aurora y MongoDB.

Necesita comprender profundamente lo que está desarrollando y por qué

La mayoría de las personas se vuelven más felices cuando tienen una meta. Esto también se aplica al trabajo.

Su objetivo como desarrollador no es traducir JIRA a JavaScript, Trello a C #, etc. Su objetivo es resolver problemas .

Si tiene un conocimiento profundo del sistema que está construyendo / manteniendo, puede tomar decisiones fuera de la tecnología pura. Haga preguntas: ¿es esta característica incluso necesaria? ¿Qué problema resuelve? ¿Podemos resolver este problema de manera diferente? ¿ Queremos resolver este problema en primer lugar?

Tal pensamiento a veces se denomina contexto empresarial, pero si desea hacer bien su trabajo, necesita no solo comprender el contexto, sino ser capaz de moldearlo e influirlo. Para influir en un producto, no es necesario ocupar un puesto directivo en una organización. Por lo menos, esto no es necesario para comprender el producto.

Si una revisión de código es estresante, entonces está terriblemente, terriblemente mal organizada.

Oh dios Verificación de código.

Realmente no pensamos en ello, pero el acto de publicar el trabajo con su estudio por parte de otras personas es algo exclusivo de nuestra profesión. No es de extrañar que esto cause estrés.

Personalmente, vi personas enviando una revisión de código específicamente en un momento en que X no estaba en la oficina o Y estaba en un viaje de negocios. X es un programador brillante, pero difícil de sostener su revisión de código. Cientos de comentarios exigentes bajo la solicitud de grupo junior no prueban en absoluto su superioridad como desarrollador. Esto prueba solo tu mala naturaleza.

OK, pero ¿qué debo hacer cuando esta función está completamente rota?

Levántate Póngase en contacto con esta persona, hable en persona . Hable con él, descubra por qué implementó el código de esta manera.

La mayoría de la gente no quiere escribir código incorrecto. Y si lo hacen, probablemente estén lidiando con restricciones de las que no eres consciente. Es posible que tampoco sean muy buenos en la programación (todavía), y aquí puedes demostrar tu valía como mentor.

Algo DEBE salir mal, prepárate

De acuerdo con Wikipedia:

La Ley de Murphy es un proverbio o epigrama que generalmente dice: "Todo lo que puede salir mal, saldrá mal".

Esta es una de esas cosas que son demasiado ciertas. Al diseñar un sistema, siempre asuma algún tipo de falla.

Si está creando un formulario de inicio de sesión, suponga que las personas copiarán y pegarán el texto de todo el libro en el campo de contraseña.

Si crea una ventana WYSIWYG, suponga que alguien intenta romperla y es probable que pueda hacerlo.

Si tiene una base de datos, se desconectará en algún momento. Si no ha probado restaurar una base de datos desde una copia de seguridad, esta no es una copia de seguridad.

Si está preparando una demostración frente a una audiencia, asegúrese de que la demostración funcione en línea, fuera de línea, boca abajo y debajo del agua.

No tengas miedo de decir "No sé"

El privilegio más agradable del título "Senior" en la insignia es, finalmente , la oportunidad de responder:

No lo sé, nunca lo he intentado. Te miraré y te devolveré la llamada.

Siendo un junior, tenía mucho miedo: de repente alguien adivinaría que era un impostor. Después de un par de años como desarrollador, si no he visto algo, tal vez todavía no ha aparecido. O simplemente apareció otra tecnología genial que necesita ser explorada. El aprendizaje permanente no es una palabra de moda, es una realidad en TI.

O simplemente soy un estafador increíble que logró engañar a todos para que realmente pueda hacer mi trabajo. Nunca se sabe.

Aprende en público

Tan pronto como cambies de "No sé" a "Bueno, eso fue interesante", compártelo con alguien. Escriba un blog, grabe un video, hable en un evento de intercambio de conocimientos o simplemente ... cuéntele a alguien. Si crees que algo es obvio para todos, esto no es así. Incluso los mejores profesionales tienen algo que aprender de los principiantes, y viceversa.

La enseñanza es una forma increíblemente efectiva de asegurarse de que realmente comprende el tema en cuestión.

Como alguien malditamente inteligente dijo:

Cuando uno enseña, dos aprenden.

¿Qué lecciones aprendiste como desarrollador?