Evite convertirse en un programador "teórico"

Encontré este artículo en varias publicaciones sobre SO. Me encuentro cayendo en el sexto arquetipo; el "teórico".

Define al "teórico" como:

El teórico sabe todo lo que hay que saber sobre programación. Él o ella pueden pasar cuatro horas dando conferencias sobre la historia de un lenguaje de programación oscuro o proporcionando una prueba de cómo el código que escribió es menos que perfectamente óptimo y puede tomar tres nanosegundos adicionales para ejecutarse. El problema es que The Theoretician no sabe nada sobre el desarrollo de software. Cuando The Theoretician escribe código, es tan "elegante" que los simples mortales no pueden darle sentido. Su técnica favorita es la recursividad, y cada bloque de código se ajusta al máximo, a expensas de la oportunidad y la legibilidad.

El teórico también se distrae fácilmente. Una tarea simple que debería tomar una hora lleva a los teóricos tres meses, ya que deciden que las herramientas existentes no son suficientes y deben construir nuevas herramientas para construir nuevas bibliotecas para construir un sistema completamente nuevo que cumpla con sus altos estándares. El teórico puede convertirse en uno de tus mejores jugadores, si puedes hacer que juegue dentro de los límites del proyecto y dejar de pasar tiempo trabajando en el algoritmo de clasificación final.

Incluso cuando trabajo en lo que debería ser un proyecto simple, tiendo a engancharme al tratar de diseñar todo desde cero (Esto probablemente explica por qué desperdicié unos 2 años tratando de hacer un sistema operativo desde cero. Pero incluso lo vi. fue inútil eventualmente).

¿Qué puede ayudarme a evitar hacer esto? ¿Y apegarse a los principios de KISS?

Gracias

Siendo un teórico por naturaleza, puedo decirle que trabajar en una tienda Agile curará rápida y decisivamente todas esas tendencias. En particular, una operación de programación eXtreme, con programación de pares (idealmente rotando con frecuencia), desarrollo basado en pruebas, time boxing y sprints limitados, deja al descubierto su trabajo para que lo vean todos sus colegas, y requiere que se abra y colabore en minuto a minuto. Este es un cambio enorme de las tareas separadas en un entorno de oficinas aisladas en el que florece el trabajo al estilo teórico. Requiere total honestidad e integridad total, ya que todos dependen activamente de los demás de forma continua.

Todavía valoro mi mirada del ombligo, pero tengo que consentirlo en casa, o en esas raras ocasiones en que puedo trabajar en un proyecto paralelo que no es parte del desarrollo de la línea principal.

1. Ten metas para lo que se supone que debes desarrollar.

2. Limite esos objetivos a algo que pueda entregarse en un futuro cercano.

3. Luego concéntrese en esos objetivos, eliminando todas las demás consideraciones. Sin antecedentes No historia. Sin extensiones Nada general o abstracto.

4. Luego, acomódelos aún más en lo menos que pueda hacer para que se pueda entregar. No está bien. No es flexible No mantenible Simplemente aceptable

5. Luego priorice en el mínimo absoluto requerido para lograr lo mínimo que puede hacer. El punto es elegir una fecha en aproximadamente una semana y avanzar hacia esa fecha. Si no puedes entregar algo en una semana. Estrecho. Atención. Recortar. Reducir.

6. Luego elimina la pelusa. Solo tienes una semana. Sigue cortando.

7. Luego, concéntrese en una implementación reducida que se realizará lo antes posible. Idealmente, menos de una semana, para que tenga tiempo de escribir documentación.

He trabajado con teóricos. Considero que los "extras" son una excusa para evitar hacer algo que podría calificarse como un fracaso.

Hacer, y fracasar, es difícil. Hablar sobre hacer algo es más fácil que hacer algo. Una gran cantidad de investigación y pensamiento es una forma de evitar hacer algo incorrecto y luego volver a trabajar después de enterarse de que los usuarios mintieron.

Simplemente ponga el código delante de ellos. Llamarán al código un fracaso. Sucede. Pero en el proceso de falla aprenderá cuáles son los requisitos reales. Y aprenderás que ellos mintieron.

No estoy seguro de que sea algo tan malo. Claramente, necesita ser productivo o no hará su trabajo, pero tener interés en el campo, ser un estudiante de arte, por así decirlo, no es algo malo.

Aprovecharía sus puntos fuertes, buscaría oportunidades donde su estilo y preferencia sean una ventaja.

Para garantizar que sigas siendo productivo mientras te dedicas a escribir un marco MVC en Erlang (o lo que sea que te resulte interesante), tal vez deberías programar tu trabajo más esotérico, por ejemplo, una hora al día. Durante el resto del día, solo concéntrate en el trabajo duro y haz el trabajo. Cuando vea algo interesante que lo distraiga, marque o marque una nota, pero continúe, luego regrese a él en su intervalo de tiempo asignado.

Personalmente, tengo una gran cantidad de URL que parecen interesantes, y una pila de libros de la biblioteca también. Tal vez obtengo alrededor del 10% de esas URL al final, y tal vez leo el 50% de los libros al final, pero aún así hago el trabajo diario también.

He tenido este problema yo mismo. Dos técnicas han ayudado:

1. Use la técnica Pomodoro o alguna otra técnica de gestión del tiempo en la que establezca una secuencia de objetivos a muy corto plazo. Cuando tiene que descubrir lo que puede lograr en los próximos 25 minutos, lo mantiene enfocado en el trabajo útil.
2. Desarrollo basado en pruebas. Si tiene que escribir una prueba concreta antes de escribir cualquier código, minimiza el soñar despierto. (No hay forma de escribir una prueba para "elegante".) Después de que algo funcione, puede pasar más tiempo del que debería refactorizar, pero al menos trabajará en código real en lugar de un ideal imaginario.

No te golpees demasiado. Es más fácil lograr que un teórico se concentre y haga un trabajo útil que lograr que las personas a quienes no les importa amplíen sus horizontes.

Evite stackoverflow.com . No me malinterpreten, soy un gran admirador, pero SO y otros foros orientados a la programación hacen que el enemigo del bien sea perfecto . Después de un tiempo, puede comenzar a sentir que miles de personas inteligentes están mirando por encima de su hombro y que nada de lo que escribe es lo suficientemente bueno. Simplemente haga que algo funcione e intente hacerlo comprensible. Siempre puede volver a visitar si necesita mejorar.

Además, evite artículos como el que ha vinculado. ¿Realmente crees que hay diez tipos de programadores? ¿O que alguien que conoces encaja completamente en una de las categorías descritas? Artículos como este tienen cierto atractivo porque contienen un poco de verdad: puedes verte a ti mismo y / o a algunos de tus compañeros de trabajo en algunos de los estereotipos. Pero las categorías contienen tanta agua como los signos astrológicos. Intenta esto la próxima vez que estés en el mezclador posterior a la conferencia: "Hola, soy un Cowboy de código. ¿Cuál es tu tipo?"

Eso no quiere decir que su pregunta no sea válida: si está pensando demasiado, es bueno saber cómo evitar esa tendencia. Pero no dejes que este experto te convenza de encasillarte a ti mismo.

Hay una pauta simple que, cuando está completamente desempaquetada, explica completamente cómo evitar este escenario.

Haz lo más simple que pueda funcionar.

- Kent Beck

Creo que una forma de mantener la cabeza fuera de las nubes es obligarse a escribir aplicaciones reales de principio a fin, además de escribir sus API o marcos teóricos. Intente poner un cuadro de tiempo alrededor de algo e intente "terminarlo" dentro de ese tiempo. Escribir marcos requiere una buena comprensión de los patrones de diseño y la arquitectura, pero descubrí que escribir una aplicación completa dentro de un período de tiempo fijo requiere diferentes habilidades que escribir un marco súper bien diseñado.

Si alguna vez quieres completar una solicitud, en algún momento tienes que bajar a la tierra y simplemente hacerlo. Esto puede requerir hacer sacrificios en los diseños, o verse obligado a implementar una función de una manera que no le satisfaga, debido a algún tipo de restricción. Soy como tú, inclinado a escribir y reescribir cosas un millón de veces, pero si me enfrento a tareas que tienen que hacerse dentro de un cierto período de tiempo, encuentro que elijo mis batallas, y solo tomo las cosas Cosas más importantes.

Simple :

1. Se pragmático .

El lado opuesto del teórico (que tiene sus ventajas en el lado de información / conocimiento del dominio de programación) es el pragmático.

Aplicar KISS, DRY, SOC y otras formas de pensar, como se describe en esta respuesta , significa ser pragmático.

También puedes aprender a ser pragmático leyendo este libro:

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

No olvide que la teoría y la práctica funcionan juntas, no solas. Sin mucha práctica, tu conocimiento no es nada. Sin mucho conocimiento no puedes mejorar tu práctica rápidamente.

Entonces, practica mucho. Y aprende mucho. Pero no dejes que uno supere al otro.

En sus proyectos, establezca una fecha límite. Apégate a ello. Luego piense pragmáticamente sobre la forma de terminar su proyecto antes de esa fecha límite. (lea el libro, realmente) Luego comience a codificar, comience a leer lo que necesitará saber, cambie de lectura a codificación y limite su tiempo de lectura.

Hrm ... Quizás tal vez intentes conseguir un trabajo en un negocio que requiera que escribas aplicaciones bajo una línea de tiempo. Yo diría por mí mismo que probablemente estoy tan lejos de ser un teórico como tú, al menos en el trabajo. Hacer ese tipo de trabajo tiene su lugar y tiempo y es importante para desarrollarse. Sin embargo, aunque aprecio ese tipo de habilidad, no tiene cabida en el mundo de los negocios, especialmente donde trabajo. ¡Un entorno de desarrollo acelerado donde a veces escribes aplicaciones en semanas y el cliente las quiere ayer! He sido bendecido con desarrolladores increíbles y ha tomado tiempo hacer que todos trabajen en equipo.

Tenía un tipo que era tan brillante como puede ser, pero como tú, siempre tenía que sacar el último bit de su código incluso cuando funcionaba bien, incluso hasta el punto en que comenzó a escribir controles personalizados que eran esencialmente el iguales a las proporcionadas por el medio ambiente. Todo fue muy bueno, pero fue una pérdida de tiempo cuando tuvimos que sacar las cosas a tiempo. Muchas veces estos proyectos paralelos respaldaron al equipo y, finalmente, comenzó a sentir la presión de los demás y se puso en forma. Sugeriría comenzar a trabajar en un entorno de equipo con otros buenos desarrolladores que tienen que sacar los productos. Siempre hay tiempo más tarde para refactorizar y rehacer cosas o escribir el MergeSort más increíble que nunca; pero a veces hay que llevar el producto a un punto en el que esté funcionando y entregarlo al cliente.

No hay nada de malo en ser un "teórico" en el sentido habitual de la palabra. Tener un conocimiento básico y poder comprender la última investigación de CS es una gran habilidad, ya que es una mina de oro de ideas buenas y originales.

La 'pregunta real' aquí es más evidente en la mitad posterior de la publicación. Conozca el objetivo específico del proyecto y trabaje para ese fin, no para ningún otro. En realidad, es solo una cuestión de autodisciplina en este caso. Vea la respuesta de S. Lott para más información sobre esto :).

Reenfoque su mente de la programación e incluso de lograr cosas para entregar software de trabajo. Establece tus prioridades.

Cómo lograr esto es otra historia. La mejor manera es concebir algún proyecto y seguir todos los pasos para ponerlo en producción. Después de eso, tendrás una mentalidad diferente a la anterior.

Gracias por esta publicación. Hace que mi trabajo valga aún más la pena. Siento lo mismo tener una educación en Arquitectura de la Información trabajando como Desarrollador de Software. A menudo me encuentro luchando con "dónde cambiar las cosas" en lugar de "qué cambiar". Hay demasiadas relaciones, demasiadas cosas inteligentes y genéricas en torno a las que lleva demasiado tiempo descubrir cómo funcionan las cosas.

Así que empiezo a hacer preguntas, y aún más preguntas hasta que conozco CÓMO y DÓNDE esto realmente se construye. Y déjame decirte que funciona. Cuantas más preguntas provoque un incendio, menos importante es mantener la arquitectura original y, finalmente, volver a lo básico.

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

Pídale a su jefe que obtenga un mentor, y luego haga lo que le dice el mentor.

La parte difícil es mantener el enfoque y reconocer que "oye, reescribamos el sistema operativo" no se beneficiará sustancialmente para terminar la tarea que se le ha asignado (por lo que un gerente de proyecto no lo hará).

También haga que el mentor revise TODOS sus diseños antes de la codificación y el código real después de la codificación. Esto lo ayudará a concentrarse en lo que debe hacerse.

Tengo la misma tentación de sobregeniar las cosas, y se necesita autodisciplina y organización para superarlo. Al codificar para otra persona, así es como lo hago:

1. Al comenzar una tarea discreta, dedique unos minutos a pensar en lo que realmente se necesita en cuanto a funcionalidad, calidad, fecha de entrega, etc.
2. Tómese un poco más de tiempo para planificar cómo hacerlo , dividiéndolo en subtareas, subtareas, etc., teniendo en cuenta los objetivos del cliente del código.
3. Calcule el tiempo para cada artículo , agregando hasta un 50% para incógnitas. Si un artículo demorará más de cuatro horas, desglose un poco más. (Si estuviera haciendo proyectos universitarios, usaría una hoja de cálculo, pero como consultor con varios clientes, uso un sistema de seguimiento de problemas llamado Redmine).
4. Lo más importante: haga solo los elementos que se me ocurrieron .

Por supuesto, pasan cosas. A veces encuentro que necesito hacer más cosas, así que empiezo de nuevo en el n. ° 1. A veces encuentro que una tarea tomará mucho más tiempo de lo que pensaba: comenzar de nuevo en el n. ° 1. A veces sé de antemano que mi diseño necesitará más detalles más adelante, así que planifico una subtarea de reestimación donde empiezo de nuevo en el n. ° 1.

Cuanto más hago esto, mejor lo hago. La autodisciplina es un músculo mental que se fortalece con el ejercicio, y también mejoro al estimar cuánto tiempo tomarán las cosas y hacer compensaciones técnicas. Y me parece útil recordar una cita del general Patton: "Un buen plan ejecutado violentamente ahora es mejor que un plan perfecto ejecutado la próxima semana".

Como desarrollador solitario, mi flujo de trabajo combina esto con aspectos de Agile, incluida una placa Kanban. A veces salgo en tangentes, pero trato de limitar las desviaciones a unas pocas horas a la semana, y funciona bastante bien.

Si planea trabajar en la industria privada, es realmente importante controlar el impulso "teórico". El programador más brillante que conozco vive en Silicon Valley, pero no ha tenido un trabajo durante años porque tiene una reputación de entregar el código perfecto demasiado tarde.