eduardweb.
Off-topicÎncepător#workflow#productivitate#burnout#mental-health

Zile în care nu am chef de cod: cum salvez ziua fără să mă prefac motivat

De Maria Vasilescu, 26 sept. 2026 · 11 vizualizări · 2 like-uri

Postat acum 5 zile

Sunt dimineți în care cafeaua nu-și face efectul și simplul gând de a deschide VS Code îmi dă o stare fizică de lehamite. Nu e burnout grav, ci doar creierul meu care refuză categoric să gândească abstract sau să caute un race condition subtil. În loc să mă prefac că lucrez 8 ore în timp ce dau scroll pe Reddit, am învățat un sistem simplu care-mi ține tichetele în mișcare fără să scriu o singură linie de logică nouă.

Nu forța logica grea când ești în ceață

Cea mai mare greșeală pe care am făcut-o ani de zile a fost să mă încăpățânez. La un proiect cu vreo 14k utilizatori activi, m-am forțat într-o zi proastă să rescriu un modul de plăți doar ca să demonstrez că trag de mine. Rezultatul? A doua zi, cu mintea limpede, am șters tot branch-ul: 6 ore de muncă aruncate la gunoi pentru că scrisesem un cod întortocheat, plin de edge cases ignorate.

Dacă simți că te blochezi la o banală schemă de reducer sau un controller REST, oprește-te. Să forțezi arhitectură într-o zi proastă înseamnă doar că vei genera tech debt pe care tot tu îl vei repara săptămâna viitoare, probabil cu nervi dubli.

Treci pe modul „secretară tehnică”

Fiecare echipă are o grămadă de task-uri pe care toți le urăsc în zilele bune, dar care sunt ideale pentru zilele fără chef:

  1. Curățenie în backlog și tichete vechi. Tichete cu descrieri vagi, reproduceri lipsă, issue-uri deschise acum 6 luni care nici nu mai există pe branch-ul curent. Faci triaj, ceri detalii de la QA, închizi ce e mort demult.
  2. Actualizat dependențe mici. Schimbi un minor version la 3 pachete, rulezi testele automate, verifici că build-ul trece. Consum mental minim, dar bifezi mentenanță utilă.
  3. Documentație. Scrie pe scurt cum se configurează mediul local pentru noul serviciu sau actualizează README.md-ul ăla prăfuit pe care oricum toți juniorii îl înjură când fac onboarding.

Fă code review, dar cu o limită clară

Aici e un trade-off sincer. Code review-ul într-o zi fără chef merge brici dacă te uiți după chestii structurale: convenții de denumire, teste lipsă, formatare, erori evidente de tipar sau logică de suprafață. E o activitate pasivă utilă pentru echipă.

Nasol e că riști să aprobi PR-uri complexe fără să vezi dedesubturile. Dacă colegul tău a rescris o bucată critică de cache distribuit, nu-ți pune aprobarea pe el doar ca să pari ocupat. Dacă nu ești în stare să simulezi fluxul în cap, lasă-i un comentariu sincer: „Mă uit mâine dimineață atent pe logica asta, azi sunt cam prăjit”. Oamenii apreciază sinceritatea mult mai mult decât un approve dat în orb care explodează în producție.

Regula de 20 de minute

Când chiar am pe masă un task prioritar de care depinde release-ul, aplic regula simplă: îmi pun un timer de 20 de minute. Îmi propun să scriu doar cel mai prost cod posibil care să compileze. Fără refactorizare, fără abstractizări, fără griji că arată oribil.

În cam 50% din cazuri, odată ce trec de fricțiunea inițială, creierul intră în ritm și pot duce ziua la capăt onorabil. În restul de 50% din cazuri, dacă după 20 de minute tot mă uit ca vițelul la monitor, recunosc înfrângerea: iau task-urile mărunte de mai sus sau, dacă sprintul îmi permite, închid laptopul cu o oră mai devreme și ies la o tură de alergat.

Voi cum gestionați zilele astea? Trageți de voi prin forță brută sau aveți alte trucuri să salvați aparențele și progresul?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.