¿Quién debería responder las preguntas de los desarrolladores y ayudarlos a resolver sus problemas o elegir las bibliotecas adecuadas?

¿Hay algún puesto en las empresas de desarrollo de software que responda a las preguntas de los programadores como: "¡Oh, me sale este error! Busqué ese error y no pude encontrar la solución. ¿Me pueden ayudar a resolverlo?".

O cualquiera que dirija a los otros desarrolladores y responda preguntas como" "¿Qué biblioteca debo usar para la parte de autenticación? ¿Cuál de estos módulos es mejor para usar en nuestra aplicación de versión móvil?".

Totalmente mi pregunta principal es que, considerando si tenemos una empresa que trabaja con tecnologías Angular + Flutter + Node.JS + PostgreSQL/MongoDB, etc., ¿deberíamos tener una persona llamada CTO que conozca todos los detalles sobre diferentes tecnologías y sea un héroe de ellos y ayudar a todos los desarrolladores o deberíamos tener diferentes CTO para diferentes tecnologías (como uno para Angular, uno para Flutter, uno para Bases de datos, etc.)?

¿O tal vez las cosas funcionan absolutamente diferente de lo que pienso?

Respuestas (5)

¿Hay algún puesto en las empresas de desarrollo de software que responda a las preguntas de los programadores como: "¡Oh, me sale este error! Busqué ese error y no pude encontrar la solución. ¿Me pueden ayudar a resolverlo?".

No esperaría que haya un puesto para alguien que pueda responder tales preguntas, aparte de "desarrollador". Debería ser posible acudir a cualquier desarrollador que tenga más experiencia en el área donde ocurre el problema para responder a tales preguntas. Por lo general, ese sería un desarrollador más senior.

O cualquiera que dirija a los otros desarrolladores y responda preguntas como" "¿Qué biblioteca debo usar para la parte de autenticación? ¿Cuál de estos módulos es mejor para usar en nuestra aplicación de versión móvil?".

Estas preguntas requieren un poco más de información general sobre todo el proyecto y, por lo general, las manejaría un desarrollador principal o un arquitecto, aunque en una empresa pequeña también podría ver a un CTO haciendo eso.

[...] deberíamos tener una persona llamada CTO que conozca todos los detalles sobre las diferentes tecnologías y sea un héroe de ellas y ayude a todos los desarrolladores o deberíamos tener diferentes CTO para diferentes tecnologías (como uno para Angular, uno para Flutter, uno para bases de datos, etc.)?

No. Un CTO es ante todo un gerente que es el responsable final de las opciones tecnológicas de alto nivel. El CTO puede haber elegido usar Node.JS, pero es muy posible que nunca haya escrito una sola línea de Javascript.

Son los desarrolladores quienes deben, colectivamente, conocer todos los detalles esenciales de la tecnología que utilizan.

"¡Oh, me sale este error! Busqué ese error y no pude encontrar la solución. ¿Pueden ayudarme a resolverlo?"

Un desarrollador de software . Mucha gente puede falsificar el desarrollo siendo expertos en cortar y pegar, pero los desarrolladores reales leen la documentación, leen el código y aprenden a trabajar con los sistemas. Internet es una herramienta increíble; pero no tanto cuando reemplaza la resolución de problemas con cortar y pegar.

¿Qué biblioteca debo usar para la parte de autenticación?

Un Product Manager si la autenticación es parte de sistemas externos que requieren funciones de autenticación específicas.

Un arquitecto de software si la autenticación es parte de una plataforma integrada que comparte componentes o funciones con otras partes de un todo mayor, en cuyo caso el arquitecto (si tiene uno bueno) indicará las funciones requeridas.

Un desarrollador de software si se conocen las funciones necesarias y se les asigna la tarea de seleccionar una biblioteca que admita las funciones.

El Departamento Legal si los elementos seleccionados contienen licencias que podrían afectar negativamente el lanzamiento del producto.

¿Cuál de estos módulos es mejor para usar en nuestra aplicación de versión móvil?

Un Arquitecto de software si el módulo es parte de un todo más grande y uno quiere asegurarse de que el todo encaje dentro de un marco que resuelva el problema sin esfuerzo adicional ni compensaciones obvias de mantenimiento. Un desarrollador de software siempre que comprenda las características requeridas del módulo necesario. Recuerde que mejor es "más fácil de usar para un desarrollador", por lo que la opinión del desarrollador es un hecho para determinar mejor, siempre que las funciones estén presentes y no haya requisitos arquitectónicos adicionales.

Las cosas funcionan absolutamente diferente de lo que piensas. La mayoría de los CTO reciben información de sus gerentes de productos y arquitectos de software para abordar las necesidades de los clientes y los planes de desarrollo. Luego emiten directivas y dinero para satisfacer las necesidades del cliente siguiendo el plan de un arquitecto. Elementos más pequeños que no requieren un cambio en la arquitectura y se manejan como elementos de "mantenimiento" (incluso si agregan nuevas funciones). Un buen CTO no necesita saber tanto de tecnología como de finanzas; pero, si tienen conocimientos de tecnología, pueden hacer su investigación sobre la dirección actual y actuar como una segunda opinión sobre los planes propuestos.

En muchos casos, muchos lugares no funcionan de esta manera, lo que ayuda a contribuir al "lío" que es el desarrollo de software.

  • Los desarrolladores crean la arquitectura, a menudo sin tiempo adicional para hacerlo. Esto conduce a elecciones arquitectónicas más pobres, lo que genera costos a largo plazo.
  • Los CTO actúan como arquitectos, lo que significa que pierden la oportunidad de aumentar los flujos de ingresos al centrar más la atención en las soluciones de productos que en las necesidades de los clientes.
  • Los gerentes de producto actúan como líderes de equipo, desviando su atención de la recopilación y el seguimiento de las necesidades de los clientes, lo que reduce la capacidad de reaccionar ante el mercado.
  • Muchos talleres más pequeños no pueden cubrir todos los roles requeridos, por lo que los roles se "comparten dentro de una sola persona" y es raro (pero posible) que la persona sobresalga en todos los roles, y aún más raro que administre su tiempo para hazlos todos bien.

En su caso, tiene una persona que desempeña el rol de Desarrollador que no está realmente preparada para su rol. Quizás eso se deba a los requisitos deficientes; pero, los requisitos nunca están perfectamente detallados. Es trabajo del desarrollador traducir los requisitos subespecificados en un producto que funcione. En un nivel bajo, "qué biblioteca hace esto mejor", serán quienes tomen las decisiones sobre lo que significa "mejor". Este tipo de preguntas son el sello distintivo de un desarrollador junior, o una persona que acaba de aprender un lenguaje de programación sin aprender mucho sobre su oficio.

Parece que el título que está buscando es líder técnico (nical) / ingeniero principal o arquitecto de software .

Un ingeniero principal , por lo general en una función similar a la de un líder técnico , es el ingeniero con más experiencia en el equipo. Por lo general, tienen la mayor experiencia en el dominio del producto y son los mejores para leer documentación compleja para aprender cosas nuevas, trabajar de forma independiente en sistemas grandes y complejos y asesorar a cualquier nivel de ingeniero en el equipo (incluso ingenieros senior). La diferencia entre un líder tecnológico y un ingeniero principal tiende a ser que un líder tecnológico tiene un poco más de interfaz con la administración y un poco menos con la ingeniería, mientras que los ingenieros principales son como ingenieros súper senior, tienen muchas de las mismas responsabilidades que ingenieros superiores, pero aún más.

Un arquitecto de software está un poco menos en el lado de la ingeniería y un poco más en el lado de la gestión de proyectos. Tomarían decisiones como qué bibliotecas o marcos usar para un proyecto o caso de uso en particular. Tienden a no hacer demasiado desarrollo directamente, sino a tomar decisiones técnicas generales que los desarrolladores pueden convertir en un producto. No es raro que un arquitecto de software y un ingeniero principal o líder técnico sean la misma persona, porque en ambos casos se necesita una gran variedad de conocimientos de software.

Un CTO es una posición completamente diferente. El CTO es el jefe del departamento de ingeniería. Para explicarlo brevemente, un CTO es para un ingeniero lo mismo que un CEO para un vendedor. El CEO no hace ventas directamente (por lo general, al menos para organizaciones medianas y grandes, excepto en casos muy excepcionales); tienen un equipo de ventas para manejar eso, y si es necesario, el CEO puede intervenir para crear políticas para ayudar a las ventas o lo que sea. De la misma manera, un CTO en realidad no hace mucha ingeniería; toman algunas decisiones para ayudar a los ingenieros y trabajan mucho con otros empleados de nivel C para ayudar a administrar el negocio desde el punto de vista técnico, pero en realidad no se involucran en el día a día de la ingeniería.

¿Existe algún puesto en las empresas de desarrollo de software que responda a las preguntas de los programadores...

Si está dispuesto a cambiar la fase de su pregunta para

"¿Existe algún puesto en las empresas de desarrollo de software que establezca la expectativa de la hoja de ruta del producto y pueda ser consultado para cualquier aclaración?"

La respuesta es: hay dos roles específicos para este trabajo

  • Dueño del producto
  • Arquitecto de producto

Se les puede contactar para cualquier pregunta/duda relacionada con casos técnicos o, en general, sobre la elección de tecnologías, o para una revisión/opinión rápida sobre los pros y los contras de diferentes enfoques, etc.

Dicho esto, si realmente está buscando resolver problemas cotidianos (como la ayuda de depuración y / o problemas de código), la mayoría de ellos se pueden resolver mediante una revisión por pares o preguntando en el equipo por ayuda, a un colega, a un ingeniero senior, a un líder técnico o a un gerente técnico (si hay uno disponible). También se pueden utilizar sitios de Stack Overflow/ Stack Exchange (como último recurso).

Para concluir: no hay un rol específico (y dudo que lo haya alguna vez) para responder preguntas de "dame tez codez". Para eso se paga a cada individuo, para resolver problemas (de código o de otro tipo).

"No hay una función específica (y dudo que alguna vez la haya) para responder preguntas de 'dame tez codez'". - tipo de. Si bien es muy específico para temas individuales, definitivamente puedo ver equipos en los que todos conocen más o menos SQL, sin embargo, hay un especialista en bases de datos (con este es oficialmente su rol) que será la referencia natural cuando se trata de "¿Cómo hago $insertar -problema-no-trivial-aquí en SQL?" tipo de preguntas.
@ORMapper no trivial != "dame tez codez"

Depende en gran medida de las empresas individuales. Los títulos por sí solos no dictan esto, ya que diferentes títulos tienen diferentes funciones en diferentes empresas.

Un CTO se comunica con la gerencia de alto nivel y es posible que ni siquiera escriba código. Su trabajo es asegurarse de que las decisiones técnicas de alto nivel reflejen los objetivos de la empresa.

Un CTO podría estar a cargo de elegir qué marcos, alojamiento y otras herramientas usa la empresa, pero depende de la empresa. En las empresas más pequeñas, es común que un CTO se duplique como arquitecto o desarrollador senior.

¿Quién lidera a los otros desarrolladores y responde preguntas como" "¿Qué biblioteca debo usar para la parte de autenticación? ¿Cuál de estos módulos es mejor para usar en nuestra aplicación de versión móvil?"

Dependiendo de la empresa, podría ser cualquiera de los siguientes:

  • CTO / Director Técnico
  • Gerente técnico
  • Arquitecto
  • Desarrollador principal
  • Desarrollador Senior

Nadie conoce todos los detalles sobre cada idioma o biblioteca. Cualquier desarrollador senior debería poder decirle qué biblioteca usa para una tarea en particular, o es posible que deba investigar una usted mismo.

El trabajo de un arquitecto es diseñar el sistema, no codificar el sistema. Su diseño puede incluir o no qué marco se debe utilizar. - Si no está documentado, depende de los desarrolladores senior o líderes tomar esa decisión, para elegir uno que cumpla con los requisitos del sistema según lo dispuesto por el arquitecto.

Oh me sale este error! Busqué ese error y no pude encontrar la solución. ¿Me pueden ayudar a resolver?

No es algo que le gustaría preguntarle a un CTO o arquitecto. Usted preguntaría:

  • Un colega
  • Desarrollador Senior
  • Desarrollador principal

Si es un problema que nadie puede resolver, entonces escalaría a niveles más altos y terminaría con la persona técnica más experimentada. En todos los lugares en los que he trabajado, este ha sido el CTO.