¿Cuáles son las buenas maneras de cambiarse si es un ingeniero lento o su administración no está satisfecha?

Answer 1

Considere pedir prestado el estilo de un abogado para explicar sus argumentos. Cada punto que mencione debe estar respaldado por evidencia comprensible por un no profesional.

• Tengo un trabajo pendiente cuando me asignas un nuevo trabajo. Por lo tanto, no comenzaré a trabajar en el nuevo proyecto inmediatamente con total dedicación hasta que envíe el código anterior a menos que las prioridades cambien y usted desee cancelar el trabajo asignado previamente.
• Dedico tiempo a aclarar los requisitos iniciales y a obtener información adicional del gerente de producto para anticipar los requisitos futuros. Esto requiere interacción con los clientes, que nunca es en tiempo real. Hacer esto me permite evitar perder tiempo construyendo características basadas en un malentendido.
• De acuerdo con las mejores prácticas de la industria, que puede leer en estas fuentes ____________________, invierto tiempo en producir código con menos errores. De acuerdo con los datos de seguimiento de errores de nuestra empresa, produzco el ___% de errores reproducibles enviados por los evaluadores y otras partes interesadas.
• Cuando finalmente cierro la sesión en mi módulo de código asignado, soy un experto en ese código y puedo admitir todas las consultas relacionadas con ese trabajo. Esto se traduce en una resolución de tickets de soporte más rápida por parte de los clientes.
• El desarrollo de software es un proceso no lineal. A veces tengo que esperar a que otros miembros del equipo completen sus tareas. Por eso, estimo conservativamente para que no se sientan presionados.
• Mi código está optimizado para el rendimiento y la escalabilidad. Cuando el equipo se enfrentará a desafíos de rendimiento en un futuro próximo, mi código tendrá muchas menos probabilidades de ser sometido a refactorización porque ya está altamente optimizado. Esto le permitirá al equipo ahorrar tiempo y dedicar más tiempo al código producido por programadores más rápidos que solo producen el código que es relevante hoy en día.
• No escribo solo código de producción, también escribo código de prueba. Eso consume tiempo, pero reduce el tiempo que se dedicaría a corregir los errores creados sin este código. Está de acuerdo con las mejores prácticas de la industria que puede leer en estas fuentes ___________.

Su desafío es que tenga en cuenta la escalabilidad, la capacidad de expansión y el rendimiento. Puede ayudarlo a dedicar una parte de su día a trabajar solo en ese aspecto en el código que envió anteriormente.

Esto le permitiría enviar el código más rápido sin una optimización prematura.

Puede encontrar el artículo de programación basado en la evidencia de Joel [1] algo que vale la pena compartir.

En resumen, ¿su código terminado suena como lo que acabo de explicar? Puedes encontrarte buscando un equipo que aprecie la calidad.

[1] Programación Basada en Evidencia

Answer 2

Un error común de los jóvenes ingenieros es tratar de “hervir el océano”. Creo que esto puede ser parte de su problema.

Tenga en cuenta que no todos los trabajos son iguales o requieren el mismo nivel de detalle.

El diseño es bueno, pero el sobre diseño es malo. Diseñe para los verdaderos límites del dominio del problema y, si puede, deje algo de espacio para el crecimiento. Pero no intentes resolver todos los problemas de mañana hoy. Si los límites del problema de hoy no están claros, solicite una aclaración. (Y mantenga un registro escrito de lo que le dicen).

El hecho del asunto es que muy poco el software sobrevive más de 3 a 5 años sin un gran recorrido de todos modos. Resuelva el problema de hoy y no dedique mucho tiempo a resolver el problema de mañana que quizás nunca llegue.

La optimización prematura es una pérdida particular de tiempo. Fui el experto / evangelista de presentaciones en Java de Sun. Mi primer consejo fue SIEMPRE este:

Regla # 1: el 80% del trabajo se realiza en un 20% de su código.
Regla # 2: No puedes * posiblemente * saber que ese 20% va a estar adelantado.

Cree un código limpio, claro y bien encapsulado porque es el más fácil de modificar. Mida ese código en una aplicación del mundo real utilizando un generador de perfiles y ajuste las partes que importan.

“La optimización temprana es la raíz de todo mal.” – Donald Knuth

Answer 3

Siguiendo el excelente comentario de Jeff Kesselman, tenga cuidado al hacer esto:

El problema general

Answer 4

¿Alguna vez has intentado sólo la codificación?

Solo ponga una línea tras otra (omita todas esas otras cosas). Vuelva y cambie algunos de ellos si tiene que hacerlo, pero solo intente producir algo, aunque sea de mala calidad, que cumpla con el requisito lo más rápido posible. De hecho, intente probar una versión anterior tan pronto como sea posible que luego agregue la siguiente funcionalidad.

Cometerá errores y tendrá que regresar y cambiar las cosas, pero será una experiencia de aprendizaje, y la próxima vez que tenga que encontrar una solución con similitudes, se beneficiará de esa experiencia y anticipará instintivamente algunas de esas cosas que La primera vez, necesitaba ser cambiado.

No me malinterpretes, no digo que esto sea mejor, pero podría ser más rápido, y parece que eso es lo que quieren tus gerentes.

Y como dice Jeff Kesselman en su respuesta:
“El hecho del asunto es que muy poco el software sobrevive más de 3 a 5 años sin un gran exceso de personal de todos modos. Resuelva el problema de hoy y no dedique mucho tiempo a resolver el problema de mañana que quizás nunca llegue”.

(Desde una perspectiva de la vieja escuela, básicamente estoy diciendo desarrollo iterativo sobre SSADM).

Además, si está bastante seguro de que los requisitos son optimistas dado el marco de tiempo, acuerde las prioridades con la administración. Esto le permite desarrollar el desarrollo en fases y enfocarse primero en los requisitos básicos, y luego es bueno tenerlo, si el tiempo lo permite. A menudo el tiempo no, y no se hará, y la solución seguirá funcionando. Por lo menos has mitigado la situación.

Answer 5

Estás haciendo lo que es responsable y práctico para el largo plazo de tus proyectos, lo cual es genial. Los buenos gerentes en los entornos adecuados le darán tiempo y flexibilidad suficientes para ser tan minuciosos.

Es posible que tus gerentes no vean el valor que estás aportando. O a ellos mismos puede que no se les dé suficiente tiempo a las partes interesadas del proyecto. A menudo hay presiones sobre un proyecto que no son visibles para los ingenieros. Además de eso, algunos gerentes no técnicos siempre tienen la impresión de que los desarrolladores tardan demasiado tiempo porque no aprecian completamente el trabajo involucrado.

También es posible que a veces te concentres demasiado en ciertas cosas. No me gusta omitir pensar en arquitectura, rendimiento o pruebas, pero la experiencia te enseñará dónde pasar más tiempo para obtener el mayor beneficio. Dentro de su equipo, su desarrollador líder debe centrarse en estos aspectos del proyecto, por lo que tal vez esté gastando tiempo en cosas que ya se han resuelto.

Answer 6

Tres cosas vienen a la mente:

1) Evite la abstracción prematura, vea ¿Cómo evita la abstracción prematura?

2) no se esfuerce demasiado en dar buenas estimaciones, consulte ¿Por qué las estimaciones de tareas de desarrollo de software se eliminan regularmente por un factor de 2-3?

3) No trates de hacerlo bien de inmediato. Escribe un prototipo primero. Cuando se le pregunte cuánto tiempo necesitará implementar X, responda algo así como “Puedo escribir una prueba de concepto rápida en una semana. Después de eso, puedo decirle cuánto tiempo hablaría para ponerlo en producción. Supongo que ‘ Estaré un mes, pero ya veremos “.

Ah, y también: considera la posibilidad de que tu administrador sea incompetente o simplemente no te agrade. Sucede.

Answer 7

Una práctica ágil que aborda su preocupación es el “Time Boxing”, en el que realiza un trabajo tan bueno o completo como sea posible en el tiempo asignado o se da cuenta rápidamente de que no se puede hacer.

Ahora que he respondido a su pregunta sobre cómo puede cambiar usted mismo ajustando la calidad y la minuciosidad para probar un calendario de reuniones, combinando lo más simple que podría funcionar para satisfacer las necesidades del cliente, permítame sugerir un enfoque alternativo.

Considera también encontrar un equipo cuya preocupación principal se alinee con la tuya.

Si la extensibilidad y la reutilización son fundamentales en la vista, intente trabajar en un proyecto que proporciona un servicio o una API que ahorra trabajo para otros proyectos.

Si la confiabilidad es primordial en su punto de vista, busque proyectos que tengan consecuencias realmente graves para el fracaso. Sistemas para equipamiento médico o transporte o infraestructura civil.

Parece que su proyecto actual puede estar más enfocado en el tiempo de comercialización, donde ser el primero puede ser más rentable que ser de la más alta calidad.

Como construir un servidor de publicidad para una nueva plataforma móvil. Ser el primero puede ser más rentable que esperar hasta que su servicio sea 100% confiable.

Answer 8

Estoy totalmente de acuerdo con Jeff Kesselman con respecto a la optimización prematura, las funciones de diseño excesivo, etc.

Además, le recomendaría que realice una programación en pareja con un desarrollador senior o que encuentre un mentor que lo ayude y lo apoye.

Answer 9

Como Jeff ya señaló
“La optimización temprana es la raíz de todo mal.” – Donald Knuth

Dicho esto, puede ser cualquiera de los siguientes escenarios.
1. Usted está dando estimaciones correctas pero no puede convencer a su Gerente
Este es un problema en su habilidad de comunicación. Tratando de convencerlo punto por punto por qué esto llevará tanto tiempo.
2. Realmente lo sobre diseñaste y por lo tanto estimas que es tan alto.
Intente convencer a su gerente de que esto es necesario y que el diseño actual se puede dividir en dos partes. Se puede hacer una para la versión actual para cumplir con el requisito de tiempo y el resto se puede cubrir en la versión futura.
3. Su gerente siempre dice esto para probar si usted estimó correctamente y está buscando alguna negociación.