¿Qué sombrero no debe usar un programador? [cerrado]

En mi experiencia, los desarrolladores de software tienden a usar múltiples sombreros y cumplir múltiples roles con diferentes responsabilidades. Desde no solo la codificación, sino a veces también la escritura de SQL, el diseño de la interfaz de usuario, el diseño de la base de datos, la manipulación de gráficos e incluso la prueba de control de calidad.

Si el rol principal es escribir software / código, ¿qué roles no debería asumir el desarrollador? ¿Hay alguna?

La intención de esta pregunta no es porque un desarrollador sea incapaz de desempeñar otro rol, sino que tener el rol adicional realmente funciona en contra del rol principal , o realmente debería ser un rol dedicado de alguien que no programa principalmente.

Sysadmin El desarrollo de software y el manejo de la infraestructura de TI son dos conjuntos de habilidades diferentes que se parecen a un extraño. (Todo es solo golpes en las computadoras, ¿verdad?) Para una empresa pequeña, la tentación será muy fuerte para hacer que The Computer Guy sea responsable de todas las máquinas en la oficina.

Si tienes las habilidades para usar ambos sombreros, genial; pero es una de esas cosas que puede ser un tiempo mucho mayor de lo que la gente cree, y si usted es autodidacta a medida que avanza, es probable que no lo esté haciendo muy bien.

Te pones el sombrero que te pide tu empleador. Eso es lo que te hace un jugador de equipo. Eso es lo que te convierte en un solucionador de problemas .

La gente queda demasiado atrapada en la idea de ser un "desarrollador" o un "arquitecto" o un "analista". Tornillo que. Deberías ser un solucionador de problemas. El código es solo una herramienta en tu cinturón.

La resolución de problemas nunca pasa de moda.

Si mi empleador quiere que brinde soporte técnico o construya computadoras, que así sea. Piensa que están desperdiciando su dinero, considerando un salario de desarrollador, pero ese es su negocio. Estoy aquí para resolver problemas. Sin embargo, puedo hacer eso, lo haré. Y si siento que, después de cierto tiempo, mis talentos se desperdician o mi satisfacción laboral no está donde quiero que esté, entonces tengo el derecho de pasar a otro trabajo.

Pero a la pregunta básica: no hay un sombrero que no uses. Diablos, si quieren que vayas a buscar café, hazlo. Resuelve sus problemas; solo sepa que tiene derecho a encontrar otro trabajo si desea un cambio.

¡Ensayador!

¡Envíenos evaluadores directamente de la escuela de evaluadores si es necesario!

Sin los evaluadores, la gente espera que todo funcione de la mejor manera porque el programador es el evaluador y son muy inteligentes, por lo que debería funcionar.

No digo que la alimentación de perros no sea una buena idea. Creo que los probadores son muy importantes ahora que soy programador.

Debes tener cuidado de convertirte en el hombre de referencia para problemas de hardware de oficina . Esto puede incluir la resolución de problemas de la PC, la administración del servidor, las copias de seguridad e incluso el trabajo del sistema telefónico. Cometí el error de mencionar mi experiencia previa en hardware y, finalmente, mis tareas de hardware / solución de problemas entraron en conflicto con mis tareas de programación.

Un programador no debe ser el único probador de su propio código .

Los desarrolladores escriben código con un conjunto de supuestos. Si los evaluadores tienen el mismo conjunto de suposiciones, no ejercerán la funcionalidad inesperada fuera de esos límites, y muchos problemas permanecerán sin ser detectados.

Además, para avanzar, los desarrolladores no están muy motivados para tratar de romper cosas, mientras que los evaluadores sí (tal vez a un nivel subconsciente).

Esto no implica que la prueba de desarrollo sea inútil. Todo lo contrario: las buenas pruebas de desarrollo permiten a los evaluadores centrarse en encontrar problemas más profundos. Sin embargo, las pruebas de desarrollo no sustituyen a un probador dedicado.

Dos que se me ocurren de inmediato.

1. Apoyo técnico. No estoy aquí para ayudar a los clientes a trabajar a través del nuevo sitio o enseñarles cómo usar las funciones.
2. Si bien puede ser necesario interactuar con los clientes en varios puntos del proceso, a menos que sea un programador gerente, realmente no debería comunicarse directamente con ellos sobre las características y las implementaciones de diseño.

Se podría decir que el desarrollo de CSS / UI estaría fuera del "ámbito" de programación, pero en mi experiencia es una habilidad necesaria hoy en día. No puede simplemente salirse con la suya y depender de otra persona para implementarlo correctamente. Puede que no me guste implementar el diseño o alterar el código para manejar un nuevo diseño, pero eso es parte del trabajo.

Escribir consultas está bien, las pruebas Q / A están bien (e IMO debería ser el trabajo del programador, hacer que un departamento externo lo haga es encontrar, pero primero debe probarlo). La administración del servidor es un poco gris. Dependiendo de qué tan grande sea el proyecto o si tiene un administrador de servidor dedicado, puede o no ser necesario.

En general, según mi experiencia, la mayoría de los programadores no deben desarrollar la apariencia de la interfaz de usuario, aunque ciertamente soy capaz de desarrollar una interfaz de usuario (y, a menudo, crear una cuando construyo un prototipo o prueba de concepto), esto es es mejor dejarlo a una persona de factores humanos (que en nuestra pequeña empresa es un artista gráfico que también hace los diseños de pantalla y crea la mayoría de los manuales y folletos).

Además, los desarrolladores no deberían estar haciendo pruebas de control de calidad: ese es el trabajo del departamento de control de calidad (la empresa en la que trabajo fabrica dispositivos médicos integrados, por lo que es un requisito que las pruebas sean realizadas por un departamento separado).

Por otro lado, no veo ninguna razón por la cual los desarrolladores no puedan diseñar bases de datos y escribir SQL, si tienen los antecedentes para hacerlo, lo he hecho muchas veces.

Apoyo técnico

Gran parte de mi día se desperdicia tomando llamadas de soporte técnico ...

Algunos populares son:

• "Mi cuenta está bloqueada" o "Olvidé mi contraseña"
• "Mi [teléfono | teclado | mouse | computadora] no funciona"
• "Mi computadora es lenta, ¿puedes verificar si hay algo inusual?"
• "¿Por qué sucede X cuando hago clic en este botón? Debería estar haciendo Y"
• "Sigo recibiendo estas ventanas emergentes ..." o "Creo que tengo un virus"
• "Esta persona ya no está aquí, ¿puedes desactivar todas sus cosas?"
• "Tenemos un nuevo empleado, ¿puede configurarlo con inicio de sesión, tarjeta de seguridad, teléfono, correo electrónico, etc.?"

Cualquier rol que lo haga manejarse. En equipos pequeños, a menudo hay una tendencia a convertir a uno de los desarrolladores principales en el gerente del proyecto, pero también a mantenerlo en el equipo como programador. Esto lleva a todo tipo de problemas, ya que este tipo, como programador, básicamente no está administrado. En lugar de delegar todas las tareas a los otros miembros del equipo, a menudo se verá tentado a asignar muchas de ellas a sí mismo, especialmente las tareas más difíciles. Por lo tanto, las tareas más difíciles, las que tienen más probabilidades de causar problemas, se asignan a una persona que solo está disponible en un 50% como programador y, como tal, no informa a nadie. Cuando otros miembros del equipo no pueden cumplir, en lugar de patear el trasero, intentará hacer sus tareas, porque, como gerente de proyecto, es responsable del éxito y la forma más segura de hacerlo es hacerlo él mismo. ¿no es así?

Soporte técnico para algo que no tuvo mano en el desarrollo, implementación o mantenimiento, y que no ha recibido capacitación y no se mantiene actualizado sobre los cambios importantes. Parte de mi trabajo se ha convertido en responder el teléfono a clientes que llaman por qué su Internet no funciona. No me ocupo de esa mitad del negocio, así que no puedo decirles nada útil.

No es tener que hacer soporte técnico, con lo que no hay problema. Es ser un secretario / chico de soporte técnico mientras intenta desarrollar cosas.

Se vuelve bastante agotador tener que escuchar a las personas que se quejan todo el día y no poder decirles nada. Aconsejaría evitar esto a toda costa.

Las ventas .

Algún pobre cabrón tiene que hacerlo, pero seguramente no deberían ser los desarrolladores.

A medida que crecí, me di cuenta de que es mejor si los desarrolladores no hacen sus propias implementaciones (luché con este diente y uña). No deberían tener ningún derecho sobre la base de datos de producción, excepto derechos de selección. Nuestro código se puso mucho menos defectuoso (y lo mismo no apareció varias veces porque el cambio solo se realizó en prod y una implementación posterior del desarrollador lo sobrescribió nuevamente y luego se solucionó solo en prod con prisa, enjuague y repetición) cuando tuvo que comenzar a entregarlo a otras personas para que lo implementaran y no se les permitió hacer cambios rápidos en la producción de arreglos porque el despliegue no era del todo correcto. Además, dejamos de tener esas "actualizaciones accidentales sin la cláusula where resaltada que cambió todos los registros en la tabla".

Artista y diseñador de interfaz de usuario .

La mayoría de los programadores son muy pobres en obras de arte, pero las empresas no se molestan en pagarle a un artista para que dibuje imágenes e íconos para sus productos, y solo usan "arte de programador", con resultados horribles. (Hasta Windows Vista, este era el factor de diferenciación más obvio entre las Mac y las PC: las Macs se veían hermosas y amigables, las PC eran una molestia)

De manera similar, muchos programadores no están muy interesados ​​en la interfaz de usuario: se preocupan principalmente por su código. Simplemente exponen el contenido de sus variables miembro directamente en algunos campos editables, a menudo no les importa dónde colocan botones y campos en sus formularios, y asumen que esto es suficiente, lo que resulta en un software inutilizable. (Toda la industria de la telefonía móvil fue muy culpable de esto hasta que llegó el iPhone para mostrarles que en realidad se podía hacer una interfaz de usuario del teléfono que fuera agradable de usar)

Lotus Notes es un brillante ejemplo de lo mal que pueden ser ambas cosas si no se contrata a un diseñador profesional para ayudar a los programadores.

Redacción de pruebas generales y planes de prueba. En serio, muchachos, puedo escribir mis propios planes de prueba, pero eso significa incorporar al producto cualquier malentendido, suposiciones falsas y errores cognitivos que cometí mientras escribía las cosas. Era lo único que odiaba de una empresa en la que trabajaba; donde estoy ahora, al menos tenemos revisiones de código que probablemente captarán estas cosas.

Nunca use más "sombreros" de los que razonablemente puede manejar y se sienta cómodo, tratando de encasillar a los desarrolladores diciendo que no deberían hacer A o B, lo que significa que un gran diseñador de UI podría pasar desapercibido porque alguien piensa que los programadores deberían mantenerse alejados de la interfaz de usuario

Al final del día, todos tendrán diferentes fortalezas y debilidades y un buen gerente / supervisor / líder de equipo debe saber la mejor manera de dirigir a las personas que trabajan para ellos para garantizar que los talentos se usen de manera adecuada. Del mismo modo, si no se siente cómodo diseñando interfaces de usuario o tratando con los usuarios finales, informe al equipo para que pueda minimizar su rol en esa área. Sin embargo, debe estar preparado para recoger algún trabajo adicional en otra área.

Además, si lleva demasiados sombreros (p. Ej., Programador, diseñador de interfaz de usuario, probador, analista de negocios, etc.), le irá mal en algunos de ellos o se agotará. Asegúrese de saber cuántos sombreros puede manejar e intente mantener la carga de trabajo alrededor de ese nivel.

Más allá de eso, realmente no hay "sombreros" que un desarrollador no debería usar si tienen las habilidades para sobresalir en ese rol.

Tiendo a aceptar cualquier trabajo que me arrojen si y solo si:

• Advierto de antemano sobre mi nivel de habilidad y posibles implicaciones y mi jefe decide que es aceptable
• Hay una persona con nivel de gurú que puede (y probablemente lo hará en algún momento) ayudarme a lidiar con algo inesperado
• Lea algunos documentos, preguntas en línea, etc.

De esta manera, estoy mayormente asegurado contra mi jefe y si alguien sale mal, al menos es reparable.

Los desarrolladores son partes interesadas en la situación (como clientes, propietarios, etc.), por lo que tienen derecho a esperar un trabajo significativo. En mi opinión, eso significa la oportunidad de trabajar con sus puntos fuertes .

Por lo tanto, un desarrollador no debe usar un sombrero que no energice, contribuya al crecimiento personal y conduzca a un rendimiento máximo, y robe el tiempo de los "sombreros" que hacen estas cosas por ellos.

Además de no ser el único que prueba su propio código, creo que cualquier "sombrero" está bien si es un trabajo significativo para el desarrollador que usa el sombrero.

El "diseñador" o el "tipo creativo". Pasará de armar inocentemente una maqueta de la interfaz de una aplicación a escribir un texto de marketing para la próxima campaña publicitaria en línea o discusiones interminables sobre el tono "azul" correcto antes de darse cuenta x_x.

ese sombrero con las latas de cerveza a un lado con una pajita. mala idea si te atrapan.

editar:

Aquí está el sombrero que odio pero que tiene una gran recompensa: es una gran señal para mí que dice que si esto se rompe todo es culpa tuya ... ah, pero si es bueno, entonces tú, mi hijo, eres el buen chico que todos conocemos. son - ahora vuelve al sótano ... buen chico ... eso es todo.

El sombrero de la culpa.