Pragmatismo e ingeniería basados en equipos
Cuando se trata de hacer cualquier tipo de desarrollo, no me importa si es para la web, para dispositivos móviles o para alguna otra plataforma, hay muchos libros, cursos en línea, etc., que hacen que sea increíblemente fácil aprender lo que sea. es que quieres aprender.
Para ser claros, tampoco estoy criticando ninguna de las formas disponibles para aprender. Después de todo, todos aprendemos de diferentes maneras, ¿verdad? ¿Y quién soy yo para decir cuál es mejor que cualquier otra, especialmente dado el hecho de que escribo diariamente sobre temas aquí y en otros sitios?
Pero definitivamente puedo decir para mí, alguien que ha disfrutado tanto aprendiendo a través de la educación formal, tutoriales, cursos, etc., que la mejor manera de adquirir experiencia en esta industria ha sido doble:
- trabajar con otras personas,
- rompiendo cosas y aprendiendo a arreglarlas.
¿Quiero decir hacerlo en este orden específico? No. ¿Significa esto que estoy a pasos agigantados por delante de los demás? Eso es ridículo.
Pero como he tenido el placer de trabajar con otros en múltiples proyectos, hablar con otros a través de Twitter, conferencias, etc. y he experimentado tanto lo bueno como lo malo, es algo que creo que todos deberían tener la oportunidad de hacer en algún momento.
Si tuviera que resumirlo, diría que se trata de encontrar un equilibrio entre el pragmatismo y la ingeniería basados en el equipo. Sin embargo, ¿por qué, si nada de lo anterior es nuevo (dado que las empresas de software han existido durante décadas), me estoy molestando en escribir sobre esto ahora?
Pragmatismo e ingeniería basados en equipos
Probablemente podría presentar una larga lista de razones por las que encuentro importante este tema en particular, pero hay tres cosas específicas que me gustaría mencionar en esta publicación. Y, por el bien de la longitud (léase: tiempo), haré lo que pueda para que sean breves.
De hecho, el TL; DR de lo que voy a hablar tiene que ver con el pragmatismo y la habilidad de ingeniería. Originalmente, también iba a incluir una perspectiva sobre los negocios en general, pero la publicación general se desvió un poco del tema.
1 pragmatismo
He escrito antes sobre equilibrar la ingeniería y el pragmatismo . Así que puede que no tenga mucho que ofrecer en cuanto a nada nuevo, pero estoy empezando a cambiar un poco mi perspectiva.
Es decir, en un momento, se trataba estrictamente de encontrar un equilibrio entre encontrar una solución que funcione para la costumbre, que esté bien construida y que resuelva su problema. Y todavía me suscribo a eso.
Y, por supuesto, hay algo que decir sobre cómo se organiza el código para que pueda mantenerse a lo largo del tiempo. Esa es la clave. Pero cómo se escribe el código y se construye la solución es donde las cosas pueden volverse un poco más borrosas con respecto al pragmatismo.
Es decir, es fácil escribir código básico orientado a objetos, documentarlo, hacer que algunas clases o funciones se llamen entre sí, conectarse a WordPress y luego llamarlo un día.
2 Habilidad de Ingeniería
Pero ese nivel de equilibrio entre el envío de la solución y la arquitectura de la solución es una línea muy fina. Sin embargo, creo que existe el peligro de tratar de ser demasiado pragmático: si su objetivo es ser lo más pragmático posible todo el tiempo y dejar sus habilidades de ingeniería en un nivel particular, es posible que no progrese como desarrollador.
Aunque prefiero usar la programación orientada a objetos en el tipo de trabajo que hago, no soy de los que se meten en una guerra religiosa o me meto en qué versión de qué lenguaje, qué tecnología, o si es funcional, procedimental u orientado a objetos. la programación es mejor.
En pocas palabras: se trata del nivel general de habilidad que puede alcanzar a lo largo de su carrera.
Y cuando trabajo con desarrolladores que han trabajado en proyectos de diferentes habilidades, que han sido educados de diferentes maneras y que han resuelto diferentes tipos de problemas, descubro que constantemente aprendo cosas nuevas.
Esto no quiere decir que no haya conversaciones sobre cosas que podemos implementar como equipo o como asociación, pero quiere decir que puede evitar frustrar el potencial para crecer como programador.
Podría continuar con esto, pero en pocas palabras es esto: si va a trabajar con otros, asegúrese de que tengan experiencia, disfruten usando el mismo tipo de paradigmas que usted, estén abiertos a conversaciones reflexivas y traigan una variedad de experiencia a la mesa.
En última instancia, esto puede ayudar a mejorar tanto su capacidad como la calidad de lo que usted y su equipo aportan.
Siempre hay más
Como dije anteriormente en la publicación, siempre hay más. Probablemente hablaré más sobre el aspecto comercial en publicaciones futuras.
Por ahora, sin embargo, dejaré lo que he escrito donde está y partiré de ahí más adelante.