Vyhoření v IT: jak skeneři nacházejí rovnováhu | Průvodce pro vývojáře

Skener, ne potápěč: jak přestat vyhořívat v IT a vytvořit prostředí pro růst

Po 15 letech v programování jsem objevil zákonitost: každé 1–1,5 roku na nové práci nastupovalo vyhoření. Pouze zavedení konceptu „Skenera“ a vědomé vytvoření prostředí pro širokou škálu zájmů mi pomohlo vyjít z začarovaného kruhu. Vyprávím, jak to aplikovat na vaši kariéru.

Schéma vyhoření: čísla nelžou

Při analýze své kariéry jsem identifikoval jasný vzorec. První místo – 5 let (Java developer), druhé – 3 roky (Salesforce developer), následující – po 1–1,5 roku. Dříve jsem hledal vnější příčiny: špatný management, zastaralé technologie, nevhodný tým. Ale skutečná příčina byla hlubší.

Na prvním místě jsem vydržel 5 let, protože uvnitř firmy jsem neustále nacházel nové výzvy: od servletů a JSP k Alfresco, GWT a FileNet. Křivka učení byla neustále stoupající. Na druhém místě – radikální změna stacku na Salesforce. Přechod byl snadný díky znalostem z Javy, krátké projekty (od týdne po pár týdnů) dávaly rychlou zpětnou vazbu a dopamin. Ale po roce–půl pół roce se stack stal povědomým, úkoly předvídatelnými a křivka učení plochou. Baterie se vybíjela.

Výjimka: jak DINS vytvořil prostředí pro skenera

Jedna firma vybočovala z vzorce – DINS. Tam jsem pracoval s potěšením, přestože v určitém okamžiku jsem chtěl odejít. Klíčový faktor – týmový lídr, který podporoval řešení jakýchkoli problémů bez byrokracie. Dostával jsem čas na studium, prototypování a zavádění. Sám jsem generoval novinku, místo abych na ni čekal od úkolů. To bylo prostředí vhodné pro skenera.

Zlom: AI jako katalyzátor kreativity

Minulé léto mi bratr doporučil Perplexity. V dialogu s Claude Sonnet jsem zaznamenal kvalitativní skok: analýza úkolů, generování kódu a nápadů se stala efektivnější. Za 4 měsíce jsem spustil více než 40 projektů:

• Pluginy pro IntelliJ IDEA a Obsidian
• Nástroje pro automatizaci rutiny
• Multiuživatelské platformy
• Pokus napsat OS na Zig

Proud nápadů se zrychlil, režim dne se změnil: spánek 4 hodiny, zapisování nápadů hned po probuzení. Byl to období maximální produktivity bez vyhoření.

Koncept Skenera: ne vada, ale architektura

Když se projektů nahromadilo příliš mnoho, zeptal jsem se AI: „Jak strukturovat nápady a vybrat monetizovatelné?“. Odpověď mě dovedla k knize Barbary Sherové „Odmítám vybírat“. Popisuje dva typy:

Potápěči – ponoří se hluboko do jedné tématiky na celý život. Hloubka je jejich živl.

Skeneři – touží po šířce. Jejich mozek je nastaven tak, že potřebují rozmanitost. Šířka není vada, ale architektura.

Sherová rozlišuje 9 podtypů skenerů:

• Žonglér s talíři – drží mnoho projektů najednou.
• Sekvenční specialista – ponoří se hluboko, pak úplně změní oblast.
• Dvojí život – žije dvěma paralelními vášněmi.
• Lovec trofejí – cílem je ovládnout, pak ztrácí zájem.
• Zvědavý – sbírá znalosti pro sebe sama.
• Encyklopedista – šířka je důležitější než hloubka.
• Včela – spojuje lidi a nápady.
• Časovač – pevně stanovený čas na každou vášeň.
• Projektový – žije z projektu na projekt.

Když jsem se v tom popisu poznal, pochopil jsem příčinu svých vzorců vyhoření a úspěchu v DINS.

Jak jsem změnil přístup k práci

Vyzbrojen znalostmi jsem přestal čekat na zajímavé úkoly. Teď, když vidím rutinu, hned navrhnu řešení: udělám prototyp a ukážu. Už jsem v současné firmě zavedl dva projekty automatizace. To reprodukuje ten pocit z DINS, ale teď proces vědomě řídím.

Test pro určení typu: technická realizace

Místo pasivního čtení jsem vytvořil nástroj. Spojil jsem model Sherové a „6 pracovních géniů“ Patricka Lencionia a napsal test na Java 21 + Spring Boot 3.

Stack: Thymeleaf, Gradle, Docker. Bez SPA a SÚBD.

i18n přes JSON-pivot: místo properties – jeden JSON na jazyk. Přidání jazyka = vytvoření souboru.

{
  "language": "ru",
  "ui": {
    "welcomeTitle": "Who you: Scanner or Diver?",
    "statsLink": "📊 Statistics"
  },
  "sherQuestions": [
    {
      "id": "q1",
      "text": "When I start a new project...",
      "options": []
    }
  ]
}

Algoritmus: vážené hlasování

Každá odpověď přidá body několika typům. Vítězí ten s nejvíce body.

public SherResult calculate(List<Answer> answers) {
    Map<SherType, Integer> scores = new EnumMap<>(SherType.class);

    for (Answer answer : answers) {
        answer.weights().forEach((type, weight) ->
            scores.merge(type, weight, Integer::sum)
        );
    }

    return scores.entrySet().stream()
        .max(Map.Entry.comparingByValue())
        .map(e -> new SherResult(e.getKey(), e.getValue()))
        .orElseThrow();
}

Statistika bez databáze: LongAdder pro inkrementy, perzistence přes JSON snímek.

public record StatsSnapshot(
    long startedSher,
    long completedResult,
    Map<String, Long> sherTypeCounts,
    Map<String, Long> geniusCounts
) {
    public double completionRate() {
        if (startedSher == 0) return 0;
        return (completedResult * 100.0) / startedSher;
    }
}

Nasazení pro developery z RF: bezplatný hosting bez karty – Hugging Face Spaces v režimu sdk: docker. Podmínky:

• YAML hlavička v README.md:

---
title: Scanner Profile
emoji: 🔬
colorFrom: green
colorTo: blue
sdk: docker
app_port: 7860
pinned: false
---

• Aplikace poslouchá port 7860.

Po git push HF sestaví image a nasadí. Plně zdarma.

Co je důležité

• Vyhoření v IT často souvisí s nesouladem typu osobnosti (skener/potápěč) a pracovního prostředí.
• Skeneři potřebují prostředí, kde mohou volně generovat a zavádět nápady bez byrokracie.
• Vědomé použití modelu skenera umožňuje vytvářet prostředí pro růst v jakékoli firmě.
• Technické nástroje (jako test na Javě) pomáhají s autogdiagnostikou a řízením kariéry.

— Editorial Team