¿Qué es más importante: conocer un lenguaje de programación o poder resolver un problema de negocios?

Hay mucho debate sobre lo que vale la pena aprender un lenguaje de programación para hacer una carrera en el campo del desarrollo. Pero estoy profundamente convencido de que el lenguaje del conjunto de conocimientos requerido no es limitado. Desafortunadamente, no todos entienden esto.

imagen

En las discusiones de tareas, las empresas y los desarrolladores hablan diferentes idiomas.

Desde el punto de vista empresarial, no importa en qué idioma se resolverá su tarea. Las empresas no piensan, y tal vez ni siquiera saben acerca de Java, Go, Ruby y otros lenguajes y tecnologías. Es genial para los desarrolladores, por supuesto, cuando un proyecto a gran escala e interesante comienza desde cero y el equipo selecciona la pila de tecnología. Pero en el mundo real, sucede mucho más a menudo. Por lo general, una empresa ya tiene experiencia en una determinada pila, que los ejecutivos de TI no quieren rechazar. Las razones pueden ser completamente diferentes, desde la prohibición del "zoológico de la tecnología" hasta las preferencias personales de los tomadores de decisiones. Existen factores adicionales, como la necesidad de tecnologías interesantes para los equipos, con el fin de atraer y retener personal calificado.

Por su parte, los desarrolladores a menudo expresan un deseo de desarrollarse en una determinada pila tecnológica. Esta intención se ve reforzada por la gran diferencia entre los salarios de algunos idiomas. Entonces, hay personas que viven duro, por ejemplo, en el marco de Java o Python (Go, Kotlin, Scala ... la lista sigue y sigue casi sin fin) e incluso Delphi, sin tratar de ver qué más hay.

En mi opinión, el deseo de profundizar es meritorio. Pero a veces "el bosque se pierde detrás de los árboles": en el proceso de esta inmersión, el especialista simplemente olvida que la tecnología es solo una herramienta para resolver sus problemas para el negocio. Como resultado, la ceguera en una pila tecnológica completa con perfeccionismo congénito ("hagamos una refactorización durante seis meses para un proyecto que no tenga planes de desarrollo serios, simplemente porque será hermoso") no se refleja de la mejor manera en la calidad de las decisiones tomadas.

Mi punto es que un lenguaje de programación particular es secundario. La comprensión primaria de los principios de desarrollo y la capacidad de resolver problemas de negocios son primarios: el conocimiento de enfoques y patrones que ayudan a sistematizar el trabajo general, la experiencia de usar diversas técnicas, incluidas las de equipo. Con tal equipaje, un idioma más que se necesita en este proyecto en particular no es difícil de dominar. Ante mis ojos, hay muchos ejemplos de cómo las personas se están volviendo a entrenar a otras pilas durante el mes: dos entrenamientos intensivos. Por supuesto, es más difícil cambiar entre idiomas con diferentes paradigmas, por ejemplo, de funcional a orientado a objetos, pero aquí nada es imposible si una persona no se opone a ese cambio "al nivel de la fe".

Al conocer varios idiomas, para cada tarea comercial específica, puede elegir su propio enfoque para resolver, uno que no solo sea adecuado, sino que será óptimo en este caso particular. Y cuanto más el arsenal del desarrollador tenga una base de estos enfoques (idiomas), más amplio será el problema y más motivado será el stack seleccionado. Esto es exactamente lo que necesita el negocio: obtener la solución más adecuada para sus tareas.

Pero con un conocimiento profundo de un idioma, pero sin la capacidad de resolver problemas comerciales, un especialista se beneficiará lejos de cualquier equipo. Por supuesto, en proyectos individuales, un conocimiento profundo de las "fichas" del lenguaje ayuda al equipo en su conjunto a lograr un mayor rendimiento. Pero más a menudo, un miembro del equipo que conoce un idioma, pero no puede escuchar negocios, solo ralentizará a sus colegas. Y, por cierto, esta "guía para caminar hacia oportunidades no obvias" es a menudo, si se necesita en un equipo en particular, solo una (sacamos conclusiones sobre la demanda de especialistas tan limitados en el mercado laboral).

La capacidad de resolver problemas comerciales es en realidad parte de una esencia más global: una experiencia laboral integral. Puede obtenerlo tanto con el empleador como como parte de proyectos en el hogar. Es cierto, en mi opinión, solo los proyectos empresariales (donde hay clientes, presupuestos, plazos) pueden dar retroalimentación tan necesaria en tales situaciones, evaluando la calidad de la solución. A saber, esto determina la profundidad de la experiencia adquirida. Simplemente no hay nadie para obtener esos comentarios de los proyectos caseros: usted mismo hace algo y en un momento determinado decide por sí mismo que lo hizo bien. Aquí es donde todo termina. Pero cuando el proyecto se implemente para el negocio, se enviará una solución insuficientemente desarrollada para su revisión,
luego una y otra vez, si es necesario. Y en el curso de estas iteraciones, inevitablemente aprenderá varios enfoques del problema: obtendrá una comprensión de un nivel superior.

Uno de los componentes de la capacidad de resolver problemas comerciales es comprender esta tarea. Y como los desarrolladores rusos a menudo participan en proyectos extranjeros, el conocimiento del idioma inglés es necesario para esta comprensión. En este asunto, no siempre puede confiar en el análisis empresarial, ya que no hay suficientes buenos especialistas en esta área en el mercado.

Una mejor comprensión del negocio ayuda a la inmersión en una industria. Cuando no solo crea un módulo abstracto que recibe, procesa y envía paquetes de datos a un destino desconocido, sino que implementa, por ejemplo, una parte de un complejo sistema de facturación o sistema bancario, donde hay diferentes tipos de usuarios, estándares y otras características. Conocer estos detalles es muy valioso. Tal inmersión te enseña a estar interesado en lo que está sucediendo en tu parte de la tarea. Esto ayuda a encontrar la mejor solución. Conozco especialistas que nunca irán a trabajar en una tarea que no está clara por qué. Y en algunas áreas de desarrollo de negocios para desarrolladores, se proporciona capacitación interna obligatoria, porque sin inmersión, en principio, el trabajo efectivo no funcionará.

Como una pequeña adición a una mejor comprensión de los problemas comerciales, recomiendo asistir a conferencias específicas de la industria. Allí, los oradores comparten sus experiencias sobre cómo resolvieron un problema comercial utilizando la tecnología de TI. A menudo, desde allí, puede obtener información útil sobre la dirección en la que debe moverse. Aunque, por supuesto, nadie necesita repetir la experiencia de los demás en detalle.

No digo que cada desarrollador deba ocuparse de las tareas comerciales. June solo entra en este círculo, en la etapa inicial lleva demasiado tiempo comunicarse con colegas y aprender a resolver un problema específico. No hay tiempo para ampliar los horizontes. Pero a partir de la mitad, la experiencia previa forma una comprensión de qué lado abordar las tareas de un determinado tipo. En esta etapa, ya no surgen preguntas sobre el ecosistema de desarrollo: cuándo y qué estados establecer, cómo responder a las revisiones de código, etc. El especialista comienza a hacer frente incluso con tareas desconocidas más rápido: este es el momento de "detener" el componente comercial. De hecho, el senior del medio se distingue por esta comprensión de los enfoques para resolver problemas comerciales comunes. Y el deseo de tal comprensión ayuda a pasar al siguiente nivel más rápido.

Por lo tanto, insto a establecer metas para el desarrollo simultáneamente en dos direcciones. Por un lado, aprenda idiomas y, por otro, gane experiencia en la resolución de problemas comerciales específicos. Y en este desarrollo es necesario mantener un equilibrio, de lo contrario será bastante difícil encontrar un lugar en el mundo de las personas mayores. Pero dónde exactamente desarrollarse, hacia un arquitecto, un desarrollador muy fuerte o un líder de equipo, depende de las ambiciones y cualidades personales (trabajo en equipo, responsabilidad, sociabilidad, etc.) de un especialista en particular.

¿Qué opinas sobre esto?

Autor del artículo: Sergey Marina

PD: publicamos nuestros artículos en varios sitios de Runet. Suscríbase a nuestras páginas en VK , FB o Telegram-channel para conocer todas nuestras publicaciones y otras noticias de Maxilect.

Source: https://habr.com/ru/post/459294/


All Articles