¡Hola a todos! Al principio quise reflejar en el título algo sobre la eficacia personal, pero luego rechacé rotundamente la idea. Quiero señalar de antemano que no se tratará tanto del logro y el establecimiento correcto de la meta (aunque esto es importante), sino más bien de la experiencia personal y los eventos que me llevaron directamente a los brazos de esta pregunta (y sucedió de manera bastante espontánea). También destacaré formas básicas de simplificar el trabajo, tan simples como efectivas.
Antecedentes
Durante la mayor parte de mi carrera de desarrollo (tanto frontend como full stack), he estado pensando en una tarea importante: el rendimiento del código. Sin embargo, la efectividad personal de alguna manera se salió de la zona de mis intereses ... Bueno, no tan directamente en absoluto, pero no me quedé allí por mucho tiempo, por lo que mi conocimiento en esta área hasta ahora era muy, muy limitado y abrupto.
Saltando largas explicaciones, pasaré directamente a ... La culminación de mi historia, que sucedió este verano. Dio la casualidad de que absolutamente todas las estrellas que podían hacerlo se juntaron. Todo estaba ahí: activamente no me gustó mi proyecto, y también me trasladaron a uno nuevo, que me gustó (en ese momento) aún menos, "agregó" felicidad y un plazo cercano, agregó leña al fuego por incidentes regulares con el entorno local, bastante grande problemas en mi vida personal, la cancelación del vuelo, gracias a lo cual me quedé atrapado en otra ciudad, si le agregas una epidemia aquí, obtienes una imagen bastante completa y comprensible. Todo esto llevó a que comencé a quemarme: me costaba trabajar, me costaba realizar tareas más o menos difíciles, todo el tiempo quería huir a algún lado: té, YouTube, un libro, etc. En algún momento, me di cuenta de que ya no podía trabajar (bueno, en absoluto).Esto es comprensible, porque todo mi trabajo en los últimos meses se ha construido sobre la autocomulsión: me obligué a trabajar. Resultado bastante lógico.
Las formas obvias de salir de esta situación son intentar cambiar de proyecto o irse de vacaciones. Pero, en primer lugar, no ocurre instantáneamente y, en segundo lugar, no sabía cuánto duraría después de unas vacaciones o en un nuevo proyecto. Luego se hizo la pregunta: ¿qué es lo que quiero, de hecho? Resultó ser cualquier cosa menos programable (increíble). Por ejemplo, beber té (me pregunto cómo responden otras personas a esta pregunta, encontrándose en una situación similar, pero quizás nunca lo sepamos). Y me dije a mí mismo: "Está bien, voy a tomar el té, pero primero haré algo". Y este es un punto muy importante, tratando de entender qué puedo hacer en tal estado, comencé a dividir la tarea en microtareas y cortar las innecesarias. Suena simple y lógico, además, estos son los fundamentos del diseño. Sin embargo, de hecho, no todo es tan optimista. En el proceso de completar una tarea,todavía consideramos la tarea como una especie de monolito, aunque es posible que se haya dividido en sus componentes antes. Además, constantemente estamos haciendo cientos de preguntas diferentes, y qué pasará si esto sucede (digamos, llega una respuesta con un error del servidor).
Hasta qué punto simplificar la tarea
Dividí el problema no en módulos independientes, sino hasta que se volvieron elementales y dejaron de causarme resistencia interna. En general, puede sonar así:
- Cree un stub de componente con una interfaz base
- Conectarla
- Agregar marcado
- Transferir datos reales
- Agregar estilos
- Escribir pruebas
Si va a ser difícil, estos pasos se pueden refinar o el componente se puede desarrollar en partes. (¿Cómo se hace?)
A continuación, quiero llamar la atención sobre tres principios importantes:
Dividir la tarea en primaria
En mi caso, la etapa inicial se veía así:
- Stub un componente con texto sospechoso
- Agrega una ruta para ella
- Comprueba que está conectada
- Descubra en qué direcciones necesita recibir datos del servidor
El resultado de esta decisión:
- Las tareas son elementales, incluso en este estado las miro con cierto alivio, no con disgusto.
- Es más fácil concentrarse en tareas como esta.
- También redujo los niveles de estrés (no me obligo, y las tareas no dan tanto miedo)
Centrar la atención en una gama limitada de subtareas
- Menos tiempo dedicado a las subtareas
- Se gastan menos recursos cerebrales
- Como resultado, la tarea en sí se completa más rápido.
Tiempo limitado de una iteración
- Puedo estar fácilmente de acuerdo conmigo mismo en que ahora trabajaré durante 15 minutos y luego tomaré un descanso agradable durante 5 minutos. Si bien convencerse (ponerse) de trabajar todo el día será más difícil y frustrante
Resumamos
Para no malgastar mi tiempo y el de otras personas, intentaré hacerlo lo antes posible:
- El trabajo ya no es estresante para mi
- Me cansé menos al final del día
- El rendimiento ha aumentado en comparación con el valor sin estrés: antes una tarea de 3 puntos de historia + pruebas de escritura me tomó 2 días, ahora resultó no más de un día y medio
- Un enfoque más profesional es utilizar un temporizador. Me gustaría hablar sobre mis éxitos (y fracasos, dónde puedo prescindir de ellos) al introducir la técnica del tomate en otro momento.