Cómo innovar a través de proyectos paralelos como programador a tiempo completo.

Answer 1

Usaré un ejemplo que uso a menudo cuando enfrento ambigüedad estratégica:

Imagine que su aplicación móvil es una corriente que está cavando para regar una aldea sedienta, mientras que, de lo contrario, se le emplea por hora para llevar agua en cubos:

1. Sea estrecho, no ancho.
2. Sea simple, no complejo.
3. No pidas permiso para empezar.
4. No esperes que otros lo “vean”.
5. No esperes las opiniones de los aldeanos.
6. Que la sed supere las barreras terrestres.
7. Deje que los transportadores de cubos de agua le paguen en trabajos de excavación, una vez que haya acortado su camino hacia el agua. Cuanto más corto sea el camino, más tiempo tendrán para reembolsarte cavando (crecimiento exponencial)

Puedes cometer errores en cada uno de estos pasos y aún así recuperarte. De hecho, te darás cuenta de que ser inexperto es una ventaja en casi todos estos factores.

Solo hay un factor crítico del que nunca te recuperarás si te equivocas:

Sed.

Answer 2

El tiempo, en términos de productividad de un programador, normalmente se piensa en términos de trabajo enfocado en lugar de solo estar en la oficina. Hay mucho que un programador debe hacer en lugar de solo codificar, y cada equipo de software (o individuo) en cada proyecto debe aprender a trabajar de manera eficiente para esa situación particular antes de alcanzar la “velocidad” completa.

Estoy usando la terminología ágil, pero en general, lo que demora dos horas para hacer en la semana 1 podría llevarle media hora en la semana 12. Aprendes lo que todos saben y también cómo superar varios obstáculos presentes en cada proyecto complejo, que definitivamente incluye una nueva “plataforma móvil” creada por un solo “nuevo desarrollador”. Por lo tanto, cuando calcula el tiempo que tomará una tarea, debe reconocer que los largos períodos de “estar en la zona” suelen ser contraproducentes, y aprender a caminar antes de poder correr es una rutina.

¿Cómo administras tu tiempo? Solo sea realista y libre de distracciones, y asegúrese de estar bien descansado y siempre trata de trabajar de manera más inteligente, no más difícil. Pregúntate a ti mismo “¿Realmente necesito hacer esto?” En cuanto al diseño, el “tío Bob” (solo un tipo inteligente) sugiere siempre codificar hacia una abstracción, para que pueda implementar algo simple inicialmente y luego intercambiarlo por algo complicado. Su ejemplo sugiere crear una base de datos simulada que solo use archivos de texto inicialmente y luego proporcionar soporte de MySQL o lo que sea más adelante, si realmente vale la pena reemplazar esa base de datos falsa. En su situación, no solo era suficiente, sino que era más rápido. Cuanto más tarde posponga las decisiones arquitectónicas, más informadas estarán sus decisiones y más sabrá qué es necesario y qué no.

(Habrá algunos comentarios extraños sobre esto, ya que inicialmente la pregunta se leía “cómo se define el tiempo como programador”. Cambié mi respuesta para adaptarla a la pregunta redefinida adecuadamente, así que ahora no solo estoy explicando qué sistema UNIX tiempo es :))