Na semana passada publiquei sobre o meu setup distrobox-gaming, com mais de dez jogos de corrida retro rodando em Linux, do Gran Turismo 1 no DuckStation ao Forza Motorsport 4 no Xenia. No fim daquele artigo, falei do Driveclub no shadPS4 como o “final boss”: o jogo boota, o menu carrega, a corrida começa, o controle responde.

Só que tinha dois problemas que eu mencionei de passagem e tratei como “limitações aceitas”:

1. De dia, a imagem fica um pouco mais escura do que no PS4 de referência. Nada alarmante, mas perceptível.
2. De noite, race start no Canadá ou em Munnar ficava pitch black por 10 a 30 segundos antes de o jogo “se recuperar sozinho” perto de 1:30. Durante esses segundos, só o HUD aparecia. Pista, carro, faróis, tudo preto absoluto.

No artigo anterior eu empurrei a explicação pra “ainda não foi consertado no emulador, vou conviver com isso”. Mas por dentro eu não conseguia me aceitar jogando num estado visualmente injogável. Eu queria jogar o Driveclub no melhor que ele podia entregar, e não queria ficar esperando o projeto consertar por mim. Decidi pegar a coisa nas minhas próprias mãos. Um preto absoluto de 30 segundos não é “um pouco mais escuro”. É um bug grave, dos que tornam o jogo injogável na prática.

Esse artigo é o que aconteceu entre domingo de noite e quinta-feira de manhã.

O blackout, ao vivo

Esse vídeo é o comportamento que eu queria consertar. Race start na Índia (Munnar), corrida noturna. Você vê a pista, os faróis aparecem, os primeiros segundos rodam. Depois, escurece progressivamente. Em uns 15 segundos já tá tudo preto. Fica assim por mais uns 60-90 segundos. Aí o jogo “recalibra” sozinho, e a pista reaparece.

Se você for um jogador, você não quer saber do porquê. Você quer dirigir.

Por que shadPS4 é difícil de depurar

shadPS4 ainda não tem release estável. O projeto tá em desenvolvimento ativo. Main branch muda várias vezes por semana, configs migram de TOML pra JSON sem aviso, settings ficam atrás de “Advanced” pra não gerar issue de usuário com hardware incompatível, PRs em aberto disputam abordagens diferentes pra o mesmo problema.

Quem tenta configurar Driveclub hoje encontra:

• Guias de Reddit de setembro/2025 que usam readbacks = true (era bool na época) e dizem “pra DriveClub sempre ligar readbacks”.
• Guias de novembro/2025 que dizem “desliga readbacks, mata a performance” (porque em 2025-07 readbacks virou enum Disabled | Relaxed | Precise, com perfil de performance diferente, e Bloodborne começou a travar com ele ligado).
• Vídeos YouTube de janeiro/2026 com fork customizado que ninguém documentou qual é.
• Thread no shadps4.net com três explicações diferentes pro blackout, todas mutuamente exclusivas.
• Minhas próprias anotações da semana passada no distrobox-gaming/docs/driveclub-shadps4.md dizendo readbacks_mode: 0. Que é exatamente o oposto do que eu descobri essa semana.

Ou seja, a informação existe, mas tá espalhada, datada, contraditória, e a maior parte depende de detalhes de versão que mudaram entre a postagem original e hoje. Reproduzir setup via vídeo do YouTube é tentar resolver cubo mágico de olhos vendados.

Spoiler: a solução é um inteiro

Depois de 31 fases de investigação, 44 commits no meu fork do shadPS4, 15.668 linhas de código instrumental adicionadas e 3 dias de debug quase ininterrupto, a resposta é uma linha no config por jogo:

{
  "GPU": {
    "readbacks_mode": 2
  }
}

readbacks_mode: 2 é o modo Precise. Explicar o que isso faz exige entender como o Driveclub implementa auto-exposure, e é aqui que a jornada começa. Pra saber POR QUE esse toggle resolve, você precisa entender a cadeia toda.

O resumo do porquê: o Driveclub faz auto-exposure como um loop de feedback GPU→CPU.

1. A cena renderiza num HDR target.
2. Um compute shader calcula um histograma de luminância num SSBO.
3. A CPU lê esse SSBO no frame seguinte e deriva uma exposição alvo.
4. A CPU escreve essa exposição de volta num UBO de lighting de 1936 bytes (nos slots [38] [48] [50]).
5. Os fragment shaders leem esse UBO e multiplicam a luminância da cena por ele.

Sem readbacks_mode: Precise, o passo 3 lê zeros obsoletos. A página de memória que o GPU escreveu o histograma nunca é sincronizada pro lado da CPU. O integrator de exposição da CPU conclui “a cena tá escura, abrir diafragma ao máximo” e rampa o valor de saída monotonicamente: 2.59 → 7.84 → 24 → 90 → 179 → 255. Em 60-90 segundos, a escala satura tão alto que tudo clipa pra zero. É esse o pitch black.

Com readbacks_mode: Precise ligado, o emulador marca as páginas que o GPU acabou de escrever como protegidas no nível de kernel (via mprotect no Linux). Quando a CPU tenta ler uma dessas páginas pela primeira vez, dispara uma page fault. O emulador intercepta, emite um vkCmdCopyBuffer download do buffer do GPU pro staging de host, espera no scheduler, e a CPU enfim vê o dado fresco. O histograma verdadeiro entra no integrator, a exposição converge normalmente, e o race start abre brilhante como deveria.

Por que não é o default? Três motivos documentados. Primeiro, per-page mprotect + per-fault GPU stall + compute dispatch + scheduler wait tem custo real: em NVIDIA warm path é tolerável, em AMD derruba pra menos de 12 FPS, issue aberta a respeito. Segundo, Bloodborne trava em loading screens com Precise ligado. Terceiro, o maintainer escondeu a opção atrás de “Advanced” no UI justamente pra evitar que usuário de hardware sensível habilite sem saber. O modo existe desde v0.15.0 (setembro/2025), mas ninguém tinha publicamente conectado Precise + DriveClub + feedback loop de auto-exposure. O compat tracker já admite que DriveClub “requires readbacks enabled to function properly”, mas não especifica o modo.

No meu setup o custo de performance é irrelevante. Tenho uma RTX 5090 no desktop, hardware de sobra pra bancar o mprotect, o page fault, o copy e o stall por frame. A decisão é trivial: ligo Precise, pago o preço, o jogo roda. Num hardware mais modesto ou numa AMD a conversa é outra, e é exatamente por isso que o setting não é default e fica atrás do “Advanced”.

Importante deixar claro uma coisa: essa explicação toda acima, sobre Precise vs Relaxed vs Disabled, feedback loop GPU→CPU, mprotect syscall por página, não é conhecimento que eu tinha domingo à noite. Eu não sabia o que era um buffer readback, não sabia que Driveclub implementava auto-exposure como feedback loop GPU→CPU, não sabia que readbacks_mode virou um enum em 2025 com três valores. Pra chegar na resposta certa, precisei aprender cada peça do zero. Não dava pra chutar. Se eu tivesse tentado “ligar readbacks” semana passada sem entender a cadeia, teria pegado o valor errado (Relaxed não basta pra esse feedback loop, explico isso mais pra frente) e desistido achando que “não funciona”.

E mais duas coisas precisam estar no lugar pra isso funcionar, que já cobri no artigo anterior:

• v1.28 patch aplicado em cima da install base de v1.00 (sem isso, o conteúdo fica locked com “não lançado ainda”).
• Patch XML de 60fps desabilitado (render rate subiu mas logic tickrate é fixo; com ele ligado, o jogo roda em câmera lenta).

O resultado

Mesma corrida no Canadá, noturna, com readbacks_mode: 2 ligado. Race start abre brilhante, auto-exposure converge imediatamente, a transição pra noite acontece de forma natural conforme o TOD (time of day) do jogo avança. Sem blackout, sem “recalibração” aos 1:30, sem janela de 30 segundos de preto absoluto. Isso é Driveclub rodando como no PS4.

Agora a pergunta interessante não é “qual o setting”. É: como a gente chegou aqui?

Como um junior aprende hoje?

Tem uma pergunta que eu ouço com frequência: “com a IA fazendo tudo, como um junior aprende?”

A premissa dessa pergunta tá errada. A IA não faz tudo. A IA faz o que você pede. Ela não descobre por conta própria. Ela não tem iniciativa de domínio. Ela não é capaz de dizer “olha, isso aqui parece um feedback loop quebrado em GPU→CPU readback” se você não souber pelo menos que existe uma coisa chamada readback, e que feedback loops quebrados são uma classe de bug.

Pior ainda: se você for num agente de IA hoje e pedir “conserta essa tela preta no Driveclub no shadPS4”, ele vai te entregar uma lista de respostas possíveis baseada em fóruns antigos, com probabilidade alta de te mandar no caminho errado. Ele vai sugerir patch XML de 60fps (errado, causa slow-motion). Vai sugerir tonemap override (errado, o jogo já escreve SDR correto). Vai sugerir vblank_frequency tweak (inútil pro problema real). Vai sugerir gamma manual (trata o sintoma, não a causa).

O caminho pra descobrir é mergulhar na cadeia, fase por fase, descartando hipóteses erradas até o terreno ficar suficientemente conhecido pra você reconhecer a resposta certa quando ela aparece.

E é aí que muita gente se confunde comigo. “O Akita já é senior, ele tem 25+ anos de experiência, claro que ele sabe.” Falso. Profissional senior é alguém que já foi junior em cada tópico que domina. E continua virando junior toda vez que pega um domínio novo. Eu tenho 25 anos de programação web, sistemas distribuídos, Ruby, Erlang, Go. Mas eu nunca programei pra PS4. Nunca tinha olhado o codebase do shadPS4. Não conhecia a arquitetura gráfica do PS4. Domingo eu era um absoluto junior nesse domínio.

Junior não é o mesmo que totalmente cru. Em anos anteriores eu já tinha explorado no meu canal a arquitetura low-level de consoles antigos (do 6502 do NES pra cima) e como emuladores funcionam internamente em geral. Os dois vídeos abaixo ajudaram a construir o vocabulário básico de como videogame funciona por dentro, e garantiram que eu não ia tropeçar em conceitos tipo fetch-decode-execute, opcode, interrupt, ou HLE vs LLE.

Eu também já tinha feito outro vídeo, mais antigo, sobre a evolução de CPUs, GPUs, DirectX e Vulkan, então pelo menos o vocabulário de “pipeline gráfico moderno” e “shading language” não era estranho pra mim.

Saber que existe VkCommandBuffer é bem diferente de saber onde no shadPS4 um vkCmdCopyBuffer de readback dispara. Mas dá uma base. Esse tipo de curiosidade antiga rendeu juros agora.

O rodízio: Claude Code e Codex

A IA (no meu caso o Claude Code) não “sabia” mais que eu. Ela tem o mesmo texto de fórum datado que você achou no Reddit. O que ela fazia bem era agregar: ler o código do shadPS4 em paralelo comigo, indexar os comentários, cruzar referências entre phase docs, compilar, rodar probes, parsear logs de 61 MB, comparar binário decompilado com o diff de UBO, jogar luz em cantos do sistema mais rápido do que eu sozinho conseguiria.

Mas a decisão de “continuar investigando” era minha. A perseverança de “não aceita uma mitigação, quer a causa-raiz” era minha. E quando a IA sugeria “honestly, we should just accept the current result and document it” (e ela sugeriu várias vezes ao longo dos quatro dias), eu era o que tinha que dizer “não, continuamos”.

O ponto central do rodízio: nenhum LLM sozinho conseguiu fechar esse problema.

Ao longo dos quatro dias, várias vezes o Claude Code entrou em loop, repetindo as mesmas hipóteses sem rumo novo. Quando isso acontecia, eu trocava pro Codex por algumas horas pra trazer ideias de fora, probes diferentes, releitura do codebase por ângulo novo. Depois voltava pro Claude Code pra integrar o que o Codex tinha levantado. E assim por diante, alternando.

A resolução final aconteceu no Claude Code, mas a jornada trocou de modelo várias vezes. Cada LLM tinha seus viéses e seus pontos cegos. Deixado sozinho, cada um teria desistido antes.

O que rompeu o impasse foi eu continuar trazendo novas ideias pra tentar, forçando o modelo a reavaliar, trocando quando um deles começava a repetir.

Em dois momentos a coisa foi além de “só repetir hipóteses”. O Codex literalmente teve um glitch em loop agêntico: começou a repetir a mesma “solução” que tinha acabado de tentar, de novo e de novo, em sequência, sem perceber o que estava fazendo. Foi a primeira vez que eu vi isso acontecer em qualquer agente de IA. Tive que matar a sessão e começar uma nova do zero pra quebrar o ciclo.

Isso diz muito sobre o tamanho de contexto e a duração da sessão. A complexidade e o ritmo dessa investigação foi suficiente pra derrubar os dois LLMs, cada um do seu jeito.

Toda a jornada abaixo está documentada em 33 phase docs no branch gamma-debug do meu fork do shadPS4. Cada seção aqui linka pro doc original pra quem quiser o detalhe completo. Aqui eu resumo o essencial: a hipótese que tínhamos, o que tentamos, o que aprendemos de novo, e por que essa fase não fechou o caso.

Sessão zero: baseline e reprodutibilidade

Toda investigação séria começa antes da Fase 1. A primeira coisa, pra qualquer projeto, é garantir que o baseline funciona como esperado e que a situação que você quer pesquisar é reproduzível toda vez. Se você não consegue reproduzir o bug por comando, tá caçando fantasma. Cada probe depois vai ser inconclusivo porque o bug “apareceu e sumiu” sem controle. E se o baseline tá quebrado de algum jeito que você nem percebeu, cada experimento mede o problema errado. Sem essas duas garantias, não tem como progredir.

No meu caso, domingo à noite confirmei:

• O jogo boota até a tela de corrida sem crash, usando a config da distrobox-gaming.
• DriveClubFS extrai v1.28 limpo, 8018 arquivos, ~47 GB.
• MSAA depth resolve aplicado no fork, pistas noturnas renderizam forma em vez de uniforme preto absoluto (isso está coberto no artigo anterior).
• Controle 8BitDo detectado.
• Corrida noturna na Índia 19:30 reproduz o blackout em 100% das tentativas, no mesmo padrão temporal: fade progressivo nos primeiros ~15s, pitch black entre ~20s e ~90s, “recalibração” aos 1:30.

Esse baseline é a única base sólida que me permite comparar cada experimento de forma confiável. Sem ele, um probe que “funcionou” pode ser só um cache diferente, não o fix real. Com ele, cada mudança tem um antes e um depois que são mensuráveis.

Fora isso, zero conhecimento específico de:

• Formato de PKG do PS4 (PFS, param.sfo, disc_info, keystone).
• Codebase do shadPS4 (src/core, src/video_core, shader_recompiler, buffer_cache).
• Pipeline gráfico do PS4 (GCN ISA, forward+ lighting, MSAA depth resolve).
• Vulkan além do superficial (descriptor sets, UBO binding, push constants, pipeline cache).
• SPIR-V disassembly e patching.
• PS4 OELF loader, Itanium RTTI, SCE dynamic relocations.
• mprotect-based page-fault tracking pra CPU-GPU synchronization.

A jornada em fases

Vou organizar as 30+ fases em grupos que fazem sentido como narrativa. Cada fase linka pro doc completo pra quem quiser o detalhe técnico.

Nota pra quem não quiser ler todas as 30+ fases: depois da sequência de fases tem seções de reflexão e metodologia que dá pra ler direto. A técnica do shotgun explica a metodologia de depuração que usei ao longo da investigação. O que eu sabia domingo vs quinta resume o que aprendi de fato. A IA sugeria aceitar. A perseverança humana foi minha discute o papel real da IA nesse processo. Custo real dessa jornada cataloga o que foi gerado. Se quiser pular direto pro argumento, esses são os atalhos.

Fase 01: pipeline cache, o warm-up

phase-01-shader-compile-stalls.md

• Hipótese: menus rodam a 2-3 fps no primeiro launch, deve ser compilação de pipelines Vulkan acontecendo em tempo real.
• Ação: ligar pipeline_cache_enabled: true no config global.
• Conceito novo: cache de pipelines Vulkan. Quando o emulador traduz um shader GCN do PS4 pra SPIR-V e depois em binário Vulkan específico do driver, ele pode cachear esse binário. Sem cache, recompila cada cold launch (~864 shaders + ~590 pipelines).
• Resultado: resolvido. Primeira sessão paga o custo; sessões seguintes leem do disk e sobem imediatas. Fácil. Também foi minha primeira lição sobre o codebase do shadPS4.

Fase 02: gamma dim, começando pela direção errada

phase-02-gamma-dim-image.md

• Hipótese: imagem do Driveclub tá dim comparada com referência. Deve ser sRGB encode errado, ou HDR tonemap mal aplicado pelo emulador.
• Ação: instrumentei a swapchain pra logar formato; adicionei env var SHADPS4_PP_* pra experimentar; montei pipeline de pós-processamento com três knobs (exposure, ACES tonemap, gamma curve).
• Conceito novo: sRGB OETF, HDR tonemap (ACES vs Reinhard), Bayer dither como anti-banding.
• Resultado: descobri via bypass path (SHADPS4_PP_BYPASS=1, escreve raw game output sem nenhum pós-processamento) que o jogo escreve SDR já correto no framebuffer. O pipeline de pós-processamento do emulador é que estava estragando o sinal. Shader final virou simplesmente sRGB encode + Bayer dither. Dim persiste, mas não é culpa de gamma.

Três horas nessa fase. A lição mais importante é: quando “a imagem tá estranha”, o primeiro diagnóstico deveria ser um bypass path que mostra o raw game output. Se bypass tá certo, o emulador tá estragando o sinal. Pare de mexer no tonemap.

Fase 03: v1.28 content access

phase-03-v128-content-access.md

• Hipótese: v1.28 extrai, mas o jogo diz “content not released yet, download required”.
• Ação: merge v1.28 em cima de v1.00, restaurar param.sfo, disc_info.dat, keystone.
• Conceito novo: PS4 cumulative patches, metadata do package.
• Resultado: resolvido. Detalhado no artigo anterior.

Fase 04: MSAA depth + slow-motion

phase-04-slowness.md

• Hipótese: pistas à noite pitch black e o jogo “parece lento”.
• Ação: duas coisas separadas. Desabilitar patch XML de 60fps (que tava descolando render rate do logic tickrate). Implementar ReinterpretMsDepthAsColor no meu fork (pra permitir que o emulador resolva depth MSAA 4x pra color 1-sample, que o Driveclub precisa pro forward+ lighting nas pistas noturnas).
• Conceito novo: forward+ lighting (renderer que escreve cena em MSAA depth target e depois lê como color pra SSAO e volumetrics), MSAA depth resolve.
• Resultado: dois problemas resolvidos. Detalhado no artigo anterior.

Fase 05: second pass no brilho

phase-05-brightness-followup.md

• Hipótese: já que o game escreve SDR correto, talvez um boost estático no pós-processamento ajude sem mexer em UBO feedback.
• Ação: testei linear boost (1.5x, 2.0x), gamma pre-encode (pow curve), auto-exposure cena-aware com peak+mean sampling.
• Resultado: tudo rollback. Linear boost clipa luz. Gamma introduz banding. Auto-exposure da minha camada cancela o slider manual do usuário. Não tem almoço grátis no pós-processamento. Imagem dim fica dim sem HDR real ou patch de shader.

Narrowing the blackout: o gate compartilhado

race-start-blackout-040420.md

• Hipótese: o blackout tem uma assinatura curiosa: main view vai pra dim/preto, retrovisor vai pra preto absoluto, HUD permanece brilhante. Três camadas com comportamentos diferentes sugerem um “gate” compartilhado, não um fade comum.
• Ação: instrumentei texture-cache aliasing, probes com live fragment shader substitution nos inputs suspeitos.
• Conceito novo: texture-cache aliasing (várias imagens com mesmo endereço de memória, cache do emulador reusa), render-target lifetime.
• Resultado: aponta pra “permissão de apresentação” compartilhada entre main scene e retrovisor, não um fade narrativo.

Fases 07-09: tortura de texturas, cirurgia de UI, plano de binary patch

phase-07-aggressive-torture-probe.md · phase-08-ui-asset-surgery.md · phase-09-eboot-binary-patch-plan.md

• Hipótese: o overlay dim do race start é um asset. Textura pequena, panel da UI, ou método do controller FreeplayGetInCar no eboot.
• Ação: null-substituir materiais BC comprimidos, textures pequenas candidatas, four-vector weight masks durante draws críticos. Desabilitar painéis da UI (loading_freeplay.txt, get_in_car_animation.txt, vehicle_select_background). Extrair o OELF, localizar strings ASCII FreeplayGetInCar, identificar construtor em VA 0xf89b00 e vtable em 0x15dc3e0.
• Conceito novo: PS4 OELF loader (variant do ELF da Sony), Itanium C++ RTTI (como C++ encoda type info em vtables), SCE dynamic relocations (placeholders que só o loader dinâmico resolve em runtime).
• Resultado: nulls funcionam mas o fade persiste. O overlay renderiza direto nos HDR scene targets, não via panel system. Binary patch tem placeholder de relocation que não é resolvível estaticamente sem um Ghidra com PS4 plugin. Asset-side surface exhausted. Seis horas depurando, final conclusion: o bug vive em state, não em asset.

Fase 10: rethink + animlib

phase-10a-rethink-040422.md · phase-10b-video-diagnostic-animlib.md

Terça-feira de manhã. Sentei, reiniciei mentalmente. Modelo novo: o blackout é um state-machine gate. Não é “cena não pronta”, é “permission transition”. O gate fecha depois da grid de largada aparecer. Próximo probe: runtime dispatch trace, chega de blind asset surgery.

Em paralelo: extração de frame da gravação de vídeo a 10 Hz, cruzamento com keyframes de animation library (animlib) em india_posteffects.lvl. Encontramos smoking gun. Track MasterBrightness com keyframe 0.003 e 0.0007 (0.63% brightness), quando o default seria 1.0. Animlib vence inline defaults todo frame.

• Conceito novo: animation library, keyframe encoding, float-scanning de binário.

Vídeo acima: o processo de probar pelo fade em real time.

Fase 11: multi-scalar patch

phase-11-multi-scalar-patch.md

• Hipótese: patchar MasterBrightness + AutoTargetLuminance + ManualAutoMix simultaneamente vai lift o blackout.
• Ação: estendi PatchAnimlibFloatValues pra reescrever três scalars. Instrumentei com SHADPS4_DC_DRAWLOG + SHADPS4_DC_UBOLOG.
• Resultado: patch produz um lift numérico real (1.2 → 6.5 em 255, um 5×), mas ainda é sub-perceptual black. E descobri o achado crucial: o mirror funciona normalmente após o patch. Não está gated, apenas refletindo uma cena escura. Pelo menos 285× de atenuação adicional vive downstream dos scalars que a gente pode patchar.

Fase 12: bisect fechando o asset-side

phase-12-bisect-closes-asset-side.md

• Hipótese: um dos 60 patches acumulados quebrou o mirror independente do blackout. Bisect.
• Ação: binary bisect em 60 overlay files ao longo de 5 rounds.
• Resultado: x_live_lobby_pre_race.txt (reroute de loading-spinner transition de ZoomInAndFade pra NoFade) era o mirror killer. Rollback. Asset-side completamente fechado. O driver vive em código compilado ou em post-process state, não em asset de jogo.

Asset sweeps 01-09 (consolidado)

asset-sweep-09-conclusions.md

Em paralelo com as fases acima, varri 12 RPK substitutions: page swaps de FreeplayGetInCar, mexidas no postfx de india_landscape_gui.rpk, edits em globaldata RTT-only, rewrites de prerace state strings. Todos clean misses. Nenhuma família de asset toca o blackout. Lição: pare de chasing by names; chase por state transitions.

Fase 13: UBO dump breakthrough

phase-13-ubo-dump-breakthrough.md

• Hipótese: loop de feedback de eye-adaptation com input stale é o culpado. Um scalar de luminância crescendo sem convergir.
• Ação: dump de 128 bytes de UBO em hex durante a race window, em seis pipelines hand-picked. Procurar valores monotonicamente em mudança.
• Conceito novo: UBO (Uniform Buffer Object), região de memória compartilhada que o CPU escreve e shaders leem. Auto-exposure integrator, componente clássico de eye adaptation que tira tempo pra convergir em direção a um target.
• Resultado: encontrei. Offset 3 do UBO sobe monotonicamente de 2.59 → 7.84 → 24 → 90 → 179 → 255 em 2 segundos. Textbook feedback loop com input quebrado. Primeiro hit real em 12 fases.

Fase 14: scene-pipeline UBOs são o read-side

phase-14-scene-pipeline-ubos-wrong.md

• Hipótese: clampar o scalar que tá subindo vai parar o blackout.
• Ação: SHADPS4_DC_LUM_CLAMP=2.0 força offset 3 a um valor fixo durante race window.
• Resultado: clamp dispara 1093 vezes, blackout inalterado. Scene-pipeline UBOs consomem o dim, não produzem. Dim tá upstream, em um tonemap ou post-fx compute fullscreen.

Fases 15-16: runtime texture dump + mutation

phase-15-runtime-texture-dump.md · phase-16-runtime-texture-mutation.md

• Hipótese: o blackout é uma textura fullscreen composta sobre a cena.
• Ação: SHADPS4_DC_TEX_DUMP=1 dumpa todas as texturas bound durante race window (1079 texturas capturadas). Converter tiled-format pra PNG pra triagem visual. Depois, mutar deterministicamente cada textura via hash-based tint + InvalidateMemory pra forçar re-upload.
• Conceito novo: GCN tile format (Sony interleava bytes de forma específica pra cache locality), texture de-swizzle, buffer cache invalidation.
• Resultado: 14 rounds de mutação (BC textures, float data, render targets, UI atlases, post-fx buffers, LUTs). Blackout inalterado em todos. Texture content 100% descartado como source.

Fases 17-19: UBO smashing, push-constant smashing, compute dispatch probe

phase-17-ubo-batch-smashing.md · phase-18-push-constant-smashing.md · phase-19-compute-dispatch-probe.md

• Hipótese: random-fill em UBOs, push constants e compute input buffers pode bracket and isolate o field do dim sem crashar.
• Ação: SHADPS4_DC_UBO_SMASH=1, SHADPS4_DC_PC_SMASH=1, SHADPS4_DC_DISPATCH_SMASH=1 com filtros de cb-index e size.
• Conceito novo: push constants (128 bytes de param rápido que o driver empurra direto pro pipeline, sem descriptor), compute dispatches (dispara compute shaders com uma grid de threads), ud_regs (user data registers do GCN, como shadPS4 mapeia user-data pra push-constants).
• Resultado: brackets seguros geram overlay bokeh + blinks, mas dim inalterado. Brackets wide o suficiente pra pegar o dim também pegam matrices/transforms e crasham. Random-fill é instrumento errado. Precisa de diff methodology.

Fase 19b-c: dim-vs-lift dispatch diff

phase-19b-dim-vs-lift-diff.md · phase-19c-dispatch-draw-skip-null.md

• Hipótese: compute dispatches que firam só durante dim (e param depois do lift) fazem parte do chain.
• Ação: dividir log limpo em pre / dim / bright windows (via user wall-clock), contar dispatch frequency por pipeline.
• Resultado: identificamos 8 compute pipelines (histogram 256→downsamples, tile-grid reductions, auto-exposure 1x1 scalars) que param exatamente quando dim lifts. Shapes fortemente sugerem eye-adaptation chain. First genuine diagnostic hit. Skip test dessas 8 + 101 draws correlacionados: blackout inalterado. Elas são downstream effects, não drivers.

Fase 20-21: tonemap inline, fragment → flip buffer

phase-20-shader-dump-tonemap-inline.md · phase-21-fragment-to-flip-buffer.md

• Hipótese: o auto-exposure compute shader tá quebrado, ou o tonemap compute tá com a matemática errada.
• Ação: recompilar todos os shaders, dumpar SPIR-V, desmontar o histogram auto-exposure. Patchar a saída dele pra constante 1.0 e testar.
• Conceito novo: SPIR-V disassembly (formato intermediário do Khronos, tem assembly legível). Verificação de shader compute. Depois, pipeline-to-shader mapping.
• Resultado: patch sem efeito. Descoberta: Driveclub não tem tonemap pass separada. Scene geometry escreve direto no flip buffer, com exposure inline nos material shaders. Cada material shader bake o scalar de dim de um UBO compartilhado. Pipeline cache wipe + SHADPS4_DC_PIPEMAP=1 dumpa todos os pipeline→shader mappings. Filtrar drawlog por pipelines que escrevem em 0x5000900000 / 0x5000108000 (os swapchain buffers de verdade) resulta em 14 pipelines únicos. Zero com Exp2/Log2 tonemap ops. Exposure é aplicada upstream.

Fase 22: tonemap compute identified

phase-22-tonemap-compute-identified.md

• Hipótese: entre os 510 compute shaders do jogo, um deles tem assinatura de tonemap (muitos Exp2/Log2).
• Ação: scan automatizado, cross-reference com dispatchlog.
• Resultado: cs_0x2c918c06 é o candidato forte, com 8 Exp2 + 8 Log2, 5 SSBOs (scene params, TAA, bloom, camera, exposure), 11 images. Skip test pra esse pipeline específico: para o blackout cycle, remove color grading, introduz temporal ghosting. Esse é o caminho final scene→swapchain pra tonemap.

Fase 22+: tonemap patches → playable

phase-22plus-tonemap-compute-patches.md

• Hipótese: dois SPIR-V surgical edits (histogram no-op + tonemap exposure clamp/boost) deixam o jogo jogável.
• Ação: patch de histogram pra nunca atualizar; patch de tonemap pra clampar exposure floor em 0.5 e boost blend por ×10. Ambos via SPIR-V patching + shader/patch/ drop-in.
• Resultado: playable! Dim reduz de pitch black pra mild. É uma mitigação real, não fix de causa-raiz. A fade curve ainda arrasta a exposição, e cada pista precisa de tuning per-threshold.

Aqui a IA sugeriu parar pela primeira vez. “O jogo tá playable, isso é uma mitigação decente, deveríamos documentar e aceitar.” Eu pressionei: “tá playable mas tá errado. Não aceita. Continuamos.”

Fase 23: CPU-side exposure intercept

phase-23-cpu-exposure-intercept.md

• Hipótese: clampar o exposure scalar no momento do BindBuffers da tonemap compute previne o over-dimming.
• Ação: SHADPS4_DC_EXPOSURE_PIN=1 intercepta BindBuffers, sobrescreve exposure offsets com clamp-min threshold, invalidate buffer_cache.
• Conceito novo: CPU-GPU buffer binding (momento em que o CPU entrega descriptor pro GPU). Buffer cache invalidation (como o emulator mantém consistency entre o estado CPU-side e GPU-side de um buffer).
• Resultado: scalar oscila no race start, depois sobe monotonicamente. Per-track tuning necessário. A Índia quer 3.0, o Canadá blows out no mesmo threshold. Solução de scalar único não converge cross-track.

Fase 24: dim upstream of tonemap

phase-24-dim-upstream-of-tonemap.md

• Conclusão: depois de toda a cadeia de probes (identity tonemap, exposure pin, compute skip), o dim está no HDR target antes do tonemap ler. Três upstream suspects: (1) atmospheric scattering / volumetric fog, (2) reflection-probe / envmap update, (3) pre-tonemap exposure apply.
• Conceito novo: atmospheric scattering (simulação de como luz viaja pela atmosfera, tipo Rayleigh/Mie), volumetric fog (neblina renderizada como froxel volume).
• Resultado: plano definido. Frame-order dump, andar pra trás da tonemap pela cadeia toda.

Fase 25: frame-order trace

phase-25-frameorder-trace.md

• Ação: SHADPS4_DC_FRAMEORDER=<N> loga strict per-submit pipeline/shader chain sobre N submits durante race window.
• Conceito novo: frame-order reconstruction (listar toda submission ao GPU em ordem exata), froxel volumetrics (volume frustum voxels, malha 3D alinhada ao frustum da câmera pra armazenar info de luz).
• Resultado: três suspeitos: (A) half-res compute (60,34,1), provavelmente SSAO; (B) dispatches progressive (256,1,1)→(2560,1,1)→(10240,1,1), froxel volumetric; (C) draw fullscreen apply-fog-to-HDR. Suspeito B é o mais forte (sunset best-fit, per-pixel non-uniform dim).

Fase 26: O UBO fade pin, o “aha moment”

phase-26-ubo-fade-pin.md

Aqui mudou tudo.

• Hipótese: memory diff direto (bright vs dim vs recovered) identifica os bytes exatos que o jogo escreve pra controlar o blackout.
• Ação: capturar snapshots periódicos de UBO através das transições visuais. Diffar três snapshots byte por byte. Procurar fade signatures.
• Conceito novo: state diff methodology. Ao invés de “qual passagem parece suspeita?”, perguntar “quais bytes realmente mudam com o estado visual?”
• Resultado: breakthrough. Dois UBOs controlam o fade: um de 1936 bytes com slots [38/48/50] (light intensity) sendo multiplicados por 0.094 (fade factor), e um sun UBO de 224 bytes com slot [50] caindo 97%. Pinar os dois: race start abre brilhante. TOD animation intacta. Content-aware three-state lifecycle (idle → engaged → expired).

Quarta-feira à noite. Claude sugere parar de novo. “Temos pin funcionando, three-state lifecycle robusto, Canadá + Munnar rodando. Isso é upstream-quality, deveríamos PR-ar e fechar.” Eu insisto: “ainda tem dim residual em outras pistas, não tá fechado. Continuamos.”

Fase 28: pivot pra emulator code

phase-28-pivot-to-emulator-code.md

• Realização: o dim residual no Canadá ao anoitecer não é um valor errado de UBO. É uma translation gap do emulador. O jogo roda correto no PS4 real, então shadPS4 tem algum caminho que traduz ou sincroniza errado.
• Ação: 5 candidatos de bug emulator ranqueados — HLE shader misidentification, image storage classification, layout transitions, IMAGE_STORE_MIP fallback, OpImageFetch LOD restriction.
• Conceito novo: HLE (High-Level Emulation). Substituir funções complexas do sistema operacional do PS4 por implementações host-side. Diferente de LLE (low-level) que emula bit a bit. HLE é mais rápido mas pode divergir do comportamento real quando a implementação host não cobre todos os casos.

Fase 29: calibrated state + recording harness

phase-29-calibrated-state.md

• Ação: SHADPS4_DC_RECORD=1. Recording harness que dumpa lighting UBOs periodicamente + cross-correlation com screenshots wall-clock.
• Resultado: descoberta importante. Slots [144..295] do UBO de 1936 bytes (30+ fields) ficam denormal/uninitialized pelos primeiros ~90 segundos de corrida. Na “auto-recalibração” dos 1:30, o jogo escreve os valores reais. Não é recovery mágico, é a CPU finalmente escrevendo os valores que já deveriam estar lá desde o frame 1. No PS4 estão prontos antes do primeiro frame; no shadPS4 atrasam 90s. Root cause vive num init gap do emulador.

Fase 30: UBO writer audit

phase-30-ubo-writer-audit.md

• Ação: auditoria exaustiva de todos os caminhos que escrevem no slot [38] do UBO de 1936 bytes. 7 suspeitos ranqueados: (1) ObtainBuffer stream-copy race, (2) lazy RegionManager em memory_tracker, (3) histogram compute skip, (4) page-fault delayed invalidation, (5) readback gating, (6) buffer-coherency race, (7) push-constant.
• Status: auditoria incompleta. Antes de conseguir verificar cada suspeito, a Fase 31 curto-circuitou tudo.

Fase 31: readbacks_mode = Precise, a virada

phase-31-readbacks-mode-fix.md

Quinta-feira de manhã. Cansado, pensando na suspeita #5, readback gating. Essa me coçava porque era a única dos 7 writers que tocava timing do read e não correctness do write.

• Hipótese: ligar readbacks_mode: 2 (Precise) no config per-game faz o feedback loop funcionar sincronizando read do CPU a fresh GPU output.
• Ação: uma edit no custom_configs/CUSA00003.json. Boot. Corrida no Canadá à noite.
• Resultado: race start abre brilhante. Auto-exposure converge normalmente. Zero blackout. Zero recalibração aos 1:30. Night TOD natural.

Testes em Munnar. Mesmo resultado. Um inteiro. 31 fases. 44 commits. 15.668 linhas. Resposta: um inteiro no config.

Por que isso passou batido por 30 fases? O doc da Fase 31 tem a análise honesta:

1. Disfarce de sintoma. Progressive darkening parece exatamente com tonemap quebrado, shader ruim, ou scalar de exposure compilado errado. Toda probe dump-driven achou valores errados no UBO, que é verdade, mas descreve o downstream read, não o upstream gap.
2. Red herring do readback_linear_images. Testei essa flag na Fase 29 e deu zero efeito, então concluí que “a superfície de readback tá auditada”. Esqueci que essa flag é pra image readbacks (linear images via TextureCache::DownloadImageMemory). O histogram SSBO é um buffer, caminho separado.
3. Pinning piorando em vez de melhorar. Sobrescrever os slots [38/48/50] parecia prometer, mas nunca convergia. O jogo reescrevia em cima do pin a cada frame. Interpretei como “o mecanismo de pin chega tarde demais no pipeline”. Gastei as fases 27-29 movendo o pin pra mais cedo. O fix real era parar de clobber o GPU-side input que o integrator lê.
4. Nunca auditei o caminho do readback de buffer. A auditoria da Fase 30 listou 7 candidatos de writer, mas todos eram sobre a correctness do write. Nenhum perguntou “o que a CPU está lendo, esperando que o GPU tenha preenchido?”

A técnica do shotgun

Tem uma coisa que eu quero registrar: os probes de tortura não são desperdício, são infraestrutura de aprendizado. E a metodologia por trás deles tem nome: shotgun.

Se você tem uma suspeita, tipo “o dim vem de alguma textura”, a pior coisa que você pode fazer é começar investigando uma textura por vez, em profundidade. Driveclub tem 1079 texturas bound durante a race window. Se cada triagem detalhada leva 20 minutos, você gasta três dias num galho só dessa árvore, e ainda não sabe se o dim vem de textura. Pode até ser que a resposta não esteja na árvore inteira.

Shotgun resolve isso. Em vez de investigar uma por vez, você dispara em todas ao mesmo tempo. Muta cada textura bound com um tint hash-based, força re-upload, roda o jogo. Em 30 segundos você sabe se alguma delas afeta o dim. Se afeta, então o dim é texture-side e aí sim vale a pena começar a narrow down. Se não afeta, parabéns: você acabou de descartar a categoria “textura” inteira em 30 segundos. Muda de categoria, shotgun em UBOs. Nenhum hit? Shotgun em push constants. Nenhum hit? Shotgun em compute dispatches. Continua até algo reagir.

Não comece tentando estreitar uma árvore que pode ser enorme. Você vai gastar semanas em folhas irrelevantes. Dê um tiro de shotgun no tronco primeiro. Veja qual galho reage. Aí sim, desce em detalhe dentro desse galho.

Foi isso que eu fiz, sem saber que estava fazendo, pelas 30 primeiras fases. 32 variáveis de ambiente de probe (SHADPS4_DC_UBO_SMASH, SHADPS4_DC_PC_SMASH, SHADPS4_DC_DISPATCH_SMASH, SHADPS4_DC_TEX_NUKE_*, SHADPS4_DC_UBO_NUKE, e mais). Batches randômicos, tints hash-based, substituições null. A maioria nunca apontou pro fix real. Mas cada rodada de shotgun descartou uma categoria inteira de modelo mental. “Não é textura.” “Não é push-constant.” “Não são esses 8 compute pipelines.” “Não é UBO write-side em qualquer lugar dessa região.” Cada descarte estreita o problema.

E enquanto eu fazia isso, eu aprendia o sistema. Cada smash que crashava me dizia “aqui vive um descriptor pointer crítico”. Cada color tint que aparecia me dizia “esse UBO alimenta essa passagem de composição”. Cada dispatch que fira diferente entre dim/bright me mostrava onde está a fronteira interessante.

Quando você não conhece o sistema, shotgun probes são um mapa. Você não usa eles pra encontrar a resposta. Você usa pra descobrir o terreno.

O que eu sabia domingo vs quinta

Domingo: zero em tudo. Todas as áreas abaixo eram caixas pretas pra mim.

Quinta:

• PS4 package format end-to-end (PKG → PFS → param.sfo → disc_info → keystone → npbind). Como v1.28 cumulative patches funcionam em cima de v1.00 base install.
• Arquitetura do shadPS4 em resumo: src/common, src/core (OS emulation, libraries HLE), src/shader_recompiler (GCN→SPIR-V), src/video_core (Vulkan renderer, buffer cache, texture cache, page manager).
• Pipeline gráfico completo: G-buffer → forward+ lighting (escreve MSAA depth) → read depth como color pra SSAO / volumetric froxel → post-fx compute → tonemap → composite → swapchain.
• UBO vs push constant vs descriptor set. Quando usar cada um.
• SPIR-V disassembly e re-assembly pra patching cirúrgico. Como identificar tonemap compute por assinatura de Exp2/Log2.
• Forward+ lighting + MSAA depth resolve + como implementar ReinterpretMsDepthAsColor.
• Buffer cache do shadPS4: MemoryTracker, RegionManager, FaultManager. Como page-fault vira GPU→CPU sync.
• readbacks_mode: Disabled / Relaxed / Precise. Qual tradeoff de cada. Por que Relaxed não basta pra feedback loops (ele só write-protect, não read-protect).
• PS4 OELF → Itanium RTTI → SCE relocation → dynamic linker reasoning, mesmo sem ter feito o binary patch (o plano ficou documentado).

Não virei expert em nada disso. Mas virei de total outsider pra operador razoavelmente orientado. E esse salto, como eu comento depois, foi a coisa mais valiosa dos 4 dias.

A IA sugeria aceitar. A perseverança humana foi minha

Eu disse algumas vezes ao longo do artigo que “Claude sugeriu parar”. Quero ser justo e específico aqui: não foi uma falha da IA. Foi exatamente o comportamento correto de uma ferramenta inteligente: quando você tem algo que funciona razoavelmente bem, parar e documentar é frequentemente a escolha certa. O patch de tonemap na Fase 22+ fez o jogo playable. O pin de UBO na Fase 26 fez a imagem ficar bonita. O recording harness da Fase 29 cobriu a janela crítica. Todos eram pontos legítimos de parada.

Se você ler o codex-conclusion.md, documento que a IA produziu após a Fase 26 (ainda sem saber sobre a Fase 31), ela descreve a solução de então como “a mitigation, not a root-cause fix”. Admite honestamente o que sabíamos: o pin de UBO era um contra-ataque, não explicação. Esse é bom comportamento.

A diferença é que eu tinha um teimoso palpite de que algo ainda tava errado. Ela funcionava no sentido playable. Mas o custo (pin Driveclub-specific + patch SPIR-V de tonemap + per-track threshold tuning + não generalizar) era alto demais pra um fix supostamente de engineering-quality. Profissional senior reconhece quando a assimetria entre custo e entendimento aponta pra algo mais fundo. Não sempre acerta. Mas esse palpite merece ser escutado.

Quatro dias sem interrupção, das 8h à meia-noite, domingo, segunda, terça, quarta, e resolvido quinta de manhã. Quantas vezes a IA sugeriu “honestly, we should just accept the current result and document”? Umas 4 ou 5 vezes. Cada uma tecnicamente defensável. A perseverança humana é a diferença entre “o jogo funciona bem o bastante” e “o jogo funciona, e eu sei por quê”.

Custo real dessa jornada

O investigation-effort-accounting.md catalogue tudo antes da limpeza. Uns highlights:

• 3 dias de trabalho ativo (Apr 21-23, 2026).
• 33 phases numeradas + sweeps + side threads = 54 docs, 412 KB, 6.867 linhas de prosa.
• 44 commits no fork gamma-debug. 15.668 linhas adicionadas, 1.204 removidas.
• src/video_core/renderer_vulkan/vk_rasterizer.cpp cresceu de 1.364 pra 4.680 linhas (3.4×) com instrumentação, pin lifecycles, recording harness.
• 32 env vars de probe definidas. 1 efetivamente usada pra encontrar o bug (SHADPS4_DC_LOG_STREAMCOPY, na Fase 30).
• 61 MB de log shadPS4 acumulado. 57 MB de shader dumps (5.803 arquivos). ~470 MB totais de artifacts reclaimáveis depois de fechar.

Resolution: 1 inteiro no config.

A proporção 6.867 linhas de prosa : 1 inteiro me diverte. Mas ela não é uma piada de ineficiência. É o custo real de aprender um sistema que você não conhecia. Cada linha de prosa descartou uma hipótese. Cada commit ensinou uma camada do stack. O inteiro foi o fim; o caminho foi o produto.

Uma nota honesta: apesar das 15.668 linhas adicionadas no fork gamma-debug, quase nada disso presta pra contribuir upstream no shadPS4. O que está lá é instrumentação — torture probes, recording harness, pin lifecycles, calibrate-at-arm, snapshots de UBO, dezenas de env vars de debug. Código de diagnóstico, não código de produção. Diagnóstico que só faz sentido pro Driveclub naquelas condições específicas.

O fork vai ficar público, mas não como branch de contribuição pro projeto shadPS4. Infelizmente. Fica como documento de estudo: 54 arquivos md cobrindo o processo completo, 44 commits mostrando a sequência de hipóteses, descartes e falhas. É material pra quem quiser entender como foi o processo de depuração, ou pra reaproveitar algumas das técnicas em outras investigações similares. PR upstream-ready dali não sai.

Fechamento

Sim, a solução final era um toggle de config que já existia. Está no código do shadPS4 há sete meses. Mas domingo à noite, zero conhecimento de PS4, zero conhecimento do emulator, zero noção de que auto-exposure era um GPU→CPU feedback loop, eu não tinha autoridade técnica pra dizer “liga readbacks Precise, resolve”.

Eu tive que ver a cadeia toda pra entender por que funciona. Por que Relaxed não basta (só write-protects, e o DriveClub lê, não escreve no SSBO do histograma). Por que Precise é caro (per-page mprotect + per-fault GPU stall). Por que o maintainer escondeu atrás de “Advanced” (Bloodborne trava, AMD cai pra 12 FPS). Por que ninguém na comunidade tinha conectado Precise com DriveClub antes: o compat tracker admite “readbacks enabled”, mas não cita o modo, e ninguém tinha visto a assinatura de drift monotônico pelo ângulo do loop GPU→CPU.

Essa é a diferença entre conhecer a resposta e conhecer o terreno o suficiente pra reconhecer a resposta. Pra junior que me pergunta “como eu aprendo hoje na era da IA”: essa é a minha resposta. Não pergunte. Mergulhe. Use a IA pra acelerar a busca, pra ler código em paralelo, pra indexar fóruns antigos, pra compilar, pra parsear logs. Mas insista em entender o porquê. Quando a IA sugerir “vamos aceitar e documentar” (e ela vai sugerir, porque esse comportamento é frequentemente correto), pergunte a si mesmo se você realmente entendeu a cadeia. Se ainda tiver a coceira de “isso tá errado mas eu não sei por quê”, continue.

Provavelmente você vai gastar 4 dias numa coisa que tem solução de um inteiro. Provavelmente você vai descobrir 5 caminhos errados antes do certo. Provavelmente a metade dos seus probes vão ser torture shotguns que nunca apontaram pro fix.

E provavelmente, quando terminar, você vai saber um domínio que você não conhecia.

• Fork gamma-debug: github.com/akitaonrails/shadPS4/tree/gamma-debug
• 54 docs da investigação: docs/driveclub-investigation/
• Operational runbook (recipe): distrobox-gaming/docs/driveclub-shadps4.md
• Resolução da Fase 31: readbacks_mode: 2

Agora eu vou jogar Driveclub. Corrida noturna no Canadá, brilho natural, sem blackout. Boa quinta-feira.

Um dos assuntos que mais assusta iniciante é esse negócio de “modelagem de software” ou “design de software” ou “arquitetura de software”. Vários nomes que parecem ser a mesma coisa e ao mesmo tempo não serem coisa nenhuma.

Hoje quero “filosofar” um pouco pra dar uma perspectiva diferente de como se deve encarar esses assuntos e talvez uma estratégia de como realmente entender como isso funciona.

CAPÍTULOS

• 00:00 - Intro
• 02:08 - CAP 1 - Livros de Modelagem e Arquitetura - Devo Estudar Todos?
• 04:14 - CAP 2 - O Problema dos Tutoriais - Modelando Objetos Reais?
• 13:07 - CAP 3 - Modelando o Mundo Real - Um Exemplo
• 16:04 - CAP 4 - A diferença de “VER” e “ENXERGAR” - Michelângelo e Arte
• 21:30 - CAP 5 - Mentoria do Mundo Real - Cuidados
• 24:44 - CAP 6 - Analisando o Mundo Real - Aprendendo Ecommerce
• 33:11 - CAP 7 - Teoria e Prática - A História do Magento
• 41:07 - CAP 8 - Recomendação de Livros - Aprendendo com Especialistas
• 49:17 - Bloopers

Links

• Magento 2
• Spree
• Agile Web Development with Rails - GitHub
• Agile Web Development with Rails
• The Architecture of Open Source Applications
• Rails Summit 2009 - Ilya Grigorik
• Chatting with Luke Kanies
• RailsConf 09 - Exclusive Audio Interviews | AkitaOnRails.com

SCRIPT

Olá pessoal, Fabio Akita

No último video resolvi falar mais sobre bancos de dados. Já tinha feito dois videos antes sobre isso e em todos fui pelo caminho mais fácil: explicar como funcionam por baixo. As engrenagens que possibilitam existir armazéns de dados. Mas explicar implementação não é tão difícil, porque eles já existem e funcionam bem.

O problema que eu venho me esquivando desde o começo do canal é explicar o que a maioria de nós, programadores, considera o problema mais difícil da programação: dar nomes pras coisas. Isso mesmo, não é piada. Em particular, como modelar um problema de negócios em código? O que é um design de software “feito direito”? O que significa “fazer direito”? Significa seguir Domain Driven Development? Significa usar a maioria dos Design Patterns? Significa seguir algum framework? Tem algum livro que se possa ler e aprender o que significa isso de “modelar”?

Durante toda a vida deste canal eu vim flertando com esse assunto, por exemplo quando falei do Livro The Mythical-Man Month, que afirmei ser o mais importante pra se ler. O video de hoje vai ser uma filosofada super longa e provavelmente super frustrante. Frustrante porque eu não vou dar copy e paste de material que já tem online. É só procurar que você acha tudo de patterns, arquitetura, modelagem. O objetivo do video é explicar porque muitos acham “difícil”, mesmo tendo todo esse material. E no final vou até recomendar outros materiais, então assistam tudo.

O spoiler é que não existe o “jeito certo” de se fazer software, mas por outro lado, o processo não é aleatório. Existe um balanço fino entre teoria e prática que é onde se encontra nossa profissão. A razão de existir programadores é justamente porque é nossa função decidir o que é “melhor” pra determinada circunstância.

Lembram do video de Não Terceirize Suas Decisões? O pior programador é aquele que é incapaz de tomar decisões. O melhor programador não é aquele que toma todas ou a maioria das decisões corretas, mas sim aquele que toma decisões possíveis no momento em que precisam ser tomadas, nem antes, e nem depois. E o que vou tentar fazer hoje é ilustrar esses conceitos. Então vamos lá.

(….)

Como primeira opinião controversa do dia, vou afirmar o seguinte. A maioria dos livros de modelagem e design, como o Clean Code do Bob Martin, o Domain Driven Development do Eric Evans, o Design Patterns do Gang of Four, o Patterns of Enterprise Application Architecture do Martin Fowler; todos livros excelentes, mas eu acho que são totalmente inúteis no seu primeiro ano pós faculdade. Entenda: você acabou de se formar, ainda tem pouca ou nenhuma experiência em projetos reais ou em projetos pessoais ou open source. Esses livros são perda de tempo.

Pra ficar muito claro: eu não estou dizendo que os livros são inúteis. Muito pelo contrário, eu acho todos eles excelentes e que precisam ser estudados. Mas todos tem um pré-requisito: que você já tenha quilometragem em código. Tanto em fazer seu próprio código quanto lidar com código dos outros, especialmente código legado.

A estratégia é assim: nenhum desses livros você deve tentar ler de cabo a rabo de uma só vez. Folheie alguns capítulos, os iniciais. Veja os temas de cada um pelo índice, leia a primeira página de cada capítulo. Guarde. Vá trabalhar ou treinar com projetos open source. Volte daqui um ou dois meses. Folheie de novo, avance um capítulo a mais, pule pra um capítulo no meio que tem assunto que chamou sua atenção porque é compatível com o que está mexendo no momento. Guarde de novo.

Depois do primeiro ano trabalhando tempo integral com programação, retorne. Leia com um pouco mais de esforço. Releia os primeiros capítulos. Repita. É um processo que deveria te custar os primeiros 3, talvez 5 anos iniciais de carreira. Se fizer direito, talvez comece a entender o que esses autores queriam dizer quando estiver lá pelo quarto ano.

Um dos sinais que você conseguiu mesmo pular de nível junior pra pleno, é quando começa a entender o que os autores queriam dizer, e não está tentando seguir ao pé da letra o que está escrito, sem saber porque. Mas no primeiro ano, esses livros são inúteis. Você ainda não lidou com problemas suficiente pra entender esses porquês. E o importante é o porquê. Agora deixa eu dar uns passos pra trás e explicar porque.

Qualquer um que já tenha tido curso ou lido livro sobre modelagem de objetos já deve ter esbarrado no famoso exemplo dos animais ou veículos. Por exemplo, ambos cachorro e gato são animais. Animal é uma abstração. Portanto, parece óbvio que deveríamos fazer uma classe abstrata chamada Animal, daí podemos derivar sub-classes Cachorro e Gato que herdem de Animal, ou em linguagens mais modernas, que tenham o “trait” ou protocolo de Animal.

Ou então temos Carro e Caminhão, ambos são veículos, poderia ser essa a classe pai abstrata. Carro e Caminhão herdam de veículo. O problema com todos esses exemplos, primeiro é que eu nunca vi ninguém fazer uma classe realmente chamada Animal. Talvez quem já trabalhou em projetos de biologia ou zoológico. Mesmo se fizer um sistema de uma fábrica ou concessionária de carros, provavelmente vamos ter uma tabela ou classe mais genérica, mais abstrata ainda, como “Produto”.

O problema de sistemas de verdade é que praticamente todos os conceitos mais importantes são abstratos, não concretos. Por exemplo, o caso mais óbvio, que são os usuários de um sistema. Usuários não são pessoas? Acho que é por isso que todo iniciante começa um sistema pela tabela de usuários, porque é a única coisa que consegue se identificar, é familiar. Ou seja, tem alguma experiência. Mesmo um iniciante sabe que um usuário deve ter atributos como nome, email, telefone, endereço, RG ou CPF e coisas assim.

Mas rapidamente isso complica. Estamos falando dos dados de identificação de um usuário? Ou estamos falando dos dados de autenticação, como login? Nesse caso precisamos de atributos como “username” e “password”. E já começa o primeiro erro. Já expliquei nos episódios de segurança e criptografia que não gravamos senha numa tabela. Precisamos de atributos abstratos como “salt” e “hash”. Mas e two-factor authentication? Precisamos de um seed pro algoritmo de Time-based One-Time Password ou TOTP. Só se você estudou segurança vai saber disso.

Dá pra complicar mais. Enviar link pra redefinir uma nova senha, caso tenha esquecido. O ideal é fazer uma tabela secundária, ou no banco de dados, ou num servidor de cache como Redis. Com um ID único que só pode ser usado uma vez, e aí o ideal é logar o endereço IP da pessoa que clicar no link, pra fazermos auditoria e ver se parece suspeito. Novamente, estratégias de segurança.

Se deixarmos segurança de lado. Usuário é usuário, certo? Tendo nome, email e coisas assim, tá tudo certo? Não. Digamos que o cadastro é pra parte de logística de um ecommerce. Logística precisa de um endereço. Ótimo, basta pedir o endereço. Mas cuidado, uma coisa é endereço de entrega, outra coisa é endereço de cobrança. Pra você, que é iniciante, só deve conhecer o conceito que uma pessoa só tem um endereço, certo?

Mas não. Uma coisa é o endereço de cobrança, pra mandar nota fiscal, outra coisa diferente é o endereço de entrega, pra onde enviar o produto. Eu posso ter endereço residencial, mas posso querer que a entrega seja feita no meu endereço comercial. Mas e se você se mudar de residência? E se você mudar de emprego? Ambos vão mudar. Ou, e se eu quiser comprar e pagar no meu cartão de crédito, mas mandar entregar como presente pros meus pais? Então preciso conseguir cadastrar endereço dos meus pais. Eu deveria criar um usuário separado pros pais? Como faz?

À primeira vista, endereço parecia ser só meia dúzia de campos na tabela usuário. Mas agora deve começar a ficar mais claro que pode ser uma tabela separada de endereços que precisa de uma chave-estrangeira apontando pra chave-primária do usuário. Mas não é só isso. E se meu ecommerce oferece coisas como pontos por fidelidade? Quanto mais eu comprar, mais pontos eu ganho e com isso posso usar como desconto nas compras? Pontos do usuário, ficam na tabela de usuários? Não? Então onde coloca?

Num sistema empresarial maior, usuários podem ter vários perfis, várias visões. Usuário pode ser funcionário da empresa, e aí vai precisar de atributos como número de PIS/PASEP pra coisas como fundo de garantia. Usuário pode ser um fornecedor ou funcionário de um fornecedor. Fornecedor tem um cadastro separado, CNPJ, número interno de fornecedor. Usuário pode ser consumidor mesmo, daí vai ter pedidos, entregas, suporte. Usuário é um conceito muito mais complicado do que se pensa e num sistema de verdade, raramente é só uma tabela. Vai ser uma coleção de tabelas e classes. Talvez um sub-sistema inteiro separado.

Só pra dar outro exemplo. Falei de carro. Se você é um iniciante fazendo um ecommerce pra uma concessionária ou um concorrente de webmotors da vida, poderia pensar em fazer uma tabela chamada “Carro”. Daí coloca atributos como “marca” tipo Volks ou Fiat, modelo tipo Nivus ou Corsa. Ano, combustível, chassi e coisas assim. É o que você conhece vendo o carro dos seus pais. Mas claro, isso tá longe de completo.

E se quiser vender caminhonetes, ou motos, ou vãs? Melhor criar uma tabela mais genérica chamada “Produto” então? Os atributos vão ser mais ou menos os mesmos mas podemos colocar uma coluna de “tipo” pra dizer se é um carro ou moto ou outra coisa. Daí é só ter colunas como preço e já era, certo? Não tá errado, mas não é só isso nem de longe.

Só pra dar um pequeno exemplo: em ecommerces e varejo em geral, existe o conceito de SKUs. Stock Keeping Unit, que é um item distinto de venda, seja de produto ou serviço. É um código alfanumérico. Esse código é importantíssimo pro gerenciamento de inventário, de estoque. Faz de conta, o produto Volks Nivus, tem a versão Comfortline e Highline. A Highline tem 4 cores especiais, 2 cores metálicas, 3 cores sólidas como Preto Ninja ou Branco Cristal ou Cinza Moonstone.

Então o Volks Nivus Highline 2023 Cinza Moonstone tem um SKU único e diferente do Volks Nivus Highline 2023 Preto Ninja. Entende porque? Se você vai na loja, não quer saber se tem o Nivus, quer saber se tem exatamente o Highline 2023 Branco Cristal. Não adianta ter estoque do Preto Ninja, não é ele que você quer. E não adianta ter o Branco do Comfortline, você quer o Highline. O SKU reflete o exato item que você quer.

Mesma coisa com roupa. Ah, tem a camiseta com estampa do Iron Maiden, mas só tem o tamanho M, mas você queria o G. Camiseta Iron Maiden, tamanho M é um SKU e tamanho G é outro SKU diferente. É assim que se modela produtos numa loja. Então, numa tabela de produtos o item que você cadastra não é “Volks Nivus” ou “Camiseta Iron Maiden” e sim “Volks Nivus Comfortline 2023 Vermelho Sunset” ou “Camiseta Iron Maiden tamanho PP”.

Mas os problemas só começaram. Porque se você é a Volkswagen, vai ter um sub-sistema separado, a da fábrica, com outro cadastro de Volks Nivus Comfortline 2023 totalmente diferente. Pra manufatura vai ter outros atributos como o BOM ou “Bill of Materials”. Precisa de quais peças pra montar uma unidade? Transmissão, injeção, computador de bordo, disco de freio, etc. Cada um desses itens tem estoque, tem fornecedor, tem leilão reverso no setor de compras, tem tempo de entrega pra receber essas peças.

Com tudo isso temos um custo de fabricação. Isso pode, ou não, estar ligado ao sistema de vendas. Primeiro, isso influi no estoque e disponibilidade. E também influi no sistema de precificação. Preço não é um valor único na tabela de produtos, como muitos iniciantes podem pensar. É o resultado de diversos cálculos. Custo de fabricação é só um dos fatores. Tem coisas com impostos. ICMS que é o Imposto sobre Operações relativas à Circulação de Mercadorias e sobre Prestações de Serviços de Transporte Interestadual e Intermunicipal e de Comunicação.

Faz diferença onde o carro é fabricado, pra onde precisa ser transportado, especialmente se atravessa estados. Existem impostos federais, estaduais, municipais. Tem todo um cálculo de impostos que influi no preço final. Por isso costumava ser mais barato comprar carro em Minas Gerais do que em São Paulo, por exemplo, não sei se ainda é, mas lembro que me falaram que por isso muito carro de empresa que aluga, tem placa de Minas. O preço varia por região. Mas não é só isso, tem cálculo de custo de oportunidade, depende da estratégia da empresa. O importante é lembrar que preços não são estáticos, tem diversos fatores.

Beleza, temos o carro fabricado, temos o preço pro consumidor final, a venda foi feita, agora o carro precisa transitar entre a fábrica de São Bernardo Campo até a concessionária em Belo Horizonte. Pra trafegar precisa da nota fiscal. Pra colocar o caminhão na rua, precisa de rotas. De onde eu puxo informação pra rota? Google Maps? Maplink? Sistema proprietário, já que eu sou grande como uma Volks?

E não é só isso. Se queremos implementar sistemas de pagamentos, que lidam com dados sensitivos como números de cartão de crédito e coisas assim, nos Estados Unidos, temos o PCI DSS, Payment Card Industry Data Security Standard que dita como empresas devem proteger esse tipo de informação. E estou falando “Estados Unidos” daí parece que não é seu problema. Mas não se esqueça que hoje empresas são multinacionais. Pode ter empresa que começou no Brasil e agora atua internacionalmente, daí precisa implementar essas normas.

No caso específico de privacidade, segurança de dados de consumidores, na Europa temos o GDPR que é o General Data Protection Regulation da União Européia e no Brasil temos o LGPD, a Lei Geral de Proteção de Dados, que é similar. Enfim, o ponto é que não basta só sair modelando tabelas e jogando em qualquer lugar. Cada indústria tem seus padrões e cada país tem suas regulamentações. Precisa seguir. E pior: não é um checklist simples. Algumas coisas você é obrigado, algumas coisas dá um jeitinho, depende de como lidar com o auditor. Muitas nuances não documentadas.

O mundo real é muito mais complicado do que simplesmente pensar em modelagem de dados da forma acadêmica, onde nos preocupamos com coisas como normalização, se queremos terceira forma normal, ou no caso de DDD se estamos falando de Bounded Context, aggregates, domain events. Ou no caso de Design Patterns, se queremos chain-of-command ou mediator. O que eu falei até agora é parte do que chamamos das tais “regras de negócio” e patterns, arquiteturas, DDD da vida é a “descrição” da implementação dessas regras.

O problema é que se você não entende a regra de negócio, não interessa discutir se vai escolher um Adapter ou um Proxy, se vai organizar na terceira ou quarta forma normal. Se a regra estiver errada, a implementação vai estar errada, independente se seguiu o livro do Eric Evans ou pé da letra. E falando no livro de DDD, logo na introdução ele dá um exemplo interessante de um sisteminha de entrega de mercadorias.

Digamos que temos as entidades Voyage e Cargo, tipo viagem e mercadoria, onde uma viagem tem muitas mercadorias. O Eric descreve um sistema que tem responsabilidade de associar cada mercadoria com uma viagem, gravar e rastrear esse relacionamento. Até aqui tudo bem. Em algum lugar do código vamos ter um método como esse:

public int makeBooking(Cargo cargo, Voyage voyage) {
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

Mas porque existem cancelamentos de última hora, uma prática padrão da indústria de entrega é aceitar mais mercadorias do que é possível numa única viagem. É o que se chama de “overbooking”. Algumas vezes é usado um percentual simples, como 110% da capacidade, em outros casos tem regras mais complexas.

Isso é uma estratégia básica no domínio de entregas que é conhecido de qualquer empresário dessa indústria, mas normalmente nós, programadores, não sabemos disso. O requerimento que vem pra nós poderia ser algo como “Permitir 10% de overbooking”, o diagrama de classes poderia ficar parecido com isto e o código seria atualizado da seguinte forma:

public int makeBooking(Cargo cargo, Voyage voyage) {
	double maxBooking = voyage.capacity() * 1.1;
	if ((voyage.bookedCargoSize() + cargo.size()) > maxBooking)
		return -1;
		
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

Ou seja, no código determinamos quanto é o novo máximo com 10% a mais de overbooking e vemos se a mercadoria que queremos adicionar ultrapassa esse máximo. Mas isso cria um problema: agora temos uma regra de negócio escondida, como uma cláusula de guarda, no meio do método da aplicação.

Segundo o Eric, essa regra de overbooking é uma política. Política é outro nome pra um design pattern conhecido como Strategy. Em resumo, esse novo código poderia ser refatorado pra ter uma classe separada de OverbookingPolicy e no método de adicionar a mercadoria na viagem, chamar o método “isAllowed” dessa nova classes, e assim separar a política numa entidade separada, que documenta melhor essa regra em vez de deixar misturada e escondida com o código anterior.

public int makeBooking(Cargo cargo, Voyage voyage) {
	if (!overbookingPolicy.isAllowed(cargo, voyage))
		return -1;
	int confirmation = orderConfirmationSequence.next();
	voyage.addCargo(cargo, confirmation);
	return confirmation;
}

class OverbookingPolicy {
	public static double OVERBOOKING = 1.1;
	public boolean isAllowed(Cargo cargo, Voyage voyage) {
		double maxBooking = voyage.capacity() * OVERBOOKING;
		return ((voyage.bookedCargoSize() + cargo.size()) <= maxBooking;
	}
}

Agora que eu descrevi dessa forma, deve ter ficado óbvio. “Puts, claro, porque eu não pensei nisso antes”. Mas o que quero expor aqui é justamente isso: pra nenhum iniciante é óbvio que isso poderia ser um strategy pattern, provavelmente não era óbvio que isso era uma “Política”. Todo mundo ia ter implementado do primeiro jeito e nunca ia pensar nisso. Até o dia que alguém pedisse pra mexer na regra e mudar de 10% pra 5% por exemplo. Daí iam gastar o dia inteiro tentando achar “onde que tá definido isso no código???”

Deixa eu dar outro exemplo pra ilustrar mais esse ponto. Eu gosto de quadrinhos, comics, mangá, até já me arrisquei a desenhar como hobby no passado. Todo mundo que fica empolgado com um One Piece ou Naruto da vida já rascunhou seus personagens preferidos em algum pedaço de papel e, se não for completamente iludido, sabe que saiu uma porcaria. Mas tudo bem, o objetivo era passatempo.

Já percebeu como todo iniciante em arte faz as mesmas coisas? Ou é paisagem de casinha com uma árvore, um sol e uma montanha. Ah sim, com uma chaminé, não pode esquecer a chaminé. Ou é close-up de rosto de anime. Agora, tenta desenhar um quarteirão de uma cidade, com ângulo olhando de cima. Ou tenta desenhar uma personagem de anime mesmo, sentada numa mesa com as pernas cruzadas e tomando um café. Vai sair a coisa mais torta do mundo, se sair.

Desenhar prédios pode parecer fácil, só retângulos, mas tente fazer um. Não vai conseguir. Convivemos a vida toda do lado de prédios, andamos todos os dias na frente de vários, por anos. Mas nunca paramos pra realmente olhar, observar, absorver os detalhes e, mais importante, nunca pensamos porque determinados aspectos de um prédio são tão particulares. Nunca tivemos treinamento formal de urbanismo. Não paramos pra pensar em zoneamento, por exemplo. Certas áreas não podem ter prédios comerciais, certas áreas tem limite na quantidade de andares. Quem mora perto do aeroporto de Congonhas sabe disso.

Por isso quando você tenta desenhar uma cidade, sai parecendo desenho infantil de casinha com sol. Pra ficar realista, precisaríamos ter experiência com urbanismo e arquitetura. Mesma coisa a personagem sentada de pernas cruzadas. A parte que mais chama a atenção de iniciantes são rostos. Por isso perde-se muito tempo só desenhando olhos, e com rostos sempre em posições parecidas, em 3/4.

Pra desenhar um corpo direito precisa estudar anatomia. Todo estudante de medicina no primeiro ano sabe isso, mas pra gente que não é médico, talvez nem fôssemos pensar nisso. Vemos pessoas na nossa frente todos os dias, em todas as posições. Mas quando você parou pra realmente observar uma pessoa? Como o tecido da calça interage com o material da cadeira, como o peso da perna cria dobras, como músculos como o biceps femoral e o soleus se mexem quando dobramos a perna?

Quando falamos de arte, imediatamente pensamos em coisas como a Capela Sistina, o magnum opus de Michelangelo Buonarroti. Contém cenas super detalhadas e difíceis como o Último Julgamento ou a Criação de Adão. É um trabalho de mais de 500 metros quadrados. Sabe quanto tempo levou pra pintar aquele monstro? Quatro anos inteiros, de 1508 a 1512, usando tecnologia do século XVI.

Entenda, quando Michelangelo começou o projeto da Capela Sistina ele tinha 33 anos. Mas começou a estudar arte desde muito cedo, provavelmente pelos 13 anos de idade e já como discípulo de Domenico Ghirlandaio. Depois estudou escultura sob a tutelagem de Lorenzo de’Medici. Por anos, estudou e produziu pinturas, esculturas e já tinha entregado nada menos que a Pieta e a escultura de David antes da Capela.

Naquela época, a arte não era estruturada e bem dividida como hoje. A maioria dos grandes nomes como Michelangelo, chamamos de polimatas. Mas eles mesmos não se chamavam de “polimatas”, isso é um termo moderno. Só hoje que dividimos que anatomia é mais coisa de médico, lentes e ótica é mais coisa de fotógrafo, urbanismo é mais coisa de arquiteto, pincel é mais coisa de artista. Antigamente não existia essa divisão. Existia o problema e que conhecimentos a pessoa achava que precisava pra resolver o problema. Ponto.

Um artista estudava seja lá o que precisava pra melhorar sua arte. Um bom artista é crítico do seu próprio trabalho. Se ele nota que toda escultura que faz não se parece em nada com uma pessoa de verdade, que escolha ele tem? Vamos lá dissecar corpos de pessoas mortas pra investigar como a pele realmente funciona, como os órgãos influenciam o movimento e assim por diante.

Não existe isso que um artista só precisa estudar cores e pincel. Não existe isso que um programador só precisa estudar algoritmos e código. Um bom profissional estuda o que for necessário pra ser a melhor versão dele mesmo. Pra finalizar. Eu estava refletindo sobre animes outro dia. Já notaram como é muito comum ter várias histórias que se passam no colégio? Romance sempre é romance entre estudantes no colégio. Aventuras sempre são com adolescentes.

Tirando o cinismo de achar que tudo é fetiche, a resposta pode ser mais simples do que isso. É só um chute, mas a maioria dos desenhistas de mangá começa a trabalhar logo depois do colégio, ou até abandona o colégio. E esses desenhistas fazem tudo: inventam a história e desenham. O que é a única experiência de vida que eles tiveram até esse momento? O colégio.

Você, iniciante que ainda não entrou na faculdade, ou mesmo recém formado, é a mesma coisa. O que você conhece sobre a vida e o mundo? Nada. Sua única experiência foi o colégio, seus únicos amigos foram do colégio, os únicos problemas que teve que resolver eram relacionados ao colégio. Festas, trabalhos, tudo. Aos 20 e poucos anos, seu conhecimento sobre o mundo é minúsculo.

Parece coisa de boomer dizer isso, mas é verdade: até começar a pagar seus próprios boletos em dia, você ainda é uma criança. Eu já disse isso em outros videos e vou repetir: é impossível ser um empreendedor que vai inovar o ecommerce aos 20 anos. Você nunca trabalhou num ecommerce. É impossível inovar o setor hospilar com 20 anos, você nunca trabalhou como médico. É impossível inovar o setor agrícola com 20 anos, você nunca sequer levantou uma enxada na vida. É impossível inovar qualquer setor com 20 anos, você nunca produziu nada com 20 anos.

E eu volto a esse ponto porque, pra programadores, temos exatamente esse problema quando discutimos modelagem de bancos de dados, modelagem de orientação a objetos, modelagem de arquiteturas. O que significa modelar? Modelar é representar alguma coisa do mundo real de uma forma abstrata. Mas eis o problema: o que você conhece do mundo real? Quase nada. Não tem como modelar alguma coisa que não se conhece.

Antes que alguém vá nos comentários discordar. Óbvio, eu sei que existem exceções. É por isso que se chamam exceções. Com esse disclaimer feito, vale relembrar porque estou cagando regra nesse assunto. Vamos lá, eu trabalhei em projetos de software de vários tipos de negócios diferentes. Telecomunicações, varejo, manufatura, RH, infraestrutura, agências, grandes corporações, startups. Em 30 anos passei por várias indústrias diferentes e por isso consigo comparar o que cada uma faz de diferente. E mesmo assim não posso dizer que sei tudo. Por isso aviso pra desconfiar de qualquer um que queira ensinar sem nunca ter tido experiências similares.

Professores de faculdade, a maioria, não tiveram essa experiência, mas eles estudaram pra profissão de ensino, fizeram pedagogia, psicologia. Eles foram treinados pra ensinar. Alguns melhores que outros, não importa, mas essa é a carreira. Porém, a grande maioria dos que criam cursos online não tem nem perto da minha experiência e nem perto do treinamento de um professor. Portanto o que tem a oferecer? Quase nada. Eles dependem de caçar material na internet, empacotar como se fossem deles e vender pra você com um discurso que parece convincente e promessas que nunca vão ser cumpridas.

Veja o exemplo do Michelangelo que falei. Seu primeiro mentor foi Domenico Ghirlandaio. Quem foi ele? Foi um pintor renascentista de terceira geração, especializado em frescos e fez diversos trabalhos importantes, embora não do calibre do seu aluno. Porém, ele reconheceu esse talento e foi ele quem recomendou Michelangelo pra academia de Medici. Parece ter sido um bom professor, que teve ele próprio uma boa carreira, suficiente pra catapultar seu aluno prodígio.

O ideal é se fosse possível todo aluno ter a possibilidade de ser mentorado por alguém experiente assim. Infelizmente isso não é possível. Não existem mentores suficientes pra todo mundo. Por isso eu digo que o correto, antes de tentar empreender qualquer coisa por conta própria, é iniciar a carreira em empresas de verdade, que tem problemas e soluções de verdade e aprender as outras áreas que não é possível ensinar numa faculdade.

Eu tive vários mentores que nem sabiam que estavam me mentorando. Quando eu tinha que ajudar a resolver um problema de marketing, tive a oportunidade de trabalhar com pessoas treinadas em marketing e entender o básico de como eles pensam. Quando tive que resolver problemas financeiros, tive a oportunidade de trabalhar com pessoas treinadas em contabilidade e finalmente entender coisas cabeludas como impostos. Quando tive que resolver problemas de varejo, tive a oportunidade de trabalhar com pessoas com experiência real em vendas e ver como de fato fechavam negócios. Nenhum curso ensina essas coisas.

O problema de todo programador é que ele assume que a parte mais difícil e mais importante é só a programação, e que todo mundo que não é programador é mais burro que ele. Por isso tem tanta dificuldade de entregar valor. Óbvio, o cliente deveria ter te explicado melhor. Basta o cara do marketing deixar de ser burro e escrever uma especificação melhor que você, o gênio, não precisa perder tempo pensando e pode só escrever seu maravilhoso código em paz.

Falando em ecommerces. Deixa eu dar um exemplo mais concreto. Vou falar de Ruby on Rails porque ainda é a área que eu lembro de mais referências, mas o mesmo exemplo vale pra qualquer outro framework da vida. Um dos primeiros livros que todo mundo que quer aprender Rails usa é o Agile Web Development with Rails. Originalmente escrito pelo lendário Dave Thomas, mantido atualmente por Sam Ruby. Aliás, excelente nome pro autor de um livro de Rails.

Enfim, o livro é um grande tutorial pra desenvolver um mini-ecommerce à medida que explica como funciona o framework Rails. No fim, temos uma aplicação web que mais ou menos se parece com um ecommerce. Mas lembrem-se, o livro não é sobre como fazer o melhor ecommerce, só em como dá pra usar Rails pra implementar uma versão simples de um. Resolvi procurar no Github e achei o código do que é mostrado no livro, pro Rails versão 6.

Usando a ferramenta Tokei, podemos ver que no final do livro, seu projeto vai ter mais de 100 arquivos de Ruby, quase 2.700 linhas de código. Além de 17 arquivos de javascript que dá mais de 1.300 linhas de código. Fora outras coisas como stylesheets em Sass e um monte de arquivos JSON. Parece bastante coisa né?

Por acaso, no ecossistema Rails existe uma plataforma aberta de ecommerce chamada Spree Commerce. Muito boa por sinal. Eu trabalhei com ela anos atrás e até conheci o autor original Sean Schofield. Na época era um projeto monolítico, mas em anos recentes dividiram em sub-projetos. Inclusive acho que a interface web agora é feita em Next.js e o projeto principal virou mais um servidor de APIs. Vamos ver só esse repositório principal com o Tokei e olha só a diferença: temos mais de 1.300 arquivos de Ruby, mais de 92 mil linhas de código Ruby.

Comparado com o projetinho do livro de Rails, estamos falando de uma diferença de 34 vezes o volume de código Ruby. E isso porque não tem nenhuma lógica de front-end, só a lógica de backend mesmo. Se pegarmos só um arquivo, o da ordem de venda propriamente dita, que ambos chamam de “Order.rb”. O do livro é super curto, pouco mais de 50 linhas. No Spree tem mais de 700 linhas e isso porque tem um sub-diretório com outros arquivos que sub-dividem ainda mais a lógica como “address_book.rb” ou “checkout.rb” ou “payments.rb”. É ordens de grandeza mais complexo.

Agora vamos fazer uma conta de padeiro. O livro Agile Web Development with Rails tem mais de 600 páginas. Se consideramos que o produto final dele é 34 vezes menos complexo que o backend do Spree. Pra explicar o Spree do zero, o livro talvez tivesse que ter então 20 mil páginas. Tem idéia do que isso significa? Coloca em perspectiva, os 5 livros de A Song of Ice and Fire, que deu origem ao Game of Thrones, male male tem umas 4 mil páginas. Ou seja, precisaria de 5 vezes o volume de Game of Thrones, uns 20 volumes, pra descrever um ecommerce como o Spree do zero.

Deixa eu complicar mais: um Spree é um ecommerce muito bom, mas nem de longe é o mais completo. Um dos mais antigos e populares ecommerces de código aberto é o Magento. Hoje existe o Magento 2. Ele é feito em PHP e rodando a ferramenta tokei, olha só: são 2 MILHÕES de linhas de código PHP. Mais de 200 mil linhas de Javascript. O Magento sozinho, só no javascript, tem o dobro de linhas de código do que Ruby no Spree que, por sua vez, já era 34 vezes maior do que o ecommerce do livro que ensina Rails.

Se em 600 páginas o livro Agile Web Development with Rails conseguiu explicar uma versão simples de ecommerce que dá 2.700 linhas de código de Ruby, sabemos que PHP e Ruby não são equivalentes, mas só por diversão, o Magento, só em PHP é mais de 700 vezes maior. Seriam 700 livros. Seriam 100 coleções de Game of Thrones pra descrever do zero, no mínimo. Conseguem entender porque eu fico tão puto quando alguém me pergunta se tem algum livro que explica tudo? Não tem, é inviável de ter.

E eu vou piorar a vida de vocês. Mesmo um Magento ainda é pequeno se desse pra comparar os repositórios de código de uma Amazon da vida, com todos os seus sub-sistemas internos. O que eu estou dizendo? Entenda essa verdades: você nunca vai saber tudo. É impossível. E isso que eu descrevi é só ecommerce. Vejam meu episódio sobre SAP e seu ERP que tem meia década de idade e roda no coração de toda grande corporação no S&P 500. Lembram? Só no banco de dados são dezenas de milhares de tabelas. Repetindo, dezenas de milhares de tabelas. É impossível saber tudo.

Se alguém ficou desesperado com esses números deixa eu contar o grande segredo: eu, Fabio Akita, nunca li o código do Spree, muito menos do Magento. Já trabalhei em projetos com eles e com outras plataformas proprietárias. Mas nunca li todo o código deles e esse é o ponto: não precisa ler tudo.

Posso estar enganado, mas me dá impressão que muitos iniciantes pensam que quando fazem um curso ou lêem um livro, ou um tutorial, “como fazer seu próprio instagram” ou “como fazer seu próprio Facebook”, acham que o código que sai no final já é quase a mesma coisa que o Instagram ou Facebook de verdade, faltando pouquinha coisa.

Ou, que o ecommerce que fez no fim do curso já é quase o Mercado Livre. Ou seja, muitos tem a noção bem errada que existe um curso ou livro que vai te ensinar 100% do que precisa saber pra fazer um produto de verdade do começo ao fim. Eu estou afirmando que não tem, não existe, e não seria prático ter. Seriam literalmente 700 livros de 600 páginas e nem isso seria tudo. Se você não consegue visualizar 700 livros, se colocados de pé um do lado do outro daria mais de 2 metros. Eu duvido que você vá ler uma fração disso na sua vida inteira.

Durante todos os videos do canal vim tentando explicar esse conceito. Deixa eu tentar repetir. Quando você faz faculdade de ciências da computação, em nenhum momento vai ter nenhum curso explicando como se faz um ecommerce, ou como se faz um rede social, ou como se faz um aplicativo de fintech, ou de edutech, ou de saúde, nada disso. Você aprende matérias esquisitas, como algoritmos e estruturas de dados, álgebra linear, cálculo, estatística e probabilidade. Mas onde que ensina como fazer um carrinho de compras ou lista de produtos?

No outro lado do espectro, você pula tudo isso e faz cursos numa Udemy da vida “como fazer seu próprio ecommerce” e sai com uma versão parecida com o do livro Agile Web Development with Rails que eu mostrei. Parece que é melhor, afinal, você fez um carrinho de compras e uma lista de produtos. Só que eu acabei de demonstrar que não é uma fração de projetos de código aberto como Spree ou Magento, na verdade, é de 30 a 100 vezes menor.

Mas eu também disse que ecommerces de verdade, como uma Amazon ou Magazine Luiza da vida, são muito diferentes do que tem num Magento. Então, como faz pra saber? Eis o ponto que eu falei sobre mentoria: você só vai saber como um Magazine Luiza funciona trabalhando dentro do Magazine Luiza. Só tem como saber como um iFood funciona, trabalhando dentro do iFood. Não tem outra forma.

Mas aí não é o problema do ovo e da galinha? Como eu vou conseguir trabalhar num Mercado Livre, se nenhum lugar ensina como eles funcionam? É isso que você também não está entendendo. Quando uma empresa dessas oferece emprego, nenhuma espera que você saiba como elas funcionam. Elas esperam sim, que você tenha um mínimo de ferramentas pra conseguir se adaptar ao sistema deles.

Por isso eu fiz videos analisando os códigos que o Twitter liberou, o código vazado do Twitch ou a arquitetura do Ingresso.com. Se não assistiu, depois assistam. Eu mesmo não trabalhei em nenhuma delas, mas é o tipo de raciocínio que é possível fazer gastando algumas poucas horas, tendo o conhecimento de base. No episódio do Ingresso.com eu falei da arquitetura de filas e salas de espera, que empresas como Amazon e outros utilizam. No episódio do Twitter explico como embeddings de álgebra linear ajudam a resolver o problema de relevância e recomendação de tweets.

Com a base de estatística e probabilidade, dá pra interpretar dados de monitoramento e chegar em conclusões corretas sobre comportamento dos usuários no site, baseado nos dados de navegação e compra. Com cálculo, dá pra saber como o sistema deveria se comportar, coisas com taxa e velocidade de resposta quando se aumenta o tráfego e quais estruturas de dados podem beneficiar mais certas partes do sistema. Com entendimento de sistemas operacionais e compiladores, dependendo do tamanho da empresa, dá pra trabalhar numa nova linguagem que nem existia, como já aconteceu até em empresas nacionais, como a Totus.

Com essa base, dá pra começar a derivar o resto do conhecimento. Uma vez dentro do sistema é que começa realmente a viver o dia a dia de operações da empresa. A burocracia fiscal, a correria de fulfillment de pedidos nos centros de distribuição, a logística de entrega, o tempo de resposta pra suporte ao cliente, as regulamentações e mudanças em leis que precisam ser refletidas no software. Com o tempo você vai aprender o que em DDD se chama de “domínio”.

O Domain, em Domain Driven Design, só faz sentido se você sabe o que compõe esse domínio. No exemplo que usei no começo do video, saber que SKU faz parte do domínio de inventário, ou saber que checkout faz parte do domínio de pagamento. E isso que eu acabei de falar não é absoluto. Em outra empresa, checkout pode fazer parte de um domínio maior chamado “vendas”, ou o checkout é tão complexo que pode ser um domínio por si só. Domínio, as tais “regras de negócio”, varia de empresa pra empresa, de projeto pra projeto. Não é uma coisa estática. É uma referência móvel.

Muitos iniciantes se perguntam se deveriam estudar coisas como Design Patterns e DDD logo de cara. E sim, acho que todo mundo deveria ler pelo menos uma vez, por cima, mas com o entendimento que sem experiência real, essa leitura não vai ter muita utilidade. Arquitetura, patterns, domínios, são conhecimentos que emergem naturalmente com experiência. Não é um checklist que dá pra seguir passo a passo em qualquer projeto. Estude uma vez rápido, e mantenha os livros por perto pra consultar pontos específicos, e assuma que seu entendimento inicial vai mudar na terceira vez que ler, na quarta vez que reler.

Se ler só uma vez ou de forma superficial, vai cometer erros que muitos iniciantes cometem. Por exemplo, achar que Bounded Contexts é só microsserviços e resolver tudo com microsserviços. Microsserviço é um estilo de arquitetura, já bounded context é um conceito de design de estratégia em DDD, que delineia as fronteiras onde um model em particular é definido e aplicável. Você pode ter bounded context num monolito simplesmente usando namespaces e módulos, por exemplo.

Ou então achar que DDD é basicamente só Event Sourcing e CQRS ou Command Query Responsability Segregation. Algumas partes do sistema podem realmente se beneficiar de um sistema de eventos imutáveis ou separação de escritas e leituras nos modelos. Em outros lugares vai ser overengineering. Não se aplica tudo de DDD em todos os lugares. Como diria Jack Sparrow, é mais um guideline.

Mesma coisa com Design Patterns ou qualquer outro livro de arquitetura. Não é pra usar tudo que se estudou em todo lugar. Saber onde usar é mais importante do que saber como usar. Uma vez que se descobre onde, o como é fácil. Muito antes de entrar nesse tipo de discussão, comece pelo básico que já falei antes: quantas vezes você já tentou baixar e rodar um Spree ou Magento ou um simples Wordpress?

“Ah, mas eu sou de Python, não mexo com PHP”. Então você é só um idiota. Porque fazer um Magento rodar não é só um problema de PHP, é subir banco de dados. Um postgres não é específico de PHP, em Python também precisa. Precisa subir um NGINX ou Apache. Numa aplicação web de Python também. Precisa saber onde e como guardar segredos como credenciais. Precisa saber como subir servidores de cache, como Memcache. Nada disso é específico de PHP. Toda aplicação web, em toda linguagem, usa os mesmos componentes. Porque você está querendo discutir patterns e arquiteturas se sequer consegue subir uma aplicação na sua própria máquina?

Apesar de um Magento da vida não se parecer com um Mercado Livre, os componentes e arquitetura geral é familiar. Não as linhas de código específico, mas os componentes gerais de infraestrutura, os conceitos de protocolos, redes, sistemas operacionais, configuração e tudo mais. Não é perda de tempo fuçar projetos como esses e nem mesmo as versões mais simples de tutoriais ou cursos, o meu ponto é garantir que vocês entendam que nunca vão ensinar tudo, mas como primeiro passo, tá mais que bom.

Outra coisa importante: um Magento tem 2 milhões de linhas de código hoje. Graças ao poder do Git, que mantém o histórico de tudo, posso facilmente voltar ao passado, pra versão 0.1.0 alpha 89, de agosto de 2014, quase 10 anos atrás, com o comando “git checkout -b teste 0.1.0-alpha89”. Daí podemos rodar a ferramenta Tokei de novo e olha a diferença, ele tinha mais ou menos a metade do tamanho de hoje, menos de 1 milhão de linhas de código PHP.

Podemos voltar pros primeiros commits, do final de 2011, começo de 2012. Não conheço toda a história do projeto. Pelo pouco que puxei no Google, parece que o Magento 1 foi criado em 2007. Uns 4 ou 5 anos depois a comunidade começou o Magento 2, por volta de 2011 a 2012. É o que os primeiros commits indicam, e a primeira versão estável só foi sair mesmo em 2015. Pelo que entendi, o Magento 2 foi um esforço homérico pra modernizar a plataforma.

De qualquer forma, o código inicial que serviria de base pro Magento 2 já tinha nada menos que meio milhão de linhas de código PHP. Comparado com hoje, é “só” um quarto do tamanho. Mas é pra dar uma noção. Levou de 2007 a 2012 pra chegar nesse meio milhão e depois quase 10 anos mais pra chegar nos 2 milhões de linhas de código de hoje. O projeto tem milhares de contribuidores. Não é um projeto que você vai varar um fim de semana e fazer igual.

Mas o importante é entender que todo projeto tem um dia 1 com zero linhas de código. Todo projeto de código aberto, todo grande site como uma Amazon ou Mercado Livre. No dia 1, todo projeto realmente se parece mais com o nível de código que mencionei dos tutoriais. Mas eles não ficam parados. Vão sendo testados no mundo real, feedback de usuários de verdade vão chegando, o código vai sendo moldado às necessidades do mundo real, 10 linhas se tornam 1000, que se tornam 1 milhão de linhas, ao longo de mais de uma década. E até hoje, o Magento não “acabou”, toda semana tem atualizações, novos commits.

Ao longo desse caminho, o Magento, que foi originalmente criado por uma empresa chamada Varien Inc depois virou uma entidade própria. Por volta de 2011 parece que o eBay entrou em cena e adquiriu uma parte da empresa, com objetivo de integrar com o Paypal. Mas em 2015, eBay e Paypal se tornaram duas entidades separadas e o Magento também foi separado. Daí entra a Adobe em 2018 que adquire a empresa. Hoje ela faz parte do Adobe Experience Cloud e pra contribuir no projeto você precisa assinar um acordo de Licença de Contribuidor.

Eis outro exemplo de como o software foi sendo adaptado pra responder a essas ações externas. Em 2007, ela não foi planejada pra fazer parte da plataforma da Adobe. O cloud da Adobe nem existia nessa época. Ninguém sabia que no meio do caminho ela iria desviar pra dentro do eBay e Paypal e nem que iria se separar poucos anos depois. O software vai se adaptando a tudo isso. A mesma coisa acontece com a plataforma de toda grande empresa. É assim que aos poucos vai virando um repositório de milhões de linhas de código. Nada disso é planejado com antecedência.

Modelagem é uma das respostas a esse tipo de coisa. Em algum momento, a prioridade talvez tenha sido Paypal. Em outro momento a prioridade passou a ser Adobe Cloud. Prioridades de desenvolvimento também ditam a arquitetura e arquitetura dita a modelagem. Modelagens que faziam sentido em 2011 provavelmente não fazem mais sentido em 2018. Entendam isso: software nunca está “pronto” ou “finalizado”. Se ele faz sucesso, é um trabalho constante de adaptação e evolução. Modelagem e arquitetura tem que ser respostas a essas evoluções. Elas emergem do software.

Todo livro, tutorial ou curso, vai simplificar isso. Não é um defeito, é uma limitação do pouco tempo. Como ilustrei até aqui, se tentar documentar tudo, precisaria fácil de centenas de volumes de livros. Ninguém ia conseguir estudar tudo isso. Nenhuma das técnicas de nenhum livro de DDD ou Design Patterns tem as respostas do que fazer em cada um desses grandes episódios. Elas servem de base pra adaptação, mas não tem nenhuma resposta pronta pra nenhum problema de negócios.

Do meu ponto de vista, eu diria que livros DDD ou qualquer outro de modelagem e arquitetura servem pra nos dar um vocabulário pra tentarmos nos comunicar. Tudo é abstrato em software. Não temos parâmetros físicos que todos conseguem concordar, como peso, volume, ou qualquer coisa assim. Software se chama software porque não é “hard"ware.

Uma simples classe de pagamento pode significar coisas extremamente diferentes pra programadores com experiências diferentes. Então tentamos racionalizar e normalizar esses conhecimentos via um vocabulário de modelagem e arquitetura pra começarmos a dar passos em busca de algum consenso, em algumas partes.

Pra não ficar só na filosofia, agora eu queria falar especificamente de alguns livros que acho que podem ajudar um pouco. Novamente, não são livros pra ler de cabo a rabo de uma só vez, e nem só uma vez. São livros pra se estudar um capitulo que tenha um assunto que te interessa no momento, voltar quando tiver mais experiência nesse assunto, e durante sua vida profissional ou acadêmica, quando esbarrar nos outros assuntos, vá indo um capítulo de cada vez.

Eu mesmo não conhecia esses livros até pouco tempo atrás, quem me recomendou foi meu sócio Talysson, que é responsável pelo programa de mentoria da minha empresa, ele mesmo um excelente programador. O primeiro livro se chama The Architecture of Open Source Applications. Ele é dividido em dois volumes. Cada capítulo é como se fosse um artigo sobre um projeto de código aberto escrito pelo próprio autor ou alguém bem experiente e reconhecido.

Por exemplo, o capítulo 11 do primeiro volume é sobre LLVM, que eu já expliquei em vários videos aqui do canal, como no video da Apple e GPL. E o autor desse capítulo é ninguém menos que Chris Lattner, um dos melhores engenheiros dos últimos 20 anos. LLVM tá por trás de todos os compiladores e transpilers modernos incluindo shaders de GPUs e programação de tensors pra IA.

O capítulo em si é super introdutório. Se você assistiu meu episódio e outros como o de compiladores versus interpretadores, a maior parte tá lá. Ele não explica tudo, nem explica em detalhes, mas é um bom capítulo pra quem nunca parou pra ler nada sobre o assunto. A intenção é que cada autor explique porque tomou certas decisões de design do software em que trabalhou. Coisas que hoje achamos óbvio, mas que pra época não era tão óbvio assim.

No volume dois, capítulo 14 temos o projeto NGINX, que eu também já falei várias vezes em episódios como Tornando sua App Web mais Rápida. O autor é Andrey Alexeev, um dos co-fundadores do NGINX. E de novo, é um capítulo bem curto, onde ele fala o óbvio: porque alta concorrência é importante, ou porque não usar Apache. Hoje, é óbvio, mas 20 anos atrás não era e ele explica porque o NGINX foi feito da forma como conhecemos hoje.

No capítulo 18 do volume II encontrei um nome conhecido. Luke Kanies, um dos criadores do Puppet. Hoje em dia, quando falamos de infraestrutura como código, lembramos de Kubernetes, Terraform, ou Ansible, mas Puppet foi um dos precursores, quando codificar infra não era óbvio. Eu entrevistei ele pro meu blog em 2009, vou deixar o link nas descrições.

Já no capítulo 15 do volume 1, outro nome conhecido, Francesco Cesarini. Todo mundo da comunidade Erlang e Elixir conhece esse nome, um excelente educador e evangelista. E foi num workshop dele que eu tive meu primeiro contato com Erlang, também em 2009. Você também pode ter seu primeiro contato com ele nesse capítulo. Enfim, todos os autores desses livros são excepcionais. Eu seria feliz de ser uma fração de qualquer um deles.

O terceiro livro dessa série é o The Performance of Open Source Applications. É o mesmo formato, cada capítulo com um autor que é reconhecido no assunto, mas focado na parte de performance. Logo no primeiro capítulo temos Ilya Grigorik falando sobre alta performance de rede no Chrome. Ilya é outro conhecido de longa data da comunidade Ruby, que eu trouxe pra RailsConf Brasil 2009. Daí ele foi pro Google, hoje está no Shopify e ensinou nossa comunidade sobre métricas, como medir, as melhores ferramentas, quais as prioridades de otimização, e ajudou a definir muito dessa área de performance junto com a W3C. Todo desenvolvedor web deveria ler alguns dos artigos dele sobre performance.

O quarto e último livro é um pouco mais prático e pode servir pra vocês se exercitarem em linguagens diferentes. Se chama “500 Lines or Less”, cujo objetivo é desenvolver uma mini aplicação em 500 linhas ou menos. Por exemplo, no capítulo 19, Audrey Tang nos ensina a fazer uma mini planilha, tipo Excel, com Angular.js. Ou Allison Kaptur que ensina a fazer um mini interpretador de Python, em Python. Se estava procurando exercícios, vale explorar esses capítulos. De novo, nenhum deles é uma aplicação completa de verdade, só os princípios pra quem nunca parou pra pensar “hm, como eu faria um servidor web simples do zero?”, esse é o capítulo 22.

Eu não procurei mas acho que nenhum desses livros tem em português. Mas neste site, que vou deixar o link na descrição abaixo, tem tudo gratuito online. Basta abrir seu navegador e começar a explorar. Eu deixaria uma aba permanente só pra ela, pra não se esquecerem de voltar de tempos em tempos. Como disse antes, não é pra ler tudo de uma só vez. Em particular, o “500 Lines or Less”, é pra abrir um editor de texto e realmente tentar codificar, senão não vai servir pra nada. Alguns capítulos vão usar linguagens que talvez nunca tenham tentado, como Clojure. É uma boa desculpa pra experimentar. E mesmo se não gostar, outro bom exercício é repetir o mesmo exercício em outra linguagem.

Todos os livros eu diria que são adequados pro nível junior até pleno. De pleno pra senior, diria que são textos fáceis. E mesmo assim talvez tenha assuntos que vocês não tenham parado pra estudar ainda. Por exemplo, no volume 1 do The Architecture of Open Source Applications, o Russel Bryant fala do lendário Asterisk. Se nunca trabalhou em projetos de voz sobre IP, antes de existir coisas como Zoom ou Google Meet, talvez nunca tenha ouvido falar. Mas muita gente ainda usa. É tipo um PBX digital. Eu mesmo nunca mexi pessoalmente, mas trabalhei próximo de projetos que usavam, então é um pouco familiar pra mim. Só porque uma pessoa é considerada sênior numa coisa, não quer dizer que é sênior em tudo. Em Asterisk eu não sou mais que um junior.

O maior problema no estágio inicial é que você não sabe o que não sabe. Livros como os que recomendei e projetos de código aberto, como um Magento da vida, são ótimas portas de entrada pra molhar os pés e começar a se familiarizar com código mais complexo e mais real do que tutoriais ou cursos. Não tem nenhum problema aprender via cursos, mas não fique obcecado em achar que quantidade de tutoriais ou cursos vai determinar sua qualidade. Porque não vai. Depois de um certo ponto, sem experiência, você vai estagnar ou pior, só ter a ilusão que está aprendendo. E experiência não é só no trabalho. Você nunca vai parar de estudar e nunca vai saber tudo. Essa é a carreira.

Pra saber se aprendeu mesmo, precisa contribuir código em projetos. Primeiro em exercícios sozinho na sua própria máquina, depois, se possível, em projetos de código aberto mais simples, ou já direto em projetos fechados de empresas. Se puder escolher, escolha empresas que tem desenvolvedores sêniors em quem se espelhar, idealmente que podem te mentorar. Mentorar não é professor e aluno, onde você como aluno fica passivo só esperando alguém te ensinar alguma coisa. É se virar pra fazer e alguém te dar orientação e feedback. A melhor coisa é alguém apontar o que você fez de errado quando achava que não tinha nada errado. Ou seja, apontar o que você não sabia que não sabia.

E tire da cabeça que só tem valor conseguir emprego numa empresa de nome grande como Amazon. Não. Qualquer empresa que tenha software é oportunidade de aprendizado. Não importa se o software é “legado”, antigo. Você nunca programou nada real. Não importa se é na lojinha da esquina ou no Magazine Luiza. Todo software é software. Basta não ficar 20 anos no mesmo lugar, fazendo a mesma coisa. Mas também, menos de 1 ano não é proveitoso. Tem que ter um período pra aprender tudo que puder aprender, em particular, tudo que você ainda não sabe que não sabe.

Como disse lá no começo, esse episódio poderia ser um pouco frustrante. Porque não tem uma resposta simples pra dizer como aprender a modelar, ou decidir arquiteturas, ou fazer um bom design de software. Sua versão 1.0 de tudo vai ser sempre ruim, e isso não é um defeito, é simples falta de experiência. À medida que se trabalhar em empresas ou participar de projetos de código aberto e se exercitar mais, os gaps de conhecimento vão ficando aparentes. E você vai começar a finalmente entender o que não sabe, pra conseguir ir atrás de saber.

A idéia não era tentar dar uma resposta definitiva, só abrir os conceitos pros iniciantes terem uma noção melhor do que tem pela frente. E o conceito principal é que você nunca vai saber o que é um “bom software” sem antes fazer muito mau software e lidar com mau software dos outros. Não existe um checklist que define todas as características de um bom software. Bom é relativo ao que se espera daquele software. E tudo que chamamos de modelagem ou design, são meros vocabulários pra tentar descrever essa abstração que chamamos de software. Se ficaram com dúvidas, mandem nos comentários abaixo. Se curtiram o video deixem um joinha. Assinem o canal e não deixem de compartilhar o video com seus amigos. A gente se vê, até mais.

DESCRIÇÃO

Faz tempo que eu falo sobre Aprendendo a Aprender do jeito certo, e depois de muitos anos de pesquisa e experimentação. Boa parte do que eu falo vem não só da minha formação, mas da forma como minha empresa CodeMiner 42 forma desenvolvedores. Faz anos que preferimos contratar recém-formados como estagiários e evoluir eles internamente. Agora queremos expandir esse aspecto da empresa abrindo um Programa Remunerado de Trainees.

Se você é recém-formado, ainda sem experiência profissional, e quer aprender mais, talvez agora seja sua oportunidade! Assista o video inteiro pra saber se o programa faz sentido pra você ou não.

E claro, se você já tem alguma experiência e quer se candidatar a vagas na CodeMiner 42, sempre temos vagas abertas. Veja em https://codeminer42.com/careers e mande currículos para become@codeminer42.com

Daqui alguns dias vou atualizar o link pro site do Programa de Trainees, então sigam o Twitter @codeminer42 ou nosso LinkedIn pra não perder essa oportunidade. As inscrições pra seleção vão fechar muito rápido dependendo da procura então precisa ficar esperto mesmo!

CONTEÚDO

• 00:00 - Trecho: “RANT: Empreendendo com Software do Jeito Errado”
• 02:13 - Intro
• 02:59 - Vagas Abertas na CodeMiner 42
• 03:48 - Trecho: “O Mercado de TI para Iniciantes em Programação”
• 05:16 - “body-shops” vs nosso estilo
• 08:19 - Contratando estagiários
• 10:03 - Trecho: “Guia Definitivo de Aprendendo a Aprender”
• 15:45 - Bronca: sempre ouça até o fim antes de reclamar
• 16:55 - Programa 1: Imersão 42
• 18:20 - Programa 2: Trainee 42
• 22:02 - Nem só seniors, nem só juniors
• 23:01 - O que este programa oferece de diferente
• 25:25 - Expectativas
• 26:30 - Conclusão

SCRIPT

[trecho do video anterior de RANT]

Outro erro super comum. Mesmo caso, o cara me chega com um calhamaço de especificações e pede “pra fazer meu sistema perfeito, preciso da equipe perfeita, me vê aí uns 5 ou 6 desenvolvedores sênior, pra viagem”. Povo pensa que é pastelaria. Nenhum projeto precisa ter só seniors, além de ser um desperdício, você vai desmotivar pelo menos metade deles, que em pouco tempo vão vazar. Isso porque todo projeto tem tarefas desafiadoras e tem muitas tarefas mundanas. Ficar trocando textos, substituir imagens, corrigir pequenos bugs, atender suporte. Pede pra um senior fazer isso, ele vai mandar você ir lá praquele lugar, especialmente num mercado aquecido e competitivo como de agora.

É que nem você querer construir sua casa dos sonhos, aí na sua infinita sabedoria pensa “cara, não vou contratar nenhum pedreiro, vou contratar uma dúzia de mestres de obra. Se os pedreiros fazem minha casa em 6 meses, certamente os mestres de obra sozinhos vão fazer em 3 meses e ainda com muito mais qualidade”. Entenderam o ridículo? Todo projeto tem tarefas pra seniors e pra juniors. A tarefa mundana que o senior já fez quinhentas vezes e não quer fazer de novo? É exatamente o tipo de tarefa que um junior precisa pra ganhar experiência.

Coloque seniors orientando juniors e não só sua produtividade vai ser melhor do que num time só de seniors, vão ser todos mais motivados e você ainda aproveita pra garantir que sua equipe naturalmente consiga se auto-repor. O junior de hoje é o senior de amanhã. E quando chegar amanhã ele vai saber da importância de orientar novos juniors, porque foi assim que ele cresceu também. É um ciclo positivo. Toda empresa de tecnologia precisa de juniors, estagiários. Não é sustentável achar que sempre você vai achar seniors com disposição pra ficar fazendo tarefas mundanas de manutenção. É isso que eu pratico na minha empresa faz anos.

“Ah, esse mercado tá foda, não consigo contratar.” Lógico, você tá procurando só seniors pra ficar mudando botão de lugar na sua tela. Não é o mercado que tá foda, é você que não sabe contratar e não sabe formar pessoas. Formação de novas pessoas é fundamental pra qualquer negócio, seja grandes corporações ou pequenas startups. Pessoas entram e saem, ninguém fica pra sempre, mas se você forma pessoas, seu processo já está adaptado a mudanças.

[fim do trecho]

Olá pessoal, Fabio Akita

Pelo jeito todo mundo gostou do video de RANT: Empreendendo com Software do jeito Errado, em particular a parte onde falo como todo mundo contrata errado. Mas aquela era só parte 1, ainda tem mais coisas que quero complementar. O video de hoje vai ser um pouco diferente. Vocês sabem que raramente falo sobre minha própria empresa, que é a CodeMiner 42, e hoje vai ser um raro momento onde vou explicar uma parte de como a gente funciona. Quero compartilhar alguns conceitos e planos que tem a ver com diversos videos que já fiz sobre aprendizado e crescimento profissional. Vocês podem assistir os detalhes na playlist de carreira, mas o que vamos fazer agora é a culminação de uns bons 5 anos de experimentação, sem contar as pesquisas que venho fazendo por mais de 10 anos.

Em resumo, em 2022 vamos entrar mais forte no mercado de formação de pessoas. Mas vamos começar a testar a iniciativa já agora no fim deste ano de 2021. Antes de começar o assunto, muita gente pergunta se tem vagas abertas na CodeMiner e sempre tem. Veja em codeminer42.com/careers e mande currículo pro email become@codeminer42.com que vamos tentar avaliar. Tem gente que não sabe se está totalmente preparado ou não, pra isso temos nossa avaliação. Minimamente precisa já ser formado, ou terminando se for pra estágio, e precisa ter fluência mínima em inglês, porque metade dos nossos clientes são dos Estados Unidos. Se tiver pelo menos isso, entre em contato. Isso dito, vamos lá.

(…)

[trecho do video mercados de TI] Ainda na categoria de terceirizadas, em segundo lugar, temos os body-shops. Qualquer empresa, física ou remota, que aloca você POR PROJETO ou seja, que não te contrata em tempo integral e não te dá o suporte mínimo ou que demite se ficar algum tempo sem projeto. Muitas ainda contratam você por um pacote mínimo de horas e você preenche planilhas ou sistemas de controle de horas e é pago por hora. A função dessas empresas é basicamente achar pessoas no mercado, manter um banco de currículos, e quando os clientes pedem algum perfil eles tentam fazer um match. É um tinder de pobre pra empregos.

Eu fortemente desaconselho iniciantes nesse tipo de empresa, porque você ainda não está preparado. Iniciantes precisam de outras pessoas mais experientes ao redor pra crescer. Esse tipo de empresa funciona pra quem já tem alguma experiência e sabe se vender sozinho, freelancers. Talvez, se for pra alocação remota pode fazer sentido pra quem quer morar numa região distante sem mercado local e quer home office, por exemplo. Ou pra quem quer cobrar mais caro alocado num cliente sem ter vínculo empregatício com ela. Novamente, funciona bem pra quem já tem experiência e pode ser uma boa alternativa mas repito: não deveria ser seu primeiro emprego. Quem vira freelancer rápido demais perde muita oportunidade de crescer antes do tempo. Você perde mais tempo preocupado se vai ter um próximo projeto. Como não tem experiência vai acabar trabalhando demais por pouco resultado e não vai ter ninguém pra realmente orientar o trabalho pra ser mais eficiente. No começo pode parecer que vai ganhar mais, mas você não cresce e fica estagnado muito rápido. É uma armadilha.

[fim do trecho]

Eu expliquei nesse video sobre mercados de 2019 que dentre os diversos tipos de empresas de terceirização o que mais tem é o jeito preguiçoso e de mais baixa qualidade: os body-shops, que basicamente é um recrutador num telefone, ou hoje em dia no whatsapp, ligando pra pessoas aleatórias o dia todo tentando contratar qualquer um pra qualquer projeto. Caiu na rede, é peixe. A intenção dessas empresas é só ir suprindo a demanda de qualquer jeito. E sim, é o resultado desse final de bolha. Se você não sabe o que é uma bolha, veja meus videos sobre mercado financeiro. Todo programador deve ter notado que aumentou dramaticamente o volume de recrutadores mandando fazendo promessas vazias em e-mails toscos de propostas, eu diria que 90% é puro lixo.

Daí tem empresas como a minha e sim, vou puxar sardinha pro meu lado. A gente costuma selecionar não só os candidatos a funcionários como também os clientes e projetos. Não somos uma agênciazinha, normalmente ninguém trabalha hora extra, feriados, fica se dividindo em 3 ou 4 projetos de uma só vez. Não atrasamos pagamentos inventando justificativas, não fazemos coisas toscas como “banco de horas”. Crescemos sustentáveis com mais de 100 funcionários, uns 20 a 25 projetos ativos de cada vez. Nossos clientes estão concentrados metade em São Paulo e metade nos Estados Unidos, por isso a empresa também é incorporada lá fora, basicamente uma empresa americana.

Em 10 anos, praticamente não fazemos nenhum tipo de advertising e propaganda e mesmo assim sempre tivemos mais procura por clientes do que conseguimos atender, operando acima de 95% da capacidade todo ano, com zero dívidas e lucrativos sem nenhum investidor externo. Mais do que isso, é função de todos os colaboradores da empresa realmente colaborarem na evolução de seus colegas. Seniors mentoram juniors, juniors mentoram estagiários e todo mundo se ajuda. Temos canais abertos de comunicação e uma série de atividades internas. Mas mais importante, somos ativos dentro dos projetos.

Frequentemente conversamos com nossos clientes pra ajudar a evoluir os desenvolvedores, seja dando mais desafios ou desafios diferentes, pra ninguém ficar estagnado, seja até mesmo trocando de projeto proativamente quando dá. Se decidirmos que é melhor trocar, em vez de esperar acabar a alocação, forçamos a troca. Obviamente não é possível sempre estar 100% satisfeito 100% do tempo em todo projeto. Tem momentos desafiadores, tem momentos tediosos, e por experiência sabemos mais ou menos quando precisamos intervir. Faz parte do processo de formação que praticamos.

Somos uma das poucas empresas da nossa categoria que não fica mandando aquelas mensagens spam bestas de recrutador em LinkedIn ou grupos de Facebook. Eu não lembro se alguma vez a gente fez mais no LinkedIn do que postar conteúdo ou notícias. Nenhum programador nunca recebeu um único e-mail de recrutamento automático vindo da gente, e se receber pode apagar, é fraude. Sério, a maioria esmagadora de e-mails de recrutamento que você recebe hoje é spam automático, especialmente aqueles que começam com “vimos seu LinkedIn e adoramos seu perfil”, mentira, o robô sequer abriu seu perfil.

Faz anos que preferimos contratar recém-formados de diversas cidades pelo Brasil, de Norte a Sul. Muita gente começou como estagiário e hoje é reconhecido como sênior pelo mercado. Um dos nossos sócios começou quase como junior anos atrás e subiu até comprar participação na empresa. Internamente temos alguns programas como de Associados, que seria como um “estágio pra virar sócio”. Outro deles começou como estagiário logo que se formou, primeiro emprego, e alguns anos depois subiu pra sênior. E agora como associado, ajuda os demais funcionários e evoluir também.

Já por volta de 2016 sempre ficamos pensando numa forma de fazer alguma coisa como uma “CodeMiner Academy”, estruturar alguma coisa mais parecida com “cursos”, mas como vocês que assistem meus videos sabem, eu não gosto de praticamente nenhum modelo de cursos tradicionais. Os conteúdos em si não acho ruins, também não varia grande coisa de curso pra curso, mas a proposta das metodologias é que eu acho muito ruins. Enquanto o modelo for alunos pagantes, qualquer empresa de ensino sempre vai privilegiar não desmotivar essa fonte de renda e manter ele por perto, pra consumir mais cursos. Eu realmente acho que falta mais e ao longo desses últimos 5 anos viemos aperfeiçoando formas de acelerar a evolução das pessoas e achamos que temos um bom modelo interno.

E não é nenhuma forma super complicada e secreta e nem nada disso. Na realidade, uma boa parte eu descrevi em detalhes no video do Guia Definitivo de Aprendendo a Aprender que publiquei 1 ano atrás. Se ainda não assistiu deixa eu puxar um trecho daquele video aqui pra refrescar a memória. E já aviso pros desavisados que alguns vão ouvir os primeiros segundos deste trecho e vão querer ir nos comentários falar bobagem porque não ouviram até o fim, então não passem vergonha e ouçam até o fim antes.

[trecho do video de aprendendo a aprender] Na CodeMiner, já faz alguns anos, contratamos estagiários. Normalmente são alunos de universidades federais ou estaduais, por volta do 2o ou 3o ano. Pra conseguir isso abrimos escritórios físicos em 12 cidades do país, de Norte a Sul, incluindo cidades como Natal, Anápolis, Santa Maria, Guarapuava, Ribeirão Preto e mais. Raramente contratamos estagiários que vieram de faculdades particulares. E por que? Porque normalmente a seleção deles é muito ruim. A palavra-chave aqui é seleção.

Entenda, além da qualidade dos professores e currículo, seleção é o fator fundamental que separa as universidades públicas das privadas. A universidade pública, por definição, não tem fins lucrativos no sentido de cobrar mensalidade, já as particulares tem. Em qual você acha que a seleção vai ser mais fácil? Como a concorrência pra entrar numa federal é ordens de grandeza maior do que numa particular, a seleção é muito superior. Por outro lado, muitos cursos particulares sequer tem seleção, significa que pagando, qualquer um pode entrar e, como eles tem incentivo pra manter o cara pagando, vai ser a pior seleção de todas, quando tem.

Além disso, se um aluno conseguiu sobreviver os 2 primeiros anos de uma boa federal de bacharelado em ciências da computação, quer dizer que ele passou por matérias consideradas hiper chatas mas necessárias como cálculo, como álgebra, como algoritmos e estruturas de dados. E se ele fez pelo menos iniciação científica, demonstra ainda mais empenho em trabalhos de pesquisa e melhoria contínua. Ou seja, um aluno de federal que já passou da metade do curso costuma ter bom potencial. E mesmo assim a gente ainda avalia ele antes de contratar.

Eu não estou dizendo que automaticamente todo mundo que faz curso comercial online é ruim. Pelo contrário, já conheci muitos programadores que se tornaram muito bons. Mas normalmente a pessoa que já tem o que precisa e sabe aprender sozinho, não foi o curso que o tornou bom. Com ou sem o curso ele já tem propensão e principalmente vontade de aprender, a despeito da qualidade do curso.

E mesmo depois de tudo isso, um estagiário meu ainda não está preparado pra entrar num projeto de verdade. Raramente é possível alocar um estagiário num projeto no primeiro mês. A maioria fica 3 meses ou mais só estudando. Nesse período ele precisa cumprir as 6 horas dele presencialmente nos nossos escritórios, e se integrar com os funcionários mais experientes. Eu já disse em outros videos que eu acho que nesse estágio de iniciante é extremamente prejudicial ser home-office, porque o aprendizado vai ser ordens de grandeza menor. Ele precisa estar do lado de gente mais experiente.

Durante esse período de estágio, ele participa de projetos internos, aprende a se comunicar com seus pares nos escritórios, aprende a pedir ajuda quando precisa, toma porrada nas revisões de código, é avaliado com alguma frequência pra ver se tá estagnado ou se tá evoluindo. Algumas vezes, quando ele é sozinho mais acelerado, até consegue participar como um programador não cobrado em projetos pequenos de verdade. Quando ele é efetivado como júnior depende muito mais dele do que da gente.

Esse é o período de treinamento no estágio. Nós não oferecemos nenhum material formal de aprendizado, em vez disso nós temos ebooks e algumas contas de cursos online que ele pode fazer. E nesses casos eu aprecio o uso de cursos online: como uma forma resumida de absorver algum assunto muito rápido pra pessoas que já tem uma fundação. Eu mesmo esses dias queria relembrar sobre React, porque eu não sou front e sim back, então assisti os cursos iniciais da Pluralsight na velocidade 2X porque eu acho todo video de curso hiper lento. E em 2 dias eu fiz o curso todo. E eu não estou endorsando a Pluralsight não, foi aleatório.

Além disso ninguém na empresa tem função específica de ser professor, não existe uma estrutura de aula nem palestras que ele precisa assistir, nem nada disso. Nós vamos jogando problemas do dia a dia pra ele resolver e ele precisa demonstrar que tem interesse em usar esse tempo. Inclusive ele está sendo remunerado, pra estudar muito. Como ele tem contato com os programadores experientes que estão em projeto, ele naturalmente começa a entender como os projetos funcionam e como nos comunicamos com clientes, na prática. Não existe um guia ou protocolo de comunicação.

Mais do que isso, nós não temos as figuras formais de gerentes ou qualquer coisa assim. Todo funcionário fala diretamente com o responsável do projeto do lado do cliente, sem um intermediário responsável em micro-gerenciar. Todo funcionário sabe que não deve só receber tarefas e fazer às cegas; aos poucos ele vai aprendendo a questionar as coisas, inclusive se ele deveria estar fazendo o que foi pedido e se não existem formas melhores e mais eficientes pra resolver o mesmo problema. E ele tem autonomia de dizer isso diretamente pro cliente. Isso faz parte do dia a dia de todo Miner. Sem micro-gerenciamento. Eles simplesmente sabem o que tem que fazer. Inclusive quero dizer que estou muito orgulhoso deles porque dia 13 de março comuniquei todo mundo pra antecipar a quarentena por causa da pandemia. Todo mundo começou a trabalhar de casa e todo mundo sabia o que tinha que fazer, sem precisar dar ordens ou instruções extras.

Eu imagino que muitos dos estagiários novos devem estranhar ter tanta liberdade logo no começo, mas ele não pode cruzar os braços, porque com tanta autonomia significa que temos tolerância zero com falta de profissionalismo ou mal caratismo. Zero mesmo, se alguém fizer alguma coisa mal caráter é demissão instantânea. Erros a gente sabe que todo mundo comete, mas se ficar cometendo o mesmo erro com frequência, toda vez, também não vai durar. É comum a gente repetir que se a pessoa se ver de braços cruzados sem fazer nada, ela está errada, porque devia estar caçando coisas pra fazer.

E por que tô contando toda essa história? Porque eu acredito que o jeito certo de aprender é esse: 1) dando problemas pra serem resolvidos 2) não ter nenhum material oficial, e sim forçar as pessoas a saber encontrar os materiais que precisam 3) não ter nenhum supervisor ou chefe que dá mastigado, forçando a criar senso de autonomia e responsabilidade. Pronto, acabei de resumir a metodologia inteira em 3 frases. E por hoje é só, a gente se vê semana que vem …. E, não, tô brincando, deixa eu explicar isso. [fim do trecho]

Como falei antes, proveito pra fazer uma crítica pros que assistiram o começo do trecho e não foram até o fim. Já foram direto nos comentários encher o meu saco falando que eu privilegio ou pior, que eu discrimino contra faculdades particulares. Isso só demonstra como tem gente que só ouve o que quer e ignora o resto. Eu disse e confirmo de novo que normalmente costumam ser aprovados nos nossos testes mais pessoas que vieram de faculdades públicas. Mas isso não quer dizer nem que faculdades públicas são superiores e nem que desaprovo particulares. Foi só uma observação estatística.

Eu pessoalmente faço a avaliação da maioria dos testes enviados e eu faço avaliação cega. Eu não leio o currículo, só vejo o código. Não sei se é homem, se é mulher, se é novo, se é velho, de que região do país que é ou onde foi que estudou. Minha parte da avaliação é só checar a qualidade do código pra ver se presta e mais ou menos que nível que tá. O código às vezes nem roda completamente, e eu sei dizer se foi por pequeno descuido ou porque fez trabalho porco. Se estou precisando de um junior, talvez a gente ainda possa consertar e ajudar a evoluir, se foi um erro honesto. Eu preciso sentir pelo código que houve esforço, que houve tentativa honesta.

Enfim, agora em 2021 resolvemos fazer alguns experimentos com uma iniciativa chamada Imersão 42. Já tivemos duas turmas de alunos de 2o a 3o ano na faculdade, pra que pudessem ter a experiência de aprender ao lado de nossos desenvolvedores e ter uma noção melhor de como empresas como a nossa funcionam mais ou menos. Cada turma ficou com a gente por um período de 3 meses, a segunda turma está na etapa final agora. A primeira turma foi só com alunos de faculdades públicas, a segunda turma só com alunos de faculdades particulares. Independente se vem de pública ou particular, nenhum aluno tem real noção de como projetos de verdade funcionam e como equipes de verdade trabalham. O choque é brutal pra muitos e o objetivo da imersão era dar um gostinho dessa experiência.

Os experimentos de imersão foram muito interessantes pra termos uma noção de como aperfeiçoar nossos modelos de mentoria. Ainda foi limitado porque os alunos não tinham tanto tempo por causa das aulas, provas e trabalhos da faculdade. O mais difícil foi conseguir ter foco só no aprendizado. E não adianta, mesmo se você for interessado, mas não tem condições de fazer mais de uma coisa ao mesmo tempo, não vai fazer nenhuma das duas coisas direito. Melhor acabar uma coisa antes de começar outra. Muita gente se pergunta se consegue fazer faculdade e trabalhar ao mesmo tempo, alguns conseguem, mas eu diria que são a minoria. Pra maioria eu diria pra fazer um de cada vez mesmo, porque por essa pequena experiência da imersão, a maioria teve bastante dificuldade.

Agora vamos começar uma fase diferente dessa imersão e transformar num programa de trainées. Pra participar é simples: se você é recém-formado, seja lá de qual faculdade, ainda tem pouca ou nenhuma experiência de trabalho, realmente acha que tem comprometimento e esforço mas não tem oportunidades e, mais importante, que realmente goste de programar e preze pela qualidade do código, então nós vamos colocar isso à prova. E pra isso, do nosso lado, também vamos nos comprometer. Não sei se quando eu publicar esse video o site novo já vai estar no ar ou não, mas sigam o twitter da CodeMiner42 pra não perder. Se nada der errado por volta do meio de Novembro de 2021 vamos começar.

Por um período super curto de alguns dias vamos abrir um processo de seleção, inicialmente vai ser só um questionário. Estamos procurando programadores de potencial que só precisam de uma chance pra mostrar que podem entregar resultado e ainda nem precisa saber tudo. Mas prestem muita atenção porque nesta etapa não vai ter nenhuma exceção, nem adianta perguntar. Nesta primeira turma de trainées, já precisa ou estar formado ou no mínimo terminando a faculdade no período da noite, porque vocês vão precisar estar disponíveis no horário do dia. E isso não é negociável, quem mentir e não conseguir aparecer quando precisamos porque tava fazendo outra coisa, vai ser cortado. Eu não quero fazer vocês perderem tempo e também não vou deixar perder tempo de quem tá participando sério e principalmente dos mentores, que num primeiro momento vão dividir responsabilidades com o programa e com os respectivos projetos reais que participam.

Além disso é essencial saber o mínimo de inglês pra ler, escrever e falar. Não estou dizendo fluente como nativo, mas fluente que outra pessoa entenda o que você fala. E por último vai precisar ter seu próprio computador. Puts, mas é bastante exigência né? Só que você não precisa se arriscar de graça nesse programa, porque os selecionados vão ser devidamente contratados e remunerados. A contrapartida das minhas exigências é que vamos pagar um salário de 2 mil reais, mais plano de saúde, assistência odontológica, vale refeição, vale academia e reembolso de cursos online como inglês. Em troca nós queremos que vocês estejam disponíveis no horário comercial inteiramente focados no que vamos passar no programa. Nesse estágio ninguém vai participar de nenhum projeto de verdade ainda, só estudos e mentoria mesmo.

O programa vai durar um total de 90 dias, com avaliações ao longo desse período, vai rolar paredão, ou Squid Game se preferirem, porque quem demonstrar que não tá se esforçando ou interessado, ou simplesmente porque talvez não seja compatível com nosso estilo, vamos demitir. Nada pessoal. Só quem chegar ao final dessa etapa de 90 dias e que avaliamos que demonstrou potencial, evolução, vão continuar como trainée e vão passar por mais um período de mais uns 30 até 90 dias pra se tornar juniors na empresa. Ainda vão continuar sendo avaliados depois também. E só pra nenhum ser perdido ir nos comentários perguntar, isso não é um curso, não damos certificação de nenhum tipo e não é pra sair usando como ponto pra outra oportunidade de emprego.

Se sobreviverem a esse período de muito estudo e treino, vão ter a oportunidade de trabalhar em projetos reais junto com nossos outros desenvolvedores mais experientes pra vermos o desempenho de verdade. Alguns são mais rápidos, alguns são mais devagar, mas o que importa é vermos uma curva de crescimento e não de estagnação. Muita gente fica preocupada que ainda não sabe o suficiente. O que estamos propondo é justamente dar a oportunidade de vocês verem o quanto já estão preparados ou não, e não estamos pedindo pra fazer isso de graça, vamos pagar vocês pra isso. O importante é crescimento, se eu dou material e suporte, e mesmo assim você fica no mesmo lugar, aí tem que repensar. Mas normalmente as pessoas crescem nesse estágio e conseguimos identificar talentos muito rápido.

Eu comecei este video mostrando um trecho falando como muitas empresas contratam errado, por exemplo, achando que dá pra ter equipe só de seniors. Eu sempre digo que não, eles precisam de alguns seniors e alguns juniors, equipe mista. Mas muitos não acreditam que um junior vai entregar coisa decente - eles acham que vai desacelerar os sêniors.

Mas o outro lado da moeda que eu não falei no outro video é que tem empreendedor de fundo de quintal que quer abrir empresa com pouco ou nenhum dinheiro daí economiza onde não devia: querendo contratar só júniors pra fazer trabalho de sênior. E claro que isso também vai dar ruim. Vão fazer um puxadinho que male male fica de pé, todo mundo vai ficar frustrado e o negócio não vai pra frente. E não é porque juniors são ruins, mas porque você tá dando tarefas incompatíveis com o nível deles. Nem oito nem oitenta. Toda boa equipe é balanceada, como todas as coisas deveriam ser. Equipe mista, onde os sêniors tem consciência que precisam orientar os júniors. Com o tempo, tudo entra nos eixos.

E esse é um exemplo de coisas que eu acho que nenhum curso vai ser capaz de fazer: posicionar o iniciante sem experiência no lugar certo pra crescer. Porque não importa quantos cursos você faça, quantos livros leia, quantos tutoriais treine, independente da quantidade de horas que se dedicar: sem experiência real, você no máximo vai ser um júnior de potencial. Material didático primeiro tem preocupação de ser didático, ser fácil de entender, que não é a mesma coisa que código feito em projetos reais.

Pra crescer precisa estar do lado de outros programadores mais experientes, enfrentando problemas do mundo real que envolve não só código mas comunicação. Conseguir argumentar suas idéias, aprender a ouvir os problemas e refletir possibilidades de solução, conseguir discutir com seus pares pra achar a alternativa que melhor se encaixa no problema, pra só aí realmente executar o que imaginou como código e entregar funcionando, dentro dos limites de custo e tempo do projeto. Isso não se aprende em livros, nem assistindo videos, só praticando, praticando e praticando.

Então, o que esse programa de trainées oferece é realmente entregar a promessa do “from zero to hero”, partindo do zero de recém formato até engatar na carreira e ter possibilidade de ir até senior, através de estudos e principalmente de projetos reais, sendo mentorado por colegas mais experientes e em breve também mentorando colegas mais novos. Um sênior que é incapaz de mentorar alguém menos experiente, não é um sênior na minha opinião. De qualquer forma, o ponto é que nenhum curso tem projetos reais pra oferecer, então você sempre vai acabar no máximo no nível de júnior, se muito. E a maioria das empresas não tem mentalidade de educação, então fica sempre cometendo esse erro de botar sênior pra fazer trabalho de junior, ou junior pra tentar fazer trabalho de sênior, e raramente se preocupando com a evolução da carreira de cada um.

E no dia a dia de projetos de uma consultoria como a nossa não tem só o projeto. Tem atividades internas, oportunidade de criação de conteúdo como no nosso blog, fazendo palestras internas que chamamos de brown bags, organizando workshops e grupos de estudo, ajudar em projetos open source, pareando e mentorando colegas menos experientes e nada disso passa em branco. Quando a empresa cresce a gente divide isso. Pelo menos nos últimos 3 anos todo mundo ganhou bonus que equivalem a 2 salários extras ou mais. Não é só 13o, é 14o, 15o, só depende de todo mundo estar entregando resultados em crescer a empresa em qualidade.

Lógico, essa primeira turma de trainées que vamos abrir não deixa de ser um teste beta que vamos continuar aperfeiçoando. Pra ter a expectativa correta não imagine que vai ser tudo perfeito. Estamos pensando em contratar pelo menos umas 30 pessoas que, como falei, vamos pagar. Vai ser um investimento inicial que vamos fazer de quase meio milhão de reais sem garantia de retorno. Tudo vai depender da nossa competência de seleção e treinamento. E mesmo se você ainda não bate nos critérios que falei antes, não se preocupe porque essa primeira turma dando certo, já em 2022 mesmo deve ter mais turmas e queremos continuar expandindo esse programa.

E que fique claro que ninguém vai pegar na mãozinha e passar a mão na cabeça, nós não tratamos ninguém como criança porque não somos uma creche. Estamos procurando adultos que querem evoluir mais rápido. Toda empresa famosinha que só fica procurando gente senior com anos de experiência tem zero noção de como evoluir pessoas. Mas ao contrário delas isso está na fundação da minha empresa, foi assim que crescemos no que somos hoje, e chegou a hora de aumentar a escala do que sempre fizemos e você pode fazer parte disso.

E se o episódio de hoje acabou virando uma grande propaganda da minha empresa, é isso mesmo. Eu continuo recebendo propostas de propagandas pagas e eu rejeito todas, porque não vejo fazendo sentido pro canal. Por outro lado a minha empresa é quem realmente permite que este canal exista em primeiro lugar, e minha intenção é ir aos poucos aumentando nossa participação numa das principais missões da empresa e deste canal que é educação e melhorar a qualidade dos profissionais deste mercado. Como eu disse antes, sigam a CodeMiner nas redes sociais, no Twitter ou LinkedIn, porque em poucos dias vamos anunciar a abertura do processo seletivo. Eu já vi muita gente falando nos comentários que queria poder trabalhar com a gente mas ainda não se sentia qualificado, e talvez agora seja a sua oportunidade.

Infelizmente não tem como acolher todo mundo então num primeiro momento vamos precisar restringir alguns critérios que vão estar mais detalhados no site. Não se sinta rejeitado, é só um problema que nossos recursos também são finitos. Mas como eu já disse, novas turmas vão continuar aparecendo, então é só ficar de olho. Se curtiram a idéia deixem um joinha, mandem suas dúvidas nos comentários abaixo, não deixem de assinar o canal, e compartilhar o video com todo mundo que vocês acham que se encaixa no que eu falei. A gente se vê, até mais.

DESCRIÇÃO

Toda hora alguém me pergunta “quais livros eu devo ler?” Normalmente eu não respondo, mas hoje resolvi fazer uma primeira lista de livros e temas que eu acho relevantes pra maioria dos programadores. Não é uma lista completa mas eu quero aproveitar pra tocar num tema que você eventualmente vai precisar entender: profissionalismo na área de programação e principalmente entender o que é “Design Emergente” em software.

Meio que é uma continuação ao que eu disse no meu video sobre “Empreendendo em Software do Jeito Errado” quando eu disse que não dá pra especificar todo um software antes de codificar e hoje vou começar a explicar porque.

Conteúdo

• 00:00 - Intro
• 01:47 - Introduction to Algorithms
• 04:31 - The Art of Computer Programming
• 08:57 - Compilers
• 11:32 - The Design and Evolution of C++
• 12:56 - Object Oriented Analysis and Design
• 14:43 - The Unified Software Development Process
• 18:21 - UML Distilled
• 19:05 - Refactoring
• 19:33 - Agile
• 23:49 - Extreme Programming Explained
• 27:32 - Clean Code
• 28:24 - The Clean Coder
• 28:54 - The Pragmatic Programmer
• 30:33 - Design Patterns
• 33:02 - Patterns of Enterprise Application Patterns
• 33:36 - Domain Driven Design
• 35:10 - The Lean Startup
• 36:59 - The Mythical Man-Month

SCRIPT

Olá pessoal, Fabio Akita

Desde que abri o canal, uma das perguntas mais frequentes, tipo que eu recebo no mínimo uma vez por semana é sobre quais cursos eu recomendo pra quem tá começando. E como eu já disse em vários videos: eu não recomendo nenhum, e na prática tanto faz qual. Nenhum curso vai ser completo, eles servem só pra ter dar um empurrão, mas nunca vão te ensinar tudo de qualquer assunto. A segunda pergunta que mais recebo complementa a primeira que é quais livros eu recomendo.

Muito do que você não vai aprender via cursos ou tutoriais está em livros. E não ache que dá pra pegar essa lista e sair lendo tudo de uma vez. Boa parte deles você vai lendo aos poucos ao longo dos seus primeiros 10 anos de carreira, porque você ainda não tem nem o conhecimento e nem a experiência pra entender de fato o que estão tentando te dizer.

Hoje vou listar alguns livros que eu pessoalmente acho importantes. Não é uma lista nem completa e nem definitiva, são livros que eu fui usando ao longo dos anos e que acho que podem te ajudar. E vou apresentar mais ou menos na ordem que conheci eles, cronologicamente, porque faz diferença quando eles foram lançados e em qual contexto. Prestem atenção ao contexto que vou falar mais do que na lista em si.

(…)

Vamos lá. Nenhum livro é obrigatório. Então não saiam por aí dizendo pros outros que o Akita falou então é pra ler. Os livros que vou falar hoje eu não li tudo de uma vez só, muitos nem li inteiro, e vim acumulando ao longo dos primeiros 10 a 15 anos da minha carreira, durante e depois da faculdade.

Ninguém vai conseguir ler e principalmente entender esses livros numa só leitura. Isso não é literatura, são livros de aprendizado e referência. Alguns temas dentro desses livros você só vai entender de verdade depois que passar por projetos reais e só daí vai vir o “ahhhh, era isso que o livro queria dizer”, aquele momento “ahá”.

Isso dito, se você assiste meu canal já deve imaginar que minha primeira recomendação é o livro do Cormen de Introdução a Algoritmos. Eu tenho esta terceira edição, não sei se tem mais novo, mas não importa. O maior problema de começar estudando e usando frameworks e bibliotecas pré-prontas é que elas evitam que você precise saber como são feitos, porque já vem tudo pré-pronto e escondido pra só usar.

Eu falei disso em videos anteriores e até mostrei, mas se usa uma lista ou collection em Javascript, você não tem idéia se por baixo tá implementado uma lista ligada, ou uma árvore Red Black ou o que. Você só adiciona elementos, remove elementos, manda ordenar e pára por aí. E isso vale pra qualquer outra coisa funcionalidade. Você usa uma biblioteca de caching do seu framework favorito, mas como é implementado? É uma fila simples? É uma fila circular? É uma árvore B-Tree? Que tipo de hashing ele usa? Pra você tanto faz, você só empilha e desempilha elementos e deixa o framework cuidar de tudo pra você.

Então toda vez que usa listas, manipula strings, usa threads ou fibers, caching e tudo mais, só confia que o framework sabe o que tá fazendo e não se preocupa. E isso é ok pra 80% dos casos, por isso que muito iniciante consegue ir até longe em alguns projetos sem nunca ter lido um único livro sobre algoritmos e estruturas de dados. Esse é o nível de um junior. Porém um sênior precisa lidar com problemas diferentes.

Otimização de performance, otimização de carga, reorganização e refatoração do código pra ser ao mesmo tempo mais fácil de dar manutenção e também mais performático, diminuir tempo de latência, diminuir uso de memória por requisição, resolver conflitos de versões de bibliotecas externas, fechar buracos de segurança e mais. E pra isso, você precisa saber como essas bibliotecas e frameworks funcionam por baixo, e pra isso, precisa da fundação, que começa em algoritmos e estruturas de dados.

Um livro como do Cormen não é completo. Ele fala de bastante coisa que você deveria saber, mas nenhum livro nunca vai ter tudo. E antes que vocês perguntem nos comentários ou fiquem me mandando DMs, não, não precisa ser o livro do Cormen. Eu mesmo não usei ele na faculdade. Eu aprendi o básico com um muito mais simples, este do Niklaus Wirth. Olha como é menor.

Diferente do Cormen, o livro do Wirth sequer entra no assunto de grafos, por exemplo. Além disso o Wirth escreveu o livro dele em 1986, já o Cormen e seus co-autores escreveram o deles em 2009. Por isso, no livro mais novo tem assuntos mais modernos, como multithreading, que ainda era um assunto que engatinhava nos anos 80.

Se você acha que precisa ter o livro mais completo de todos, ele não existe mas o mais próximo não é um livro, mas uma coleção de livros, do lendário Donald Knuth, o famoso The Art of Computer Programming, o magnum opus da ciência da computação que ele começou a escrever em 1962 e até hoje não terminou. Eu já falei dele em outro video mas os livros que eu tenho são do 1 ao 3 mais o 4A. Segundo a Wikipedia ele tá escrevendo os fascículos 5 e 6 que são os primeiros dois terços do volume 4B.

E quanto ainda falta pra acabar? Bom, depois do 4B ainda vai ter os volumes 4C e 4D e depois os volumes 5, 6 e 7. Ou seja, o que eu tenho aqui ainda não é nem metade do que seria a obra completa. Essa coleção é o Game of Thrones da computação, e o Knuth é o George R R Martin da nossa área. Todos cruzando os dedos pra ele conseguir terminar tudo. Os livros do Wirth e do Cormen eu diria que são um resumão do que seria os livros de 1 a 4D do Knuth.

Ou seja, os temas dos primeiros 7 volumes do Knuth, que incluem os volumes 4B a 4D que ele ainda não escreveu são o que você encontra no sillabus dos primeiros anos de um curso de ciência da computação. Começa com coisas como matemática básica, números, potências, logaritmos, teoria dos números, permutações, fatoriais, coeficientes binomiais, ou seja, não só o assunto de algoritmos mas temas de matemática que você aprende nos primeiros 2 anos de ciências da computação em matérias como Álgebra, Estatística e probabilidade.

No primeiro volume do Knuth você tem coisas básicas como pilhas, filas, listas ligadas, listas circulares, arrays, árvores binárias, que foram assuntos que eu detalhei alguns videos atrás. Por isso o primeiro volume se chama Algoritmos Fundamentais. Já o segundo volume complica um pouco mais. Ele se chama Algoritmos Seminuméricos e logo de cara o primeiro assunto no livro é definir números aleatórios.

Fazendo uma tangente, números aleatórios gerados por computador não são puramente aleatórios, são pseudo-aleatórios. Em qualquer linguagem moderna de programação você só usa uma função como Random e esquece, mas nesse livro você pode estudar como isso funciona. E nos capítulos seguintes ele vai discorrer sobre sistemas posicionais de números como aritmética de ponto flutuante, que foi outro assunto que já expliquei alguns videos atrás. E continua em assuntos como aritmética racional, aritmética polinomial.

E sim, essa coleção inteira é bem pesada em notação matemática. Se você não tá acostumado é absolutamente intimidador. Entendida toda a base matemática fundamental, só no volume 3, que é chamado de Ordenação e Procuram, é que vamos finalmente encontrar os algoritmos de ordenação como inserção, seleção e procura com temas como pesquisa binária e árvores balanceadas que eu também já mostrei alguns videos atrás.

Finalmente chegamos ao volume 4A que é chamado de Algoritmos de Combinatória Parte 1 que explica o básico de álgebra booleana, truques e técnicas de operações bitwise, diagramas de decisão binária e geração de todas as possibilidades onde entramos no assunto de n-tuplas, permutações, combinações, partições, conjuntos e muito mais. E isso é parte 1 porque o tema de Algoritmos de Combinatória vai se esticar nos próximos volumes ainda não escritos, do 4B ao 4D.

Só esses 4 volumes somam quase 3 mil páginas. Pra colocar em perspectiva, o livro do Cormen é menos da metade disso. Mas se prestou atenção vai notar que os livros do Knuth cobrem mais assuntos, em particular a base matemática. Livros mais focados só em algoritmos e estruturas de dados, como do Cormen, se preocupam menos com as provas matemáticas e mais em como cada elemento é implementado e funciona. Eu diria que é mais prático pra gente. Você só vai realmente ler página a página do Knuth se for se especializar em matemática aplicada ou algo assim.

Mas pra assuntos específicos, vale como referência se quiser descer a fundo. Por exemplo, como realmente números aleatórios são matematicamente definidos? Eu repito, a grande maioria de nós não tem o vocabulário de matemática teórica suficiente pra realmente conseguir absorver tudo do Knuth, por isso qualquer coisa perto do livro do Cormen é mais prático. Mesmo o Cormen é um pouco pesado em matemática, então qualquer livro de algoritmos e estruturas de dados é suficiente.

Mas e os livros de 5 a 7 que o Knuth ainda não escreveu? Os títulos parecem que vão ser Algoritmos Sintáticos, teoria de linguagens livres de contexto e técnicas de compiladores. Linguagens livres de contexto você vai cair no trabalho mais importante do Noam Chomsky - e na minha opinião, a única coisa que você precisa ler dele. Enfim, na realidade já existem livros que cobrem esses assuntos. Se você fez ciência da computação já sabe. Essa é minha segunda recomendação: o famoso livro do dragão, o Compiladores - Princípios, Técnicas e Ferramentas, do Aho, Ullman e outros, publicado em 1986.

Eu já falei em outros episódios sobre compiladores como GCC, e principalmente sobre uma das tecnologias mais importantes deste século: o LLVM, que se você pelo menos acompanha artigos técnicos, já ouviu falar diversas vezes. Eu explico sobre LLVM no episódio sobre a Apple e recomendo que assistam pra entender o contexto, mas é graças a LLVM que você tem linguagens como Swift, Rust, Crystal, Julia, linguagens de shaders pra GPU e muito mais. E pra entender LLVM você precisa entender compiladores e realmente como linguagens de programação são criadas.

Na prática, a menos que você pretenda criar sua própria linguagem do zero, não precisa saber o livro do Dragão de cabo a rabo. É mais pra entender os principais conceitos. Esse livro vai te explicar o que é análise léxica e ferramentas como Lex e você mesmo vai descobrir outras como o GNU Flex depois. Daí vai pular pra análise sintática e ferramentas como o Yacc e outros como o GNU Bison. O livro usa os antigos Lex e Yacc, na minha época da faculdade no meio dos anos 90 era Flex e Bison, mas hoje em dia existem ferramentas mais modernas.

Isso é só pra desenhar a linguagem e criar um parser, mas a partir daí tem que fazer a geração do código binário propriamente dito que passa por um código intermediário, otimizações independentes de máquina, paralelismo em nível de instrução, localidade, análise interprocedural. Se você me perguntar se eu ainda sei essas coisas, não, não lembro nem uma fração mais hoje. Mas os conceitos que guardei me ajudam a avaliar toda vez que uma nova linguagem aparece, eu consigo entender como funciona, o que procurar na linguagem, no compilador, no código final gerado e tudo mais.

Compiladores é um tema que você não deveria tentar aprender tudo de uma só vez. Compensa até começar com algum livro mais simples, curso online ou até um tutorial com ferramentas de mais alto nível que te permitem criar linguagens simples que não necessariamente vão ser performáticas, mas vão ajudar a “molhar os dedos” no assunto antes de aprofundar nos detalhes que tem no livro do dragão.

De qualquer forma, só faz sentido ter a ambição de escrever a própria linguagem se você estudou um pouco mais a fundo sobre linguagens. E não só “ah, eu gosto de parênteses” ou “ah, eu prefiro não ter ponto e vírgula no fim das linhas”. Design de linguagem é muito mais que isso. Um livro que talvez ajude a entender as features de uma linguagem é o The Design and Evolution of C++, do Bjarne Stroustrup que é o pai do C++.

Ele conta um pouco a história de como o Stroustrup se inspirou em C with Classes pra chegar ao C++ e justifica as funcionalidades que criou em cima disso como o gerenciamento de memória, herança múltipla, casting, templates, exceptions, namespaces e tudo mais que forma a base do C++ e depois serviu de inspiração pra implementar muitas das linguagens modernas que você usa como um Java ou C#.

Entender o pulo do C pro C++ pela visão do autor é interessante e também as primeiras interpretações sobre o que é orientação a objetos. C++ é uma linguagem que eu mesmo nunca usei muito profissionalmente, então eu mesmo sou amador, mas acho fascinante entender como se encaixa na história das linguagens de programação. Ela ainda é uma das linguagens mais usadas pra código de sistemas, tudo de mais importante que você usa é escrito com C e C++, seu Javascript é escrito em C++. E isso não vai mudar por um bom tempo ainda.

Daí pulamos um pouco do tema de ciências da computação e vamos um pouco pra engenharia de software. Eu já expliquei a diferença em outro video, mas aproveitando o gancho da orientação a objetos do C++ vale pelo menos mencionar outro livro, o Object Oriented Analysis and Design with Applications do Booch e outros autores.

Orientação a objetos é um tema super longo, bem mais complexo do que você aprende na faculdade e eu não vou detalhar tudo hoje. Dependendo da era que estudar você vai ter interpretações diferentes de muitos conceitos, mas o que muita gente chama de orientação a objetos deriva do vocabulário criado pelo Grady Booch, Ivar Jacobson e Jim Rumbaugh. Cada um deles tinha uma versão de definição de orientação a objetos e eles se juntaram pra compilar seus trabalhos numa obra só. O que se publicou dos anos 90 em diante deriva disso.

Esse livro em particular não é a obra definitiva nem nada disso, mas eu acho interessante que ele tenta justamente definir muito desse vocabulário, definir o que exatamente é uma classe, o que é um objeto, qual é a notação que se deveria usar pra comunicar um modelo de objetos. Algumas partes, em particular a seção 3 do livro que pode estar um pouco defasado porque ele tenta explicar esses conceitos usando exemplos de cinco aplicações que vão de um sistema de navegação de satélite até um sistema de rastreio de férias via web, definido com essa notação de objetos.

Eu digo defasado porque a forma como desenvolvemos aplicações e até a forma como modelamos classes e objetos mudou daquela época até hoje então alguma coisa ficou obsoleta mesmo, não tem jeito, mas muitos dos conceitos ainda valem hoje e principalmente o raciocínio e história por trás de porque eles definiram as coisas daquele jeito. Esse livro em particular vale mais pra capturar um momento da história do que pra ensinar todas as técnicas que você precisa saber.

Esse livro, na real, é opcional e complementar a outro livro mais conhecido que é o The Unified Software Development Process escrito pelos mesmos Los 3 Hermanos, o Jacobson, Booch e Rumbaugh. Ele define a famosa e famigerada notação UML mas, mais importante, define o processo de desenvolvimento de software conhecido como Unified Process ou até hoje o que você conhece como Rational Unified Process ou RUP.

Lembrando, esses livros foram escritos antes de 2001, nos anos 90, portanto antes do Manifesto Ágil, antes de cloud computing, antes de smartphones, antes ainda da primeira bolha da internet, literalmente na infância da Web. Então tudo que você conhece como formas modernas de desenvolvimento de software, que só nasceram nos últimos 20 anos, ainda não existiam nessa época. Mesmo assim, eu ainda acho que vale a pena ler o começo desse livro, porque muitos dos conceitos de engenharia de software que você usa são derivados dessa época.

Em particular, eu já falei em outros episódios que pra mim um bom exemplo de linguagem orientada a objetos, por incrível que pareça é o Erlang, em particular o Elixir. Muita gente pensa em Elixir como uma linguagem funcional, mas pra mim é o contrário. Ele é primeiro uma linguagem orientada a objetos que por acaso tem aspectos funcionais. Eu argumentaria que Elixir e Erlang são mais orientados a objetos do que Java, que muita gente ainda pensa como a referência em objetos. Se você não entendeu isso, ainda precisa estudar mais.

Um dos argumentos sobre Erlang é que logo no prefácio desse livro, eles contam sobre o case da Ericsson, que é a inspiração do Unified Process. Se você não sabe, o “ER” de Erlang é de Ericsson. Os autores argumentam que o sistema de telecomunicações deles era tão bom porque modelaram o sistema inteiro como um conjunto de blocos interconectados, o que em UML se chamaria de componentes ou sub-sistemas. E eles foram montando blocos de baixo nível e subindo pra sub-sistemas de alto nível pra tornar o sistema mais fácil de gerenciar e foram encontrando esses blocos trabalhando pelos casos de tráfego anteriores - o que hoje se chamaria em UML de “casos de uso”.

O caso da Ericsson é relevante pro assunto de orientação a objetos porque quem trabalhou lá foi justamente um dos co-autores desse livro, o Jacobson, que saiu em 1987 e fundou a empresa Objectory e nos anos seguintes ele e alguns colaboradores desenvolveram um processo chamado Objectory também pra servir pra mais casos além de telecomunicações, e foi aí que coisas como “casos de uso” ganharam esse nome.

Alguns anos depois, em 1995 a empresa Rational Software Corporation comprou a Objectory e eles trabalharam em juntar os dois processos que tinham e chegaram primeiro no Rational Objectory Process. Depois disso que o Booch, Rumbaugh e Jacobson colaboraram pra criar o Unified Modeling Language, o UML, pra ter uma linguagem visual pra comunicar as idéias sobre objetos e finalmente chegaram no Unified Process ou Rational Unified Process, que é o RUP, que muitos que fizeram engenharia de software devem ter estudado.

Em 2021 raramente você vai ver alguma empresa usando fortemente UML e RUP em projetos. Pelo menos eu espero que não. Talvez em empresas antiquadas e altamente burocráticas, mas em tech startups é bem raro encontrar. Mas muito do vocabulário e notações que usamos até em rascunhos numa lousa são derivados do UML. Muito da engenharia de software moderna ainda usa os nomes originais, como “casos de uso” por exemplo, ou diagrama de componentes. O que eles chamavam de sub-sistemas você poderia chamar hoje de micro-serviços e assim vai.

Se quiser aprender esse vocabulário sem perder muito tempo no detalhamento do processo em si, que ninguém mais usa como antigamente, você pode pular direto pra outro livro bem menor, de menos de 200 páginas, chamado UML Distilled do Martin Fowler, que é basicamente um resumão de UML e RUP. Ele tem só o que o Fowler acha que é mais relevante alguém saber, é quase um cheat sheet sobre UML.

Levou alguns anos, até demais na minha opinião, pras pessoas entenderem que seguir algo como um RUP ao pé da letra era absolutamente burocrático e improdutivo. A gente tava mais preocupado em rastrear, gerenciar e aprovar artefatos, como diagramas, do que com o código em si. É uma das grandes críticas em relação ao campo da orientação a objetos em geral.

Falando em Martin Fowler, ele foi um dos escritores mais prolixos e influentes do fim dos anos 90 até pelo menos o meio dos anos 2000 e um dos seus livros mais importantes parece uma reação contra o que um RUP representa. Esse livro obviamente é o Refactoring, publicado em 1999. E hoje em dia todo mundo fala em refatorar, refatorar, mas quantos de vocês conseguem definir o que é refatorar? Qual a diferença entre refatorar e reescrever?

Nas palavras do próprio Fowler, refatorar é o processo de mudar um software de tal maneira que isso não altere o comportamento externo do código e mesmo assim melhore a estrutura interna. É uma forma “disciplinada” de limpar código que minimiza as chances de introduzir bugs. Em essência, quando você refatora, está melhorando o design do código depois que ele foi escrito. Muita gente falando “refatoração” na verdade está querendo dizer “reescrever”, que não é um processo disciplinado de melhoria sem mudar comportamento, é literalmente jogar fora e escrever de novo de outro jeito, com outro comportamento, e não garante nenhuma melhoria.

E não é à toa que o Martin, junto com outros autores como Kent Beck, são signatários do Manifesto Ágil. Em metodologias antigas de engenharia de software, onde o RUP se inclui, a ideia principal é primeiro criar o design inteiro do software, por exemplo desenhando com diagramas com UML. E só depois que o design estiver perfeito que se começa a escrever o código. Ou até mesmo daria pra gerar automaticamente esse código a partir dos diagramas. Eles consideram design e codificação como duas etapas separadas. Mesmo tendo coisas como iteração no processo, as etapas em si ainda são conceitualmente separadas. Muitas empresas tentaram criar ferramentas que partiam dos diagramas de classes e tudo mais de UML e geravam código em Java da vida.

Essa ideia nunca funcionou direito e a gente foi entendendo melhor porque depois da virada do século, depois que começamos a ideia de agilidade. A premissa errada é achar que é possível criar um design perfeito em papel primeiro e depois o código seria só um reflexo direto desse design. Na realidade o código “é” o design e ele nunca vai estar perfeito, muito menos na primeira vez. Daí vem a ideia de fazer o primeiro código que funciona primeiro, que provavelmente vai ser um código ruim, e só depois, disciplinadamente, refatorar esse código até termos uma estrutura que seja livre de bugs e de mais fácil manutenção.

Aliás, vale aproveitar pra dizer que muita gente pensa que primeiro nasceu o Manifesto Ágil em 2001 e só depois começamos a entender o que são técnicas ágeis, mas é o contrário. Primeiro os signatários do manifesto passaram anos praticando, formulando as técnicas e documentando, durante os anos 80 e 90 principalmente, e só depois que isso deu origem ao Manifesto. Essa ordem é importante, porque o Manifesto é só um resuminho de 20 anos de experiência de cada um deles que veio antes.

Na indústria mais tradicional, por décadas sempre se tentou o conceito de design primeiro e código depois. Lá atrás a gente desenhava software com fluxogramas em linguagens procedurais, por exemplo. E isso fazia sentido porque debugar software depois era custoso, difícil, tedioso. As linguagens antigas eram fortran, cobol, algol, Ada ou C. Nenhum programador nos anos 70 e antes tinha um notebook multi-core com gigabytes de RAM. Não, eles tinham que compartilhar um único computador grande com vários outros engenheiros e programar a partir de terminais remotos.

Esses terminais eram lentos, ninguém tinha um VS Code ou Sublime Text da vida. O editor VI original foi criado justamente pra ser super otimizado pra desenhar o mínimo possível na tela e permitir navegar no código com o mínimo de comandos. Porque cada comando navegava numa rede lenta até um computador compartilhado lento que tinha no máximo kilobytes de RAM. Portanto, você gostaria que o código funcionasse de primeira, não era produtivo ficar debugando e “refatorando” o código depois.

O que aconteceu nos anos 90 até os 2000 é que microcomputadores apareceram e ficaram consideravelmente potentes, internet e rede mais veloz apareceu, e agora era factível você rodar um sistema inteiro no seu computador pessoal antes de rodar no servidor da empresa. Fazer o design antecipadamente era crucial nas décadas de 60 a 80, mas depois disso a tecnologia avançou o suficiente pra gente conseguir fazer código ruim primeiro e refatorar depois pra ter código bom, então o design e o código passaram a ser um processo orgânico de melhoria contínua. Isso é uma interpretação minha, mas eu diria que “Agile” marca quando separávamos design e código em etapas distintas pra serem unidos em design emergente.

Falando em processos ágeis, se tiver só um livro que você queira ler, que seja o Extreme Programming Explained, do Kent Beck, também de 1999. Veja que em 1999 e 2000 que começou a aparecer mais livros sobre esse novo jeito de programar que vinha sendo praticado fazia mais de 10 anos, que culminaria com o manifesto ágil em 2001 e muito do que você considera técnicas de engenharia de software modernas como pair programming, test driven development, continuous integration, refactoring, small releases, nascem nele.

Engenharia de software é um campo em constante mudança. Dependendo de que ano é a literatura que você está estudando, vai cair nos RUP da vida ou vai cair em derivados de Extreme Programming. A ideia não é dizer que os conceitos dos anos 90 estavam errados. Eles faziam sentido pras circunstâncias da época e vale a pena entender porque.

Vocês podem ver que alguns livros e temas envelhecem melhor que outros. Uma coisa que me ocorreu gravando esse video é que se você prestou atenção, note que livros de ciência da computação tendem a envelhecer melhor que livros de engenharia de software. Livros de ciência da computação de 30 anos atrás ainda se aproveitam hoje, mas livros de engenharia de software de 30 anos atrás, estão obsoletos.

Até hoje ainda não temos “o” melhor jeito de escrever software, estamos constantemente mudando os processos de como transformar idéias em código. Mas as peças fundamentais que usamos pra construir essas idéias ainda continuam válidas. Na ciência da computação o conhecimento meio que vai se estendendo mas não jogando muita coisa fora pelo caminho.

Uma parte disso é porque as teorias matemáticas que embasam coisas como algoritmos, uma vez provadas, variam muito pouco na implementação. É o trabalho de caras como Knuth. Uma árvore balanceada, seja feita em C ou seja em Kotlin, continua sendo uma árvore balanceada. Linguagens diferentes mas as características continuam as mesmas. É um dos motivos de porque linguagens funcionais ganharam algum destaque nos últimos anos. Muitos tentam trazer esse rigor matemático, como de lambda calculus, pros processos de como escrever código. Mas escrever código não é uma ciência exata, é um processo aberto à interpretação.

O problema é que código não é só rápido, ou seguro. Em engenharia a gente tenta buscar várias características como mantenabilidade, flexibilidade, portabilidade, reusabilidade, legibilidade, testabilidade, segurança e assim por diante. Você pode escrever o código mais seguro possível, mas vai prejudicar a flexibilidade e reusabilidade, e assim por diante. O desafio de um programador é balancear essas características, e isso é difícil porque depende de quais problemas você precisa realmente resolver com esse código. E pior, os requerimentos desse código mudam conforme o software é usado.

Num primeiro momento a prioridade pode ser eficiência, mas depois de um tempo a prioridade passa a ser segurança, depois passa a ser mantenabilidade. Então o código precisa ser modificado ao longo do tempo, o design desse código vai mudando conforme as necessidades vão mudando. Por isso, nenhum código está 100% pronto e congelado pra sempre. E repetindo, por isso é quase impossível fazer um design perfeito antes do código.

Muito amador ainda acha que código, se rodar, tá ótimo, não importa se tá sujo, com nomenclaturas toscas, com alta complexidade. “Ah, roda, então foda-se”. Código que roda, mas é sujo, com baixa mantenabilidade, é lixo, pode jogar fora. Não adianta nada rodar se amanhã você precisar estender, consertar, reusar. Daí mais atrapalha que ajuda. É lixo. Não basta rodar, precisa estar limpo o suficiente pra quando outro programador for reusar, não vai sofrer.

Se você quiser um livro mais estruturado com a melhor forma de escrever código e como se comportar como um bom profissional, o melhor livro pra começar é de outro agilista, o controverso Robert Martin, vulgo Uncle Bob. Ele é outro escritor prolixo e seu livro mais conhecido é sem dúvida o Clean Code, ou Código Limpo. E o conteúdo é parecido com o Code Complete do McConnell mas bem mais atual.

Ele toca em coisas tipo, como criar nomes de variáveis, funções que sejam fáceis de entender. E segue falando de todas as boas práticas que deveriam ser óbvios pra todo profissional: escrever funções com corpo curto, código bem formatado e legível, como escrever código que lida com exceções, como criar fronteiras claras entre diferentes módulos, como fazer testes unitários, um pouco sobre organização de classes em linguagens orientadas a objetos, noções de design emergente, ou seja, design que emerge à medida que você escreve código, testa e refatora.

Eu diria que se você quer ser um bom profissional, no mínimo tem que escrever código limpo como o Bob Martin ensina E falando em profissionalismo, um livro mais recente dele que lida com temas mais sobre como trabalhar em equipe, como gerenciar tempo, como fazer estimativas e coisas assim é o Clean Coder, ou Programador Limpo. Esse eu mesmo não cheguei a ler, mas pelo pouco que vi, acho que pode ser útil pra quem tá começando na profissão e ainda não sabe exatamente quais são suas responsabilidades perante seus colegas e projetos.

Outro livro com tema similar é um grande clássico que fez 20 anos recentemente, escrito por outros dois agilistas, Dave Thomas e Andy Hunt, o famoso The Pragmatic Programmer. Se o Clean Code e o Clean Coder do Bob Martin são meio que um manifesto do profissional de código, o The Pragmatic Programmer é uma mistura dos dois e tenta explicar a filosofia de um programador pragmático. Eles discorrem sobre como lidar com resolução de problemas de software, tocam em assuntos de agilidade de novo como testes, como escrever código limpo.

Se você assistiu meu episódio intitulado Esqueça Metodologias Ágeis, já sabe que estamos numa era pós-Agile. Os conceitos e técnicas originais de agilidade são simples, mas diversas empresas e consultorias sequestraram o termo “ágil” e inventaram um monte de metodologias e ferramentas burocráticas que nos levaram de volta à época do RUP e UML.

Se você quer saber o que é realmente ser Ágil, deve ler os autores originais e não trabalhos derivados. Em particular Martin Fowler, Kent Beck, Bob Martin, Dave Thomas e Andy Hunt, que são todos os livros que eu recomendei até agora. Leia os livros deles e você vai estar meio caminho andado pra conseguir distinguir ágil de verdade das bullshitagens de coach de consultoria ágil por aí.

Muitos já me pediram pra falar sobre alguns desses temas, como testes. Ainda não sei se vou fazer um video disso porque é um tema tão bem documentado já que você só não aprende se fizer esforço pra ignorar. E repetindo: leia sobre assuntos de agilidade a partir dos autores originais. Quer saber sobre testes? Comece com Kent Beck e seus livros de Extreme Programming, não tem que inventar moda.

Tem três outros livros que vale mencionar. Uma coisa que vocês só vão realmente entender lendo e escrevendo muito código de verdade é sobre a diferença entre design e código e como design emerge a partir do código e de seu uso, como eu já disse. Num primeiro momento, se está começando os estudos, não pense que vai conseguir pré-planejar todos os aspectos de um software antes de escrever uma linha de código. Não vai. E os próximos livros podem confundir vocês nisso.

O primeiro é o clássico Design Patterns, escrito pelo Erich Gamma e sua gangue dos quatro. No tema de achar que dá pra planejar em detalhes antes de codificar, esse é o primeiro livro mal interpretado. Cansei de ver amador com esse livro embaixo do braço querendo pagar de arquiteto e falando bullshitagens como “vamos fazer esse módulo usando alguns decorators pra montar um adapter que vai sair de um factory que vai ser um singleton derivado de um command de um chain of responsability suportado por um observer”. Bleh.

Eu já expliquei isso no fim do meu video sobre como aprendi inglês, mas vou repetir. A tradução do título desse livro em português é “Padrões de Design”. Dá a impressão que esse livro tem todos os padrões, no sentido de as melhores peças, ou as peças definitivas, pra se fazer design de software. O problema é que a palavra “padrão” em português pode ser traduzida em 3 palavras diferentes em inglês, standard, default ou pattern.

Muita gente pensa que “padrão” é o standard. E standard é como você pensou mesmo: um padrão oficial, uma definição definitiva sobre alguma coisa. Mas estamos falando de “pattern”, e pattern é só alguma coisa que se repete muito, independente se é boa ou ruim e definitivamente não é o “padrão definitivo”. O livro de Design Patterns é um catálogo de patterns, de repetições que os autores viram muito em diversos projetos, e simplesmente deram um nome pra eles. Só isso, nada mais, nada menos.

Esse livro foi publicado em 1994, um ano antes de entrar na faculdade. E eu só fui conhecer ele alguns anos depois, lá por 1998. Nesse momento eu já tava programando faz alguns anos e quando vi o livro, em inglês, foi exatamente o que pensei. “Oras, o livro só dá nome pra coisa que já vi várias vezes”. Por exemplo, quem mexia com emuladores naturalmente reconhecia o Design Pattern Adapter. Toda vez que troco a biblioteca opengl do game por um directx é meio que um Adapter.

Design Patterns é um catálogo, e não um manual de como fazer design. Se você já programou tempo suficiente, só vai descobrir que alguns trechos de código que já viu várias vezes por acaso tem nomes, como Singletons, ou Visitors. Esse livro é útil somente pra nos dar um vocabulário comum pra ficar mais fácil pra dois programadores comunicarem um conceito com um nome comum. E ele nem é o catálogo mais completo, existem diversos outros patterns que não estão nesse livro. Vide livros como Patterns of Enterprise Applications Architecture do próprio Martin Fowler.

Falando em arquitetura, outro livro que alguns podem usar errado pensando que é um manual de instruções é o Domain Driven Design do Eric Evans, publicado em 2003. Nas palavras do Martin Fowler, esse livro descreve uma forma de desenvolvimento de software centrado num modelo de domínio que tem um entendimento rico dos processos e regras desse domínio. Em resumo bem resumido, é mais um livro que orienta em como dar nome pras coisas e como organizar essas coisas.

Assim como Design Patterns, ele nos dá novos vocabulários pra descrever sistemas como Ubiquitous Language, Aggregates, Bounded Contexts e outras classificações, mas enxergando mais o big picture de um sistema em vez de só pequenos componentes. Bounded Contexts em particular é interessante porque descreve um pattern que aparece em muitos sistemas.

Por exemplo, imagine que você tem um sub-sistema que tem contexto de Vendas e outro sub-sistema com contexto de Suporte. No de vendas você tem entidades como Vendedor, Oportunidade. No de suporte tem entidades como ticket, defeitos. Mas no bound, na fronteira entre os dois sub-sistemas ele compartilham entidades como o usuário ou o produto.

Começa a ficar difícil de lidar com sistemas que crescem se num sub-sistema você chama usuário de cliente e no outro sub-sistema você chama de comprador, por exemplo. Parte da idéia de DDD é criar um linguagem ubíquita, comum entre desenvolvedores e usuários. Enfim, como eu disse antes, ele se preocupa muito com a arte de dar bons nomes pras coisas. Não é à toa que a gente brinca que uma das coisas mais difíceis da computação é dar nomes pras coisas.

O terceiro e último livro, por incrível que pareça acho que é a cola que une todos os livros de engenharia que falei até aqui. É o famigerado The Lean Startup, do Eric Ries, publicado em 2011. Foi exatamente quando começou a atual bolha de tech startups e esse livro apareceu na hora certa pra se tornar meio que a bíblia das novas tech startups. É um livro meio que de empreendedorismo, é superficial, e por causa disso muita gente interpreta do jeito errado. Próxima pessoa que falar que “validou” a idéia fazendo pesquisa com uma dúzia de pessoas, eu juro que eu chuto.

De qualquer forma, ele fala algumas coisas que são relevantes pra engenharia de software. Você pode estudar orientação a objetos, processos de desenvolvimento de software, metodologias ágeis, como fazer código limpo, como modelar sistemas com DDD, mas se você não entende o mínimo de negócios, seu software sempre vai ser ruim. Porque o melhor software é aquele que resolve problemas do mundo real, e não do mundo teórico.

Um conceito importante que o The Lean Startup ajudou a popularizar foi o de Minimum Viable Product ou MVP, ou simplesmente Protótipo. A ideia ultrapassada, vinda de processos monumentais como RUP da vida, é de tentar fazer o design do melhor software possível, o mais complicado, com mais opções, com maior número de funcionalidades possíveis. Eu não sei se alguém aqui já passou por isso, mas eu já tive que avaliar calhamaços, literalmente pilhas de quinhentas páginas de especificações e diagramas de UML.

Nunca vi um design assim no papel que desse pra traduzir em software, sempre tinha um monte de buracos pelo caminho. É impossível desenhar 100% de um software antes de construir, é sempre mais prático começar com um design mínimo, construir, aprender com os erros e ir estendendo e refatorando, ou seja, fazendo o design emergir do software.

Casos que já vi várias vezes, seja a partir de um software legado já existente ou um MVP, povo sempre fica com a ideia de “agora sim, eu já sei como que o design de verdade deveria ser” e aí segue tentando desenhar a versão 2.0 “perfeita”, e cai na armadilha do “Segundo Sistema” que nosso amigo Fred Brooks já avisou no livro The Mythical Man-Month, que eu já fiz um video inteiro a respeito meses atrás. Dêem uma olhada.

É muito difícil fazer uma lista com TODOS os livros que eu acho que todo mundo deveria ler. Acho que uma lista assim seria impossível. Dependendo da sua escolha de carreira ou mesmo dos seus gostos, alguns são mais interessantes que outros. Essa lista é a que pessoalmente acho que é relevante, embora incompleta, pra maioria. Minha recomendação é sempre ir atrás dos autores originais de um determinado tema, autores que têm mais de décadas de experiência em projetos reconhecidos. Evitar ao máximo derivativos que costumam simplificar demais ou até alterar o que o original dizia.

Mas como eu disse antes, em particular livros de engenharia de software tendem a envelhecer mais rápido do que livros técnicos de ciências da computação. Mas ambos os temas são importantes pra qualquer programador. De qualquer forma, se ficaram com dúvidas mande nos comentários abaixo, se curtiram o video deixem um joinha, não deixem de assinar o canal e compartilhar com seus amigos. A gente se vê, até mais!

06:52 - o que vem depois hello world 09:50 - Apple GPL

DESCRIÇÃO

Esta é a edição da palestra que dei no evento #DoWhile da Rocketseat no dia 15/12/2020. Ela serve como um resumo de vários assuntos importantes do canal então aproveito pra deixar como introdução pra quem está chegando agora. Durante o vídeo vou mostrando as thumbnails dos diversos videos onde entro em detalhes sobre cada assunto.

E sendo o 1o vídeo do ano, deixo meu FELIZ 2021!! 🥳🎊🎉

ERRATA: no tweet do cara investindo e calculando juros errados, dependendo de como interpretar o texto dele (e aqui fica pior, porque além de tudo ele tem dificuldade de explicar) fica ainda pior a matemática. Se considerar que ele achou que dividindo o dinheiro dele, digamos 70 mil reais, em 7 fundos, colocando 10 mil em cada, e cada um a 0.5%, não vai ser 7 x 0.5% obviamente e sim um total de … 0.5% porque isso é juros simples. Eu ainda superestimei ele levando pra juros compostos. Enfim, esse tweet é um completo desastre não importa como você interprete.

SCRIPT

Olá pessoal, Fabio Akita

Agradecimentos pelo convite de participar neste evento da RocketSeat e de poder compartilhar algumas idéias com todos vocês. Imagino que muitos estão começando a estudar e muitos também tentando reciclar conhecimentos e aprender coisas novas pra se diferenciar. Hoje eu quero dar um passo atrás e tentar abrir um pouco os horizontes.

Pra quem não me conhece, eu sou desenvolvedor de software há quase trinta anos. Desenvolvedor do que? Front, back, infra, segurança, mobile, gerente, PO, consultor, se tem alguma posição no mundo TI eu provavelmente passei por ele. E nos últimos dez anos administro minha própria empresa de outsourcing de desenvolvimento, que hoje tem quase cem desenvolvedores, com um dos menores índices de turn over do mercado, atuando em projetos daqui e maioria nos Estados Unidos.

Nos últimos dois anos comecei um canal no YouTube como hobby pra compartilhar as experiências e conhecimentos que acumulei durante esse tempo todo, então não deixem de seguir o canal Akitando pra ter mais detalhes do que vou falar hoje. Se já assiste meu canal, vou repetir um pouco o que contei nos vídeos, mas vale relembrar.

Depois de passar anos pensando a respeito, se tem uma coisa importante que eu acho que pouca gente entende, seja iniciante ou seja experiente, é o conceito da lei de oferta e procura. Aí você pensa, “como assim, lógico que eu sei, se um produto tem muita procura mas não se consegue fabricar rápido o suficiente, tipo o novo Playstation 5, então o preço vai subir absurdamente”. Exatamente, está correto, e o inverso também é verdade. Se existisse mais Playstations do que tem de demanda por ele, os preços iriam cair mais rápido.

Pense em você fazendo cursos. Parece fácil, faça dois ou três cursos, gaste seis meses estudando, e parece que quase garantido tem uma oferta de emprego já pra você. Isso não é normal, é um momento do mercado de alta demanda. Só que alta demanda nunca dura pra sempre, ela vem em ciclos. Tem ciclos de abundância e ciclos de depressão e dica pra vocês: estamos saindo do último ciclo de abundância, que começou uns 10 anos atrás.

Agora pense, com a quantidade enorme de cursos aparecendo, se tá tão fácil criar centenas de novos programadores a cada seis meses ou um ano, significa que a oferta de programadores iniciantes em breve vai ultrapassar a demanda. E portanto, o valor de cada um de vocês vale menos e menos. Porque é fácil qualquer um saber o que você sabe.

Outro dia eu vi um tweet que me deixou horrorizado. Alguém tava fazendo um investimento num fundo imobiliário porcaria. Ele tava super animado porque ofereciam rendimentos de meio porcento ao mês. E ele entrou em sete fundos, cada um oferecendo esse meio porcento, ou seja, na cabeça dele seria 7 vezes zero ponto cinco que dá três e meio “porcento” ao mês e vezes doze meses, daria quarenta e dois porcento!! Imagina, investe dez mil reais em janeiro e no fim do ano vai ter catorze mil?? Investimento da China!

Cara, se você ouviu o que eu acabei de falar e se perdeu todo nos números, ou pior, se concordou com o raciocínio do cara, fica preocupado, aliás, fica BEM preocupado porque isso é juros compostos e ao final de doze meses não é quarenta e dois porcento e sim perto de seis porcento só. Pior, se subtrair a inflação anual de uns quatro porcento, se tirar a taxa de administração dos fundos, se sobrar um porcento no fim de um ano vai ser muito. Ou seja, o cara tava imaginando que em dezembro ia ter mais de quatro mil reais de lucro mas na realidade seriam só uns cem reais. Se você chegou nesse resultado de cabeça também, parabéns, talvez você tenha futuro.

Durante trinta anos eu vim acompanhando programadores, de iniciantes até virarem seniors, em todos os tipos de linguagens, em todos os tipos de projetos, com todos os tipos de formação diferentes e o que mais me deixa assustado é como a grande maioria faz contas que nem o cara desse tweet. É com esse nível de raciocínio que vocês engolem propostas salariais de startups, acreditando em números ilusórios. A realidade é que a grande maioria dos programadores não sabe matemática básica, de nível ginasial.

Isso porque a maioria das pessoas nunca teve vontade de aprender e simplesmente se aproveitou de um sistema de ensino que manda você decorar meia dúzia de coisas, dá perguntas simples de múltipla escolha pra resolver, metade chutando, e no final te dá um certificado e você acredita que aprendeu alguma coisa. Agora some isso com um momento de mercado aquecido, que tá contratando qualquer coisa, de qualquer qualidade, e você vai ter um exército de pessoas mal qualificadas que vai ficar surpreso de porque com o passar do tempo tá ficando mais e mais difícil conseguir aumentos ou mesmo ser aprovado em posições maiores em outras empresas.

Porque seu valor é diretamente proporcional à sua produtividade, ao seu raciocínio rápido, à sua capacidade de receber problemas, que nem podem ser consideradas difíceis, como esse tweet que acabei de falar e imediatamente chegar na resposta correta. Essas coisas não vêm de graça. É a diferença de quem estudou e ralou quatro anos num curso de ciências da computação e quem passou fácil em provas fáceis em cursos de seis meses. É incomparável. Mas, cuidado, com o que eu acabei de dizer, vocês podem achar que estou dizendo pra obrigatoriamente fazer faculdade. Lembrando, eu mesmo não me formei, mas os dois primeiros anos que fiz de ciência, onde só tinha matérias de matemática, economizaram alguns anos na minha formação de autodidata.

Isso porque existem dois tipos de cursos: os que te ensinam ferramentas e os que te ensinam a aprender. Os que ensinam ferramentas tem validade super curta, os que te ensinam a aprender duram anos a fio. Infelizmente você só vai entender de verdade essa diferença depois de muitos anos. Quem é jovem talvez só conheça um mundo onde parece que a internet sempre existiu e sempre vai continuar existindo igual. Povo da minha geração lembra de uma época onde a internet não existia. Faz muita diferença ter perspectiva de tempo, de longo prazo.

Por exemplo, nos anos 90 as linguagens mais disputadas eram totalmente diferentes das de agora. Talvez fossem Visual Basic, Delphi e Java. Você gastou seis meses estudando Visual Basic, agora você se acha o fodão. Passa a virada do século vinte e a demanda por programadores de Visual Basic cai dramaticamente, agora as linguagens mais demandadas talvez fossem PHP, ASP, talvez Flash até.

Agora, você de Visual Basic gasta mais tempo irritado, dizendo como esses moleques de PHP e ASP não entendem as qualidades do Visual Basic e que essa tal de Web é só uma moda e já já vai passar. Daí passa mais dez anos, agora as linguagens mais desejadas eram Objective-C, Ruby, Javascript. E como foi ficando o cara de Visual Basic, que era o rei dos anos 90? Cada vez sem opções e perdendo todas as ondas de novas tecnologias. Ele perdeu a primeira onda da Web, a onda das redes sociais, a onda do mobile, a onda dos e-commerces e assim por diante. Hoje as linguagens mais demandadas talvez sejam Python e frameworks como Flutter ou React. O que acontece nos próximos dez anos? Eu não contaria que as coisas vão continuar iguais, porque a tecnologia está em constante evolução. Não tenta adivinhar, é perda de tempo.

Sabe o que não envelhece, saber fazer continhas bestas como a dos rendimentos de investimento que eu acabei de contar do tweet. Só que nenhum curso oferece formação em matemática básica, cálculo, álgebra linear, estatística e probabilidade. Sabe por quê? Porque nenhum aluno tem nem a paciência pra fazer e nem acha que devia pagar pra aprender contas porque fazer contas é chato. E ainda acha que programação é saber seguir tutoriais, passo a passo e copiar e colar pedaços de código de sites como stackoverflow. Programação é ensinada como se fosse montagem de Legos, e tá longe disso, muito longe.

É muito fácil seguir tutorial, óbvio, já tá descrito passo a passo tudo que tem que fazer. Copia o comando tal, cola no terminal, dá enter e cruza os dedos. Deu certo? Agora digita outro comando, dá enter e vai aparecer outra mensagem e assim vai indo. O que você aprendeu? A ler, copiar e colar. Todo curso baseado em seguir tutorial te ensina só copiar e colar coisas e mais nada. Você não sabe porque tá digitando esses comandos nessa ordem, você não sabe porquê essas ferramentas existem e quais problemas resolvem de verdade. Você não sabe que alternativas existem e que combinações diferentes pode fazer pra ter resultados melhores, porque cursos não ensinam você a raciocinar, apenar a seguir.

E no começo não tem nenhum problema, todo mundo precisa começar de algum lugar e eu comecei igual, seguindo tutoriais. Eu comecei a programar quando adolescente, talvez aos catorze ou quinze anos. Passei quase um ano lendo um livro da linguagem da época, dos anos 80, dBase, e conseguia fazer programinhas e até comecei a fazer uns trabalhos de freelancer. Algumas vezes dava uns bugs que eu não tinha ideia porque, mas mexia de um lado, mexia de outro, do nada começava a funcionar e fui seguindo assim. Aos dezessete resolvi entrar na faculdade de ciências da computação e foi um choque absurdo.

Eu entendi que tudo que eu sabia não servia pra quase nada. Primeiro porque a linguagem dBase praticamente já tinha morrido quando entrei na faculdade, descobri que existiam coisas como C ou Pascal, e fiquei chocado que não tinha quase nada de programação durante dois anos inteiros da faculdade, ou seja, metade do curso de quatro anos era integral só de matérias de matemática. E como todo mundo, eu fiquei abismado porque sempre achei um conhecimento inútil que eu nunca ia precisar.

Levou uns cinco anos pra eu de fato começar a entender porque aprendi toda aquela matemática. De repente eu precisava desenvolver sistemas que tinham funcionalidades como pesquisar palavras no banco de dados, e os códigos que eu achava pra copiar e colar eram lentos quando o banco de dados crescia e eu sabia entender porque. Eu lia as documentações, código fonte e conseguia criticar matematicamente a complexidade e saber porque um select like de SQL que todo mundo faz sem pensar é horrível em comparação a usar coisas como Elastic, especialmente com alto volume de dados.

Quando começaram a falar de data science e machine learning, imediatamente me relembrou as coisas que aprendi na faculdade. Eu sabia que machine learning é basicamente um pacote de tudo que eu aprendi em estatística e probabilidade. Até em assuntos da atualidade, como epidemiologia de Covid, me relembrou coisas como o teorema de Bayes, que é uma das coisas que se usa em machine learning. Você simplesmente não tem como escolher a ferramenta certa pra usar em cada caso se sequer sabe fazer continha básica de juros compostos de rendimentos.

Por isso muita gente vai pras ferramentas mais simples de aprender, as que é só encaixar um botão na tela e não pensar muito além disso. Trabalho de encaixar peça de Lego. Mas sendo a coisa mais fácil, é o que todo mundo vai pensar primeiro também, então se forma um volume grande de pessoas procurando emprego em mercados que, apesar de aquecidos agora, tendem a diminuir no médio a curto prazo. Quando a demanda cair, a prioridade não vai ser só sair produzindo funcionalidades novas a rodo e sim em otimizar e aumentar a qualidade do que foi produzido até agora, pra conseguir lucrar mais com a mesma coisa.

Agora você precisa de gente que sabe raciocinar e não só seguir passo a passo, que sabe pegar o que já existe e tirar mais valor sem aumentar quantidade de código. Não tem uma solução pronta pra otimizar coisas, pra fazer o mesmo software funcionar duas vezes mais rápido, ou pra fazer a mesma infraestrutura aguentar três vezes mais usuários sem ficar adicionando mais máquinas. Coisas como melhorar o software pra oferecer de primeira o produto que o usuário tá procurando no menor número de cliques. Tudo isso exige capacidade de aprender rápido.

Mudar ferramentas, seja bibliotecas, frameworks ou a linguagem que você gosta é difícil. Todo mundo tende a se apegar à primeira ferramenta que aprende, e tenta resolver todos os problemas com ela, mesmo quando não é a mais adequada. Porque é mais cômodo. Quando a situação claramente exige mudar de ferramenta, os iniciantes tendem a ficar na defensiva, justificando e defendendo um time que já perdeu, tipo o cara de Visual Basic dos anos 90 que falei antes. É o sinal de que você perdeu o controle e nunca controlou a ferramenta e sim a ferramenta te controlou, você se tornou escravo de ferramentas e de marcas de produtos.

Só que um programador de verdade é promíscuo, tem zero lealdade a ferramentas e marcas. Não fica defendendo Angular, ou Google. Tecnologia não é time de futebol, não é pra ter torcida organizada, ficar tatuando marca de tecnologia ou sair na rua pra defender. Ferramenta é só isso, ferramenta. Você já viu uma discussão de alguém defendendo martelo e outro defendendo chave de fenda? Não faz sentido né? Então defender Python e Javascript é a mesma coisa. Python é um martelo, Javascript é uma chave de fenda. Se precisar bater um prego, usa Python, se precisar girar um parafuso usa Javascript e ponto final. E pensando nisso? Se você só sabe martelo o que acontece? Todos os problemas pra você parecem pregos. E daqui a pouco você tá batendo um parafuso com martelo, que nem um idiota.

A profissão de programação é muito maior do que sua linguagem favorita. Infinitamente maior. Pra onde sua carreira pode ir? Pra onde você quiser, não tem como saber hoje o que vai precisar daqui dez anos. Mas se tem uma certeza absoluta é que se daqui dez anos você ainda estiver usando a mesma ferramenta que aprendeu hoje, você certamente limitou sua carreira demais e perdeu todas as oportunidades de evoluir.

Recentemente tivemos notícias de crimes de internet no Supremo Tribunal Federal e no Ministério da Saúde. Quando eu vejo essas notícias, preciso até pausar um segundo e colocar a mão na cabeça pra acreditar no que tô lendo. Coisas crassas, imbecis, como senha de conexão de banco de dados trafegando no javascript no front-end. Senhas de usuários sendo gravados em banco de dados como texto aberto. Se você não entende a gravidade do que isso significa, você ainda tem muito pra aprender.

Ninguém em sã consciência grava senha de usuário em banco de dados. Seria igual um cirurgião achar que é opcional lavar as mãos antes da cirurgia. Já pensou? Se qualquer site que você visitar te oferecer a opção de receber a senha que você esqueceu por e-mail, não precisa pensar duas vezes, esse site tá inseguro e o programador que fez é um amador completo. O do vazamento de dados do Ministério da Saúde foi um amador completo. Hoje em dia é fácil invadir sites, não precisa ser nenhum gênio. Programadores assim já deixa tudo aberto.

Lá por 2004 eu era um dos consultores num dos maiores projetos da Vivo, que tinha se formado fazia pouco tempo. Pra quem não sabe ou não lembra, a Vivo foi a unificação de meia dúzia de telecoms de vários estados do Brasil, em São Paulo era a antiga Telesp Celular. Esse projeto se chamava Atena e ia unificar os bancos de dados e sistemas de todos eles, coisa gigante que levou mais de dois anos e centenas de programadores e consultores.

Pois bem, quando cheguei lá recebemos ordens de usar um framework proprietário. Se você é de Java, pensa um Spring feito do zero. Se você é de Javascript pensa um Express e Angular feitos do zero. Esse framework foi desenvolvido pela BEA que foi comprada pela Oracle, pra facilitar imagina só a Oracle, que é gigante. Quando eu fui vendo como esse framework funcionava eu senti um cheiro de podre, na minha cabeça pensei, puts, esse troço nunca libera toda a memória que aloca. Pra tirar a dúvida fiz um teste de stress nele num servidor e dito e feito, o framework alocava memória sem parar e nunca devolvia pro sistema e crasheava meu teste. Eu mandei e-mail pro meu chefe avisando e ele marcou uma reunião com os arquitetos da Oracle.

Eu fui acusado de estar tentando falar mal do projeto deles porque eu era de outra consultoria e como ele era o fodão, porque era arquiteto certificado da Oracle e bla bla bla. Vou fazer o que, fiquei quieto e pensei “bom, eu avisei, não é problema meu”. Passou alguns meses, minha alocação lá acabou e depois troquei ideia com meu antigo chefe pra perguntar se os sistemas tinham ido pro ar. E ele me falou, “pois é, a gente precisa rebootar os servidores em produção a cada meia hora”. Obviamente, eu tava certo.

Quando eu falo sobre matemática, o povo fica intimidado e com medo, porque todo mundo odeia ver aquele monte de número e montes de equações. Nem eu gosto disso. Eu gosto do pensamento matemático, de como a gente aprende a enxergar os dados e todas as formas que eu posso manipular esses dados, como enxergar funções, que são basicamente equações, e acostumar a pensar não em como são feitos, mas como são delimitados, definir os limites, a complexidade, e como manipular os dados com funções diferentes. Pensamento matemático é aprender a não seguir procedimentos cegamente e enxergar as possibilidades diferentes do procedimento, incluindo como detectar erros como no caso que contei agora.

Pense assim, você sofreu lavagem cerebral por mais de dez anos da sua vida. Do fundamental até sair da faculdade, sua rotina foi receber um currículo bem definido, com cada matéria exata que era obrigado a estudar. Sempre tinha um professor cagando regra do que você tinha que fazer. As provas eram previsíveis, bimestrais, com a matéria exata que cai em cada uma. Mesmo se você fosse o preguiçoso do preguiçoso, você sabia o que ia cair na prova. E foi fazendo assim, estudando o suficiente pra tirar 5 e passar de ano.

Agora você virou adulto e tá no mundo real. Não tem mais currículo que diz o que precisa estudar daqui pra frente. Não tem mais um professor que te diz o que fazer. Os problemas da vida aparecem do nada, sem aviso. Provas que você não sabe o que vai cair, mas precisa resolver sem ter um bimestre de aviso pra estudar antes. É totalmente estressante, porque depois de sair da faculdade você não tá diferente do moleque do fundamental, no primeiro ano de novo. Ninguém te ensinou como o mundo real funciona e como ele é diferente da escola.

O que seu instinto manda você fazer? Procurar cursos, que têm currículo bem definido, professor pra te dizer o que fazer, e provas fáceis com data pré-marcada e matéria pra estudar bem definida, tudo que te dá a ilusão de estar progredindo. E você fica frustrado quando tenta aplicar na vida real e tem dificuldade. Na sua cabeça o mundo da programação realmente é difícil, porque você tá tendo muita dificuldade, e a vida real provavelmente está errada porque os projetos não são bem definidos, seus chefes não são como seus professores que te dão instruções exatas do que fazer, e você se sente injustiçado e cada vez mais frustrado.

Isso porque até você assumir que te induziram a aprender errado a vida inteira, tudo vai ser difícil, você sempre vai enxergar o mundo como um lugar que te maltrata, onde mesmo que você se esforce pra seguir a matéria, o mundo continua te dando situações que não tinha no curso, e seus colegas e chefes dificultam sua vida te dando problemas que você nunca aprendeu a resolver. Só que a realidade é que você simplesmente tá vendo as coisas do jeito errado, não é o mundo que é difícil, é você que ainda não aceitou que tá fazendo as coisas do jeito errado.

Aprender não é decorar matérias e fazer uma prova. É enxergar o problema e aceitar que te falta conhecimento, procurar você mesmo por esse conhecimento, testar hipóteses e falhar, assumir o fracasso e criticar o que você fez de errado, pra no próximo problema saber lidar melhor e assim sucessivamente, um pequeno passo de cada vez, ao longo de anos, sem nunca poder dizer que “sabe tudo” de qualquer coisa. Programação é uma profissão cujo estudo não termina quando você se forma na faculdade ou quando tira certificados nos cursos. Ele só começa a partir dali pra você estudar sozinho e saber descobrir sozinho o que estudar primeiro.

Eu estou nessa carreira faz uns trinta anos, desde o fim dos anos 80. Apesar de ter me tornado empresário eu continuei programando tempo integral em projetos até quase dois anos atrás. Nesse período eu aprendi uma dúzia de linguagens, frameworks, bibliotecas. A cada geração deixei pra trás todas as ferramentas que tinha aprendido e ia aprendendo coisas novas. E quanto mais eu fazia isso, mais aprender coisas novas ia ficando mais e mais fácil.

Hoje eu consigo aprender uma linguagem nova, a ponto de ficar minimamente produtivo, em um mês. Antigamente levava pelo menos um ano. E isso só é possível porque desde o começo eu tive o primeiro choque quando entrei na faculdade, de entender que eu não sabia nada do que achava que sabia e ver a minha primeira linguagem, que demorei dois anos pra aprender, se tornando obsoleta e ficando pra trás. Aprendi a desapegar e a ter humildade de entender que eu não sabia nada.

Pior, antigamente, eu tinha dois, três livros à minha disposição. Não tinha Amazon pra consultar e pedir online. Porra, não tinha internet, então não tinha fórums, não tinha comunidades pra pedir ajuda. Hoje, se você quiser aprender a base da ciência da computação pode entrar nos sites de grandes universidades como Stanford, Harvard e tem as aulas gravadas de cálculo, álgebra e tudo mais que qualquer boa faculdade ensina. É só ter a disposição pra sentar a bunda na cadeira por 2 anos e aprender.

Faculdades, cursos, e qualquer tipo de instituição de ensino tradicional não são ruins. Mas elas são rodinhas na bicicleta. Se você entender isso, não tem nenhum problema. O problema é você achar que na vida real dá pra ir muito longe com rodinhas. Quanto mais cedo tirar as rodinhas e começar a cair, mais cedo vai aprender a levantar e pedalar sozinho. Aprender de verdade dói, e dói bastante. Mas tem que doer, exatamente por causa da lei da oferta e da procura. Tudo que é muito fácil, qualquer um pode aprender, e por isso mesmo, vale muito pouco. Tudo que não tá doendo, por um longo período de tempo, tem muito pouco valor e quase nenhuma evolução lá na frente.

Não é só a vida que é injusta, talvez seja pouco esforço mesmo. Lembre-se, é muito fácil ganhar bem num momento temporário de mercado que tá aquecido. Quem realmente tem valor é quem aprendeu a aprender sozinho e a se virar e consegue nadar num mercado em depressão. Dado tempo suficiente, os mercados naturalmente filtram os caras que são bons daqueles que só tiveram a sorte de entrar no mercado quando tava aquecido. Mas esse ciclo vai inverter em breve, e se eu fosse vocês ficaria preocupado.

Como alguém que lidou com contratações e treinamentos e viu a evolução de literalmente centenas de desenvolvedores. É muito triste ver alguém que ainda é iniciante, sendo incorretamente super valorizado num mercado aquecido, ficando cego achando que já é bom, e congelando a evolução, fazendo a mesma coisa por muito tempo e ficando pra trás quando o mercado muda de direção. Daí ele fica sem entender porque antes era valorizado mas depois não consegue mais subir. E não entende que o mundo real não é estático, não fica parado. Ele tem altos e baixos. Quem nasceu na alta não entende a baixa. Só quem já caiu é que enxerga e valoriza as oportunidades.

Com tudo isso dito, espero que alguns de vocês tenham ficado preocupado o suficiente pra repensar o que estão fazendo agora, correndo atrás de recompensa fácil e tomando atalhos, ou tá se preparando pra enfrentar o desconhecido que o mundo do futuro vai te apresentar e conseguir finalmente surfar as grandes altas quando elas voltarem. Por hoje é isso aí, espero ter ajudado a aumentar os horizontes do que vocês imaginavam, se curtiram o video mandem um joinha e convido vocês a verem o meu canal pra ouvir os detalhes de todas as coisas que acabei de contar. A gente se vê, até mais!

DESCRIÇÃO

Hoje vou responder às perguntas que mais me fazem via DM. São 3 temas principais: quais cursos fazer, low-code e GPT-3, mas todos convergindo pra falar sobre a ansiedade na sua carreira.

Capítulos:

00:00 Abertura 01:32 Avaliação de Testes de Candidatos 06:32 Low-Code/No-Code 13:06 IA e GPT-3 25:31 Sua carreira vai acabar 28:49 Quais cursos fazer?

Links:

• Lei de Amdahl (https://en.wikipedia.org/wiki/Amdahl%27s_law)
• GPT-3, Bloviator: OpenAI’s language generator has no idea what it’s talking about (https://www.technologyreview.com/2020/08/22/1007539/gpt3-openai-language-generator-artificial-intelligence-ai-opinion/)
• Deep Learning’s Carbon Emissions Problem (https://www.forbes.com/sites/robtoews/2020/06/17/deep-learnings-climate-change-problem/#2fcb9e4b6b43)
• 3Blue1Brown - Playlist Neural Networks (https://www.youtube.com/watch?v=aircAruvnKk&list=PLZHQObOWTQDNU6R1_67000Dx_ZCJB-3pi)

SCRIPT

Olá pessoal, Fabio Akita

Sim, vou ficar de touca hoje já que povo ficou falando que tô com cabelão de Jaspion. E como dá pra notar, eu ainda não consegui voltar de verdade. Depois que fiz o último episódio onde contei como me acidentei, descobri que de fato eu fraturei meu ombro. Ainda vai levar até quase fim de setembro pra recuperar meus movimentos, mas tenho tentado escrever e tá foda porque o ombro começava a doer depois de uma ou duas páginas. E isso me deixa de muito mau humor, daí eu apagava tudo e começava tudo de novo alguns dias depois pra ver se doía menos.

Esta deve ser a quarta ou quinta vez que tentei escrever e finalmente consegui terminar. Como eu ando mau humorado sem poder me mexer direito, acho que faz sentido este episódio ser mais um estilo RANT. Este é um bom exemplo de porque eu não monetizo meu canal nem aceito patrocínios. Podem se preparar pra bronca.

Tem duas motivações pro tema de hoje. A primeira são as dezenas de perguntas que vocês me mandam toda hora no DM do Insta. A segunda é que no video passado anunciei que minha empresa tá contratando, daí passei os últimos dias avaliando vários testes de código de candidatos. Nos últimos meses a maioria das perguntas tem a ver com três temas. O primeiro é o constante “akita, quais cursos você acha que eu devo fazer?”, O segundo é “akita, fala como o low-code vai revolucionar a programação”, e o terceiro, claro, é “akita, fala como o GPT-3 vai substituir os programadores”.

Como tudo isso tá conectado? Vamos ver.

(…)

Deixa eu começar com os testes que ando avaliando. Primeiro de tudo, pelo menos em termos de quantidade, tivemos uma boa resposta e mais de uma centena de currículos recebidos. A Codeminer não é uma empresa de recrutamento nem body-shop, essa foi a primeira vez que tivemos que lidar com tanto currículo de uma só vez. Então já peço desculpas caso as respostas não tenham sido muito satisfatórias. Ah sim, algumas pessoas vivem perguntando sobre trabalho voluntário, sem receber, e eu já vou dizer: não existe trabalho voluntário em empresa privada. Se você trabalha pra alguém, em qualquer capacidade, cria-se vínculo empregatício. A lei não permite diferente disso. Eu não sou ONG, não posso ter voluntários, só contratados.

Eu não vou dar detalhes do teste porque não é objetivo do video mas deixa eu colocar uma coisa muito clara: se você não tem interesse em se esforçar num teste, acredite que eu vou ter menos esforço em te considerar. É recíproco. Como eu disse, isso Não é trabalho voluntário. Outra coisa, eu pessoalmente olho a maioria dos códigos dos candidatos junto com outros desenvolvedores do meu time. O mesmo teste passa pela avaliação de umas 2 pessoas. E eu nunca leio o currículo antes de ver o teste, pra não ter viés. Mas eu nem preciso. De bater o olho eu tenho uma idéia de quanto tempo a pessoa levou pra fazer, se fez com má vontade, eu muitas vezes consigo ver a faixa etária e que tipo de experiência essa pessoa já teve. Se você nunca pensou nisso, fica um insight: o código expõe muito de quem você é.

Deixa eu colocar em perspectiva. Eu venho avaliando código, seja de colegas de trabalho, seja de projetos de clientes, seja de contratações, seja open source, faz 30 anos. Nesse período eu li código de centenas de pessoas diferentes. Só a minha empresa tem quase 10 anos, com quase 100 desenvolvedores e já passaram fácil umas 300 que entraram e saíram. Quando você faz isso por tantos anos, naturalmente encontra patterns, você sabe que determinado tipo de código tem determinado tipo de origem.

Isso significa que eu faço codigo melhor que os outros? De jeito nenhum. Eu não programo mais todos os dias. É como um avaliador de arte. Ou um sommelier de vinho. Ou alguém da Michelin avaliando restaurante. O melhor avaliador de arte raramente é o melhor artista. O melhor sommelier não necessariamente é o melhor produtor. O melhor avaliador de restaurantes raramente é o melhor chef e assim por diante.

Isso explicado, é hora de dar a carteirada. Exemplo simples: o teste pede que o candidato desenvolva um conjunto de funcionalidades. Algumas são propositalmente simples e outras são propositalmente mais complexas. Alguem nível estagiário, eu realmente não espero que consiga fazer as coisas complexas. Mas o que normalmente acontece é que as pessoas começam querendo fazer as coisas simples primeiro e deixam as complexas por último. Só que aí elas gastam uma semana floreando o que não precisava, acaba o prazo e ela não sabe o que fazer, e dá pra ver que a primeira metade é mais caprichada que a última. Claramente não assistiram meu vídeo sobre Prioridades.

Mas pior ainda é quando você pega o teste, incompleto, só a parte simples feita. Às vezes sequer roda. Eu avalio como nível estagiário ou junior, daí vou ver o curriculo e o cara se diz pleno ou senior. Menos né. Eu falo sobre isso de niveis no video Começando na Carreira de TI. Mas o ponto é que o código costuma dizer um nivel diferente do que a pessoa escrevendo o código acha que é. Alguns são mais realistas, alguns são mais deslumbrados, mas o código costuma ser objetivo. No caso sobre ser senior, muita gente se pergunta se já é, e eu sempre digo que se você tem dúvidas, provavelmente não é. Você vai ter certeza quando for.

Aliás, pra quem ficou de mimimi no meu video de Aprendendo a Aprender, e não sabe escutar e concluiu que eu privilegio quem se formou em federais, tente escutar o que eu acabei de falar: eu não olho o currículo antes de ver o código. O que eu disso no outro video e reitero, é que depois que eu avalio o código e vou ver o currículo pra saber quem era a pessoa, por acaso a maior parte que eu avalio bem acaba sendo de federais. É uma correlação e não um preconceito. Vocês de particulares e cursos avulsos querem mudar isso? Não mandem testes incompletos, mal feitos, que sequer rodam.

Outro exemplo óbvio: mesmo depois de avaliar uma dezena de códigos de teste, eu achei alguém que copiou partes do teste de outra pessoa. Ha, pra cima de mim? Não tô falando um trechinho, como todo mundo faz com stackoverflow. Tô falando quase tudo, incluindo comentários e os console.log esquecidos nos mesmos lugares. Ha. Os dois tão desclassificados. Porque se num simples teste eu já encontro essa falta de ética, você acha que vou confiar o código dos meus clientes como? Como eu disse, o código expõe muito do tipo de pessoa que você é.

Eu poderia fazer um video inteiro falando só sobre as coisas que eu consigo enxergar num teste, mas vou parar com esses exemplos mais simples. Porque o objetivo de falar disso foi pra falar do tema principal deste episódio: vocês são ansiosos demais. Porque os 3 temas das perguntas que mais me fazem, sobre quais cursos, sobre o tal do low-code ou o tal do GPT-3, tem origem no mesmo lugar: vocês querem saber como ter emprego garantido. Como saber que você vai ter um lugar nesse mercado hoje e no futuro. E como saber se você vai continuar evoluindo, ou seja, ganhando mais. Todo mundo quer tentar ser mais esperto que o resto e normalmente não tá sendo.

Deixa eu começar falando rapidamente sobre o tal do Low-Code. Seja a da tal Outsystems ou coisas como o Amazon Honeycode ou Monday.com ou qualquer outra plataforma desse tipo. Sim, elas permitem desenvolver aplicativos com pouco, que é o low-code, ou nenhum código, que é o no-code. Vamos deixar uma coisa muito clara: isso NÃO É PROGRAMAÇÃO. Vou repetir se não ficou claro: isso NÃO é programação.

Se você ainda não entendeu eu quero que vocês prestem atenção nisto na minha mão. Estão vendo? Isto é Low-Cook ou No-Cook sejá lá qual termo você preferir. Você ferve água, coloca neste copo, espera 3 minutos e tem uma refeição. Se quiser ser fancy, você quebra um ovo dentro. Isto, Não é gastronomia. E ao colocar água no copo você não andou nem um único passo na direção de ser um Massimo Bottura, Ferran Adriá, Dominique Crenn ou Gordon Ramsay. Nem um único passo na direção de ser cozinheiro de carrinho de cachorro quente, muito menos de chefs Michelin 3 estrelas.

Agora eu pergunto. Você acha que este Cup Noodles, ou esta sopa enlatada Campbell’s representam alguma ameaça à arte da gastronomia? Você acha que porque inventaram a sopa enlatada ou o macarrão instantâneo, acabou a necessidade de cozinheiros e chefs de verdade? Ou pior, você se acha um chef quando coloca água quente num copo? Então por que diabos você acha que um operador arrastando componentes numa tela pra fazer um app fast food é programador?

Vou inverter a pergunta, não precisa nem ser um Ferran Adriá, você acha que o cozinheiro do restaurante italiano do lado da sua casa tá preocupado em perder o emprego achando que todo mundo vai comer cup noodles? Ou outra pergunta mais óbvia: se um cup noodles é uma refeição tão mais barata e simples de fazer, porque diabos você acha que 100% da população não migrou pra cup noodles?

Entendam uma coisa que devia ser óbvia se você tem alguma esperança em ser um profissional de programação algum dia: esta não é a primeira vez que esse tipo de plataforma aparece. Não tem nada de novo aqui, muito menos “revolucionário”. Eu já vi isso aparecer nos anos 80, nos anos 90, nos anos 2000 e agora de novo. Nos anos 90 por exemplo, tivemos o hype do RAD ou Rapid Application Development que deu origem às antigas IDEs e componentização como Hypercard, Powerbuilder, Access, Visual Basic ou Delphi. Vejam meu episódio sobre Dimensão do Tempo pra entender o ciclo de obsolescência da história.

Não estou dizendo que todas essa ferramentas são necessariamente ruins. Elas tem utilidade. A realidade é que pra uma parcela gigante de micro e pequenas empresas, elas simplesmente não tem capital pra custear grandes sistemas customizados. Ou o business é tão pequeno que realmente não precisam de muita coisa. O tipo de apps que eles precisam são alguns cadastros simples, alguns workflows simples, alguns relatórios simples. E sim, nesses cenários, plataformas de low-code ou no-code provavelmente vão ser úteis e até substituir uns Excel malfeitos por aí. Mas é só isso, no máximo. Assim como um cup noodles, se a pessoa tá com fome e não tem muito dinheiro, é uma alternativa legítima. Muito estudante de faculdade vai ter histórias de como conseguiu sobreviver graças a miojo. Eu mesmo já tive períodos assim no passado.

Mas vamos voltar ao foco do que me perguntam: que tal fazer uma carreira de “programação” em cima de ferramentas low-code pra produzir apps de baixo custo? Não vejo nenhum problema nisso. É um emprego legítimo como qualquer outro. Mas de novo, você não está no mercado de programação, não se iluda. Não existe caminho de migração entre fazer apps low-code e depois fazer aplicativos customizados de verdade. É como você querer migrar de fazer cup noodles em série pra vender pros amigos da faculdade e disso virar chef. Não tem nenhuma relação. Se depois você decidir virar chef, tem que começar absolutamente do zero na gastronomia, como qualquer um faria. Fazer cup noodles não te levou mais perto disso.

Outra, se amanhã uma Outsystems desaparecer, se amanhã a Amazon decidir que não gosta mais do Honeycode, se amanhã a Monday.com decidir parar de oferecer low-code, você não tem pra onde correr. No máximo vai migrar de uma ferramenta de low-code pra outra ferramenta de low-code, ou seja, vai evoluir de fazer cup-noodles pra esquentar lasanha congelada no microondas. E isso é o outro problema: todas as ferramentas de low-code são proprietárias, como as grandes IDEs dos anos 90 e 2000 que eram da Oracle ou IBM e já não existem mais. Se amanhã eles decidem descontinuar esses produtos, problema seu. O conhecimento que você adquiriu não tem utilidade em programação de verdade.

Eu sei o porquê de muita gente me perguntar se vale a pena aprender low-code em vez de estudar programação de verdade. Porque é mais fácil! Infinitamente mais fácil. E nem vem com essa conversa idiota de elitismo ou qualquer coisa assim, o fato é simples: se é fácil pra você, é fácil pra qualquer um. E se qualquer um consegue fazer com mínimo esforço, cada um de vocês vale menos e menos. Não existe caminho pra cima, só pra baixo. Não existe evolução, nem carreira. E de novo, não tem nenhum problema nisso. É como trabalhar montando Big Mac no McDonald’s, isso não é gastronomia, mas muita gente precisa de um primeiro emprego, juntar um dinheiro enquanto faz faculdade ou algo assim. Empregos temporários que exigem baixa capacidade tem muita utilidade. E low-code é o equivalente. Pode ser um bom emprego temporário enquanto você se prepara pra uma carreira de verdade no futuro.

E se tudo isso ainda não convenceu, uma última coisa que deveria ser meio óbvia: uma ferramenta de low-code não tem capacidade de gerar outra ferramenta de low-code melhor que a original. Ela morre nela mesma. E o que é necessário pra evoluir qualquer plataforma de low-code ou criar uma nova melhor? Precisa de um programador de verdade. Um operador de low-code não vai jamais criar outra plataforma de low-code sabendo só low-code. É impossível. Isso não é uma opinião, é uma resposta absoluta e inquestionável, é um fato: você que é operador de low-code tá 100% a mercê de quem é programador. E é por isso que low-code jamais vai substituir um programador de verdade, assim como um cup noodles nunca vai substituir um chef de verdade.

No final do video eu vou voltar ao low-code, então segure esse pensamento. Vamos pro segundo tema: mas e as inteligências artificiais? Não faz muitos anos, o DeepMind do Google derrotou um dos maiores jogadores de Go do mundo, Lee Sedol. Eu assisti ao vivo e achei sensacional. Go que é o jogo de tabuleiro mais difícil do mundo e a gente achava que nenhum computador seria capaz de derrotar um jogador humano pelo menos nos próximos 10 anos ainda. Não só isso, o mesmo DeepMind hoje consegue jogar dezenas de jogos de Atari, que ele aprendeu a jogar sozinho, melhor que humanos também. Vou deixar o link sobre isso nas descrições abaixo.

Daí em 2020 tivemos as notícias bombásticas do Generative Pre-trained Transformer versão 3, também conhecido como GPT-3, da OpenAi do Elon Musk. E toda vez que eu ouço Elon Musk, meu sentido aranha começa a apitar. Metade do que se diz sobre ele é relevante, metade é puro marketing. Ele me lembra Steve Jobs no sentido de criar bolhas de distorção de realidade. E o hype nas redes sociais e noticiários só amplifica essa distorção. Vide o preço sem nenhum sentido das ações da Tesla atualmente. É uma bolha.

As pesquisas em cima do GPT-3 de fato são muito interessantes do ponto de vista puramente técnico. Eu não sou estudioso de inteligência artificial, mas qualquer estudante de ciências da computação tem capacidade pra entender o básico. Inclusive, muitos trabalhos de conclusão de curso ou iniciação científica são sobre redes neurais e outros aspectos de IA. Se você é de ciências da computação e não é cínico com as notícias que andam circulando, eu reavaliaria a quantidade de horas que você tá gastando em cervejada em vez de estudar o que devia. E antes que eu me esqueça, não comentem se eu assisti video de fulano ou ciclano sobre GPT-3, eu sei que saiu um monte por causa do hype e eu não tive interesse de assistir de ninguém, eu fui ler os artigos direto.

Pra todo mundo que não fez ciências, por trás de todos os palavrões impressionantes como Inteligência Artificial, Machine Learning, Deep Learning, tem conceitos simples de entender mas implementações que dependem de matemática pesada como cálculo, álgebra linear, estatística e probabilidade e assim por diante. Você não precisa ser matemático pra entender os conceitos. Eu recomendo uma série do canal 3Blue1Brown que explica como funciona Deep Learning de uma forma visual e que eu considero simples e muito didático. Vou deixar linkado nas descrições abaixo e recomendo que vocês assistam depois.

O maior problema pra população em geral é quando colocamos as palavras “inteligência” e “aprendizado” na mesma frase. Dá impressão que a Skynet vai acordar daqui a pouco e dominar o mundo. E se você acredita nisso, eu entendo que faz sentido pensar que a carreira de programação está com os dias contados, porque se uma ferramenta low-code é incapaz de gerar uma nova ferramenta low-code melhor, como eu afirmei antes, certamente uma inteligência artificial, através de machine learning e deep learning poderia ser capaz de aprender a programar e sozinho gerar até uma nova inteligência artificial ainda melhor. Mas não, isso é ficção científica, eu não vejo isso chegando perto de acontecer enquanto eu estiver vivo e nem na próxima geração ainda.

Por hoje, eu não vou fazer uma grande tangente pra explicar sobre inteligência artificial, primeiro porque eu não sou estudioso da área e segundo porque o assunto tem atraído muito público então existem dúzias de materiais recentes excelentes tanto em forma de artigos, livros ou videos em tudo que é lugar. Eu não preciso ser redundante. Como eu disse antes, se você quer os detalhes, existe esse troço chamado Google que vai te dar excelentes respostas e materiais de estudo.

Pro que nos interessa aqui, o GPT em si é um modelo de linguagem autoregressiva com objetivo de produzir textos que parece que foi um ser humano que escreveu. Uma das inovações tá na letra “T” do nome, os transformers. Existe todo um campo de pesquisa e tecnologias chamado Natural Language Processing ou NLP, onde temos técnicas chamadas de Recurrent Neural Networks ou RNNs. Algumas dessas técnicas incluem Long-Short Term Memory ou LSTM. Resumindo de forma simplória, essas técnicas exigem processamento sequencial, ou seja, pra processar o próximo passo ele precisa do resultado do processamento anterior. É altamente acoplado. Se você é programador e já estudou sobre processamento assíncrono, sabe que isso é um problema porque impede paralelização. Se você não entendeu nada do que falei agora, pesquise estes termos no Google.

Os tais transformers são a evolução dessas técnicas de maneira que permitem um nível muito maior de paralelização. O GPT-2 já dava resultados impressionantes com 1.5 bilhões de parâmetros de aprendizagem e obviamente dizer que o GPT-3 processou (cento e setenta e cinco) 175 bilhões de parâmetros é algo que faz títulos de notícia ficarem particularmente mais clicáveis. A pergunta do GPT-2 pro GPT-3 é quando iríamos bater na lei de retornos decrescentes. Aliás, esse é outro conceito que você precisa entender. É muito difícil você conseguir que um programa paralelizável fique infinitamente mais veloz só aumentando a quantidade de processamento. Você bate na Lei de Ahmdal. É impossível paralelizar o mesmo programa pra sempre só aumentando processamento. Mas no caso, o GPT-3 ainda não bateu nesse limite, pelo que eu soube. Só entenda que não existe almoço grátis aqui também.

Agora, isso tudo dito, o que isso significa? Muita gente viu os demos de textos gerados pelo GPT3 incluindo trechos de código, poemas, capacidade de responder perguntas e muito mais. Eu nem vou perder tempo mostrando esses demos, porque como eu já disse, aqui no YouTube você vai encontrar centenas de videos fazendo demonstrações com a API do GPT e pra nossa área de programação interessa que existem até exemplos dele gerando trechos de código. Tipo, eu digo “crie um botão azul centralizado na tela” ou algo assim e ele gera o HTML pra isso direitinho. Uma pessoa comum, um normie, vendo isso facilmente esticaria o raciocínio pra imaginar que já era programadores.

Entenda uma coisa sobre redes neurais, eles precisam de uma quantidade absurda de treino. Treinar é fazer ele processar o máximo de material que existe pra conseguir gerar algo semelhante. Por exemplo, se eu jogar todas as obras do Shakespeare pra ele processar, ele vai conseguir gerar um texto que tem a cara de um texto de Shakespeare. Se eu jogar todas as músicas de Mozart ele vai conseguir gerar uma música nova que tem cara de Mozart. Se eu jogar um monte de código do Github de javascript, ele vai conseguir gerar alguns trechos de javascript que fazem sentido. Isso realmente é possível.

Mas esse é o limite. Ele consegue imitar um humano, mas não é nem de longe um humano. E eu não digo isso porque eu sou algum tipo de humanista que não acredita em máquinas substituindo humanos ou qualquer bobagem assim. Pelo contrário, eu adoro ficção científica, cyberpunk e tudo mais, eu quero mais é que um inteligência artificial supere logo os humanos. Mas falando friamente nos limites do que existe, isso ainda não é possível. Por mais impressionantes que os textos gerados pelo GPT pareçam, eles são o resultado desse treinamento de encontrar padrões, dar pesos pra esses padrões, e gerar algo baseado nesses pesos. Quando eu falo ‘botão azul’ ele processou vários HTMLs que tem botões, vários CSS que tem cor azul, e tem os padrões que juntam as duas coisas e solta um HTML coerente.

A mesma coisa vale pra um DeepMind que tem o conceito de aprender sozinho. Por exemplo jogos de Atari que eu não ensino nada e deixo ele ficar errando milhares de vezes, até ele começar a achar o caminho sozinho. Isso funciona em games simples, com regras simples e delimitadas. Por mais impressionantes que seja ver o DeepMind jogando um Pong ou Arkanoid ou Pacman sozinho, assim como no caso do Go, ele tá confinado num tipo de tabuleiro, onde as coisas só se movem de uma maneira simplificada, e não expande mais que isso. Mesmo em jogos que parecem mais complicados como um Dota 2 que já teve IA jogando. Pular disso pro mundo real, que tem milhões de variáveis extras, que é um sistema complexo não-linear, estamos falando de ordens de grandeza de diferença de complexidade.

Outra coisa, pra um GPT-3 gerar os textos que gera ou pra um DeepMind jogar Go como joga, estamos falando de um custo de processamento absurdamente alto. Não sei se vocês pararam pra pensar, por mais impressionante que seja a demonstração do GPT-3 gerando meia dúzia de linhas de HTML, quanto custou pra ele conseguir fazer isso? Vou deixar um artigo linkado embaixo, mas estamos falando de níveis tão caros quanto minerar criptomoedas. No caso do paper do GPT-3 ele foi treinado ao longo de seis meses, foram quase 5 mil versões de modelos de treinamento, exigindo GPUs queimando energia por quase 10 mil dias inteiros, 24 horas por dia, sem parar gerando mais de 30 toneladas de emissão de CO2. Ou seja, mais do que uma pessoa vai emitir durante dois anos inteiros. Pra todo mundo aí que já fez mimimi de emissão de carbono, tô esperando falar de Deep Learning da mesma forma.

Aliás, eu também não sou ambientalista, então seja em mineração de criptomoedas, seja gastando toneladas de carbono processando dados pra produzir alguns demos interessantes que deixam a internet doidona. Eu realmente não me preocupo porque como sempre, se a tecnologia for valiosa, ela vai ser otimizada ao longo do tempo. Como eu já disse numa palestra, se existisse Twitter nos anos 40 a gente não teria tido a revolução dos computadores, porque os primeiros como um ENIAC usava energia suficiente pra esquentar um lago. Era extremamente custoso e alguém ia twittar “ah, isso de computador não vai dar certo, vai destruir o meio ambiente, precisamos parar com isso”.

Neste momento, Deep Learning de verdade é algo inacessível pra maioria das pessoas quando estamos falando em níveis de DeepMind ou GPT-3. Você assistindo provavelmente nunca vai ter acesso aos detalhes da implementação e nem vai conseguir replicar o que foi feito. Entenda o outro grande problema: é tudo fechado. Você tem acesso ao paper, a algumas APIs e só. É tudo um grande experimento inacessível pra mim e pra qualquer pessoa fora das equipes de pesquisa desses projetos. O máximo que podemos fazer é especulação, por isso eu nunca me interessei em falar muito sobre isso. Significa também que você não vai fazer uma carreira nessa área. Vai no máximo consumir APIs de alguma dessas empresas e acreditar na caixa preta por baixo.

Toda vez que falamos de inteligência artificial na prática estamos falando de integrar com APIs da IBM, da Microsoft ou da AWS e agora da OpenAI. A maioria das pessoas sequer sabe como esses motores funcionam, só que funcionam, e pra maioria de nós isso é suficiente, mas entenda que só porque você usa uma API dessas, não o torna nem um pouco mais perto de ser da Área de IA, assim como colocar água no cup noodles não te leva perto de ser um chef.

E aqui eu volto ao problema que falei de low-code. Lá no futuro, quem sabe o GPT-1000, depois de ter sido treinado com todo o histórico de código dos GPT anteriores, seja capaz de gerar o GPT-1001, uma versão melhorada. Diferente de low-code, em teoria, ele poderia um dia ter essa capacidade. Mas eu tô falando de tanto tempo no futuro e é uma premissa tão abstrata que o que eu acabei de dizer tá mais perto de ficção científica do que qualquer outra coisa. Portanto não, pelas próximas décadas nem low-code e nem IA vai substituir a necessidade de programadores de verdade.

E tem outro agravante. Vamos fazer outro exercício mental. Digamos que no começo dos anos 2000 já tivéssemos meu teórico GPT-1000. Digamos que eu tivesse acesso aos códigos fonte de uma America Online, de um Yahoo, de um Orkut, de um ICQ e todas as principais startups do começo dos anos 2000. Mesmo assim ele não seria capaz de gerar coisas novas diferentes, como o Netflix, ou o Uber, ou o Airbnb a partir de 2008. Porque não é só uma questão de evolução de código, tem milhares de outras variáveis que não estão no sistema, como o momento econômico e social dessa época. Um modelo de negócios não nasce da sua cabeça só porque você quer, o melhor modelo de negócios é uma resposta eficiente ao momento econômico, depende muito de timing e da sua capacidade de implementar não só com codigo fonte. Já pensaram em marketing por exemplo?

Um exemplo besta, muita gente acha que se Gary Kildall, o criador do DOS, não tivesse vendido pra Microsoft, que na época era uma pequena empresa, talvez ele tivesse se tornado bilionário no lugar do Bill Gates. E esse pensamento tá errado. O que tornou Gates bilionário não foi o código do DOS, foi o fato dele ser um Gates. Lógico que tem a inteligência e competência dele, mas a mãe de Gary Kildall não era Mary Maxwell Gates, empresária e filantropa e amiga do então presidente da IBM, John Fellows Akeres. O que colocou a Microsoft no mapa foi o acordo de licença do DOS pros IBM-PC. Você acha que o Gary, um desconhecido, ia bater na porta da IBM e conseguir o mesmo acordo? O DOS em si não era um software especial, era bem bugado e ruim na realidade.

Na maioria das vezes o sucesso do software não tá só no software. Claro que ajuda um código inovador e bem feito, mas isso não é o único fator. QI costuma fazer bem mais diferença, o famoso “Quem Introduz”. Mas o ponto é que um low-code da vida é super limitado no que pode fazer e jamais vai inventar a próxima onda. E mesmo a melhor inteligência artificial, superior ao GPT-3 ou DeepMind de agora, vai sofrer pra fazer mais que alguns trechos de código. Por agora só serve pra dar mais like pra biscoitero. Portanto programadores de verdade ainda vão ser muito necessários pelas próximas décadas.

Mas existe um grande porém nessa história toda. Existe sim uma parcela da população de programadores que vai se tornar obsoleta. Essa categoria sempre existiu e vai continuar existindo, e são os que ficam estagnados num conjunto muito limitado de ferramentas ou marcas. A gente brinca que hoje um programador de Cobol ganha muito bem, mas é porque existem poucos sobrando. Se de repente amanhã aparece centenas de novos programadores de Cobol a única coisa que ia acontecer é que a oferta ia exceder a demanda e a grande maioria não ia ter onde trabalhar, porque não existe uma demanda crescente de Cobol. A demanda diminui ano após ano. E essa é outra coisa que já falei em vários vídeos pra vocês entenderem: a lei da oferta e da procura.

Com a pandemia e a atual bolha de startups cresceu a demanda por programadores. O problema é que cresceu a demanda por qualquer programador, independente da qualidade. Ou seja a demanda tava crescendo mais rápido do que a oferta conseguia suprir, portanto um programador que nem é tão bom assim tava ganhando muito mais do que devia. Por isso eu falo que precisa entender um pouco de economia. Com fatores como juros baixos tava mais ou menos fácil conseguir dinheiro pra investimento e por isso aparecia um monte de startups basicamente só engordando o porco, como a gente costuma dizer. No papel valiam muito, mas na prática não valiam nada. Caso clássico disso foi a derrocada da WeWork, que qualquer um com o tico e o teco no lugar sabia que não valia os bilhões que diziam. E de fato, antes ainda da pandemia implodiu.

Os low-codes e até as IAs da vida vão rapidamente ter capacidade pra substituir alguns tipos de programadores mais limitados. Famoso cachorro de um truque só. Muitas posições hoje são desnecessárias. Faz anos que eu me pergunto porque diabos geração de telas ainda não foi pelo menos semi-automatizado. Antigamente na era do DOS eu precisava desenhar coordenada por coordenada cada coisa na tela, manualmente, era um saco. Quando surgiram as interfaces gráficas também surgiu o conceito de WYSIWYG ou what you see is what you get e coisas como Visual Basic e arrastar elementos numa tela.

Se você faz apps mobile nativos com XCode da vida, faz a mesma coisa hoje. Um React Native ou Flutter da vida já diminuíram muito o trabalho de se fazer telas. Fazer telas é um trabalho repetitivo que a cada ano que passa acrescenta menos e menos valor. A tendência é se tornar mais e mais automatizado até que não seja necessário alguém especializado só em fazer isso. E não precisa esperar o GPT-1000 pra isso. É uma coisa natural. Igual robôs substituem operários em fábrica. Igual e-commerces substituem a necessidade de existir lojas físicas e vendedores. Faz parte da natureza que as coisas se tornem obsoletas e sejam substituídas por processos melhores.

O problema todo que eu vim descrevendo no video é a ansiedade de iniciantes de querer se tornar um programador rápido demais, tentando achar atalhos, queimando etapas, deixando de lado as coisas que parecem difíceis e pouco úteis de imediato. Porém, são justamente essas coisas difíceis, tediosas, que exigem esforço, estudo, suor e lágrimas que realmente vai garantir que você passe por diversos ciclos de obsolescência de tecnologia sem ficar pra trás toda vez, porque o que você vai aprender não é uma tecnologia ou ferramenta e sim o processo de aprender a aprender.

E isso me leva ao terceiro e último tema, a pergunta que todo mundo me faz toda hora de quais cursos devia fazer. É sempre a mesma coisa, seja um adolescente de 15 anos que tá ansioso pra começar logo. Seja alguém de 30 anos que sente que tá estagnado depois de trabalhar 10 anos na mesma linguagem ou ferramenta. Seja alguém que quer mudar de área, com 40 ou 50 anos e quer virar programador. Todos querem saber, Akita, devo fazer curso de python ou de javascript. Devo fazer curso de Angular ou React. Devo tentar uma linguagem nova como Elixir ou Go. Ou devo tentar algo que parece que tem mais empregos como Java ou .NET. E cursos, de quem eu devo fazer? Devo fazer Coursera? Pluralsight? Udemy?

E a resposta pra todas essas perguntas é … yes.

Meio brincadeira mas a resposta é simples: tanto faz. Muita gente ficou me falando de GPT com o medo de que vai ser substituído em breve e que tudo que estudou em cursos vai pro espaço. Nesse sentido eu diria que você não tá muito errado, você já sabe que o que você sabe é muito pouco e facilmente substituível. A boa notícia é que eu não acho que vai ser o GPT-3, a má notícia é que vai ser qualquer outra coisa. Tá correto ficar preocupado, mas você tá preocupado com a coisa errada. Deixa eu tentar martelar na cabeça de vocês, de uma vez por todas, tudo que você precisa saber sobre cursos. São 9 itens, vamos lá.

Número 1: desde quando era novo, eu nunca fiz nenhum curso. Ouça e entenda: eu nunca fiz nenhum curso. Eu estudava por conta. Eu não tinha muito dinheiro, e o que tinha eu tentava gastar em livros. Quais livros? Sobre os assuntos que me chamavam atenção. Eu ficava prestando atenção, e o que atiçava minha curiosidade eu ia atrás. Se você sequer tem curiosidade de ir atrás das coisas, você tá na profissão errada, porque você vai ter que se manter curioso pro resto da vida.

Número 2: Desde quando eu era novo, eu nunca ia em nenhum evento, nunca assistia nenhuma palestra, e tinha zero interesse de ver o que os influencers da minha época recomendavam. Zero interesse. Eu sabia que não fazia nenhuma diferença. Nenhuma. Eu já tinha entendido um fato importante: eu programava já antes de entrar na faculdade, e eu vi as ferramentas que eu demorei tanto pra aprender se tornando obsoletas. E eu aprendi desde cedo a desapegar da propaganda. Eu sabia que seja lá o que eu estivesse aprendendo, em 5 ou 10 anos não ia mais existir.

Sabendo disso, consuma seus materiais, livros, cursos ou o que for sabendo que são temporários. É que nem o emprego do McDonald’s. É o trabalho que vai colocar comida na sua mesa hoje e tentar te dar uma chance de ter uma carreira no futuro. Não fique muito confortável com seja lá qual linguagem ou framework ou bibliotecas você gosta. Em 10 anos elas não vão mais existir ou no mínimo vão estar relegadas a segundo plano porque outras coisas novas vão aparecer. Isso pode parecer desesperador mas assista meu episódio de Dimensão do Tempo. Qualquer um que começou querendo ser programador antes de 2010 nunca ia ter idéia, por exemplo, que depois disso ia existir um mercado de apps mobile, porque não existia isso antes. Sua carreira não é uma coisa pré-determinada, que você escolhe hoje e vai fazer a mesma coisa pro resto da vida. Você não tem e nem deve escrever em pedra sua carreira, você precisa criar fundações pra que ela possa ser qualquer coisa dentro da área.

Número 3: Curso de React, Angular, Flutter, Node, Spring, Laravel, é tudo igual, seja lá quem faça o curso. São ferramentas, que nem um martelo. Não tem tantas formas tão diferentes assim de ensinar como um martelo funciona. Faça qualquer um, faça mais de um, não faz diferença. Eu pessoalmente acho muito lento fazer cursos mas eu entendo que tem gente que se sente mais confortável quando alguém mastiga o assunto pra você. Nenhum curso vai ser excepcionalmente muito melhor que os outros.

Número 4: Ferramentas são de fato temporárias. Elas vão embora. Mas conhecimento de base não vai. A base é tudo aquilo que você considera chato e que parece que nunca vai ser útil. Eu falo disso nos videos sobre faculdades. Na minha época de faculdade não se falava muito ainda em temas como inteligência artificial, computação gráfica, ou coisas assim, em 1995 a gente ainda tava no começo disso. A gente tinha noção mas não tinha como adivinhar de que forma as coisas seriam no século XXI.

Hoje em dia você ouve os termos hypados da comunidade como data sciences, e o que é isso? cálculo, estatística e probabilidade. Ou Machine learning, o que é isso? cálculo, estatística e probabilidade. Deep Learning, o que é isso? cálculo, álgebra linear. Computação gráfica, o que é isso? álgebra linear. Se você se diz de data science porque sabe importar uma planilha numa ferramenta e exportar outra planilha, e não sabe cálculo e estatística e probabilidade, você não é de data science, você é só um operador de ferramenta.

Se você tem interesse em qualquer uma dessas áreas mas nunca parou alguns anos pra aprender matemática, você é e sempre vai ser só um consumidor, um operador de ferramentas. Você nunca vai ser a pessoa que vai trabalhar na criação e manutenção dessas ferramentas, e você nunca vai estar à frente da curva, sempre vai estar reagindo às demandas do mercado. Pior do que isso, o que eu mais vejo é gente de programação que sequer sabe português direito e é incapaz de formular um e-mail coerente com começo, meio e fim. E você quer falar de inteligência artificial?? Ah vá.

Número 5: pela própria natureza do business, empresa de cursos não tem tanto interesse na sua carreira propriamente dita, ele só quer te manter fazendo os cursos dela o mais tempo possível. E não digo isso insinuando que elas são perversas ou qualquer coisa assim. É simplesmente como o mercado funciona. Pra qualquer empresa de cursos é interessante que você tenha a ilusão que precisa de mais e mais cursos deles pra cada nova ferramenta que o mercado comece a demandar. Quase ninguém tem demanda imediata pros tais cursos de base que eu falei, como cálculo, álgebra linear. Por isso eu falo que é importante, se puder, que você faça uma faculdade. Não é pelo canudo ou pra se formar, mas pra você descobrir essa fundação que a maioria dos cursos comerciais nem menciona. Programar não é só sair escrevendo qualquer código e fazer rodar e ficar feliz com isso. Isso é só o equivalente a colocar água no cup noodles e achar que virou chef. Isso não é empoderamento, é só gratificação instantânea.

Entenda o modelo de negócios: se num mundo ideal todo mundo descobrisse que não é tão difícil assim ser autodidata, haveria necessidade de cursos? Vou dar um exemplo anedota de mim mesmo. Eu comecei a aprender Java em 1996, quando saiu a versão 1.0, não tinha curso. Eu aprendi .NET em 1999 quando acho que era versão Beta, e ainda não tinha curso. Eu aprendi Ruby em 2005, quando ainda não tinha curso. Eu aprendi Objective-C em 2010, quando ainda não tinha curso. Eu comecei a aprender o básico de Swift em 2014, no dia que lançou 1.0 e ainda não tinha curso. Eu aprendi Elixir em 2015, quando ainda não tinha curso. Tudo que eu aprendi foi quando ainda sequer tinha a opção de cursos. Não espero que todo mundo faça isso, mas é mais uma das coisas que você não vai conseguir fazer se pra tudo você depende de um curso.

Número 6: com tudo isso eu não estou dizendo que cursos são ruins, cursos são só serviços. Nada mais, nada menos. Eles ajudam, mas não faz parte do modelo de negócios ensinar você a aprender sozinho, não importa a propaganda. E você sempre vai ter a ilusão que porque fez um curso já aprendeu tudo ou quase tudo que precisava e aqui vem outra coisa importante: nenhum curso vai ser capaz de ensinar mais que uns 20%, se muito, de qualquer tema, não importa qual. Os outros 80% você vai ter que aprender sozinho. Mesmo que no título do curso tenha a palavra “avançado”, continua não sendo nem perto de tudo.

Número 7: você só sabe que tá começando a pegar ritmo na sua carreira quando tudo que sai de novo, você consegue se virar pra aprender rápido e sozinho. Cursos são como a rodinha na bicicleta, uma hora você precisa tirar e andar sem. E quando tira a rodinha, você vai começar a fazer o que já devia ter aprendido desde o começo: a cair e levantar. Você só postergou esse dia em troca de gratificação instantânea sem de fato ter aprendido o mais importante. De novo, alguns precisam das rodinhas pra pegar coragem antes de tentar sem, mas não se engane, uma hora você vai precisar tirar, então garanta que isso aconteça o mais cedo possível.

Número 8: eu falo isso desde o video de Matando Semi-Deuses, mas só porque eu ou qualquer outro influenciador disse alguma coisa, não dê tanta importância pra isso. A gente só é um bando de chato cagando regra pros outros. Eu disse agora pouco que quando eu tinha uns 20 anos eu nunca tive nem curiosidade de procurar influenciador - e eu sequer sabiam quem eles eram porque eu não acompanhava. Nunca senti vontade de pedir recomendações.

Por exemplo, se você pergunta pra mim ou qualquer outro influenciador quais cursos eu recomendo, o que você espera? Nenhum de nós fez todos os cursos do começo ao fim pra poder tabular numa matriz, comparar e apresentar uma resposta objetiva pra você. Eu detesto fazer cursos, acho todos muito devagar. O máximo que qualquer um de nós pode fazer é dizer o que a gente ouviu falar. Ou seja, meu chute não vai ser muito melhor que seu chute. E nesses casos eu sempre prefiro ficar com meu chute. Lembra do episódio de Não Terceirize suas Decisões? Pois é, eu nunca tive e continuo não tendo interesse no que um influenciador tem a dizer. Duvide do que a gente fala, faça você mesmo sua lição de casa.

Número 9: de novo, não estou dizendo que são todos os cursos ou que eles são culpados disso, mas o formato que todo mundo tá acostumado é seguir uma lista de itens, um checklist. Você faz um passo a passo, vai cumprindo os itens do curriculo, e no final você acha que evoluiu só porque conseguiu cumprir os passos. É uma rotina que te deixa acostumado com a coisa errada. Em vez de você pensar por você mesmo pra saber se evoluiu e pra onde ir, você se acostuma a esperar um checklist de tudo. E quando faz um item a mais, já acha que conquistou grande bosta. Sem querer, rotinas assim como de cursos te deixam reativo e passivo. Você espera que a vida real é que nem um video game, com fases simples e pré-definidos que quando você passa acha que é grande coisa. É que nem que jogar Fifa no playstation e no final acha que virou Neymar. Entenda, esses checklists foram feitos pra você passar. A vida real não, ela foi feita pra não deixar você passar. Já passou da hora de tirar as rodinhas da bicicleta né?

Finalmente, o que vai tornar você obsoleto e colocar sua carreira em risco não são ferramentas de low-code ou o GPT-3 ou o DeepMind ou a Skynet, é a sua incapacidade de aprender sozinho, sua irritante ansiedade em achar que é esperto e queimar etapas, e sua eterna credulidade de se iludir com gratificação instantânea. E você não tá sozinho, ou você acha que todo mundo também não quer ganhar rápido com pouco esforço? Por isso que esquemas de pirâmide nunca desaparecem. Como diz o ditado, todo dia sai um malandro e um trouxa de casa, se eles se encontram, sai negócio. E sempre quem procura recompensa fácil com pouco ou nenhum esforço é o trouxa. Quem vai tornar sua carreira obsoleta não é ninguém além da sua falta de esforço. Então pare de tentar achar justificativas de ficção científica pra achar que sua carreira corre perigo.

A moral da história é, você decidiu ser um chef, mas é preguiçoso demais pra aprender a descascar batata. Alguém inventa o Cup Noodles e você treme nas bases achando que acabou sua carreira. Sério isso?? E eu to reclamando mesmo, porque vocês não tem noção de quantas perguntas iguais a essa eu recebi nos últimos meses. É o mesmo tipo de cara que tá precisando de emprego, daí você oferece e manda um teste e o indivíduo me devolve feito nas coxas e vai no twitter reclamar que ninguém dá chance dele virar techlead ganhando salario de 6 digitos e por isso é uma vítima da sociedade. Se eu quando tinha 20 nos anos 90 já sabia que o mundo não funciona assim e dei meus pulos, vocês hoje já deviam ser muito mais espertos que isso, com a quantidade massiva de material de graça que tem disponível hoje. Vai no site do MIT ou da universidade de Stanford e faz as aulas gratuitas de matemática que tem. Alguém já tentou?

DESCRIÇÃO

Quem é o tipo de profissional que vai sobreviver à Crise Econômica Pós-COVID-19 na nossa área de desenvolvimento de software? Como se faz pra ser tornar esse profissional?

Se por acaso eu decidisse fechar meu canal hoje, eu diria que este seria um FINALE digno do que eu produzi até agora.

Este vídeo vai ser um dos mais longos e talvez até um pouco cansativo em partes mas é porque eu realmente quero martelar pela última vez o que eu venho falando faz um ano e meio sobre o processo de aprendizado, particularmente para iniciantes que querem aprender programação.

Links:

• 42 SP (https://www.42sp.org.br/)
• CodeMiner 42 (https://www.codeminer42.com)

Playlists:

• Programação para Iniciantes (https://www.youtube.com/watch?v=O76ZfAIEukE&list=PLdsnXVqbHDUc7htGFobbZoNen3r_wm3ki)
• Carreira (https://www.youtube.com/watch?v=A2-yU3YjB1U&list=PLdsnXVqbHDUcAWAN3cXHWnM9JEw2gjIN9)
• Tough Love (https://www.youtube.com/watch?v=HEaIsKm-pao&list=PLdsnXVqbHDUck2oHncXftVmut6_agAGRC)

Me siga nas redes sociais:

• Twitter (https://twitter.com/akitaonrails)
• Instagram (https://instagram.com/akitaonrails)
• Facebook (https://facebook.com/akitaonrails)
• Podcasts (https://anchor.fm/akitando)

SCRIPT

Olá pessoal, Fabio Akita

Estamos na semana do dia 1o de abril de 2020, esta é minha 3a semana de quarentena por causa da situação do COVID-19. Eu descrevi sobre os possíveis desdobramentos econômicos no vídeo da semana passada e recomendo que dêem uma olhada se ainda não viram pra ter contexto. Aliás, agradecimentos a todos que contribuíram compartilhando porque aquele video ironicamente “viralizou”! E por isso, finalmente hoje vou fazer meu primeiro vídeo patrocinado! O video de hoje é patrocinado por Skill Share …. Ha! Primeiro de Abril! Vocês sabem que eu não aceito patrocínios.

Como vieram milhares de pessoas novas acho que vale 10 segundos pra explicar rapidamente que este canal é mais voltado a pessoas de tecnologia, em particular aqueles que são ou querem se tornar programadores. Não vai embora! Serve pra quem não é também mas de vez em quando vou puxar mais pra programador! Eu sou programador e empreendedor e tenho quase 30 anos de experiência na área, e o canal é uma forma de compartilhar o que aprendi até agora. O canal tem pouco mais de 1 ano e meio e não é monetizado de propósito, porque eu não faço questão de fazer conteúdos só aumentar público a qualquer custo. Por isso você pode voltar pro primeiro video do canal e começar a assistir tudo hoje porque eu faço conteúdos que sejam válidos em qualquer época. Alguns são mais técnicos, alguns são mais gerais. Vejam a playlist Carreira ou Tough Love, por exemplo.

O tema do vídeo de hoje é educação, mais do que isso, é sobre o que eu considero a forma correta de aprender, não só programação, mas qualquer coisa que seja profissão de prática. O jeito que você não vai achar em praticamente nenhum curso por aí. Se você já assistiu meus videos anteriores, acho que já tem idéia de onde eu vou chegar - e mesmo assim acho que vai ter uma surpresa no final. Já peço desculpas porque vou ser até meio repetitivo em alguns tópicos porque realmente quero marretar esses conceitos de uma vez hoje.

Considerando que muitos são novos no canal e ainda não viram, deixa eu introduzir com um trecho do meu vídeo Pequena Retrospectiva 2018 e Previsões 2019 que publiquei em janeiro de 2019, mais de um ano atrás. Eu vou aumentar a velocidade pra 1.5x em todos os trechos pra ir mais rápido:

(VIDEO …)

[trecho - ini] Em termos de carreira na nossa área de tecnologia, estamos num momento de consolidação. Como disse antes, eu não vejo nada particularmente interessante que valha a pena focar todas as suas energias. Já faz pelo menos uns 5 anos que nada de realmente interessante aparece, só vaporware, só hype, mas nada que se provou ainda. Então, não acredite em nenhuma propaganda que se auto-intitula a salvação da lavoura, porque não tem. Só consolidações. A diferença é que eu espero que você tenha investido nos seus estudos nos últimos anos porque se o mercado se retrair, a competição vai aumentar, a demanda vai cair, e o mercado vai começar a separar o joio do trigo.

Por acaso, a entrada no século XXI foi marcado por um grande crash e uma depressão em 2001. Quase 10 anos depois em 2008/2009. E agora em 2019 ou 2020 já temos sinais de que estamos pra passar por algo similar. [trecho - end]

[trecho - ini] Resoluções pra 2019? Se a recessão não chegar este ano, aceite a sorte. Use este ano pra investir o máximo que puder nos seus estudos. Em 2020 você vai precisar disso.

E claro, como eu disse, especialista ou não especialista, ainda não existe ninguém que pode prever o futuro com certeza, nem especialista financeiro, nem cartomante. Mas, os sintomas estão aí. Vai bobear? Ah sim, e mudar de país não resolve o problema, porque essa tal próxima crise pode ser global e justamente os países hipster que a molecada gosta vão ser os primeiros a ser afetados. [trecho - end]

Não, eu não tô querendo dizer que eu previ o que ia acontecer em 2020, obviamente eu não tenho bola de cristal, não sou Bidu e muito menos Nostradamus, que também não previu grande coisa. Mas se um ano atrás parece muito longe, vamos ver um trecho do video de junho de 2019 chamado A Bolha de Startups vai Estourar:

[trecho - ini] Vamos colocar dessa forma: eu tomaria cuidado em apostar numa tech startup que opera com cash flow negativo, ou seja, que não dá lucro e não tem planos no curto prazo pra reverter. Especialmente se você estiver apostando morar fora do país ou algo assim. Esses planos vão ser cortados muito em breve. [trecho - end]

[trecho-ini] Eu gosto de ser conservador, eu detesto ser otimista demais porque os otimistas são os primeiros a cair quando uma crise aparece, especialmente uma que já está dando sinais cada vez mais claros. Eu sou um cético pragmático. Eu já sobrevivi a 2 ou 3 grandes crises. Sobrevivi os anos 90, os anos 2000 e os anos 2010, cada década teve uma crise e eu realmente nunca tive grandes problemas durantes esses períodos de transição. E o ponto de dizer tudo isso é porque durante minha carreira eu segui exatamente a descrição acima sobre a minha profissão. Quando o mercado acumula gente demais e de repente a demanda some, quem você acha que as empresas mantém e quem você acha que elas abandonam? [trecho - end]

[trecho - ini] O recado é muito simples: você está vivendo hoje num mercado que globalmente paga mais do que se deveria, fique esperto, essas coisas nunca duram. Se você está sentindo dificuldades hoje, vai ficar pior. Por outro lado, quem está conseguindo se enganar surfando na onda, vai tomar um caldo muito em breve. [trecho - end]

Está parecendo atual? Vamos ser mais atuais ainda. Na semana do carnaval a revista Exame continuou contribuindo pra idéia errada de que programação é um dos empregos mais bem remunerados e virou piada porque ainda quis fazer uma chamada bem click-bait, ou pega-trouxa em bom português, contando a anedota do estagiário que recusou uma proposta de 10 mil reais. Basicamente todos os casos contados na matéria eram exceções da regra, distorções. E o problema: eles não explicaram o momento de bolha do mercado, que é a razão dessas distorções. Sem querer, uma semana antes dessa matéria sair eu já tinha uma resposta pronta no video Programação Não é Fácil, de 19 de fevereiro de 2020 onde dentre várias coisas eu expliquei:

[trecho - ini] Pior que isso, mais da metade do valor de um lugar desses é só promessa. Imagine o montante de equity que existe espalhado nesse mercado. É um valor absurdamente grande. Só que isso é uma promessa. Se a startup falir antes de conseguir atingir o ponto de abrir capital e realizar sua valuation, todo esse equity vai valer zero no dia seguinte. Isso mesmo, zero. É uma bolha. [trecho - end]

[trecho - ini] Sabe onde isso vai chegar? Da próxima vez que a bolha estourar, e isso pode ser em breve ou pode ser em poucos anos, quem não for programador de verdade, ou seja, quem não souber como de verdade entregar resultados proporcionais ao que ganha, vai ficar sem emprego. Nunca se esqueça: sempre vai existir um indiano que faz o que você faz por menos da metade do preço. Provavelmente pode colocar um chinês junto nessa equação agora também. [trecho - end]

[trecho - ini] Sempre tenha em mente, você raramente vale o que você “acha” que vale. Todo mundo acha que deveria ganhar mais. E todo mundo que paga sempre vai achar que deveria pagar menos. Esse é o jogo. E é a lei da oferta e da procura que vai dinamicamente ajustando isso. Só que em períodos de bolha a demanda é desproporcionalmente mais alta, não dá tempo da oferta atender, então o que varia é o preço acima do normal. Em crises é o oposto, a demanda seca, e a oferta fica com estoque sobrando, o que varia é o preço abaixo do normal. Essa é a conta. [trecho - end]

Tudo que eu mostrei dos meus videos anteriores parece super profético, mas não é bola de cristal. Todo mundo que estava acompanhando sabia que as economias globais montaram uma casa de cartas muito frágil e estava já a perigo de cair com qualquer sopro. Ninguém poderia imaginar que não seria um sopro e sim uma martelada brusca e violenta na forma dessa pandemia. o cenário que nós já prevíamos como difícil a partir de 2020 se tornou quase um apocalipse.

Repetindo, estávamos em uma bolha, que 6 circuit breakers então, e contando, estourou. Se você tem só uns 25, talvez até 30 anos, você conheceu um mundo que só veio inflando desde 2009. Foram 10 anos de exuberância irracional, com centenas de tech startups operando com caixa negativo, dependendo de rounds de investimento pra pagar as contas, com a promessa de um dia poderem dar exit seja abrindo IPO ou vendendo pra outra empresa maior. Essa mamata acabou. Com a crise iniciada com o COVID-19 o dinheiro ficou mais caro. Dólar se tornou o ativo mais importante pra agora. Ou seja, os VCs ou Venture Capitalists, que dependem de levantar fundos, vão ter dificuldade de levantar mais dinheiro. Então as startups que dependiam desse dinheiro agora, ou não vão ter nada, ou se puderem ter vai ser às custas de dar mais equity pros investidores. Como os investidores anteriores tem cláusulas anti-diluição, quem vai ser diluído são os fundadores. E quem tinha stock option, nos dois casos, está pra ver essas opções virando fumaça.

Eu chutaria que se metade sobreviver o próximo ano, deram sorte. Na prática pelo menos um quarto deve fechar as portas. E eu já tenho recebido notícias de vários conhecidos em várias partes do mundo dizendo que as startups estão já cortando um número grande de funcionários. O pior caso que eu ouvi até agora foi de uma startup de Amsterdam que parece já ter demitido 70% do seu quadro, incluindo todos os programadores que trabalhavam remoto aqui do Brasil. Tenho ouvido sobre startups em Berlin e outros lugares do mundo cortando também.

Muitos vão conseguir se recolocar porque são excelentes programadores, com real experiência e cujos códigos e produtividade são diferenciais. Porém, uma parcela considerável são muito ruins. Na ânsia de crescer rápido demais, dezenas de startups começaram a contratar em atacado, inclusive fazendo coisas como acqui-hire, que é basicamente adquirir muitas pessoas de uma só vez, em vez de ter o trabalho de convencer uma a uma pra tirar de outras empresas. É tipo um hostile take-over disfarçado.

Nos próximos meses vamos ver um número crescente de programadores indo pra rua e não tendo mais onde se recolocar. Muitos eram ainda iniciantes que inflaram o ego e acharam que eram tudo aquilo que os recrutadores diziam. Recrutadores esses, que sabem perto de zero do que é programação de verdade. Além disso, muitos programadores de palco, que falam bem e serviam como chamarizes de contratação pros patrocinadores, também vão começar a sumir, porque a maioria falava mais do que realmente sabia programar. Pelo bem ou pelo mal, todo esse circo montado nos últimos dez anos finalmente vai passar por uma correção.

Vou repetir o que eu disse no meu vídeo de fevereiro: a despeito do que muita gente ainda fala, programar Não é fácil. Profissões de prática de fato são muito fáceis de começar. Por exemplo, qualquer idiota consegue começar a desenhar, basta rabiscar qualquer coisa num papel e chamar isso de arte. Porém a barreira pra se tornar um profissional de verdade, com técnica, qualidade, é extremamente alta e não é fazendo um curso qualquer por aí que vai te levar até lá.

E agora chegou a hora de eu falar de cursos comerciais e livros técnicos. Eu tô cansado de receber perguntas toda hora me perguntando que cursos eu indico, ou que livros eu indico. Sério, parem de me perguntar isso, não só pra mim como pra qualquer outro que você considere como influencer. Eu fiz um video inteiro só sobre isso, que foi o Não Terceirize Suas Decisões e onde eu falo por exemplo:

[trecho - ini] Mas perguntas que claramente tem a expectativa de justificar uma escolha, ou pior, terceirizar a decisão da sua carreira pra mim ou qualquer outro, não faz nenhum sentido. Por que você quer terceirizar as decisões da sua vida pra outra pessoa? Não faça isso. Só porque você vê alguém como eu ou qualquer outra pessoa em cima de um palco, isso não nos torna oniscientes, eu não te conheço, não sei que caminho você trilhou até agora, que dificuldades você teve, eu não sei quais seus objetivos de vida, se é que você tem objetivos. Nem eu, nem ninguém, poderia te dizer o que fazer sem conhecimento da sua história e dos seus objetivos. [trecho - end]

[trecho - ini] Se você está pra começar a faculdade, entenda que nos últimos 10 anos você aprendeu a estudar do jeito errado. Eu percebi isso só quando entrei na faculdade também. Por mais de 10 anos da sua vida você aprendeu a seguir um currículo. E você se condicionou a estudar o mínimo necessário e só pouco antes dos trabalhos ou provas. E as frequências das provas é sempre a mesma, provas bimestrais. E você sempre sabia o que estudar, porque já estava pré-definido. Todo mundo estuda o mesmo material, você nunca teve que escolher o que estudar.

Daí você entra na faculdade, e é mais ou menos a mesma coisa. Todo curso tem material pré-definido. Você tem as provas em datas pré-definidas. Talvez uma das poucas atividades que quebrem a rotina seja o Trabalho de Conclusão de Curso, o temido TCC. Que a maioria faz só na última hora mesmo que eu sei. Quem faz iniciação científica talvez tenha tido mais treinamento, mas no geral, você continua seguindo um currículo.

Parem pra pensar nisso: se você nunca repetiu de ano, você tem 21 ou 22 anos, recém formado da faculdade. E você passou uns 14 ou 15 anos da sua vida, ou seja, literalmente sua vida inteira seguindo uma receita pré-definida. É por isso que muita gente reclama quando entra no mercado de trabalho que a faculdade não preparou ele direito. Eu nem vou entrar no mérito da qualidade e da metodologia da educação moderna, e também não adianta chorar sobre o leite derramado. Só aceite que até o fim da faculdade, uma pessoa mediana só aprendeu a tirar 5 pra passar de ano e de repente não tem mais prova bimestral, não tem mais currículo, não tem mais professor “enchendo seu saco”. A partir de agora, todo dia é uma prova. Você só andou de bicicleta de rodinhas e do dia pra noite vai ter que aprender a fazer bicicross e saltar uma rampa por dia. [trecho - end]

Entendam: você tem uma noção errada sobre o que é aprender. Um curso, online ou presencial, é mais ou menos a mesma coisa que eu expliquei no trecho anterior: é um professor que cospe um monte de passo a passo. Você repete esse passo a passo. No final, talvez, você tenha alguma provinha irrelevante e fácil, e ganha algum certificado de conclusão de curso. Daí, você adiciona no seu LinkedIn e começa a mandar mensagens pra recrutadores. Como o mercado estava desproporcionalmente aquecido, muitos conseguem um emprego, até em tech startups. E por que? Três motivos, 1) os recrutadores não entendem de tecnologia e acreditam em certificados e coisas idiotas assim 2) porque a startup tem meta de crescimento e não meta de lucro, por isso quanto mais ele contrata mais parece que ele cresce e 3) por causa desse ambiente que não tem eficiência como prioridade, muitos que não deviam acabam conseguindo uma posição onde nem tem que fazer grande coisa.

Como existia essa demanda artificial, começaram a aparecer os parasitas pra sugar o máximo possível dessas vacas leiteiras de dinheiro fácil. Eu acredito que existem alguns poucos cursos bem feitos que estão realmente preocupados em ensinar, mas também que muitos são só aproveitadores esperando gente ingênua que acredita em papai noel e não enxerga onde está se metendo, incluindo gente que sequer gosta tanto assim de programação, mas tá com os olhos arregalados em matérias exageradas como da revista Exame que prometeram pra ele: salários de 10 mil reais sem precisar ser muito bom.

E intermediários como influencers, coaches, e tudo mais inventam mais e mais “coisas” pra atrair mais gente. Coisas como Data Science, Machine Learning, Inteligência Artificial, que de fato são assuntos muito interessantes, que em empresas com história séria de engenharia como um Google da vida são usados de forma avançada. Mas na grande maioria das tech startups só se faz o básico. Big data na maioria das empresas é um data lake de logs que a maioria nem sabe muito bem o que fazer. Fazem alguma coisa, claro, mas comparado com o investimento? Acho que não. E a maioria dos “cientistas de dados” no máximo são usuários de ferramentas, então tá tudo certo. A quantidade de cientista de dados que sequer sabem cálculo, álgebra linear, estatística e probabilidade e saem aplicando regressão linear em qualquer coisa é grande. E lógico, pra saber essas coisas precisa de no mínimo uns 2 anos só de matemática, mas a maioria dos cursos por aí, se tiver 6 meses é muita coisa.

Mas como quem contrata não sabe o que tá contratando e quem é contratado não sabe o que tá fazendo e tudo bem porque tem dinheiro infinito de investidor, então foda-se, vamos inflando o mercado porque tá tudo aquecido mesmo. Tem dinheiro de Softbank cujo credor é o governo Japonês, então sua startup tá queimando dinheiro do contribuinte japonês. Tem dinheiro de fundos de pensão, então sua startup tá literalmente tirando dinheiro de velhinhos. Tem fundos soberanos de governo, de novo, dinheiro do contribuinte. Daí que surgem montes de pseudo-programadores politicamente corretos, achando que sua startup tá revolucionando o bem estar do mundo, porque é ingênuo o suficiente pra acreditar no marketing e não sabe que o salário que recebe pra produzir pouco ou nada o dia inteiro, provavelmente vai deixar uma velhinha sem aposentadoria. Como se sentem agora? É uma grande infelicidade que muitas pessoas vão sofrer nesta crise, muito mais do que deveriam, pessoas que realmente estavam se esforçando como podiam. Por outro lado, todos esses parasitas do sistema vão ser expurgados também.

Ou seja, se você tem na cabeça, qual das dezenas de cursos online deveria fazer, talvez Udemy, talvez Pluralsight, talvez outro? A resposta é simples: tanto faz. A partir deste ponto eu quero estruturar a resposta que eu falei do que eu acredito que é o jeito certo que falei na introdução. Eu digo tanto faz porque todo curso online é apenas material de referência e exercícios simples. A maioria simplesmente resume o que tem na documentação oficial da linguagem ou framework e grava em video. Toda vez que alguém me pergunta de um livro eu tenho vontade de responder “você já leu a documentação oficial? Se não, porque diabos tá pensando em livros ou cursos?” E invariavelmente a resposta mais muleta de todas é: ah porque eu só consigo aprender com livros, ou com cursos.

Bullshit. Eu vou dizer o que você realmente quer. Digamos que você queira aprender a arte da pintura. Mas o que você realmente quer é que alguém te dê um livro fácil de colorir; sabe aquele que as crianças gostam que tem numerozinho passo a passo dizendo qual cor colorir em qual espaço? E você quer alguém pra te dizer “nossa, conseguiu completar o passo a passo, você vai ser um Leonardo da Vinci um dia”. É isso que você quer, um elogio barato na forma de uma certificação e um passo a passo que não precise de muito esforço, especialmente se você estiver pagando.

Aliás, perceba a motivação de um curso: é manter o aluno pagante suficientemente contente. Muitas vezes a coisa certa a se fazer seria dizer: “cara, eu realmente acho que você não leva jeito pra programar e sugiro procurar outra coisa”. Mas eu ainda tô pra ver um curso fazer isso com frequência, porque num mercado aquecido eu chutaria que uma boa parcela da classe é de gente que nem deveria estar ali. Mas um curso comercial tem incentivos pra fazer de tudo pra animar as pessoas e fazer elas continuarem até o fim pagando mensalidade. É inevitável.

Falando num caso bem particular que é o meu, pra quem não sabe, eu sou dono de uma empresa de desenvolvimento de software chamada CodeMiner 42, que vai completar 10 anos ano que vem. Eu raramente falo da minha empresa no canal porque a intenção não é fazer propaganda, nem mesmo pra minha própria empresa. Mas pra ilustrar meu ponto eu quero contar uma coisa que nós fazemos e pouca gente sabe. A maioria dos body shops do mercado, os recrutadores que às vezes se intitulam consultorias, saem caçando currículo em LinkedIn e ficam ligando o dia todo pra programador pra tentar contratar. Sem tanto critério mesmo, e muitas vezes tentando roubar gente de empresas consideradas melhores, pra facilitar o trabalho. Eu tô de saco cheio de mesmo receber proposta de recrutador que foi preguiçoso demais até pra ler meu LinkedIn direito e fica me mandando proposta pra ser programador deles.

Aliás, seja recrutador independente ou dentro de RH de empresas grandes, grande parte da culpa do mercado de certificações é deles. Eu tenho zero consideração pela maioria das certificações porque eles só certificam que você assistiu aula e pagou mensalidade, mas não que você aprendeu alguma coisa. Lá por 2001 eu cheguei a estudar pra me certificar como Arquiteto Enterprise pela Sun, mas nem cheguei a fazer a prova porque eu não tava a fim de pagar só por um papel. E a Sun nem existe mais aliás. Eu estudei e comecei a aplicar na prática e só, me lixei pro papel.

Em 2005 minha consultoria queria ter mais gente certificada em PMI, então me pagaram pra fazer o curso e a prova. Foi um puta saco, eu decorei tudo, treinei dezenas de simulados. A prova foi super simples, sério, acho que eu levei 30 ou 40 minutos pra acabar e no final passei. E este, é o meu certificado PMP. Pra ser justo, o PMI não diz que quem é certificado já um bom gerente, ele até tem atividades que você precisa fazer pra se manter como PMP e ele tinha validade de 3 anos. Mas quem contrata raramente pede pra mostrar o diploma. Eu continuei sendo junior em gerenciamento e só depois de anos praticando eu posso dizer que aprendi o suficiente pra me considerar um gerente.

Eu respeito o corpo de conhecimentos do PMI, não me entenda errado, mas eu guardei o papel na gaveta e não pendurado, justamente pra um momento como hoje, porque vou te mostrar o quanto eu valorizo papel. Este é o certificado do curso obrigatório de PMI que tive que fazer (…) este é o diploma por ter passado na prova de PMI e que me certifica como PMP (…) e estas outras papeladas fazem parte do guia de PMP incluindo um (argh) código de conduta ….

(….)

Dramatizações à parte, falando sério. Na CodeMiner, já faz alguns anos, contratamos estagiários. Normalmente são alunos de universidades federais ou estaduais, por volta do 2o ou 3o ano. Pra conseguir isso abrimos escritórios físicos em 12 cidades do país, de Norte a Sul, incluindo cidades como Natal, Anápolis, Santa Maria, Guarapuava, Ribeirão Preto e mais. Raramente contratamos estagiários que vieram de faculdades particulares. E por que? Porque normalmente a seleção deles é muito ruim. A palavra-chave aqui é seleção.

Entenda, além da qualidade dos professores e currículo, seleção é o fator fundamental que separa as universidades públicas das privadas. A universidade pública, por definição, não tem fins lucrativos no sentido de cobrar mensalidade, já as particulares tem. Em qual você acha que a seleção vai ser mais fácil? Como a concorrência pra entrar numa federal é ordens de grandeza maior do que numa particular, a seleção é muito superior. Por outro lado, muitos cursos particulares sequer tem seleção, significa que pagando, qualquer um pode entrar e, como eles tem incentivo pra manter o cara pagando, vai ser a pior seleção de todas, quando tem.

Além disso, se um aluno conseguiu sobreviver os 2 primeiros anos de uma boa federal de bacharelado em ciências da computação, quer dizer que ele passou por matérias consideradas hiper chatas mas necessárias como cálculo, como álgebra, como algoritmos e estruturas de dados. E se ele fez pelo menos iniciação científica, demonstra ainda mais empenho em trabalhos de pesquisa e melhoria contínua. Ou seja, um aluno de federal que já passou da metade do curso costuma ter bom potencial. E mesmo assim a gente ainda avalia ele antes de contratar.

Eu não estou dizendo que automaticamente todo mundo que faz curso comercial online é ruim. Pelo contrário, já conheci muitos programadores que se tornaram muito bons. Mas normalmente a pessoa que já tem o que precisa e sabe aprender sozinho, não foi o curso que o tornou bom. Com ou sem o curso ele já tem propensão e principalmente vontade de aprender, a despeito da qualidade do curso.

E mesmo depois de tudo isso, um estagiário meu ainda não está preparado pra entrar num projeto de verdade. Raramente é possível alocar um estagiário num projeto no primeiro mês. A maioria fica 3 meses ou mais só estudando. Nesse período ele precisa cumprir as 6 horas dele presencialmente nos nossos escritórios, e se integrar com os funcionários mais experientes. Eu já disse em outros videos que eu acho que nesse estágio de iniciante é extremamente prejudicial ser home-office, porque o aprendizado vai ser ordens de grandeza menor. Ele precisa estar do lado de gente mais experiente.

Durante esse período de estágio, ele participa de projetos internos, aprende a se comunicar com seus pares nos escritórios, aprende a pedir ajuda quando precisa, toma porrada nas revisões de código, é avaliado com alguma frequência pra ver se tá estagnado ou se tá evoluindo. Algumas vezes, quando ele é sozinho mais acelerado, até consegue participar como um programador não cobrado em projetos pequenos de verdade. Quando ele é efetivado como júnior depende muito mais dele do que da gente.

Esse é o período de treinamento no estágio. Nós não oferecemos nenhum material formal de aprendizado, em vez disso nós temos ebooks e algumas contas de cursos online que ele pode fazer. E nesses casos eu aprecio o uso de cursos online: como uma forma resumida de absorver algum assunto muito rápido pra pessoas que já tem uma fundação. Eu mesmo esses dias queria relembrar sobre React, porque eu não sou front e sim back, então assisti os cursos iniciais da Pluralsight na velocidade 2X porque eu acho todo video de curso hiper lento. E em 2 dias eu fiz o curso todo. E eu não estou endorsando a Pluralsight não, foi aleatório.

Além disso ninguém na empresa tem função específica de ser professor, não existe uma estrutura de aula nem palestras que ele precisa assistir, nem nada disso. Nós vamos jogando problemas do dia a dia pra ele resolver e ele precisa demonstrar que tem interesse em usar esse tempo. Inclusive ele está sendo remunerado, pra estudar muito. Como ele tem contato com os programadores experientes que estão em projeto, ele naturalmente começa a entender como os projetos funcionam e como nos comunicamos com clientes, na prática. Não existe um guia ou protocolo de comunicação.

Mais do que isso, nós não temos as figuras formais de gerentes ou qualquer coisa assim. Todo funcionário fala diretamente com o responsável do projeto do lado do cliente, sem um intermediário responsável em micro-gerenciar. Todo funcionário sabe que não deve só receber tarefas e fazer às cegas; aos poucos ele vai aprendendo a questionar as coisas, inclusive se ele deveria estar fazendo o que foi pedido e se não existem formas melhores e mais eficientes pra resolver o mesmo problema. E ele tem autonomia de dizer isso diretamente pro cliente. Isso faz parte do dia a dia de todo Miner. Sem micro-gerenciamento. Eles simplesmente sabem o que tem que fazer. Inclusive quero dizer que estou muito orgulhoso deles porque dia 13 de março comuniquei todo mundo pra antecipar a quarentena por causa da pandemia. Todo mundo começou a trabalhar de casa e todo mundo sabia o que tinha que fazer, sem precisar dar ordens ou instruções extras.

Eu imagino que muitos dos estagiários novos devem estranhar ter tanta liberdade logo no começo, mas ele não pode cruzar os braços, porque com tanta autonomia significa que temos tolerância zero com falta de profissionalismo ou mal caratismo. Zero mesmo, se alguém fizer alguma coisa mal caráter é demissão instantânea. Erros a gente sabe que todo mundo comete, mas se ficar cometendo o mesmo erro com frequência, toda vez, também não vai durar. É comum a gente repetir que se a pessoa se ver de braços cruzados sem fazer nada, ela está errada, porque devia estar caçando coisas pra fazer.

E por que tô contando toda essa história? Porque eu acredito que o jeito certo de aprender é esse: 1) dando problemas pra serem resolvidos 2) não ter nenhum material oficial, e sim forçar as pessoas a saber encontrar os materiais que precisam 3) não ter nenhum supervisor ou chefe que dá mastigado, forçando a criar senso de autonomia e responsabilidade. Pronto, acabei de resumir a metodologia inteira em 3 frases. E por hoje é só, a gente se vê semana que vem …. E, não, tô brincando, deixa eu explicar isso.

Contraste o que eu acabei de falar com o que você conhece normalmente como “cursos”. Um curso tradicional tem material didático específico pro curso, apostilas, passo a passo de tudo que você precisa fazer, e tem uma figura de autoridade na forma de um professor que vai te dizer o que tá fazendo certo ou errado. No final, talvez tenha uma provinha, e ganha um certificado e pronto. Esse formato tem pouca serventia. Os alunos que realmente tem potencial e gostam do assunto vão estudar outros materiais fora do curso, vão fazer experimentos, vão discutir com amigos. Os acomodados que nem sabem porque tão ali, vão seguir o passo a passo e fazer o mínimo esforço pra tirar a média e ganhar o certificado. Ambos no final ganham certificado e por isso eu não uso esse formato e por isso eu não valorizo papel.

Um bom curso deveria ser difícil, extremamente difícil aliás, pra servir de filtro e separar quem realmente quer aprender daqueles que tão ali mais pra agradar o pai que paga o curso, ou porque só quer arranjar logo um emprego fácil que paga bem. Além disso um curso não deveria ter um currículo totalmente fixo; ele deveria ter uma fundação obrigatória de conceitos que não são “cool” de aprender mas que são obrigatórias pra passar pras coisas que as pessoas realmente querem. Assim como engenharia numa federal, onde os dois primeiros anos é igual pra todo mundo e só depois eles escolhem civil ou naval ou elétrica e assim por diante. Mas a fundação deveria ser obrigatória. Não deveria existir a escolha de fazer um curso de Javascript sem o requerimento de ter feito, por exemplo, curso de algoritmo e estruturas de dados antes.

Além disso, não deveria ter um professor falando e os alunos só ouvindo, seja numa classe ou seja online num EAD. A figura do professor deveria ser como eu falei dos meus funcionários mais experientes, eles estão ali do lado do estagiário de suporte mas não tem nada estruturado. É o contrário, é o estagiário que tem que aprender a pedir ajudar e aprender a fazer perguntas inteligentes. Mesma coisa num curso, o aluno deveria só receber um monte de problemas pra resolver, sem livros, sem material didático, sem nenhum passo a passo, e usar seus colegas e professores pra responderem perguntas pontuais. Isso porque a primeira coisa que os alunos deveriam aprender a fazer é formular perguntas que façam sentido.

O mundo não é simplezinho assim, que tudo funciona organizado, bastando saber um passo a passo de coisas e tudo se resolve. Muito pelo contrário, o mundo de verdade é complexo, desorganizado, caótico e só quem consegue ir pra frente é quem sabe fazer as perguntas certas. Inclusive faz parte da idéia do 42 do nome da minha empresa que, se alguém tinha essa curiosidade, sim, vem do Guia do Mochileiro das Galáxias. O que é 42? Como diz no Guia é a resposta pra vida, pro universo e tudo. E o que isso quer dizer? Absolutamente nada, a pergunta foi mal feita e por isso a resposta não tem sentido nenhum. Essa é a moral da história, a resposta certa depende da pergunta correta.

Só que como eu disse no meu video de Não Terceirize suas Decisões: você passou sua vida inteira estudando nesse formato de passo a passo, currículo bem definido, professor que é a autoridade, continuar sendo passivo copiando matéria da lousa e não pensando muito, e se contentando em tirar 5 na prova e passando de ano, ficando com a falsa impressão que tava aprendendo alguma coisa. E é um dos motivos de porque os iniciantes ficam tão impressionados com tech startups de piscinas de bolinhas, que pegam na sua mão, te dão almoço, lanchinho, trocam sua fralda e cuidam de vocês como se fossem crianças. Eu, por outro lado, acredito em contratar adultos, eu não sou creche.

Chega de falar da minha empresa,o objetivo não é fazer propaganda, mas o contexto é que a gente não faz tudo isso desde o começo. Fomos aprendendo enquanto fazíamos, é um processo de aprendizado pra todo mundo. Já discutimos internamente até em fazer alguma coisa como uma CodeMiner Academy alguns anos atrás, com material didático, conceito de turmas e professores e tudo mais. Ainda bem que essa idéia nunca foi pra frente. Intuitivamente tanto eu como meu sócio acreditávamos na idéia de colocar estagiários juntos com sêniors, dar problemas e tarefas, e avaliar como eles resolvem e como eles evoluem ao longo do tempo. E esse acabou se tornando o modus operandi até agora.

Só cursos online é muito pouco. Em alguns momentos eles servem como um pequeno aquecimento. E só cursos são insuficientes, então tem ebooks, posts de blog, ler o código-fonte das coisas e assim por diante. Mais importante, eu não dito pra eles o que eu acho que eles deviam estudar. Muitos de vocês ficam me perguntando que materiais ou cursos eu indico. Entenda, eu não indico nem pros meus funcionários, eu quero que eles se virem sozinhos, porque eu acredito que encontrar o melhor material faz parte do treinamento. Se a pessoa sequer gasta um pouco de tempo e neurônios no exercício de avaliar material, como ele espera um dia virar programador?

Sem querer, o tipo de ambiente que criamos força as pessoas a aprenderem o famoso “se virol”. Essa é definição de Aprendendo a Aprender, é se virar, de verdade. Bicicleta sem rodinhas, caindo e tentando de novo. Eu fiz um video chamado A Dor de Aprender onde eu digo o seguinte:

[trecho - ini] O prazer de um autodidata é provar pra ele mesmo que ele suporta a dor. A gente sente dor, igual todo mundo, mas em vez de evitar a dor, a gente faz esforço pra se acostumar a sentir dor. É bem doloroso quando você faz um curso, lê um livro, e seu código ainda não funciona ou você nem sabe como fazer um código diferente do que foi ensinado. É super frustrante. E sua primeira reação é o que? O curso é que não deve ter sido bom. Ou deve ter outro livro que vai ensinar de verdade o que precisa saber. Desculpe se eu sou o primeiro a dizer isso: a menos que você esteja disposto a encarar a dor, engolir o choro, esquecer a frustração, e começar a cair e ficar roxo na frente dos outros, não adianta nenhum curso, nenhum livro, nada, você nunca vai aprender. Ou você pára de desperdiçar dinheiro indo atrás de fórmula mágica, ou engole a dor, pára de mimimi, se compromete e foca no objetivo. [trecho - end]

Meu mantra sempre foi: no pain, no gain. Estávamos numa bolha onde tudo era fácil, então começou a se popularizar a noção errada que ninguém deveria sentir dor, de nenhum tipo, incluindo se sentir ofendido. Tá errado. Se não está doendo, só quer dizer que você não está tentando com força o suficiente. Se você não está se sentindo frustrado, desmotivado, ansioso, estressado de tanto tentar e não alcançar, então não é aprendizado. O mundo não foi feito pra ser fácil, tudo tem que ser conquistado. Conhecimento tem que ser conquistado. Tem uma frase que eu tenho repetido recentemente entre amigos pra ilustrar a próxima crise: tempos difíceis criam pessoas fortes, pessoas fortes criam tempos fáceis, tempos fáceis criam pessoas fracas e pessoas fracas criam tempos difíceis.

Deixando claro, eu não sou contra os diversos cursos comerciais, nem faculdades particulares, nem EAD. Eles funcionam dentro do que se propõe: dar uma introdução de algum assunto de uma forma um pouco mais organizada. O objetivo é usar esses cursos onlines como mais uma ferramenta, pra rapidamente ter uma introdução, sabendo que vai aprender o 1%. Os 99% seguintes você vai ter que caçar sozinho à medida que vai precisando. Não existe nenhum curso que vai ter dar nem perto dos 100%. E vai ser sempre mais difícil se você evitar o esforço de ter fundações sólidas. Se você entende esta verdade, não existe nenhum problema em usar nenhum curso.

Duas coisas que as pessoas me mandam nos comentários dos vídeos ou em mensagens diretas, por que eu não monto um curso? E a resposta é simples: porque cada assunto de tecnologia já tem material suficiente na internet. Tem gente com mais paciência do que eu criando conteúdo didático. Eu não tenho paciência pra repetir o que já existe. E também por isso você raramente vê videos de tutoriais no meu canal. Esse tipo de video envelhece muito rápido. Quando sai uma nova versão, o video já ficou obsoleto. E eu não quero conteúdo que fica obsoleto tão rápido assim. Eu só quero produzir conteúdo que não se encontre facilmente por aí, parte da tal fundação que eu tanto falo.

No começo de 2019 eu comecei uma série de vídeos que era intitulada Começando aos 40 e depois renomeei a playlist pra Programação pra Iniciantes. Ela não ensina Javascript, nem Python, nem nada da moda. Eu explico os conceitos mais básicos. O que são processos? O que são threads? O que é alocação de memória? Quais os diferentes jeitos de alocar memória? O que é um scheduler? Quais os diferentes tipos de schedulers? Qual a diferença de um hypervisor e um container? Eu não consigo entender como alguém pode se dizer programador e não saber esse básico. E é por isso que muita gente tem dificuldade de mudar de linguagem ou ferramentas. Como elas aprenderam só “como” usar a ferramenta mas nunca “por que” a ferramenta existe, toda nova ferramenta confunde elas.

Aprender uma nova linguagem é fácil pra quem tem as fundações. Mas pra quem só fez cursos superficiais, estilo passo a passo, sempre acha difícil mudar de linguagem. E como ele estudou do jeito errado que expliquei, quando ele consegue fazer um código que roda, se apega a isso. A pessoa tende a se tornar escrava da ferramenta que aprendeu primeiro, porque foi difícil. E isso é o primeiro grande erro que todo programador iniciante comete: ele se torna seguidor cego de marcas, criando uma falsa sensação de validação, que seus esforços valeram a pena, e qualquer um que fale diferente tá errado. E eu falei disso lá no começo do canal nos dois vídeos que intitulei “Sua Linguagem Não é Especial”:

[trecho - ini] Também como disse no episódio de faculdade, eu comecei no fim dos anos 80, passei por Basic, dBase III, Clipper, Turbo Pascal 6, Visual Basic 6, Delphi desde a versão 1.0, Perl desde a versão 5 - se bem que ela nunca saiu da 5, PHP desde a 3, ASP clássico, .NET C# e VB.NET desde a versão 1.0, Java desde a versão 1.0, Javascript desde antes de virar padrão ECMA, Python 2. E isso foi só até o fim dos anos 90.

Se tem uma coisa que vocês devem levar deste episódio é o seguinte: linguagens de programação Não são filosofias de vida. Linguagens de programação são meras ferramentas. Ferramentas foram feitas para servir seus mestres, e não o contrário. Linguagens de programação não merecem lealdade e definitivamente não são religiões. Eu não sou definido pela minha linguagem de programação favorita. Você não é sua linguagem de programação. [trecho - end]

Independente se você pode fazer uma boa faculdade, ou se só tem condições de fazer pequenos cursos comerciais ou EADs, isso não importa. Todo material é material. Parta deste princípio: muitos programadores como eu começaram sem acesso a nenhum material. A gente precisava primeiro achar alguém que tinha pra pegar emprestado e tirar xerox em papel. Eu aprendi a programar antes da existência da internet. Eu pegava ônibus pra ir longe na casa de alguém que tinha algum programa ou material que eu não tinha pra pegar emprestado. Hoje vocês tem centenas de conteúdos gratuitos na internet e tão de mimimi? Pelamordedeus, você quer aprender esse troço ou não quer? Aprende a se virar.

A conclusão do que é Aprendendo a Aprender é isso: aprender a se virar, sem precisar da validação de ninguém, sem ninguém pra pegar na sua mão ou te dar tapinha nas costas, mergulhar em problemas que você não sabe resolver, sofrer, se frustrar mas continuar sem desistir, apesar da dor. Esse é o filtro. Quem persiste e passa obstáculo atrás de obstáculo, é quem tem maiores chances de chegar em algum lugar. Nada que não te faça sentir dor tem valor. No pain, no gain. Lembram do meu vídeo “Faça aquilo que Ama, só que não”? Se você realmente ama alguma coisa, você não deveria desistir só porque tá doendo. Por outro lado, se você só quer as partes boas, você não ama de verdade, só é preguiçoso.

[trecho - ini] Você tá frustrado no seu emprego, pensando em mudar de emprego? Você tá frustrado com seu mundo? Quer mudar de mundo? Não adianta. Enquanto você tá frustrado com sua falta de esforço, qualquer emprego, qualquer lugar, vai terminar do mesmo jeito, porque a realidade é que tudo tem partes ruins, todo trabalho tem partes chatas, a VIDA tem muitas partes chatas. Começa fazendo as pequenas coisas direito, e vai se acostumando a parar de justificar sua frustração como sendo culpa da sua família, dos colega, do seu chefe, do dos políticos. Apontar defeitos dos outros é simples, qualquer idiota pode fazer isso. E os seus? Começa a onde realmente importa: tomando controle do que você mesmo faz. Já que vai fazer, faz direito, qualquer coisa. Em vez de dizer pros outros como fazer certo, que tal mostrar pros outros como fazer certo? [trecho - end]

O maior medo que todo mundo tem quando começa a tentar aprender é se tem falta de talento. Isso é um assunto controverso e existem argumentos diferentes dependendo de pra quem perguntar. Eu realmente não acredito tanto em gente que nasce talentoso, ele pode nascer com propensão a certos tipos de atividade, mas não nasce sabendo. O que diferencia as pessoas que você chama de “talentoso” de você é a quantidade massiva de prática deliberada que ele fez. É o que eu explico nos meus episódios de Talento: Matando Semi-Deuses. Particularmente na parte 2:

[trecho - ini] Prática deliberada é sobretudo um esforço de foco e concentração. É isso que o torna “deliberado”. Continuamente procurando exatamente os elementos de performance que são não satisfatórios e então forçando na melhoria especificamente desses elementos. Digamos, em programação, muita gente acha difícil escrever bons testes. Porque não pratica? Escreva centenas de testes. Não só pros projetos do seu trabalho, que como eu já disse, é insuficiente. Escreva, escreva, escreva. Vai sair um monte de porcaria no começo. E pra evoluir você precisa fazer o que Mozart fazia: copiar, testar, avaliar, corrigir e recomeçar, e recomeçar, e recomeçar, centenas de horas. [trecho - end]

Assistam esses vídeos pra entender que um Einstein ou Mozart não eram deuses, eles eram humanos, e humanos que treinaram dezenas de milhares de horas a mais que um ser humano normal, é por isso que eles tiveram resultados acima do normal. Não porque eles eram deuses, mas porque você não tá disposto a se esforçar como eles. Não desvalorize o esforço que eles tiveram dizendo que era só talento. Se eles são reconhecidos hoje foi resultado do esforço monumental que eles fizeram.

Finalmente, chegamos à parte final deste vídeo. O objetivo de dar mais esse tapa na cara é acordar vocês pra uma nova realidade. A bolha estourou, tá acabando a vida fácil. Eu sei que muita gente assistindo tá até pensando “do que esse cara tá falando, minha vida sempre foi difícil”. Sim, eu sei. Isso foi pro playboy da capital que o pai paga as contas, não se esforça pra nada, só reclama, e ainda se acha vítima da sociedade. Pra quem a vida já tava difícil, sinto dizer que pode piorar. Então, pra quem tem a sorte de ter condições e quer entrar no novo ciclo de tecnologia, prepare as fundações. Gaste o tempo e o esforço necessários, aprenda a se virar.

Sobre cursos e livros, parem de me perguntar recomendações e parem de perguntar pra outros influencers que você sequer sabe se eles realmente sabem programar de verdade. Na prática, qualquer curso e qualquer livro servem. Não é a qualidade do material técnico que faz um programador ser bom. Vou repetir, eu não fiz nenhum curso da atualidade. Quando eu quero saber que livro ler, eu vou no Google e pesquiso “best books of .. Go” e pronto, tirando quando eu conheço o autor, eu vou na primeira opção. E à medida que vou me aprofundando, daí procuro outras referências de partes específicas. Não tô nem aí se influencer fulano ou beltrano recomenda ou não recomenda.

E se tem uma coisa que é básico e você precisa ir estudar e levar a sério o quanto antes é inglês. Não é uma coisa que fazendo um curso você aprende, você precisa incorporar no seu dia a dia. Eu fiz um vídeo inteiro chamado Como eu aprendi Inglês. Quando eu tava na faculdade também male male sabia ler o básico e não falava nada.

[trecho - ini] TUDO que sai de mais importante na área de tecnologia sai primeiro em INGLES. Sabe o que acontece se você depende de material em português? Você precisa esperar essa tecnologia ganhar público, alguém se arriscar a traduzir material em português e publicar aqui. E todo mundo sabe que todo projeto open source, principalmente nas primeira iterações, muda o TEMPO TODO. [trecho - end]

[trecho - ini] Mundo open source é assim mesmo. E se por acaso um novo projeto consegue ganhar o seu público de early adopters e começa a ter demanda, sabe quem ganha mais dinheiro? Quem aprendeu sobre o software antes mesmo de ter saído a versão 1.0. Depois que saiu a versão 4, 5 etc que já tem livro, já tem curso, já tem toneladas de screencast, é quando o taxa/hora vale menos, 2x, 5x, 10x menor do que era pago pra quem se arriscou e aprendeu na versão 0.1 alfa. [trecho - end]

Isso tudo dito chegou a hora de fazer uma coisa que eu achava que nunca fosse fazer no meu canal: falar de uma escola de programação. Este canal é exclusivamente produzido como se fosse um backup do meu cérebro. Ele tem começo, meio e um dia terá um fim. Eu expliquei isso no meu video sobre o diário de Henry Jones:

[trecho - ini] Em retrospecto, tudo que eu faço eu faço pra mim, nunca pros outros. Eu sempre fiz tudo sem buscar validação. Eu não preciso muito que os outros digam que estou fazendo certo ou errado. Eu escrevi e gravei sobre porque você não deve procurar fazer só o que ama. Como eu disse naquele vídeo, eu não amo ficar varando noite pra editar vídeo, mas eu gosto de assistir o resultado tipo “da hora, pra um amador como eu, até que esse vídeo não tá vergonhoso, mas eu sei que posso fazer melhor”.

Deve ser muito frustrante quem faz as coisas esperando a validação de alguém. Eu não entendo muito quando as pessoas reclamam que ninguém elogia ou dá feedback positivo no trabalho delas. Me soa muito com uma extrema falta de capacidade de auto-crítica. Eu dou feedback pra mim mesmo. Eu nunca fiz nada porque alguém me motivou. Eu me motivo sozinho. Eu me sentiria muito mal se pra tudo que eu fosse fazer eu precisasse ser validado. [trecho - end]

Um pouco de história, na França surgiu um dos maiores campus de startups, a Station F no começo dos anos 2010, fundada pelo bilionário Xavier Niel. Não notem minha tentativa pobre de sotaque de francês. Enfim, também na França surgiu uma rede de escolas particulares de programação chamada Equitech fundada em 1999 por Nicolas Sadirac com uma proposta bem à frente do seu tempo onde os estudantes ensinam uns aos outros. Pelo menos na época foi considerada uma das melhores escolas de programação. Em 2014 Xavier resolveu doar 50 milhões de euros pra um novo projeto de educação, uma escola sem fins lucrativos com uma nova metodologia de ensino para formar os melhores programadores. Xavier trouxe Sadirac pra dirigir a primeira unidade e hoje ele continua como diretor-geral. Eu imagino que ele trouxe a experiência de suas próprias escolas particulares Equitec pra essa nova empreitada que eles chamaram de École 42.

Essa escola abriu unidades em várias partes do mundo, incluindo no Brasil em 2019. Eis que em 12 de fevereiro de 2020 um aluno dessa recém formada escola que aqui foi batizada de 42 SP, o Salem, me manda um direct pelo Twitter, que eu vou ler pra vocês aqui: “Eu sou aluno de uma escola de programação que veio da França para São Paulo e oferece curso de programação de maneira gratuita a todo tipo de pessoa e em qualquer faixa idade. Para você ter uma ideia a média dos alunos é de 36 anos e existem alunos das mais variadas profissões (médicos, arquitetos, geólogos, matemáticos e muitos engenheiros). Eu por exemplo sou da área de engenharia Civil e estou em busca do meu sonho que é viver de programa…..rsrsrs O curso básico começa em programação em Shell, C, Git e assembly que não é nada básico. Criação de Shell scripts, criação das nossas próprias bibliotecas em C desde memcpy, calloc, atoi, itoa indo até o famoso printf … O curso dura de 3 anos a 5 anos“

Nas primeiras frases que ele falou em curso, eu já imaginei “puts, mais um curso”. Mas quando ele falou que começam a aprender o shell de Linux, linguagem C, Git, assembly e criando as próprias bibliotecas de C com funções básicas como mem copy, funções como atoi que transforma strings em inteiros e assim por diante, antes de chegar em coisas como Python ou Javascript, certamente chamou minha atenção, porque tirando uma boa faculdade, nenhum curso online que eu opera dessa forma. Então começamos a conversar e o Salem se propôs a falar com a administração da escola pra de repente eu ir visitar.

Daí quem me manda mensagem é um dos fundadores da 42 SP, o Guilherme Décourt, que por acaso eu já cheguei a conhecer brevemente, anos atrás, quando minha empresa prestava serviços pra várias startups da VC Monashees, e o Guilherme era um dos sócios. Então eu fiquei sabendo que ele saiu da Monashees, se uniu com a publicitária Karen Kanaan e conseguiram trazer a École 42 pra cá. Ok, agora eu fiquei mais interessado ainda e eu precisava ver isso com meus próprios olhos. Nós marcamos e poucos dias depois fui visitar a escola, que fica no Alto de Pinheiros aqui em São Paulo, na famosa rua Aspicuelta que todo mundo aqui conhece pelos bares e atividade noturna.

O espaço que eles conseguiram é impressionante, realmente parece uma escola moderna, com dezenas de iMacs em uns dois andares, fora a cobertura. A decoração é moderna e bem artística do jeito que eu gosto. Só pelo espaço eu já gostei, mas claro que só isso não é suficiente, então eles começaram a me contar mais da história. Pra começar, o material de ensino vem toda da École 42 da França, eles vêm até o Brasil pra instalar os servidores com tudo que os alunos vão usar. O sistema é todo gamificado e cada aluno tem um perfil onde ele mesmo pode acompanhar seu progresso.

Ah sim, antes de continuar vale fazer um disclaimer. A 42 SP não me patrocinou pra fazer este vídeo. Nem eu mostrei este vídeo antes de publicar no canal, então eles tão vendo ao mesmo tempo que vocês. Portanto nada do que eu disser considere como oficial, estou apenas relatando minhas impressões pessoais e dando minha opinião. Do mesmo modo, a 42 SP não necessariamente compartilha de todas as minhas opiniões. Somos duas entidades independentes e por isso eu posso dizer que minha opinião não foi enviesada.

Voltando, o conceito da 42 é que eles não tem turmas e nem professores. Mais do que isso, eles não tem apostilas nem material didático próprio. Eles também não obrigam alunos a comprar livros nem nada disso. Cada aluno evolui no seu próprio ritmo, com um requerimento que passa a ser natural de um ajudar o outro. Até parte da avaliação dos alunos é receber feedback online de quem ele ajudou. Assim como na minha empresa, quem tá lá só pra codar e ficar isolado e não ajudar ninguém, ele perde seu seu espaço. Na 42 SP, é um requerimento estar no mesmo espaço físico e ajudar seus pares. Por isso eles não tem intenção de ser um curso online.

As matérias são organizadas no que eles chamam de galáxias. Pense o conteúdo organizado na forma de anéis, os do centro são a fundação obrigatória e à medida que ele vai passando de nível vai abrindo os anéis superiores, até chegar em matérias opcionais onde ele pode escolher, por exemplo se for web, se quer começar aprendendo Ruby ou PHP. Ou ele pode não querer web e se especializar mais em segurança. O importante é que você só abre esses anéis se passar pela fundação, no centro da galáxia. Que é 100% o que eu vim dizendo até agora. No total são 21 níveis, que dependendo da pessoa pode levar 3 ou 4 anos. Ou seja, não é curso superficial de 3 meses. A partir do nível 7 você já poderia ser considerado talvez um nível júnior pro mercado, ou o que na minha empresa seria nível estagiário. Eu ainda não posso opinar sobre isso porque não avaliei um aluno nível 7 pessoalmente, mas pelo que vi parece fazer sentido.

Se você assistiu meu vídeo de Devo Fazer Faculdade - 22 anos depois, eu explico minha teoria das pirâmides do conhecimento. Não é a mesma coisa que os anéis da Galáxia da 42 mas são conceitos similares de conhecimento progressivo:

[trecho - ini] Daí eu criei uma noção na minha cabeça que pretensiosamente eu chamava de Teoria das Pirâmides. Tudo que eu aprendi até o fim do colégio era o pequeno topo de diversas pirâmides. Pirâmide de matemática. Pirâmide de Português. Eu nunca ia saber tudo sobre tudo. Em vez disso eu falava pra mim mesmo que deveria aprender o topo de muitas pirâmides, e à medida que eu fosse avançando, iria descendo nessas pirâmides. E eu pensei em pirâmides meio como a dificuldade, o topo é menor, a parte mais fácil, a base é maior, as partes mais avançadas, quanto mais você desce na pirâmide, mais difícil fica. Muitos pensam em ir completando uma pirâmide inteira de cada vez e eu sempre achei isso ineficiente.

Antes da faculdade, e até talvez o primeiro ano, eu tentava ler os livros inteiros, mas antes dava, porque não tinha muito mais pra se ler. Na faculdade eu vi que isso não iria acontecer mais. Antes meu mundo se restringia a uma dúzia dessas pirâmides de conhecimento. Foi quando eu parei de tentar ler livros técnicos inteiros, eu só lia a introdução. (pegue o livro) E ia avançando se precisasse. Em vez de ler 1 livro inteiro, era melhor ler o começo de 10 livros. E gastava mais tempo praticando do que lendo.3 [trecho - end]

Agora eu gosto mais da analogia de galáxia também. E nesse mesmo vídeo eu falo sobre um problema que muita gente que faz cursos online e aprendem só o básico enfrentam sem saber:

[trecho - ini] Existe uma enorme armadilha no começo de carreira: a minha teoria das pirâmides tem outro detalhe: só de aprender o topo da pirâmide, você consegue entregar um projeto. Hoje em dia eu ilustro isso como o problema dos 80/20. Com 20% do conhecimento você consegue resolver 80% dos problemas. Mas pra resolver os últimos 20%, vai precisar dos 80% de conhecimento que ainda não tem.

Com meus pífios 20%, eu entregava projetos. O perigo era eu achar que já era bom, eu entendia isso. O que me mantinha no chão é que pra entregar esses projetos eu varava muitas noites corrigindo bug. Na minha cabeça, se eu não consigo entregar com menos bugs e se eu não consigo entregar só no horário do trabalho, era minha falta de experiência. Esse era meu termômetro de competência. [trecho - end]

No caso da 42 eles tem um problema similar só que mais pra 30/70, mas a idéia é a mesma. Muita gente a partir do nível 7 já sabe o suficiente pra ser útil num projeto ou startup e consegue um emprego. Ainda mais na bolha que tava. E eu sei a sensação porque eu também abandonei a faculdade. Na minha época começou a Bolha das Pontocom no fim dos anos 90. E que também acabou na Crash do ano 2001. Parece que alguns alunos da 42 chegam nesse nível 7 e com o trabalho acabam desacelerando e até deixando a escola. Isso é o problema velho problema de afobação. Mas no video da semana passada eu declarei que a bolha estourou, e foi isso que eu disse e que vale pra esse pessoal:

[trecho - ini] Pra quem é jovem e estava afobado porque parecia estar atrasado pra entrar num mercado que não parava de crescer, pause um segundo, os mercados pararam de crescer. Na realidade o que vai acontecer é muita demissão. Por isso o valor de um profissional medíocre vai cair. Lembra? Oferta e demanda. Vai haver muita oferta, muito estoque sobrando, de pessoas que só fizeram cursos básicos ou tiveram formação inadequada e vai crescer a demanda por profissionais bem preparados, que já são raros hoje. Vocês acabaram de ganhar uns 2 anos ou mais pra estudar com calma, criar fundações sólidas, como eu venho repetindo sem parar em vários videos do canal.

E quando a maré virar, o mercado vai precisar de gente bem preparada. Eu disse isso antes e vou dizer de novo: com ou sem crise, o mercado sempre tem espaço pra gente competente de verdade, aquele que realmente faz a diferença no resultado da empresa. E agora você vai ter menos concorrência, porque a maioria quis pegar atalho pra surfar a onda, não fez fundações sólidas, escolheu cursos mais por serem curtos do que por serem bons. Evitaram as coisas difíceis e como o mercado só crescia, eles tinham espaço. Esse espaço vai começar a desaparecer a partir de agora. Eu disse isso no meu vídeo de Programação não é Fácil, se você tem uma posição que não é fundamental pra sobrevivência da empresa, fique preocupado. Claro, com o resgate do FED ainda vão sobrar muitas, mas se tudo der certo, pelo menos as piores vão falir. [trecho - end]

A vantagem do sistema de não ter turma nem professor é que o seu ritmo não é freado pelo ritmo do aluno mais fraco. Você pode avançar no seu próprio ritmo. Quando tem dúvidas sempre tem alguém na sua frente que pode te ajudar. E por sua vez, sempre tem alguém um passo atrás precisando da sua ajuda. Isso é muito importante porque você exercita colaboração de verdade, coisa que nunca acontece numa sala de aula de curso, nem de faculdade. Aliás, quando eu tava no colégio eu odiava trabalhos em grupo. Só significava que ninguém se esforçava, deixava tudo nas minhas costas pra fazer, e no final só queriam que eu colocasse os nomes deles antes de entregar. É um lixo esse sistema porque não existe motivação pra ninguém colaborar.

E porque na 42 SP seria diferente? E aqui vem a outra parte que me convenceu neles. Eu disse que a 42 SP, assim como a École 42 e todas as outras subsidiárias são organizações sem fins lucrativos, ou seja, eles não vivem de mensalidade dos alunos e sim de doações de fundos de investimento ou de empresas que acreditam na causa. O próprio prédio onde eles estão foi doação do dono do prédio. Os iMacs todos foi um programa da Apple onde eles deram um puta desconto.

Os alunos não pagam nada. É tudo gratuito. Por causa disso eles podem se dar ao luxo de selecionar os alunos que entram e até expulsar quem tá atrapalhando ou nem tá querendo colaborar. É a mesma coisa com minha empresa, porque eu pago salário pra estagiário sem ele estar trabalhando pra nenhum cliente, só pra estudar e colaborar. Por isso se ele não usa o tempo dele pra evoluir, está tomando o lugar de outra pessoa mais esforçada. Tão entendendo os paralelos?

Quando eles abrem inscrições, rola 2 provas online de lógica, sem código. Eu não lembro de cabeça os números então vou só chutar a ordem de grandeza, mas sendo escola gratuita e com pedigrée francês, obviamente milhares de pessoas do país inteiro se inscreveram. Eles estabelecem tipo uma nota de corte e só os 300 ou 400 melhores são escolhidos. Depois disso eles precisam ir pessoalmente pra participar de algumas reuniões presencialmente. Só de não ser curso online, um monte já desiste. E eu gosto desse conceito porque se a pessoa não tem comprometimento nem pra ir lá pessoalmente, provavelmente não tá levando a sério o suficiente, e só nisso muitos já desistem.

Depois dessas reuniões inicia uma fase chamada de Piscina, e até eu quero roubar esse nome agora. Pense se fosse uma escola de natação, a idéia é jogar todo mundo na piscina e deixar se virar pra não afogar. Quem sobrevive vira aluno. Essa piscina é uma imersão presencial de nada menos que 28 dias seguidos, onde de cara recebem dezenas de problemas de programação pra resolver. Isso mesmo, eu achei sensacional, a pessoa chega e recebe um computador, uma conta na escola, a lista de problemas que precisam resolver com código e só. Não tem instrução, não tem aula, não tem material didático, não tem professor apresentando matéria. É um por todos e todos por um. Cada um vai resolvendo, ajudando os outros e avançando como puder. E a escola fica aberta 24 horas por dia todos os dias, então quem quiser pode até varar noite se quiser.

É uma versão bem mais puxada do meu estágio, onde o estagiário não tem nada estruturado, as coisas vão aparecendo e ele vai tendo que se virar. Eu achei esse conceito sensacional porque essa é a seleção final. Então foram tipo 3 etapas de seleção pra separar quase 200 alunos dentre milhares que se inscreveram. Eles fazem o que eu falei que eu gosto das faculdades federais e que os cursos comerciais não fazem: os recursos não são infinitos, e os alunos não pagam mensalidade, portanto eles precisam selecionar quem parece que vai tirar melhor proveito do material disponível. Uma pessoa que tem dinheiro pra pagar mas não tem interesse nem esforço só estaria desperdiçando o lugar de outra pessoa.

Daí eu pedi que eles me mostrassem o pouco material que eles dão pro aluno, a lista de problemas. E de fato, cada problema é um pequeno pdf de umas 3 ou 4 páginas, declarando o problema, declarando os critérios pra passar, o que eles não podem usar, e o que é esperado. Por exemplo, mesmo em faculdade ou tecnólogo que começa com a linguagem C, a gente começa fazendo algoritmos e programinhas simples. E bem naturalmente a vai aprendendo a usar malloc pra alocar memória, free da desalocar, memcpy pra copiar o conteúdo de uma variável em outra variável, sizeof pra saber o tamanho do tipo de uma variável, printf pra printar mensagens formatadas no saída padrão do terminal e assim por diante.

Mas o PDF inicial que eu vi era mais hardcore. Pra começar é tudo em inglês! E isso eu também achei sensacional porque é realmente zero muletas, zero rodinhas na bicicleta. Eles tinham que implementar as próprias funções básicas da biblioteca C, o próprio memcpy, o próprio printf, exatamente como o Salem me contou no Tweet dele. Nem eu nunca tive que fazer isso. E confesso que fiquei com vontade de sentar naquele computador e começar a resolver o problema.

Pensa uma pessoa que nunca programou uma única linha de código na vida ou no máximo fez tutoriais de Javascript, lê esse PDF. E é só isso. No final, quando ele terminar o código, precisa subir no Git da escola onde alguns problemas parece que tem o equivalente de um CI, um continuous integration, que roda um script de teste automatizado pra avaliar e tem professores que fazem a revisão desse código. Então esse aluno precisa, do zero, sem aula e sem material didático, descobrir como usar um editor de textos, descobrir o que é um compilador, descobrir como debugar. Daí precisa aprender sozinho o que é C, como é uma função main básica, o que é um ponteiro, o que é um loop. Daí como funciona o git até conseguir subir o resultado pro repositório da escola. E tudo isso num único problema, logo no primeiro dia, e são centenas deles.

Se conseguir chegar na área de segurança você vai ter que construir seu próprio malware do zero. Se for mexer com redes vai ter que descobrir sozinho o que é OSI até montar seu próprio protocolo. Se for pra games vai ter que montar sua própria engine gráfica do zero. E é assim com todas as áreas de conhecimento. Alunos que começaram do zero depois da piscina, acho que 6 meses depois estão todos usando shell, usando clang, usando Vim de editor e avançando sozinhos. Excelente.

Claro, nem eu e nem eles estão dando garantias. Não é qualquer um que vai conseguir aprender a programar. É o contrário, a 42 é um grande filtro. Quem desistir lá, não vai aprender melhor em outro lugar. Falta de esforço nenhum curso conserta. Quem entrar na 42 tem que estar preparado pra encarar essa realidade de que talvez falte determinação própria. Por outro lado, quem conseguir durar até o nível 21 eu acredito que saia de lá com nível no mínimo igual ou até superior a qualquer um que tenha feito ciências da computação numa boa faculdade federal. Na questão de ter realmente aprendido a aprender, eu acho que talvez seja muito melhor.

Eu pratico modelo semelhante tanto pessoalmente quanto na minha empresa e quando eu vi a 42 eu pensei, “se eu fosse montar uma escola de programação, provavelmente seria exatamente nesse modelo”. E foi uma grata surpresa ter visto alguém que pensou semelhante e anos antes já colocou o modelo em prática. Eu gosto até do nome!

Eu acredito que pessoas em aprendizado precisam de contato direto com outras mais experientes e ao mesmo tempo devem ajudar as menos experientes, e isso só é eficiente num ambiente presencial. Já disse que acho home office bom pra quem já é experiente, mas prejudicial pra quem é iniciante. Porém, com a situação atual de quarentena o processo da 42 infelizmente também foi prejudicado. Todos aqui torcendo pra essa situação se normalizar o quanto antes.

Eu também disse que o processo todo é obrigatoriamente presencial. Significa que quem não puder estar lá durante os 3 ou 4 anos não pode ser aluno. Os recursos são limitados, o espaço é limitado, mas mesmo assim a 42 tem um programa de bolsa parcial ou total dependendo do potencial do aluno e dos fundos que eles tem disponíveis. Alguns alunos estão podendo ir graças a essas bolsas. E aqui eu deixo o convite a qualquer empresa, que vá visitá-los pra de repente também contribuir.

A 42 SP ainda é nova, eles abriram as atividades no meio do ano passado. Mês passado deveria acontecer uma nova piscina pra selecionar mais alunos, mas de novo, essa atividade de imersão teve que ser adiada por motivos óbvios. Finalmente, deixo aqui meus parabéns pra Karen, pro Guilherme, pra Mari que cuida da comunicação. Eles me forneceram as informações que trouxe aqui pra vocês. Agradecimentos ao Salem que fez a indicação. Vou deixar links nas descrições abaixo pra vocês procurarem saber mais sobre eles.

E por hoje é isso aí, o episódio de hoje foi super longo, me desculpem por ter me alongado tanto mas eu achei que este deveria ser o episódio pra eu resgatar parte do que eu já disse desde o começo do canal pra vocês entenderem que esse é um assunto que eu passei literalmente anos pesquisando e refletindo. Se ficaram com dúvidas mandem nos comentários abaixo, se curtiram o video mandem um joinha, não deixem de assinar o canal, clicar no sininho pra não perder os próximos episódios e compartilhar com seus amigos. Eu continuo aqui na quarentena, e quem puder continue seguro e continue em casa. A gente se vê, até mais!

Quem é o tipo de profissional que vai sobreviver à Crise Econômica Pós-COVID-19 na nossa área de desenvolvimento de software? Como se faz pra ser tornar esse profissional?

Se por acaso eu decidisse fechar meu canal hoje, eu diria que este seria um FINALE digno do que eu produzi até agora.

Este vídeo vai ser um dos mais longos e talvez até um pouco cansativo em partes mas é porque eu realmente quero martelar pela última vez o que eu venho falando faz um ano e meio sobre o processo de aprendizado, particularmente para iniciantes que querem aprender programação.

Links:

• 42 SP (https://www.42sp.org.br/)
• CodeMiner 42 (https://www.codeminer42.com)

Playlists:

• Programação para Iniciantes (https://www.youtube.com/watch?v=O76ZfAIEukE&list=PLdsnXVqbHDUc7htGFobbZoNen3r_wm3ki)
• Carreira (https://www.youtube.com/watch?v=A2-yU3YjB1U&list=PLdsnXVqbHDUcAWAN3cXHWnM9JEw2gjIN9)
• Tough Love (https://www.youtube.com/watch?v=HEaIsKm-pao&list=PLdsnXVqbHDUck2oHncXftVmut6_agAGRC)

Me siga nas redes sociais:

• Twitter (https://twitter.com/akitaonrails)
• Instagram (https://instagram.com/akitaonrails)
• Facebook (https://facebook.com/akitaonrails)
• Podcasts (https://anchor.fm/akitando)

DESCRIPTION

Faz anos que você ouve falar que “programar é fácil” ou “qualquer um consegue programar”. Eu mesmo já disse coisas parecidas.

Hoje eu quero explicar porque na última década a programação alcançou esse status bizarro de “salvador da pátria” e porque os mercados estão num momento desproporcional de abundância, e o que isso pode significar pra sua carreira.

Warning: quem achou outros vídeos um “tapa na cara” ou “pedrada”, entre neste com cuidado porque pode ser pior. Frágeis de ego: eu avisei.

SCRIPT

Olá pessoal, Fabio Akita

Esta semana, pra variar vou fazer um video mais curto que o normal, me preparando pra tentar fazer algo maior durante o Carnaval. O videozinho que vocês acabaram de ver sou faz uns 6 anos atrás, era 2014 e fui convidado pra participar com um vídeo pra um movimento chamado Ano do Código. Eu tentei o possível pra Não fazer um vídeo tentando dizer o famoso “qualquer um consegue programar” mas meio que acaba dando pra entender assim, se você não pegar o contexto.

Eu pessoalmente não gosto desse vídeo que eu fiz. E eu acho que muita gente assume que minha mensagem é sempre próxima disso que eu disse. Eu nunca quero dizer isso. Então meu vídeo de hoje vai ser uma divagação sobre esse tema.

(…)

Em 2014 estávamos no pico do “awareness” popular sobre desenvolvimento de software. O mundo estava se recuperando da última grande crise financeira que assolou muitos países. E no meio desse momento apocalíptico, que gerou muitos desempregos, fechou muitas empresas, uma categoria parecia emergir como a solução de todos os problemas. E isso foi a programação, especialmente porque o conceito de App Store naquele ponto tinha 4 anos e gerou um boom de apps. E vários apps se tornaram icônicos como Uber ou Airbnb que deram uma alternativa a muita gente que perdeu emprego de conseguir trabalho que antes não existia. Quantas vezes você não viu reportagens nos jornais, de engenheiros, médicos, que perderam empregos e se tornaram motoristas de Uber?

Algo parecido tá acontecendo no Brasil agora. Naquela crise de 2008 e 2009, o governo brasileiro, chamou a crise de “marolinha” achando que o Brasil era invencível ou imune. Óbvio que não. Vivemos uma bolha artificial e a conta chegou. E por isso o mesmo episódio aconteceu aqui também, com a popularização de aplicativos como iFood, Rappi e outros que estão tendo o mesmo papel do Uber 8 anos atrás. A primeira vez que eu peguei Uber foi em 2012 em São Francisco. Era novidade ainda e a categoria era muito menor.

Muita gente não se lembra, mas o conceito também era diferente, a idéia do Uber não era popularizar o transporte. Era ser um transporte diferenciado de nicho. Pra começar você tinha que dirigir carros pretos mais classudos com os Lincoln. A idéia era você chegar nos lugares “like a boss”. O que hoje em dia se chamaria de Uber Black era o Uber normal, por isso Uber se chama Uber, aliás. O nome original era UberCab, e Uber vem do alemão e quer dizer algo como “superior”, então seria o táxi superior.

Aliás, foi por volta de 2012 que eu vi muitos dos aplicativos que usamos hoje se popularizando. Foi quando eu usei o Waze pela primeira vez direto em Tel-aviv, em Israel. Todo mundo lá estava usando, mas por aqui ainda era novidade. Geolocalização era uma tecnologia que começou fazia pouco tempo, 4 anos antes em 2008, inaugurado pelo Foursquare na South by Southwest daquele ano. O Google Maps tinha começado pouco tempo antes em 2005. Mas foi com o advento dos iPhone 3G com GPS em 2008 que a população em geral começou a tirar proveito de geolocalização pra mapas e rotas, pra criar geofencing e tudo que hoje em dia é super comum e trivial. Mas faz só pouco mais de 10 anos que tudo isso começou.

Essa tangente foi pra dar contexto daquele momento histórico. Tivemos o nascimento de novas categorias de tecnologia e por coincidência naquela época iniciou uma das maiores crises da história, e nós programadores estávamos no lugar certo e no momento certo pra ganhar as honras de salvadores da pátria. Pra uma parcela considerável de uma população, graças a termos smartphones no bolso e acesso a apps como Uber, ou Airbnb, milhares de pessoas puderam sair do desemprego causado pela crise. E por isso não é estranho que a população em geral visse com bons olhos não só as tecnologias mas as pessoas por trás delas.

Até o presidente Barack Obama na época, empolgado com essa nova alternativa, ajudou a incentivar uma nova geração de programadores. Em 2014 ele entrou forte nessa propaganda, muitos noticiaram quando ele se tornou tipo o primeiro presidente a escrever um código. Outros grandes nomes se uniram a essa causa como Bill Gates. Tecnologia deixou de ser só uma curiosidade, ou um instrumento pra especular fortunas como foi na Bolha do Ano 2000, pra se tornar uma solução social. E o resto, como diriam, é história.

Por isso em 2014 principalmente surgiram vários movimentos pra incentivar o aprendizado de programação como algo tão fundamental como aprender a ler e escrever. Tudo isso é positivo porque a profissão de programação foi finalmente reconhecida pelo que ele já vinha fazendo faz décadas: elevando as capacidades da humanidade.

Porém, isso também teve efeitos colaterais graves. O fato de todo mundo ter se tornado tão positivo à tecnologia acabou dando carta branca e tolerando muitas coisas que acabaram como escândalo anos depois. Vide o notório episódio da venda de dados dos usuários do Facebook pela Cambridge Analitica. Vide as acusações de manipulação da opinião popular pra eleger um presidente. E mesmo assim o Facebook continua firme e forte e crescendo. Por menos que isso, no ano 2000 a Microsoft quase foi obrigada a ser quebrada em múltiplas empresas independentes pelo Supremo Tribunal no caso antitruste.

Com tudo isso Tecnologia se tornou uma nova religião, e os grandes nomes da tecnologia se tornaram seus sacerdotes. Silicon Valley se tornou a nova Meca, e muita gente peregrinou pra lá. E os programadores se tornaram os seguidores cegos dessa nova religião. Diversos efeitos nefastos derivaram disso e continuam causando problemas até hoje.

Sem entrar muito em lei econômica, mas é sempre bom ilustrar com alguns extremos pra ter um modelo na cabeça. Vamos pro pior extremo possível, um monopólio. Ou mesmo algo próximo, um oligopólio, formado por um cartel de empresas que age em conluio. Ou ao contrário do que muitos imaginam, monopólios não são formados apenas por empresários malvadões. Governos são os campeões em gerar monopólios. Em qualquer desses casos o efeito pra um trabalhador comum é extremamente ruim.

Se não existem outras opções de trabalho, todo mundo é obrigado a participar desse jogo de cartas marcadas. O monopólio pode te pagar só mínimo necessário pra sobreviver ou até menos e não tem muito o que você possa fazer, especialmente se o monopólio for estatal. Se sair, não existe outro emprego. Se tentar empreender vai ser massacrado.

Por outro lado, quando você tem fartura, abundância e liquidez no mercado, temos outro efeito interessante. Pense o cenário de Silicon Valley ou qualquer outra dessas Mecas onde se concentraram os sacerdotes da tecnologia. Todo mundo peregrina pra lá com as promessas de salvar o mundo E ficar rico no processo. Não é incomum você ter programadores ganhando 150 mil ou 300 mil ou meio milhão de dólares por ano em São Francisco.

Se fizer a conta de padeiro e converter pra Real a 4.30, os 300 mil seria você ganhar 1.3 milhão de Reais por ano, bruto. Seria um salário de quase 100 mil reais por mês. É claro que chama a atenção. Dentro dos Estados Unidos isso chama atenção, e fora dele em países em desenvolvimento como o nosso, ou países ainda piores que o nosso como Índia, Angola, Nigéria. Claro que todo mundo quer ser programador!

Mas precisa fazer outra conta pra entender o que de fato esses 300 mil dólares do exemplo significam. Em muitos casos, metade disso pode ser só equity. Falando em linhas simples equity é uma promessa. Quando a startup abrir capital, você tem opção preferencial de compra das ações. Você não tem As ações, quando chegar a hora você precisa ter dinheiro pra exercer essa compra ou perder a opção. Isso é a primeira coisa que pouca gente pára pra pensar. Pra exercer essas ações você tem um período de vesting. Ou seja, se sair antes desse período, você perde essas opções. Equity é um mecanismo pra reter pessoas que é bem popular porque a empresa não precisa gastar nada por um bom tempo.

Então digamos que você ainda receba líquido essa metade por ano, ou seja, 150 mil. Isso daria pelo menos 12 mil dólares por mês. Continua sendo um puta dinheirão pros padrões brasileiros. Porém, o mercado não é estático. Se muita gente se concentra num mesmo lugar, ganhando salários cada vez mais altos, a lei da oferta e da procura entra em ação. Todo mundo que peregrinou pra lá agora precisa morar em algum lugar. A procura por imóveis aumenta drasticamente, mas a oferta não tem como aumentar do dia pra noite, portanto o preço dos imóveis aumenta também drasticamente. Então não é incomum achar apartamentos pequenos custando na faixa de 4 mil dólares pra cima.

Um terço desse salário que você achou enorme já foi embora. Então agora você tem 8 mil dólares por mês. Continua sendo um dinheirão. Mas não acaba aí. Digamos alimentação. Aqui no Brasil você pega seu Sodexo ou VR e em São Paulo pode pagar 30 a 40 reais por almoço. Nos Estados Unidos não existe o conceito de vale alimentação, e a refeição equivalente que você comprar na rua vai ser 30 ou 40 dólares. Vezes 22 dias úteis num mês, e se não tomar cuidado, vai perder mais de 600 dólares, só em almoço.

E vai fazendo essa conta pra tudo, luz, água, lavanderia, plano de saúde, academia, vestuário, entretenimento, talvez escola se você tiver filhos. Você pode perder mais 3 mil dólares ou mais nessa brincadeira. Os 8 mil começam a virar 5 mil ou 4 mil. E não se esqueça que também tem impostos. Apesar de serem menos que no Brasil, você ainda precisa pagar. Na faixa entre 80 a 160 mil dólares você deve pagar uns 28%. Então não é 12 mil que você tem líquido por mês, é dois terços disso, ou seja, 8.600.

No final do mês, você achou que tinha 12 mil dólares, mas tire tudo isso e muito mais que você precisa gastar numa das cidades mais caras do mundo, e se tiver sorte, vai sobrar mil dólares, talvez 2 mil. Ainda assim, pro padrão brasileiro, se sobrar mil dólares parece bastante coisa, mas você não pode comparar com o custo de vida brasileiro, que é ordens de grandeza mais barato. Aliás essa é outra coisa que pouca gente faz: só vê o número absoluto. Não considera custo de vida ou impostos.

Daí acontece efeitos bizarros de você ver um americano que ganha teoricamente 5 a 10 vezes mais que você aqui, e reclamando que ganha pouco e não dá pra viver. E se parece exagero, vide exemplos recentes quando a empresa de jogos TellTale Games demitiu dezenas de pessoas do dia pra noite porque eles ficaram sem dinheiro. Um monte de gente que foi pra rua ficou sem ter dinheiro pra pagar o aluguel do mês seguinte. Eles realmente viviam de contra cheque em contra cheque. E essa é a realidade da grande maioria das pessoas, aqui ou lá. Não é diferente.

Na Europa é a mesma coisa. Na Ásia é a mesma coisa. Não existe bala de prata. Se 150 mil dólares for uma média, considere que pelo menos metade da população ganha consideravelmente menos que isso. Médias salariais não dizem nada. O contexto e os custos são completamente diferentes. E claro, os valores e contas que eu fiz aqui são hipotéticos, não adianta ficar jogando nos comentários “ah mas meu amigo que eu conheço é diferente” eu sei, é um exemplo. E casos isolados não define uma regra geral. A história do “cara que você conhece” ou o seu próprio é apenas isso: uma anedota.

Voltando à história de monopólios que eu falei, onde você realmente trabalha por centavos. A situação de Silicon Valley e outros centros com grandes investimentos é o inverso. Parece que existe abundância, pra todo mundo. E parece que se você ganha menos de 150 mil dólares por ano, você está sendo explorado. Mesmo se for esse o caso. Foi uma escolha sua ir pra lá. Ninguém colocou uma arma na cabeça forçando você a estar lá. E você tem escolhas, estamos num período de abundância. Só que ninguém quer ganhar “menos”, ou assumir um erro, ou assumir outros riscos. É um problema de ego, não de economia.

Pior que isso, mais da metade do valor de um lugar desses é só promessa. Imagine o montante de equity que existe espalhado nesse mercado. É um valor absurdamente grande. Só que isso é uma promessa. Se a startup falir antes de conseguir atingir o ponto de abrir capital e realizar sua valuation, todo esse equity vai valer zero no dia seguinte. Isso mesmo, zero. É uma bolha.

Tem duas coisas que podem acontecer num cenário desses. A primeira é a bolha estourar. E quando ela estourar o valor de tudo vira pó. Só que agora sobra um exército de programadores hiper caros que, no papel, e só no papel, acha que vale tudo isso de verdade. Só que não vale. Valor não é absoluto, é um produto do mercado. Qualquer empresa que cair a ficha que precisa controlar e cortar custos, em vez de gastar desenfreadamente em mesa de sinuca e piscina de bolinhas e propaganda cara, em busca do sonhado market share, tem alternativas. Umas das alternativas se chama outsourcing, ou terceirização. Pra onde? Pra países onde programadores de qualidades semelhantes custam metade, um terço, ou ainda menos. Nós, aqui no Brasil, os indianos, os ucranianos e assim por diante.

Eu já vi isso acontecer antes. Em 2001 não foi só as torres gêmeas que caíram, caiu também a bolha especulativa da internet. Centenas de programadores que achavam que eram bons de repente não tinham pra onde ir. Foi assim que cresceu o mercado da Índia no começo dos anos 2000, se tornando referência em terceirização de programação e outros serviços como call centers e qualquer coisa que era possível terceirizar. Por isso americano odeia a globalização.

Eu já tinha contado essa história e estou repetindo aqui pra dar contexto. Agora vem o que eu queria dizer no começo. Programação não é salvador da pátria. Ela é só uma profissão, que deve sim, ser levada a sério. Só que passamos os últimos dez anos com o falso estigma que ser programador é uma coisa “nobre” pra sociedade, que vamos resolver todos os problemas do planeta, vamos acabar com a fome, vamos consertar o clima, vamos consertar tudo. E pior, surgiu a noção de que é fácil programar. E não só é fácil programar, mas a procura por programadores aumentou drasticamente por conta de todo esse dinheiro fantasma, toda essa promessa de riqueza, de repente qualquer programador mais ou menos, passou a ganhar mais do que deveria num mercado fora dos padrões.

Sabe onde isso vai chegar? Da próxima vez que a bolha estourar, e isso pode ser em breve ou pode ser em poucos anos, quem não for programador de verdade, ou seja, quem não souber como de verdade entregar resultados proporcionais ao que ganha, vai ficar sem emprego. Nunca se esqueça: sempre vai existir um indiano que faz o que você faz por menos da metade do preço. Provavelmente pode colocar um chinês junto nessa equação agora também.

Sempre tenha em mente, você raramente vale o que você “acha” que vale. Todo mundo acha que deveria ganhar mais. E todo mundo que paga sempre vai achar que deveria pagar menos. Esse é o jogo. E é a lei da oferta e da procura que vai dinamicamente ajustando isso. Só que em períodos de bolha a demanda é desproporcionalmente mais alta, não dá tempo da oferta atender, então o que varia é o preço acima do normal. Em crises é o oposto, a demanda seca, e a oferta fica com estoque sobrando, o que varia é o preço abaixo do normal. Essa é a conta.

O quanto você vale depende da sua qualidade, da oferta e da demanda. E em períodos de demanda desproporcional, mesmo a qualidade não sendo grande coisa, ainda assim existe oportunidade.

Agora, tudo isso que eu usei de exemplo é nos grandes centros. São Francisco, Berlin, Londres, São Paulo, e assim por diante. As pessoas de cidades mais distantes do interior, ainda estão completamente fora dessa realidade. Toda vez que um programador rock star de um grande centro fala das maravilhas de tudo isso, ele está criando uma falsa expectativa. Mercados não melhoram só com discurso.

Como a tal demanda que eu falei é altamente desproporcional, mesmo assim não é tão difícil ouvir falar de casos de programadores que saíram de lugares longínquos e hoje estão morando nesses grandes centros, ganhando seus 150 mil dólares por ano. Esses casos se tornam a propaganda pra um sub-mercado que aparece toda vez durante esses períodos de abundância. Eu sei que estamos num período de abundância quando existe oportunidade pra certificar coach de coach ISO 9001 em instituição nacional de coach por exemplo. Num mercado normal, onde reinaria a eficiência, essa posições simplesmente não existiriam. Então sim, estamos num período de abundância excessiva.

Você tem que tomar cuidado com aproveitadores. Por exemplo, não é de hoje que ouço falar de cursos rápidos e workshops de poucos dias ou semanas, que trazem até pedigree estrangeiro, prometendo a pobres incautos que eles também podem rapidamente usufruir desses altos salários em grandes centros. E a demanda é tão alta, que de fato, alguns deles até conseguem posições, de tão baixo os critérios que muitos recrutadores colocam pra conseguirem suprir a demanda. E isso só alimenta a propaganda enganosa.

Deixa eu ser o estraga prazer. É impossível se tornar um bom programador, do zero, em duas semanas, ou mesmo dois meses. Esse tempo é suficiente pra, no máximo, saber fazer tarefas muito simples. E como eu sei disso? Por que eu faço contratações pra minha empresa e já fiz pra várias outras empresas ao longo de 20 anos. Eu já contratei literalmente centenas de pessoas e avaliei centenas de curriculos e acompanhei a evolução deles. Eu sei uma coisa ou duas sobre contratações e avaliações.

Coloque em perspectiva. Alguém considerado estagiário, já está num curso, seja de ciência da computação ou engenharia de software ou técnico em programação por pelo menos 2 anos. Isso significa uma carga horária mínima de 3 a 4 horas por dia, por uns 8 meses e 22 dias úteis por mês ou no mínimo 700 horas. Sem contar o tempo de estudos, trabalhos, e pesquisa. Um workshop realmente puxado de 8 horas por duas semanas são míseras 80 horas. Não chega nem perto da metade do que um estagiário já estudou.

Se o curso for excepcionalmente bom e se você for excepcionalmente estudioso e aplicado, ainda assim estamos falando de chegar no nível de estagiário. Faça as contas. Não tem como. Do nível estagiário, dependendo de onde ele estagia, as pessoas mais experientes com quem tem contato, os diferentes desafios e estudos extras no estágio, ainda precisa na média de mais 6 meses a 1 ano pra se tornar um júnior. Então estamos falando de uma carga extra de treinamento de mais 6 meses de 22 dias úteis e 6 horas no estágio, ou seja, mais 700 horas.

Ou seja, chutando na média, pra sair do zero até chegar ao primeiro estágio de júnior, estamos falando de uma carga aproximada de 1400 horas entre estudo teórico e treino prático. No mínimo. E eu não estou falando que um curso rápido ou workshop são ruins, é apenas uma questão de expectativas. Eu acho que esses workshops são bons pra dar uma introdução e os primeiros passos, as primeiras 80 a 100 horas de um percurso de 1400 horas. É 5% do percurso. Existem exceções? Casos excepcionais de gente talentosa que consegue em metade desse tempo? Claro que tem, mas por isso chamamos de exceções e não da regra.

Só que a grande maioria das pessoas não faz essas contas simples que eu acabei de fazer. Em vez disso, prefere cegamente seguir alguma palestra motivacional que ouviu de algum fake coach por aí e mergulhar na corrida do ouro sem saber que está indo atrás de ouro de tolo. Quantas histórias eu já vi de pessoas que nem de fato se interessavam tanto pela área, mas foram influenciadas e só depois de ver o tamanho do caminho, se frustraram e desistiram pelo caminho.

Pior ainda os que caminharam o 5% do percurso e tiveram a sorte de entrar na onda da alta demanda e conseguiram alguma posição em algum lugar. Alguns até ficaram bons o suficiente, mas ainda assim não são programadores de verdade. Eu não tenho nenhuma pesquisa cientificamente correta para trazer dados, mas eu não consigo não parar pra pensar no motivo de porque de repente tem tanta gente sofrendo de síndrome do impostor. E porque existem grupos grandes de pessoas em nível básico se comportando na defensiva de suas posições. Porque são posições super frágeis e na maioria das vezes desnecessárias, criadas num momento de alta artificial da demanda. Quando tem dinheiro sobrando, porque se preocupar em eficiência?

Falando como um sobrevivente de umas 3 crises, nos anos 90, nos anos 2000 e nos anos 2010, uma coisa permanece constante. Os que ficam pra trás foram os que estacionaram no básico, cegos por um valorização fora do normal, achando que já são bons o suficiente já que existe demanda por eles. Os que vão pra frente e sobrevivem são os que não colocaram esse valor como base e sim as próprias habilidades de resolver problemas reais, seja lá quais eles sejam. E você só consegue ser flexível pra resolver problemas diferentes quando seu conhecimento tem fundações sólidas, treino sólido. Não importa se é momento de abundância ou momento de crise, um tipo de emprego que nunca acaba são as posições reservadas ao reais solucionadores de problemas.

Muita gente deve estar tomando um balde de água fria e provavelmente me xingando já neste momento. Não culpem o mensageiro. Mas eu diria que é melhor se frustrar antes do que depois quando é tarde demais. Mas agora eu volto à segunda parte do meu vídeo de 2014 e o que eu quis dizer:

(… video)

Se você ainda não assistiu tudo, eu venho fazendo uma série de vídeos tentando explicar como funciona esse começo, como funciona o mercado e em particular sobre a metodologia de aprender a aprender. Recomendo voltar à playlist de carreira que eu fiz e assistir com calma. Mas deixa eu fazer outra tangente.

Eu sou ruim em esportes. Eu sempre fui, sabe aquele japonês CDF que na educação física é sempre o último que todo mundo escolhe pra colocar no time e termina no máximo como gandula. Pois é, sou eu. Talvez se eu me aplicasse mais eu talvez conseguisse ser alguma coisa melhor. Só que eu não gosto de esportes. Acho chato. Não prende minha atenção por mais que 30 segundos. Eu simplesmente não gosto.

Eu sou ruim de gastronomia. Eu adoro comer, todo tipo de comida do mundo eu como e você vai ter dificuldade de achar qualquer ingrediente que eu me recuse a comer. Quando quero só relaxar e não pensar em nada eu gosto de colocar nos canais Tasty e ficar vendo chefs cozinhando. Porém eu mesmo não gosto de cozinhar. No máximo eu fervo água pra colocar em miojo, se precisar muito eu faço um ovo frito, mas eu não tenho nenhum prazer em cozinhar. De novo, eu me colocar pra cozinhar é me entediar. Não rola.

E assim vai, eu sou ruim em muitas coisas e não tenho nenhuma intenção de investir tempo pra ser bom em nenhuma delas. É uma escolha consciente. Do outro lado da moeda eu gosto de programar. Saber como funciona cada pequena coisinha de cada tecnologia chama minha atenção, me prende por horas, eu já cansei de ficar entretido e só parar quando vejo o sol nascendo, de novo. É um contraste enorme com as coisas que eu não gosto.

Da mesma forma, eu tenho certeza que existem diversas pessoas com gostos totalmente opostos aos meus, que amam esportes e acham programar ou jogar videogames coisas completamente tediosas, maçantes e sem sentido. E elas tem total razão: gosto é que nem bunda, todo mundo tem um. Esporte profissional não é pra qualquer um. Como hobby sim. Programação também não é pra qualquer um. Como hobby sim.

Incentivar a fazer esportes é normal, correto e sempre faz bem pra população em geral. Esportes tem o benefício de ajudar você a se manter saudável, ajuda você a trabalhar em equipe e ajuda você a exercitar sua vontade de ser um pouco melhor. Tem um monte de boas razões pra se fazer. Mesmo assim você não vai me convencer, porque simplesmente não me atrai. Por outro lado, acho que pouca gente tirando as crianças fazem esportes com o objetivo de se tornar o Neymar. Você sabe que é um caso em um milhão. Você pode tentar copiar tudo que ele já fez e as chances de você virar algo próximo de metade um Neymar continua sendo inatingível. Foi uma combinação impossível de repetir de talento e esforço pessoal, timing, e estar no lugar certo na hora certa. Esforço e sorte é que geram sucesso. Não é uma receita que qualquer um pode repetir.

Mesma coisa em qualquer outra profissão de prática. Você sempre pode ter ídolos mas as chances de você se tornar um deles é perto de impossível. Todo mundo sabe disso. Então o que fazer? Simples, não faça propaganda de “você também pode ser o Bill Gates”, é mirar alto demais. Em vez disso desça vários níveis na cadeia, onde existe mais gente e que ainda assim é uma minoria. No caso os rock stars da programação já parece algo mais palpável, então bora fazer propagandas assim. “Você também pode ser um rock star de Silicon Valley.”

Quando eu digo no vídeo de 2014 que é só uma questão de “começar a praticar”, eu não tive tempo de dar toda essa explicação. E quando eu e qualquer outra pessoa fala que programar é fácil e um monte de gente que não tem vocação nem muito menos o interesse ouve isso continuamente, ele acha que o errado é ele. Assim como me faziam pensar que o errado era eu por não saber chutar uma bola. Felizmente desde cedo eu sabia ligar o “foda-se” e simplesmente ignorava 99% dos meninos que tiravam sarro porque eu nunca consegui chutar uma única bola na direção do gol. Eu simplesmente tinha outros interesses, que nos anos 80 basicamente ninguém tinha: programar.

Então a primeira coisa que eu preciso corrigir do meu video é: não é simplesmente dar o primeiro passo. Se tecnologia não prende sua atenção e concentração por horas ininterruptas, onde você simplesmente não vê o tempo passar, e onde se dedicar mil horas ou duas mil horas não é algo que pareça maçante pra você, então sim, só falta dar o primeiro passo e começar. Mas se pra você computação é igual futebol é pra mim, eu nem começaria.

E eu digo isso porque eu já vi um monte de gente começar e depois ficar frustrada e depois vem “eu segui o que o Akita disse, ou o que outro rock star disse, e eles mentiram pra mim, não é fácil assim”. E ele tem razão. A única discordância que vamos ter é que eu tomei cuidado pra minha carreira inteira eu nunca incentivei ninguém a virar programador. De propósito eu deixo de fora qualquer discurso mais otimista e incentivador. Eu simplesmente digo: eu gosto de tecnologia e eu gosto de falar sobre tecnologia e é isso que vou fazer. E ao mesmo tempo faço vários vídeos ilustrando que o mundo de tecnologia não é esse mar de rosas que muitos querem fazer você acreditar.

Um dos filmes que muitos palestrantes já usaram da forma errada é o clássico Ratatouille da Disney. Onde à primeira vista faz parecer que até um mísero rato é capaz de cozinhar melhor que um ser humano a ponto de mudar a opinião de um dos mais exigentes críticos gastronômicos da França. Mas ele é muito claro na mensagem: “nem todo mundo pode se tornar um grande chef, mas um grande chef pode vir de qualquer lugar”. Essa é a mensagem.

Significa que você não precisa ter nascido em São Francisco e estudado em Stanford pra ter chance de ser um grande programador. Você pode ter nascido numa cidadezinha do interior com 2 mil habitantes, estudado sozinho, e chegar no mesmo nível. Mas não é qualquer um. Da mesma forma como o filme é claro: de uma população gigantesca de ratos, apenas 1 demonstrou ter o que era necessário pra atingir isso. No nosso mundo é a mesma coisa. Bill Gates é celebrado até hoje, porque só existiu 1. Só existiu 1 Steve Jobs. Só existe um Jeff Bezos ou Jack Ma.

Você quer ganhar o sonhado salário de 6 dígitos em dólar por ano. Mas não está disposto a investir 2 mil, 4 mil ou, mais corretamente, 10 mil horas pra chegar lá. Sinto te dizer, é certeza absoluta que a menos que aconteça um evento de muita sorte, tipo ganhar na loteria, você não vai chegar.

E pior que isso, num período de hiper abundância que temos hoje. Se você acha que está difícil arranjar boas posições agora, sinto dizer que na próxima depressão vai ficar exponencialmente mais difícil. E enquanto isso você prefere defender que aprender inglês é ser anti-patriota ou qualquer bobagem assim, que é basicamente a desculpa de quem está com preguiça de aprender inglês ou simplesmente - assim como eu em esportes - simplesmente se entedia de tentar. É melhor assumir a realidade do que inventar histórias.

Em momentos de monopólios ou em momentos de depressão, toda frustração e reclamação é válida: é a realidade. Mas em momentos de abundância ver gente reclamando que ganha 5 dígitos em vez de 6, ou que não viaja vezes o suficiente por ano, ou que não consegue trocar de celular a cada 6 meses, é literalmente problema de primeiro mundo de uma geração que ainda não teve a experiência da primeira crise. Porque existem opções. Se elas não estão pulando pra próxima opção, não é falta de opção, é falta de vontade mesmo. Porque ficar no mesmo lugar e reclamando e se sentindo vítima da sociedade é sempre mais fácil do que assumir riscos. E sem assumir riscos, que tipo de resultados você acha que vai ter? Nenhum.

Já diria Einstein que um louco é aquele que fazendo sempre a mesma coisa, espera resultados diferentes. Eu acho que cursos, workshops, coaches e todo o aparato de intermediários que está surfando a onda da abundância está realmente realizando fraude. Eu desaprovo e me enoja ver gente praticando abusos e ativamente tentando enganar os outros. Por outro lado, muita gente simplesmente escolhe acreditar no ouro de tolo, porque se acha mais esperto, porque não quer recompensas com pouco ou nenhum esforço. E nesse caso, eu acho que os dois se merecem. Você quer ser enganado, é uma escolha, ninguém colocou uma arma na sua cabeça.

Pra finalizar, eu acho mó engraçado um monte de programador rock star com salarios de 6 dígitos reclamando de desigualdade. Por experiência aprendam, qualquer pessoa que fala a palavra igualdade só quer ganhar mais. Nada mais que isso e não tem nenhum problema em querer ganhar mais. Mas antes de falar bonito vale lembrar. Você trabalha numa startup que não tem lucro? Da onde acha que vem o dinheiro pra te pagar? Provavelmente de algum fundo de pensão, dinheiro de aposentadoria. Pois é. Eu entendo, todo mundo quer pegar uma fatia maior desse bolo, aproveitando que todo mundo acha que tecnologia ainda é mágica e solta dinheiro assim fácil.

O objetivo dos videos que eu faço é falar sobre o que eu gosto e ao mesmo tempo eu vou intercalando com alguns avisos: o mundo da programação é vasto, tem uma história muito rica que precisa ser respeitada, e possibilidades inexploradas que estão aí para quem tiver o conhecimento e a vontade de perseguí-las. Mas, não é pra todo mundo. Tenha isso em mente. E como eu disse, o episódio de hoje foi mais curto, semana que vem devo falar de algum outro assunto técnico da minha lista. Se ficaram com dúvidas, mande nos comentários abaixo. Se curtiram o vídeo mandem um joinha, não deixem de assinar o canal, clicar no sininho pra não perder os próximos episódios e compartilhar com seus amigos pra ajudar o canal. A gente se vê, até mais!

DESCRIPTION

Muita gente me procura via mensagens diretas em redes sociais, em particular pelo Instagram. Pro episódio de hoje eu selecionei 10 perguntas que representam a maior parte dos temas que costumam me perguntar e apesar de já ter parcialmente respondido algumas delas via os temas de outros vídeos passados, vou tentar compilar respostas um pouco melhores hoje. Espero que ajude.

O tema vai ser “Perguntas mais frequentes de iniciantes no mercado de tecnologia”. Diferente do vídeo que eu fiz chamado “Começando na Carreira de TI” (https://www.youtube.com/watch?v=H84WD_xyj10) onde eu abordei assuntos que começam mais na escolha da faculdade primeiro, esta é mais focado no primeiro emprego e na forma de começar a evoluir. Depois de assistir este video convido vocês a tentarem o vídeo “Dimensão do Tempo” (https://www.youtube.com/watch?v=Qb5b8ZE9tIY) e “O Mercado de TI para Iniciantes em Programação” (https://www.youtube.com/watch?v=O76ZfAIEukE) também.

Se vocês ainda não me seguem nas redes sociais, não deixem de seguir (@akitaonrails em todo lugar). E podem mandar perguntas em privado que eu possa usar em próximos episódios de perguntas e respostas.

Links diretos pra cada pergunta

03:14 - pergunta 1

11:27 - pergunta 2

15:23 - pergunta 3

19:23 - pergunta 4

21:30 - pergunta 5

29:00 - pergunta 6

30:30 - pergunta 7

33:13 - pergunta 8

35:14 - pergunta 9

36:21 - pergunta 10

SCRIPT

Olá pessoal, Fabio Akita

Ultimamente eu ando bem distraído por assuntos pessoais, e ao mesmo tempo tem alguns assuntos técnicos pros próximos episódios que vão demandar mais tempo de pesquisa do que eu normalmente faço, por isso acabei procrastinando um pouco mesmo. Provavelmente minha frequência de lançar videos vai ficar irregular agora entre dezembro e janeiro. Um desses assuntos pessoais é que estou pra me mudar pra outro apartamento, e ainda tem uma obra que vai começar agora, tem feriados que vão atrapalhar essa obra. Eu imagino que quando eu terminar de me mudar e estiver com tudo pronto mais do meio pro fim de Janeiro é que vou conseguir me focar 100% pro canal de novo. Inclusive, até o fim de Janeiro significa que o cenário do canal vai mudar também.

Pro episódio de hoje eu resolvi repescar algumas perguntas que vocês me mandaram em mensagem privada. Eu não peguei todas, acho que vasculhei um período de quase 2 meses de mensagens no Instagram. Por alguma razão a maioria das pessoas interage mais comigo no Instagram mais do que em qualquer outra rede social. Aliás, se vocês nunca prestaram atenção, todo vídeo eu começo com meus perfis de rede social, então não deixem de me seguir. Às vezes eu não consigo responder todas as perguntas como eu gostaria. Não se sintam mal quando eu não respondo, muitas vezes é simplesmente porque eu esqueço mesmo, outras vezes é porque eu não estou muito a vontade de responder qualquer coisa rápida.

A maioria das perguntas acaba sendo em torno de assuntos de carreira, principalmente início de carreira. Eu já falei sobre vários desses assuntos como no vídeo sobre Mercado de TI ou Conhecimentos Gerais e vários outros. No episódio de hoje eu vou repetir algumas das coisas que já falei em outros vídeos, mas vou tentar reformular em algo que se pareça mais com respostas. Então vamos lá!

Antes de mais nada, eu não vou dizer quem mandou as perguntas. Eu imagino que se me perguntaram em privado pode ser que não se sintam a vontade de eu expor publicamente. Então se vocês reconhecerem suas perguntas e quiserem expandir em cima delas nos comentários, sintam-se à vontade. Ou se preferem falar em privado, podem mandar direct no Instagram ou Twitter.

Outra coisa que é meio óbvio mas melhor avisar antes. Cada pessoa tem circunstâncias diferentes. Por isso não existe resposta universal que cabe pra todo mundo. Na minha posição, toda resposta podia começar com “depende”. Depende de que tipo de formação você já teve, depende de quanto você tem condições de investir em educação, depende se você tem objetivos específicos como morar fora do país, depende se você tem limitações que te impedem de escolher um ou outro caminho. Por isso ajuda muito se você se apresentar um pouco melhor quando faz as perguntas.

E isso já é uma dica: no trabalho muita gente quando fala alguma coisa acha que todo mundo devia entender suas circunstâncias, mas ninguém vai saber se você não disser. Todo mundo vai responder no seu ponto de vista particular e não no de quem perguntou. Por causa disso também, minhas respostas provavelmente vão ficar meio compridas. Porque eu vou tentar dar um contexto em vez de só dar uma receita simples. Então vamos começar com a primeira pergunta que é: “Quais dicas você daria pra quem tá começando na área de dev. Interior, quase não tem empresas pra contratar devs, só com faculdade.”

Eu achei essa pergunta interessante porque na real é onde eu acho que a maioria das pessoas se encaixa no Brasil. Muito do material sobre carreira parece mais voltado pra quem é de algum grande centro ou pólo tecnológico como São Paulo, Belo Horizonte, Porto Alegre, Recife. Mas a maioria das pessoas vive fora das capitais. Durante mais de uma década eu visitei cidades como Xanxerê, Maringá, Rio Branco, Criciúma, Macapá, Campos de Goytacazes. A maioria sequer tem aeroportos perto. A indústria de tecnologia na maioria das cidades do interior simplesmente não existe.

Pouco a pouco isso vem mudando, muitas empresas estão procurando cidades fora dos grandes centros. A minha própria empresa, a Codeminer, costuma procurar cidades fora de São Paulo pra montar escritório, por isso estou em lugares como Santa Maria, Guarapuava, Poços de Caldas, mas nenhum de nós vai conseguir cobrir o Brasil inteiro tão cedo. Muitos estudantes tem o sonho de se mudar pra uma cidade maior e alguns até mesmo morar em outro país, mas isso não é realidade pra muita gente que não quer ou mesmo não pode deixar a família pra trás, por exemplo.

Por isso muita coisa que se usa em tech startups, linguagens mais arrojadas como Elixir, Clojure, Scala, Go, Typescript ou até mesmo coisas que consideramos super normal como Lambdas, NoSQL, Machine Learning, nada disso é remotamente perto da realidade. No máximo tem projetinhos Web simples que se integram com sistemas legados que tem 20, 30 anos de idade até. Pra todos os efeitos e propósitos, não é exagero eu dizer que já vi empresas do interior que estão literalmente presos a tecnologias e práticas que eu só via nos anos 90 e começo dos anos 2000. Você vai achar implementações de ERP como os da Totus, ou coisas customizadas dessa época feita em Delphi antigo, ou até mesmo Clipper, que eu parei de usar em 1994.

Então vamos lá. Vamos assumir que por qualquer razão, você esteja preso na região. Não tem planos de se mudar tão cedo. Não há sequer agências pequenas de sites e serviços de Web. Só empresas que Não são tecnologicamente avançadas mas tem sistemas pra manter. Coisas em Java antigo, ou .NET antigo, ou VB ou Delphi ou até Clipper. Que usam bancos de dados antigos como Interbase, Informix, Ingres, Caché. Se você não tem opção, então a escolha já está feita. Eu imagino que você vai precisar comer e pagar suas contas. E se sua vocação é programação, não tem como evitar lidar com tecnologias antigas.

Começar em empresas assim, ao contrário do que pode parecer, não é necessariamente uma coisa ruim, especialmente se você está no começo de carreira. Mas tem duas coisas que você vai precisar fazer. A mais importante delas é estudar inglês até se tornar fluente. Esse vai ser seu passaporte pra conseguir coisas melhores. Eu fico pasmo que até hoje ainda tem gente na área que desincentiva o aprendizado de inglês mas fica empurrando tecnologias inúteis que a maioria das empresas sequer tem intenções de usar por muito tempo ainda. A menos que você goste de programação só como hobby, você precisa aprender inglês, o quanto antes. Pra saber como fazer isso sem gastar muito, veja meu video sobre Como eu aprendi inglês.

Apesar de hoje de fato termos bons materiais em português pras tecnologias mais populares, a maioria delas fica defasada muito rápido, porque todas as linguagens, frameworks, ferramentas e plataformas, estão recebendo novas versões o tempo todo. E quanto mais usado é uma tecnologia, mais rápido ele recebe atualizações. Em poucos meses um livro em português fica defasado. Mesmo em inglês os livros ficam defasados apesar deles receberem novas edições com muito mais frequência do que no Brasil. Por isso a grande maioria dos programadores que estão à frente não estão estudando por livros, mas sim pelas documentações nos sites oficiais de cada tecnologia e foruns de discussão, e adivinhem: 100% delas é em inglês. As tecnologias que não são populares ainda, mas que tem potencial de mercado no futuro próximo, sequer tem livros publicados ainda.

Pior ainda, talvez muitos nem saibam disso mas se você usa Wikipedia em português, você sempre está lendo versões curtas e incompletas. Vejam por exemplo o verbete de computação quântica que foi assunto que eu gravei a respeito algumas semanas atrás. Em inglês tem mais de 70 referências. Em português tem uma lista ridícula de 18 links, metade pra posts de blog. O mesmo vale pra stackoverflow que todo programador usa todo dia. Se você não usa a versão em inglês, você está perdendo provavelmente 80% das opções, se não mais. Nem importa se você ainda não é fluente, pare de usar as versões em português e vá direto na versão mais completa em inglês. Por que você quer ficar em desvantagem em relação a todo mundo?

Enquanto seu inglês for ruim, sim, use todo material em português que conseguir encontrar porque não tem outra opção, mas faça isso sabendo que você está com um material que é incompleto ou já está defasado. Agora, sua vida vai ser bem mais difícil mesmo. Você vai ter que aprender a tecnologia antiga que a empresa da sua região usa e em paralelo vai ter que estudar as tecnologias um pouco mais modernas que são mais populares no mercado dos grandes centros, como Javascript ou Python, frameworks como React, linguagens mais modernas como Go. Se as empresas da sua região pelo menos usarem coisas como Java ou .NET menos mal, porque elas são fundação pra muita coisa nova. Eu diria que todo programador deveria saber um pouco ou de Java ou mesmo C#. Você aprecia melhor as novas linguagens se souber algumas um pouco mais antigas. Não procure a linguagem que é a mais simples pra aprender, ou a que você acha que pagam melhor, se for você realmente entrar na carreira de programação, você vai aprender várias linguagens diferentes ao longo do tempo. Se você estiver anos com a mesma, você está se colocando em desvantagem, de novo.

O outro problema é a falta de faculdade. Nos grandes centros isso também ainda é um requisito, especialmente em começo de carreira onde você ainda não tem muito como demonstrar o que sabe, porque não tem experiência anterior. Não preciso dizer que as leis trabalhistas do Brasil são uma das piores do mundo, sério é o conjunto de leis mais primitivo e imbecil e um das coisas que mais dificulta a entrada de iniciantes no mercado. Por exemplo, você só pode ser estagiário se estiver cursando faculdade, porque estágio é um processo assinado entre empresa, o estagiário e a faculdade. Existe a obrigatoriedade da figura da instituição de ensino. Pra contratar alguém, sem faculdade e sem experiência, é um custo muito alto pra maioria das empresas, porque o vínculo empregatício e a liability que isso trás custa caro. As leis trabalhistas são obstáculos pra todo mundo que não fez faculdade e precisa buscar experiência. Essas leis garantem que você que não fez faculdade comece em desvantagem.

Daí a única outra alternativa que pode acabar sobrando é tentar se tornar autônomo ou freelancer muito cedo na carreira. E isso é péssimo, porque se você aprendeu sozinho e nunca trabalhou em projetos de verdade ou com alguém mais experiente que consiga te mentorar, você não tem noção ainda do que um projeto realmente precisa pra ser entregue de ponta a ponta, e vai ter um caminho ainda mais difícil. Especialmente porque sem saber até onde dá pra ir, você só vai ficar repetindo as poucas coisas que aprendeu, e muitas vezes do jeito errado por muito tempo. A maioria desiste porque a pressão e frustração são grandes demais.

Por isso eu digo que mesmo se na região não tiver empresas com tecnologias modernas, mesmo que não paguem tão bem, ainda assim é melhor que nada. Você precisa ver como uma empresa funciona no mundo real. Mesmo se ela for ruim, você precisa ver o que ser ruim significa. Mesmo se o código for antigo e mal feito, você precisa ver como é um código antigo e mal feito. E ao mesmo tempo aprender como lidar com outras pessoas, mesmo chefes ruins pra saber o que significa ser um chefe ruim. Entenda, mesmo com faculdade, tendo aprendido só teoria, por mais que tenha lido livros e feito cursos online, você ainda não sabe 1% do que precisa.

Pra continuar, vou aproveitar o gancho da segunda pergunta que separei pra hoje que diz: “É legítimo o alarmismo com relação a escassez de profissionais na área de programação? Mão de obra qualificada. Não que precise ser genial, mas alguém que tenha uma base boa pelo menos.”

E sim, existe escassez de profissionais qualificados neste mercado. Não é alarmismo. Nos grandes centros a situação é bem diferente do interior e regiões afastadas do país. São realidades completamente diferentes aliás. Em centros como São Paulo, Rio de Janeiro, Recife, Belo Horizonte, Porto Alegre, e um pouco menos em outras capitais como Florianópolis, Curitiba, Fortaleza, por exemplo, o ciclo econômico dos últimos 10 anos trouxe um boom de tech startups e grandes empresas que absorveram parte da cultura das tech startups. Essas regiões atraíram muito investimento tanto nacional quanto internacional. Não é exagero dizer que o Brasil em 10 anos conseguiu crescer um ecossistema de tech startups muito grande. Só que com todo crescimento rápido demais conseguir mão de obra qualificada vai ficando mais e mais difícil. Porque qualificação de verdade não acontece do dia pra noite, exige anos de dedicação, estudo e experiência.

Pra tentar suprir essa demanda, também houve uma explosão em cursos online e geração de material de aprendizado. Mas não existe milagre. Educação exige tempo. É impossível só via um curso online produzir programadores seniors, nem mesmo pleno. Via de regra, qualquer curso online, os melhores, só vão conseguir gerar, no máximo do máximo, programadores júniors. A partir de um determinado ponto, o júnior precisa obrigatoriamente se inserir numa empresa de verdade pra aprender na prática o que significa desenvolver um sistema grande de verdade, como desenvolvedores mais experientes resolvem problemas de verdade. Nenhum curso jamais vai conseguir queimar esses passos. Aliás, se você ver algum curso ou bootcamp que faça promessas imbecis como “estude com a gente e pule de júnior pra pleno em x tempos” eles são charlatães, fuja. Outros cursos exigem que você já seja um pleno pelo menos e tenha uma formação boa pra conseguir usar o material mais avançado.

O lado menos óbvio se você não é da área é que apesar do número de tech startups ou empresas similares em tecnologia tenha crescido rápido, elas tem um problema grave: quanto mais investimentos ela recebe mais a pressão pra crescer mais rápido. Só que a maioria não tem experiência em gerir uma empresa que cresce tão rápido. E dentre as várias coisas que elas são péssimas em fazer é treinar os programadores júniors. Por isso elas tendem a procurar só programadores mais experientes, muitas vezes tentando tirar funcionários de outras empresas e pagando mais caro do que deveriam. Isso causa distorções graves no mercado e ao mesmo tempo é um tiro no próprio pé. Elas não percebem isso porque muitas sequer dão lucro, vivem de rodada de investimento atrás de rodada de investimento, então eles não entendem o conceito de eficiência, são máquinas de queimar dinheiro. A maioria vai quebrar ou ser adquirida por outra empresa maior.

Então de um lado existe alta demanda e escassez de profissionais experientes. E do outro lado existe uma oferta crescente de programadores júniors saindo de cursos online que não vão conseguir chegar nesse nível de qualificação sendo contratados por tech startups que ainda não chegaram no nível de crescimento acelerado via investimentos. E esse é aquele cenário onde o júnior é contratado como se fosse sênior, não vai ser mentorado direito, e tem grandes chances de acabar queimado, frustrado e sem evolução adequada. Por isso outra consequência é que o nível de retenção é baixo, os programadores crescendo nesses ambientes tem uma visão irreal de como as coisas funcionam e do que realmente valem, e a barreira de entrada é maior. Portanto existe essa escassez de moscas brancas, os seniors que conseguem carregar esse tipo de estrutura ineficiente nas costas.

Pra completar esse pensamento, vou engatar a terceira pergunta que é “Você falou sobre aprender tecnologias que estão ficando “top trending”, mas seria errado você aprender uma tecnologia já bem estruturada no mercado de trabalho e depois se aventurar por tecnologias novas?”

Parte da estratégia das tech startups é tentar adotar tecnologias mais novas que elas acreditam que podem dar alguma vantagem no crescimento delas. São as que estão usando os Clojure ou Elixir da vida, coisas mais novas da AWS como Lambdas, serviços de machine learning de uma Azure por exemplo. Ao mesmo tempo é uma forma de tentar reter as pessoas porque não tem tantos outros lugares que elas podem usar tecnologias novas demais. Por outro lado você é um profissional que tem mais valor se ao mesmo tempo souber as coisas novas e tiver domínio sobre outras tecnologias mais difundidas e maduras como Java ou Python por exemplo.

Uma empresa de tecnologia raramente usa uma única marca de tecnologias, porque sempre existe a ferramenta certa pro uso certo. Saindo do mundo Web, você tem mais valor como programador mobile se souber Java e Kotlin direito pra programar Android. Ou pra mercados mais de nicho que faz coisas como IoT ou hardware embarcado. Ou mesmo em grandes corporações. Aliás, voltando à conversa de se você for iniciante e tiver acesso a uma região geográfica com mais grandes empresas que não são tech startups, essas podem ter condições de oferecer programas de trainée mais estáveis, que conseguem absorver mais programadores júniors inexperientes e dar um treinamento melhor. Eu expliquei um pouco mais sobre isso tanto no meu vídeo sobre o Mercado de TI quanto no de SAP, não deixem de assistir pra saber mais.

Quando se fala em carreira você não deve ser imediatista. Eu sei como é, a gente é jovem, vê o brilho das tech startup, tecnologias modernas, e acha que esse é o objetivo do emprego dos sonhos. Baixe suas expectativas. Tech startups no geral são péssimos lugares pra iniciantes, porque a prioridade não é te ensinar nada, a prioridade é crescimento acelerado acima de tudo, muitas vezes queimando etapas. É um lugar melhor pro senior aventureiro que tem mais mobilidade pra fazer o que ele já sabe que tem que ser feito. Mas pra maioria dos juniors, você pode acabar sendo queimado rápido demais e se frustrar com a área antes do tempo. De novo, óbvio que tem exceções, mas como estou considerando a maioria da população e o mercado em geral, eu diria pra procurar empresas que tem um histórico maior, já existem faz 10 anos ou mais, e que oferecem um mínimo de suporte pra ganhar experiência. Não existem garantias, só brincar com a sorte mesmo. Talvez você desperdice menos tempo no começo, que é quando você ainda não vai conseguir enxergar tudo. Mesmo que essa empresa seja como no caso da primeira pergunta: no interior, com tecnologias legadas.

Muito se fala em soft-skills. Tem milhares de podcasts, videos, livros e palestras sobre o assunto. O mais importante é aprender a ser honesto. E não, se você é iniciante, você ainda não sabe disso. Quando você trabalha sob pressão é que você vai saber se é de verdade ou se também vai sucumbir a dar respostas fáceis. Ser honesto é saber dizer “não” quando sabe que não vai conseguir entregar. Só que não dá pra dizer “não” sempre, senão pra que você serve? Como aprender a dizer esse “não” na hora certa, ou melhor, como aprender a gerenciar expectativas?

Você pode ler quantos livros quiser. Mas a única forma de aprender é na prática, em situações reais, tomando até decisões erradas e tendo que consertar depois. Por isso eu digo que não importa se é uma empresa de interior, com software mal feito, com chefes ruins. Se você sempre for o cara que diz sim, fica quieto quanto devia falar, ou fala demais quando não precisa, e não consegue explicar objetivamente porque você prefere uma opção que considera melhor do que a outra que a empresa já usa, então não importa se é uma empresa de interior ou uma tech startup, você ainda não tem o que precisa. Então vai lá e pratica.

Agora aproveito pra colocar a quarta pergunta: “Iniciei recentemente um curso de Javascript e agora estou estudando o mesmo por conta. Gostaria de saber, apenas com Javascript consigo algum trabalho, o quanto tenho que saber nessa linguagem pra atuar na área? Qual é o mínimo que preciso saber pra atuar em uma empresa ou prestação de serviços?”

Isso é um pouco o que eu já respondi acima. Neste momento existe uma demanda alta também por bons profissionais de Javascript. Mas não basta só saber um pouco da linguagem, isso é simples. No caso de front-end, você precisa saber frameworks como React, precisa saber Redux, dependendo da região geográfica precisa saber os concorrentes como Angular que infelizmente muitas empresas ainda usam. Precisa saber como organizar projetos corretamente, as melhores práticas pra organizar módulos, como configurar coisas com Webpack direito.

Precisa saber as bibliotecas mais usadas. Se for fazer uma landing page ou gerenciador de conteúdo precisa saber coisas como Gatsby. Se for server-side precisa saber Node, precisa saber Express. Precisa saber usar frameworks de teste como Chai, Mocha, Puppeteer. E isso que acabei de falar aqui é só o básico. É o mínimo pra Javascript. E quando falamos Javascript, claro, estamos falando da versão ES6 que é a mais usada hoje, mas lembrem-se do que falei no começo: muitos livros e documentações antigas estão defasadas na versão ES5. A forma como se organiza código Javascript hoje e 5 anos atrás é bem diferente.

Como falei na pergunta anterior, por causa desse boom de crescimento rápido tanto de tech startups como produtos web em grandes empresas, a demanda por profissionais que conheçam coisas como Javascript cresceu bastante. Especialmente porque muitos modernizaram ou estão modernizando os front-end com componentes React, usando coisas como Progressive Web Apps pra fazer aplicativos web que funcionem como aplicativos desktop, como a app do Twitter por exemplo. Javascript completo hoje é muito mais abrangente do que 5 ou 10 anos atrás.

Eu diria que hoje, indo pra 2020, o ecossistema Javascript tá um pouco mais estável e menos caótico do que 3 a 5 anos atrás que era uma zona completa. Mas agora se você é iniciante e não sabia disso, pode estar meio assustado, como aprender tanta coisa logo no começo? Vamos pra quinta pergunta que é gancho pra isso, e a pessoa falou: “Tenho alguns problemas que me impedem de prosseguir nessa carreira. Sou muito imediatista, quando inicio algum curso, seja de inglês ou de uma linguagem nova, eu já penso em um longo caminho pra percorrer e acabo desanimando de prosseguir, não consigo adquirir uma rotina de estudos. E também tenho medo de ser burro e não saber programar, ou esquecer de tudo na hora que uma empresa me contratar. Meu conhecimento na teoria é bom, mas na hora de praticar ou criar alguma coisa, eu esqueço ou desanimo por pensar que não consigo achar o que as pessoas iriam pensar. Sempre me dá um branco e não consigo começar nada, nem um portfolio que preciso muito. Tem alguma dica? Já passou por isso?”

Eu já estou parecendo uma vitrola quebrada, mas vou repetir isso até vocês enjoarem ou entenderem de uma vez: existe um limite do que cursos e livros podem fazer só na teoria. Chega uma hora que simplesmente não adianta só estudar. Ninguém aprende a programar só lendo. Não tem um ponto exato pra começar, mas eu sempre vou dizer que você precisa dividir seu tempo entre estudar teoria e praticar. O problema é que muito iniciante ainda acha que prática vem no emprego. E isso era bem verdade, até o começo dos anos 2010 pelo menos. Mas especialmente nos últimos 10 anos com um acesso melhor que a maioria da população tem de internet de banda larga e com a popularização de plataformas como GitHub, você tem literalmente milhares de projetos open source à sua disposição.

Eu falei no episódio sobre a Dor de Aprender o que você tem que fazer: não fique só lendo post, vá no GitHub e baixe os projetos. Digamos que você é o iniciante no interior, que só tem a opção de trabalhar numa empresa com sistemas legados. Ou mesmo se você é um júnior numa tech startup caótica que ninguém tem tempo nem estrutura pra te treinar. Como você vai conseguir aprender o que é um bom código se você só está exposto a código mal feito, seja porque é legado ou seja porque é feito às pressas num lugar que prioriza crescer rápido acima de tudo?

A sua única opção é código open source. Não estou dizendo que todo projeto open source tem bom código, na verdade tem muito código bem porcaria também. Mas o importante é que você consegue achar bons códigos. E mais do que isso. Eu falei que você precisa saber um monte de bibliotecas que muitas empresas modernas usam. Muitas dessas bibliotecas sequer tem cursos ou livros. A sua única forma de saber como elas são usadas é procurar projetos que usam essas bibliotecas. Exemplo simplificado em post de blog é muito pouco. Mas ver só num projeto é pouco, você precisa ver como vários projetos usam a mesma biblioteca de maneiras diferentes.

Aqui você vai encontrar a barreira: você vai ter que encarar qual é sua real determinação em querer aprender. Se você diz que só consegue estudar dentro do horário de uma aula de curso. Se você diz que só consegue pegar no teclado pra digitar código durante o horário de serviço. Essa é sua barreira. Não é um defeito, só não é sua vocação. A maioria dos programadores é assim na realidade. São mais raros os que tem a determinação de, nas horas vagas, ler documentação online, baixar as dezenas de projetos na própria máquina e treinar esses códigos.

Lembre-se, você não tem experiência, muitos que não quiseram ou não puderam fazer faculdade, sequer tem a fundação. Se você não tiver essa disposição, eu realmente não tenho muito mais que eu posso recomendar pra você. Literalmente todo dia tem coisa nova aparecendo. Você pode escolher que não quer ter que estudar pro resto da vida, então você tem a opção de empresas que não estão tão preocupadas em seguir as novas tendências. As tais empresas de interior, empresas cujo foco não é tanto tecnologia, setor público por exemplo. Eu chutaria que a maioria dos programadores na realidade são mais codificadores, não estão tão preocupados em buscar as melhores soluções, mais em manter o que já tem e torcer pra não mudar muito pra não ter que estudar nada novo. Já deixo bem claro que esse não é meu público alvo.

Mas se você gostaria de uma carreira que vai evoluir, e você vai ter mais valor no futuro, você tem que colocar na cabeça que vai ter que estudar e praticar com frequência, pro resto da sua vida, não é uma opção. Na pergunta a pessoa fala que tem dificuldade de se colocar numa rotina de estudos. Isso é muito comum. Eu também não consigo ficar estudando coisas na teoria sem nunca usar na prática. Eu prefiro iniciar pela prática e buscar a teoria pra complementar o que eu não sei e vou intercalando. Raramente eu leio um livro técnico do começo ao fim. Na verdade eu não lembro se um dia cheguei a fazer isso. Eu realmente nunca li um livro técnico de cabo a rabo. Seria uma enorme perda de tempo. Livro técnico é que nem dicionário: é uma referência que você busca em momentos específicos, pra ler um trecho específico, e daí voltar pra prática.

E aí tem o tal medo de numa entrevista não lembrar do que estudou. Ou mesmo quando vai tentar começar um projeto não se lembra também. A razão disso é a falta de prática. Só fazer curso e ler livro é uma chatice. Eu não lembro a última vez que fiz algum curso, mesmo lá no começo. Na real, faz anos que eu não leio livros técnicos nem faço cursos online. Eu só procuro referências quando eu tenho dúvidas específicas. Como eu disse, pra muitas das coisas novas, sequer existem cursos. Eu prefiro sempre ir atrás das documentações online e em alguns casos abrir o código fonte dos projetos que quero usar pra ter uma noção de como funcionam.

Muita gente recomenda você começar um projeto pessoal do zero. É a pior recomendação que se pode dar, justamente porque se você não tem experiência, como vai imaginar como se começa um projeto do zero? Na verdade isso é uma experiência super frustrante pra quem tem zero experiência. É muito melhor começar baixando projetos dos outros. Copie código dos outros, sem nenhum objetivo de no final ter um produto seu que tenha alguma utilidade.

Eu disse isso em outro vídeo e vou repetir de novo: copie muito código. Literalmente abra o navegador no projeto do Github de um lado, abra seu editor de textos do outro, e copie. Treine sua memória muscular a se acostumar com código. Não só baixe o projeto e rode. Crie um novo diretório e redigite tudo do zero de novo. Você vai descobrir que mesmo copiando, seu código vai falhar. Você vai descobrir que às vezes é melhor codar algumas coisas do começo ao fim, às vezes é mais fácil copiar uma parte, tentar rodar, depois continuar. Você vai descobrir que algumas partes você já sabe como codar de uma forma melhor e vai ver na prática se o que você acha que é melhor realmente funciona. E além disso vai ver bibliotecas sendo usadas que você nem sabia que existiam e pra que servem, na prática. Quando você está começando do zero, isso é extremamente importante.

Nem pense tanto em contribuir nos projetos open source logo de imediato. Essa não é a prioridade. Com o tempo, você vai saber quando tá apto a contribuir. E contribuir é vantajoso tanto como exercício e prática quanto pra montar portfolio e currículo. Porque é um código seu que qualquer um consegue avaliar e ver até onde você consegue contribuir. No Brasil parece que nem toda empresa olha isso, mas no exterior é um critério muito importante.

A sexta pergunta eu ouço bastante, a pergunta é curta e a resposta não vai ser satisfatória, mas a partir daqui minhas respostas devem ficar um pouco mais curtas pelo menos. Vamos lá, a pergunta é assim: “Qual seria a linguagem mais fácil pra começar a programar? Eu tentei Python mas falhei.”

Cara, Python é uma das linguagens mais simples pra começar. A sintaxe dela é uma das mais simples, tem poucas exceções às regras, ninguém fica inventando muita moda nos patterns. Não é a toa que muitas faculdades escolhem Python hoje, porque realmente é simples de começar. Mas isso dito, não existe isso de “linguagem mais fácil pra começar”. Qualquer linguagem é fácil pra começar. É que nem eu perguntar: qual idioma é mais fácil pra começar. Tanto faz. Qualquer criança no mundo, nascida em qualquer país do mundo, aprende o idioma local. O que faz a diferença não é a dificuldade do idioma comparado com a que você já sabe, é quanto você está disposto a mergulhar nela. Como eu disse antes, se sua disposição for fraca, qualquer opção vai ser difícil.

Você tá no começo, literalmente tanto faz. De preferência procure um conjunto de tecnologias que é usado nas empresas da sua região. Depois você aprende outras. Daqui 5 anos as linguagens que hoje são consideradas as mais tops, já não vão mais ser. Nem se preocupa e se não assistiu ainda veja meus episódios sobre “Sua Linguagem Não é Especial” e “A Dimensão do Tempo” onde eu tento explicar mais essa visão de longo prazo.

A sétima pergunta é outra que ouço bastante ainda: “Pra irmos pro framework, precisamos dominar a linguagem pura ou basta saber do básico ao intermediário? Por que as vagas de emprego hoje em dia tudo pede eles, perdi duas vagas em entrevista porque eu disse que sabia a linguagem pura.”

Você precisa saber obviamente, tanto a linguagem quanto o framework. Por exemplo, Javascript e React. Python e Django. PHP e Laravel. Ruby e Rails. Java e Spring. Você nunca vai conseguir saber 100% de qualquer linguagem. Isso leva anos, provavelmente nem os criadores dessas linguagens conseguem saber tudo que elas fazem hoje, porque é como um idioma. Nem Shakespeare saberia tudo de inglês. Só com a linguagem, sem ter conhecimento do ecossistema ao redor, você tem bem pouco valor pro mercado. O mercado adota frameworks, bibliotecas, ferramentas e processos que você vai precisar saber. Portanto não tem nenhum problema em começar pelo framework e aprender o mínimo da linguagem pra conseguir copiar e colar trechos que viu no stackoverflow. Muita gente faz isso.

Mas deixa eu colocar isso bem claro: é muito fácil pra qualquer sênior olhar pro código feito dessa forma e saber que é trabalho de um iniciante. Vira e mexe eu avalio código e de bater o olho eu já sei se é um iniciante ou alguém mais experiente. Sei quais trechos tem cheiro que foram copy e paste. De novo, pensa um idioma. Se você faz uma redação, algumas partes você mesmo escreve, outras partes você abre um livro de Shakespeare e copia trechos, abre um livro de Mark Twain e copia outro trecho. Você não acha que o estilo da codificação fica diferente? Alias, fica bem diferente? Por isso eu enfatizo tanto pra você treinar copiando código dos outros o máximo que puder. Com o tempo você vai começar a notar esses padrões. Comprimento de métodos, complexidade do código, estética da organização, e com o tempo vai começar a se preocupar não só com a função, mas com a forma do seu código. Vai identificar o que é sujeira desnecessária, vai aprender a reduzir seu código ao mínimo necessário que deixa ao mesmo tempo legível e também eficiente.

Não se preocupe, seu código no começo vai ser sempre ruim. Não importa se você começou aprendendo primeiro a linguagem e depois pulou pro framework, ou se começou pelo framework e foi aprendendo a linguagem no caminho. Qualquer das duas opções você tem que continuar estudando os dois. E se você parar, qualquer um mais experiente vai saber qual é seu nível só de olhar pro seu código. Aliás, isso é outra dica: se alguém que se diz senior, olhar pro seu código de junior, e não tiver nada a dizer, provavelmente é porque ele também é junior e só tem o título de senior.

A oitava pergunta é uma continuação. Depois de ter passado do estágio de aprender o básico de uma linguagem e dos frameworks, a dúvida é: “Eu tenho muita dificuldade com CSS, não consigo encaixar as coisas onde eu quero na página, e também tenho dificuldade com responsividade. A maior parte do meu trabalho é construindo APIs REST, e alguns back-offices com o próprio Rails. Meu foco é no backend, mas acabo mexendo um pouco com front e deploy no Heroku. Como profissional, eu devo focar meus estudos em superar essa dificuldade com CSS ou focar na minha carreira de backend e estudar TDD, design patterns, fundamentos, etc? Lembrando que meu foco é ser desenvolvedor fora do Brasil.”

A velha discussão sobre desenvolvedor full-stack. Isso existe e não existe. Em pequena escala é possível ser full-stack. Mas em grandes tech startups, que já tem alcance e escala, o trabalho de engenharia é muito mais especializado. Então a discussão se divide entre empresas onde é possível ser full-stack e onde não é. E a barreira é a quantidade de conhecimento avançado e experiência que o profissional precisa ter. Pra que direção você vai depende que tipo de empresa que você tem como objetivo. Tanto no Brasil quanto no Exterior. Empresas menores tendem a querer mais um “full-stack” que no fundo é alguém que consegue desenvolver e deployar uma aplicação web de ponta a ponta sozinho, mas sem se preocupar com escala e segurança de tech startup nível Uber. Claro que o que esse full-stack vai saber em termos de conhecimento e experiência é muito menos que um back-end especializado senior de um Uber.

Agora, o que foi listado como TDD, design patterns, fundamentos, ainda é só o básico. Tanto pra empresas médias, quanto pras grandes isso é be-a-bá, coisas que juniors já tem que estar estudando, plenos já tem que saber. Back-end senior tem ir além disso. Mas o que vai determinar até onde você vai é o quanto você tem disposição pra buscar coisas novas versus se conformar onde está e evitar mudanças.

A nona e penúltima pergunta é outra que não tem uma resposta satisfatória. A pergunta é: “Onde você vê mais vagas de emprego. No front-end ou back-end?”

Dependendo de que site de empregos ou post analíticos você procurar, vai achar respostas diferentes. Dependendo se está olhando só na sua região, nos grandes centros, em outros países. Depende. E de novo, como eu disse antes, existe escassez de profissionais de qualidade e existe excesso de profissionais inexperientes ou ruins mesmo. Se você for um programador ruim, não tem vaga decente em quase nenhum lugar. Se você se esforçou pra ser qualificado, existe vaga sobrando. E tanto faz se é em front, se é em back, em devops, em infosec. Pense sempre assim: se você sabe pouco, tem muito mais concorrência, portanto você vale menos. Se você se esforçou pra saber mais, tem muito menos gente que se esforçou, então a concorrência é menor. É lei da oferta e da procura. Use essa lei a seu favor e acumule mais conhecimento e experiência do que a maioria está fazendo. Se você está seguindo a maioria, você provavelmente está indo na direção errada.

E finalmente, a décima e última pergunta de hoje diz: “Meu sonho é ser um engenheiro de software, programo já tem 5 anos e amo fazer isso, mas ao mesmo tempo amo empreender. Estou criando minha empresa, vai ser um produto saas. Será que um dia vou ter que tomar a decisão de ou empreender ou programar? Os dois consigo fazer? Ouvi dizer que um dia se eu quiser que a empresa tenha sucesso vou ter que deixar de codar.”

Empreender, principalmente no mundo de tech startups, tem um fator que é pouco dito: o fator QI, que é Quem Indica. Nada é garantido no mundo de empreendimento, mas se você já é bem conectado, seja por histórico familiar e coisas assim, você sempre vai ter chances melhores de conseguir parcerias melhores, investidores e tudo mais. Se como eu, você não teve nada disso, sua única chance é conseguir isso do zero e confiança é algo que se adquire rápido. Certamente não tem vantagem nenhuma ir em evento de networking trocar cartão.

Criar um produto é razoavelmente fácil. Se você não for ruim demais, eventualmente consegue codificar um produto. Se ele vai ser bom ou não é outros quinhentos. Porém o maior custo de um produto do zero é o marketing. Estou falando numa ordem de grandeza maior do que você gastar pra fazer o produto. Um produto ruinzinho que tem um marketing caro tem mais chances de atrair usuários do que um produto extremamente bem feito que ninguém nunca ouviu falar. Eu falei que estamos no meio de um boom de tech startups, significa que a concorrência é enorme. Ser só um pouquinho melhor do que a concorrência, ainda mais se for só subjetivo, não basta. Pra conseguir crescimento orgânico só na competência técnica, sem apoio externo, é basicamente sorte.

Se seu objetivo é ser um engenheiro de software bom, isso vai de encontro a empreender, que também é uma atividade de tempo integral. De novo, se você já não tem excelentes sócios administradores, que conseguem perfeitamente levar a parte tributária, fiscal, vendas, marketing, suporte, recursos humanos, você vai ter que fazer tudo isso sozinho. É muito raro, sozinho, conseguir fazer tudo e ainda conseguir ter alguma chance de ter sucesso. Já vi gente conseguir, mas é a exceção da regra. Por isso não é uma recomendação.

E isso é outra coisa que eu falo pra todo iniciante na carreira. Empreender muito cedo não é nunca uma recomendação. Administrar uma empresa de maneira inteligente e eficiente, especialmente no começo, é tão difícil quanto fazer um bom código que funciona, sem bugs e que escala. Não superestime suas capacidades de programação e nem subestime a dificuldade de ser empresário com as leis toscas do Brasil. Aqui é uma preferência pessoal, mas eu prefiro ir um caminho de cada vez. Primeiro ganhar calo como programador de verdade em uma variedade de projetos diferentes até se tornar realmente bom e com o tempo ver como as empresas realmente funcionam e durante esses projetos ir conhecendo pessoas fora da sua área como advogados, contadores, administradores, que você passe a confiar e que também confiam em você depois de ver resultados, e naturalmente você pode se tornar um empresário.

Tudo isso muda se você já tem dinheiro, vem de família abastada, e pode contar com esse networking e recursos, claro. Mas não é a realidade da maioria das pessoas. O caminho pra se tornar um bom profissional, um bom engenheiro de software, não é simples. E não deveria ser mesmo, por isso ele é bem remunerado. Justamente porque a maioria das pessoas desiste no caminho, é desonesto, não consegue admitir as próprias fraquezas e por isso nunca sabe onde precisa melhorar, e gasta mais tempo botando defeito no mundo e nas outras pessoas do que em si mesmo. Eu sempre falo que se alguém reclama tempo demais, é justamente o tempo que não está usando pra praticar, estudar e entregar valor de verdade. Acho que falei no video sobre SAP que no mundo de consultoria a gente tem um nome pra isso: consultor crocodilo, que é aquele que tem boca grande e braço curto.

E por hoje é isso aí, não dá tempo pra responder todas as outras perguntas que recebi, mas essas representam a maioria das coisas que me perguntam. Eu tentei cobrir os cenários que eu acho que a maioria das pessoas se encaixam, seu caso particular talvez não esteja aqui. Também não tem problema me mandar perguntas em privado pelas redes sociais, mas eu realmente não consigo responder todo mundo de bate pronto, mas pode ser muito útil pra um próximo vídeo. Vocês gostam desse tipo de video de vez em quando? Não deixem de dar feedback nos comentários abaixo, se curtiram o video deixem um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. Aliás, o YouTube vira e mexe tira a sua assinatura do canal se você não volta com alguma frequência, então chequem se ainda estão assinando! Por hoje é isso aí, a gente se vê, até mais!

Olá pessoal, Fabio Akita

Antes de mais nada, meus agradecimentos ao Codigo Fonte TV pelo convite pra compartilhar nossas mensagens pra comunidade brasileira de desenvolvimento de software.

Estamos nos anos 20 do século XXI eu fico pensando uma coisa. Faz só 6 décadas que começou a revolução do circuito integrado. Faz só 5 décadas que começou a revolução dos computadores desktop. A revolução da Web ainda não completou 3 décadas. E faz só 1 década que tivemos a revolução dos smartphones. Durante minha carreira de 30 anos de programação eu tive o privilégio de testemunhar boa parte dessa história em primeira mão e mesmo assim eu não consigo imaginar o que vai acontecer na próxima década. Não existiu melhor momento pra se tornar um programador do que agora e fazer parte dessa história que vai continuar transformando a humanidade. E não tem nada mais empolgante pra mim do que saber como essas coisas funcionam e ter parte da construção do futuro. Juntem-se a nós!

Muita gente me procura via mensagens diretas em redes sociais, em particular pelo Instagram. Pro episódio de hoje eu selecionei 10 perguntas que representam a maior parte dos temas que costumam me perguntar e apesar de já ter parcialmente respondido algumas delas via os temas de outros vídeos passados, vou tentar compilar respostas um pouco melhores hoje. Espero que ajude.

O tema vai ser “Perguntas mais frequentes de iniciantes no mercado de tecnologia”. Diferente do vídeo que eu fiz chamado “Começando na Carreira de TI” (https://www.youtube.com/watch?v=H84WD_xyj10) onde eu abordei assuntos que começam mais na escolha da faculdade primeiro, esta é mais focado no primeiro emprego e na forma de começar a evoluir. Depois de assistir este video convido vocês a tentarem o vídeo “Dimensão do Tempo” (https://www.youtube.com/watch?v=Qb5b8ZE9tIY) e “O Mercado de TI para Iniciantes em Programação” (https://www.youtube.com/watch?v=O76ZfAIEukE) também.

Se vocês ainda não me seguem nas redes sociais, não deixem de seguir. E podem mandar perguntas em privado que eu possa usar em próximos episódios de perguntas e respostas.

DESCRIPTION

Pra continuar esta sequência respondendo algumas perguntas frequentes que as pessoas me tem feito em mensagens diretas em redes sociais, no episódio de hoje que explorar as perguntas de “Quais cursos são melhores? Quais livros vou aprender mais rápido? Devo começar com Design Patterns?”

Eu não imaginava que as pessoas tinham tanta dificuldade no início, sobre o que exatamente devem fazer. Eu já falei bastante sobre “Aprendendo a aprender” e também sobre “prática deliberada” mas eu acho que nunca elaborei o suficiente pra ficar prático pra maioria das pessoas.

Então eu quero dizer mais claramente o que, na minha opinião, tem de errado na maioria das recomendações pra iniciantes que eu sempre ouço, e o que eu acho que é a melhor forma de pensar no aprendizado em geral.

Links:

• Introduction to Algorithms (The MIT Press) 3rd Edition, Kindle Edition (https://www.amazon.com/Introduction-Algorithms-Press-Thomas-Cormen-ebook-dp-B007CNRCAO/dp/B007CNRCAO/ref=mt_kindle?_encoding=UTF8&me=&qid=)

SCRIPT

Olá pessoal, Fabio Akita

Ultimamente eu venho tentando responder algumas perguntas frequentes, por isso fiz os episódios de não terceirizar decisões e depois sobre os níveis de experiência. Mas tem outra pergunta que muitos iniciantes fazem bastante e eu tenho tentado responder direto de vez em quando mas acho que é hora de fazer um vídeo a respeito.

O episódio de hoje é pra explorar a seguinte pergunta: “Akita, que cursos eu deveria fazer ou que livros eu deveria ler pra começar em programação? Comprei o livro de Design Patterns, vai me ajudar?” Mas e se eu te dissesse que eu leio muito pouco livro técnico e acho que nunca fiz nenhum curso de programação de verdade até hoje?

Pra ser exato, se você assistiu meu vídeo sobre meus primeiros 5 anos, eu fiz um pequeno curso de programação sim, em 1990, quando tinha uns 13 anos, de Basic. Este episódio é um daqueles difíceis de organizar as idéias, porque dá pra explicar de dezenas de jeitos muito diferentes. Se você não assistiu os outros vídeos do meu canal, eu sou programador desde 1991 e de lá pra cá eu aprendi e trabalhei com dezenas de linguagens e frameworks diferentes, de comerciais como Java ou C#, a open source como PHP e Ruby, a mobile como Objective-C e entreguei projetos de todos os tipos. E desde 1990 eu venho aprendendo a maior parte do que eu sei quase sempre sozinho. A intenção do vídeo de hoje é ser meio repetitivo mesmo porque eu quero tentar marretar alguns conceitos na sua cabeça.

Quando eu entrei na faculdade eu já sabia o básico de programação. Eu não tinha a fundação pra explicar o porquê das coisas, mas eu conseguia achar as pistas iniciais pra começar a resolver um problema. Então a faculdade nunca me ensinou a “programar” propriamente dito. Agora, eu sinto que muita gente que ansiosa tá no problema anterior: você se sente devagar. Sente que estuda, estuda, mas não avança. Parece que todo novo problema te joga de volta à estaca zero. Você consegue resolver um problema, mas o próximo não consegue mais.

Parece que existe um consenso num caminho: faça um curso, compre um livro, daí tente fazer um projetinho seu do zero. Já ouvi muito isso. Mas eu acho que isso não é eficiente pro aprendizado. Pra que fique claro: eu não estou dizendo que o conteúdo em si seja ruim. Eu só acho que em alguns casos não se leva em consideração que existem dois tipos distintos de público.

Eu dividiria os iniciantes entre aqueles que naturalmente são autodidatas e os que não são. Os que não são, por diversos motivos, tem dificuldade de desviar do material que é apresentado. Elas se sentem mais confortáveis seguindo uma receita ou um procedimento. E quando algum passo diverge do procedimento eles ficam angustiados e travam e não conseguem saber que passo tomar em seguida.

Autodidatas naturalmente não se importam muito com procedimento. A gente obviamente tenta seguir, mas quando um passo não funciona, em vez de sentir angústia a gente sente uma raiva que nos leva a querer entender porque o passo falhou. Foi culpa do procedimento? Foi minha própria culpa porque errei algum passo anterior? Se for esse o caso, deixa eu voltar passos e tentar de novo. Deixa eu voltar pro começo e tentar tudo de novo. Ainda não funciona? Deixa eu pesquisar. Deixa eu perguntar pra outras pessoas. E assim vamos até uma hora avançar pro próximo passo. Por isso eu digo que autodidatas sempre vão avançar independente da qualidade do material de ensino. Porque a gente naturalmente não se conforma. E quando um autodidata se dá bem, não foi por causa de algum curso ou material, foi só a determinação de avançar mesmo.

Por isso eu enfatizei a idéia de não delegar suas decisões num vídeo inteiro. No aprendizado os autodidatas naturalmente tomam uma decisão: se o procedimento não funciona, vou tentar descobrir porque. O procedimento não decide por mim, eu decido pelo procedimento. Os não-autodidatas quando encontram uma barreira, eles travam, e tem a expectativa que alguém ou alguma coisa vai tirar eles do problema. Como assim o procedimento não funciona? Devia funcionar. Vou cruzar os braços e esperar até alguém consertar o procedimento. E vou reclamar que o procedimento não funciona. E vou querer meu dinheiro de volta. Em qualquer outro contexto isso não está totalmente errado, mas em aprendizado é o exato oposto de aprender.

Eu não sei como chamar um não-autodidata então me perdoem se o termo não soa bem, mas vou chamar de pessoas passivas, que esperam as coisas acontecer em vez de fazer as coisas acontecerem. Em um ambiente de aprendizado, você precisa ser diferente: você não quer que as pessoas digam o que você tem que fazer. Você quer referências e orientações mas não ordens nem procedimentos. Mas a maioria dos tutoriais e cursos introdutórios que eu vejo se preocupam em ensinar o “o que” em vez do “porque” e faz sentido. Explicar “o que” fazer é muito mais fácil do que explicar “por que”. Vejam este canal. O “o que” normalmente tá no título, ou no primeiro minuto do vídeo. É o porque que custa 30 minutos ou 1 hora.

Agora, se alguém quer ensinar, ele quer que os alunos tenham o máximo de satisfação possível no final. Se tentar ensinar de verdade, forçar os princípios, explicar os porquês, criar situações de frustração pros alunos. A maioria vai desistir. Porém, se focar mais em exemplos simples e procedimentos, até o pior dos alunos vai conseguir passar por todos os passos. E a satisfação no final vai ser maior porque fica a falsa sensação que aprendeu alguma coisa, quando na verdade só seguiu um procedimento. E qualquer um consegue seguir procedimentos, não requer talento, tampouco habilidade.

É que nem quando você era criança e tinha aqueles livros de colorir com espaços numerados bonitinho. No número 1 você pinta de vermelho, no 2 você pinta de verde, vai seguindo as instruções e no final você tem um desenho colorido bonito o suficiente. Você aprendeu a pintar? Não. Você aprendeu a teoria das cores e como harmonizar essas cores no desenho? Não. Você pintou um desenho mas não avançou nenhum passo em aprender arte. Isso se chama passatempo.

Eu não sei se vocês já se interessaram em assistir vídeos ou documentários sobre o início dos computadores caseiros no fim dos anos 70 e começo dos 80. Na Europa com os ZX-Spectrum. Nos Estados Unidos com os Commodore. Mesmo no Brasil com os TK que eram clones dos Sinclair. E vários outros modelos similares e simples de 8-bits ou 16-bits. Você podia programar em Basic ou Assembler, linguagem de máquina mesmo. Eram computadores super fracos, com pouquíssima memória e processamento, mesmo pros padrões da época. E eles costumavam vir com um manual de instruções que normalmente ensinava o básico de Basic .. alguns exemplos de códigos pra animações e joguinhos simples nível jogo da velha. E era só isso que você tinha.

Muitas vezes você sequer tinha onde gravar o que programava, porque gravador de fita cassette era opcional, disk drives de 5 e 1/4 ou 3 e 1/2 eram mais caros. HD então era inacessível, muitos desses computadores nem aceitavam. A maioria das pessoas se contentava em comprar joguinhos e programas educacionais e ser só um mero usuário do computador. Uma pequena parcela aprendia a programar nessas máquinas limitadas. Sem cursos. Sem livros. Sem internet pra pesquisar nem nada.

Vocês perceberam que eu já contei muitas dessas histórias em episódios anteriores? Eu posso ter sido sutil, mas eu falei de tudo isso até hoje pra ver se vocês chegavam na pergunta mais óbvia. Como pessoas como eu, quando criança, conseguimos aprender a programar num ambiente muito mais hostil do que hoje em dia?

Eu já dei metade da resposta no vídeo de não delegar suas decisões e também no de como eu aprendi inglês sozinho. E a resposta não é porque eu ou essas outras crianças da época éramos gênios, com QI superior ou qualquer bobagem dessas. A resposta mais simples é porque a gente não deixou de ser criança até hoje. Vou relembrar o que eu disse no vídeo de inglês. Muita gente tentando aprender a falar em inglês não consegue, porque tem vergonha de falar errado. Então fica nervoso, gagueja, dá branco, e isso deixa ainda mais nervoso, gaguejando mais. Até o ponto onde a pessoa conclui: ahhh isso Não é pra mim, eu não sou inteligente o suficiente pra aprender (chora).

Eu não sou um profissional de ensino, nem estudioso do comportamento humano, mas eu tenho uma teoria. Tirando os casos de real deficiência física, doença, ou algo assim, eu realmente não acredito que as pessoas sejam incapazes de aprender qualquer coisa. E eu não digo isso porque eu sou algum tipo de humanista e tenho fé nas pessoas ou qualquer bobagem assim. Na verdade é até o oposto. Mas deixa eu apresentar um fato pra vocês. No exemplo do inglês por exemplo, pra você que acha difícil falar, que acha que o curso é ruim, ou que o material que você tem é ruim, ou que você só é burro mesmo e nunca vai aprender. Você fala português?

Concorda comigo que 100% das pessoas nascidas no Brasil, com ou sem educação formal, todas falam português? Porque existiria uma deficiência pra se aprender inglês mas não existe uma deficiência que te tornou incapaz de aprender português quando você era criança? Minha teoria é que todos nós nascemos sem noção de “sentir vergonha” ou qualquer tipo de “auto-julgamento”. Quanto mais nova uma criança, menos vergonha ela tem, mesmo falando errado. E ela fala errado o tempo todo, alguns adultos acham bonitos, outros acham irritante. A gente tenta corrigir e elas não ficam mudas de vergonha, elas atentamente copiam os adultos. Elas vão de poucas sílabas sem sentido, palavras que não formam frases direito, até conseguir argumentar coisas complicadas com os adultos. E tudo isso sem NENHUM treinamento formal.

Nenhuma criança precisou de curso pra aprender a chutar bola na rua. Nenhuma criança precisou de curso pra aprender a se comunicar com as outras no jardim da infância. Elas simplesmente vão e fazem. À medida que se envelhece - e aqui eu não tenho bagagem técnica pra explicar porque - cria-se uma barreira. Em algum momento você tentou fazer alguma coisa que ainda não sabia como, você errou, alguém te criticou ou tirou sarro de você, e você parou de tentar. A partir desse dia, tudo que antes você não julgava difícil começou a ficar angustiante, frustrante, você se sente desajustado, inadequado, burro e até mesmo incapaz.

A grande maioria das pessoas de 40 anos, se eu falar, suba num palco e fale. Ou, grave vídeos e mostre pras pessoas. Elas vão ficar aterrorizadas. Eu também fico. Até hoje quando vou dar uma palestra, não importa se é pra 500 pessoas ou pra 10 pessoas, me dá frio na barriga, começa a vir os pensamentos de “e se me der um branco”. Se eu errar será que as pessoas vão achar que eu sou uma fraude? A diferença é que independente disso eu sou kamikaze, então eu ligo o “foda-se” e simplesmente vou. Pessoas como eu não fazem as coisas porque não temos medo. A gente faz as coisas apesar do medo. O medo que você sente eu também sinto e ela continua aqui. Mesmo depois de anos e anos. Você pode se esconder e evitar o medo ou você pode aprender a conviver com o medo. Em qualquer dos dois casos o medo vai continuar, então porque não só ligar o foda-se?

Deixa eu fazer uma tangente. Alguns meses atrás eu decidi comprar um uniciclo. É super difícil se equilibrar nessa porcaria. A dificuldade inicial é mais ou menos a mesma de skate, do básico de skate, quero dizer. Eu passei 2 ou 3 dias caindo no chão. Se você quer aprender coisas novas, você não pode pensar “puts, que coisa feia eu quarentão caindo no chão e me ralando todo como se fosse uma criança de 10 anos”. É extremamente vergonhoso você sair na rua pra treinar e cair na frente dos outros. E eu tenho tomado tombo na rua mesmo. E o que eu vou fazer? Desistir e inventar justificativas de porque alguém da minha idade não devia estar fazendo essas coisas? Nem a pau.

E veja que interessante. A loja onde comprei até ofereceu um grupo de suporte pra iniciantes treinarem juntos. Mas eu sou muito mais teimoso e arrogante pra isso. Eu gosto de aprender as coisas sozinho. É uma coisa minha. Eu prefiro tentar usar meu tempo da forma mais eficiente possível e me deslocar pra algum lugar, num horário pré-determinado, nunca me pareceu eficiente pra mim. Eu não gosto de ter outras pessoas do lado pra cair na armadilha de usar a muleta do “puts, isso é difícil mesmo né? Se a gente tivesse 10 anos já tinha conseguido” e aí fica um se sentindo mais confortável porque o outro tá lamentando também. Eu vira e mexe me vejo lamentado mas eu odeio ficar me lamentando, e eu detesto mais ainda ouvir o lamento dos outros.

Então, pra aprender, eu comecei num sábado de manhã cedo e eu treinei sem parar, sem pausas mesmo, tomando tombo e tentando de novo, tombo atrás de tombo, até lá pelas 9 horas da noite que foi quando eu consegui andar em linha reta pela primeira vez sem cair. Eu terminei o dia com as pernas roxas, inchadas e raladas de tanto cair. E quando eu caía eu caía mesmo, deixava meu corpo inteiro ir pro chão. Acordei domingo cedo e fiz a mesma coisa, horas a fio até conseguir dar curvas. Eu tinha colocado na minha cabeça que eu ia aprender a andar naquela porcaria em 2 dias, então eu fui e fiz. E isso pra aprender o básico, não estou pulando rampas nem fazendo malabarismo não.

Como qualquer um faria, eu assisti videos de tutorial na sexta feira. Nenhum me ajudou muito porque nenhum disse a coisa mais óbvia. Você já tentou subir numa bicicleta e ficar parado em cima dela? Não dá, ela despenca pros lados. Como você faz pra não despencar? Você sobe na bicicleta já dando a primeira pedalada e sai pedalando. É a inércia do movimento que impede você de cair. É a mesma coisa no uniciclo, você precisa subir nela já andando. Sem isso você vai cair. Sei lá porque; tanto eu, como todo mundo que pediu pra tentar, o primeiro instinto é ficar de pé parado em cima do negócio. Agora que eu sei, é claramente idiota isso, porque ninguém vai conseguir ficar imóvel em cima disso, é impossível. No máximo você vai fazer a roda ficar girando pra frente e pra trás pra se equilibrar no mesmo lugar. Mas parado, parado é impossível.

E eu aprendi a andar a primeira linha reta quando esse insight me ocorreu. Daí o próximo passo foi brigar com o próprio corpo que instintivamente quer parar quando ele se vê indo pra frente sem as pernas estarem se mexendo. Sério, a memória muscular do corpo é uma droga. O corpo quer frear sozinho, daí são horas até você obrigar o seu corpo a desaprender e aceitar que o novo estado natural dele é andando pra frente em cima do negócio. Aprendizado, no seu núcleo, é uma briga de você contra você mesmo. Por isso eu acho que nós anti-sociais temos uma vantagem, porque a gente tá acostumado a brigar com nós mesmos.

Desculpa fazer essa longa tangente de uniciclo mas esse episódio me lembrou dessa situação, porque é igualzinho com qualquer outra coisa que você tá aprendendo. Primeiro, você precisa perder a vergonha de cair, porque é lógico, você é iniciante, você tem que cair, tem que se ralar todo, tem que ficar roxo e machucado. Segundo, você precisa desaprender o que você acha que sabe, porque senão você freia automaticamente e cai sem saber porque.

Respondendo a pergunta que eu fiz agora a pouco. Como nós aprendemos a programar naqueles computadores dos anos 80? A gente caía. Nossos códigos davam pau. A diferença é que a maioria desiste nas primeiras tentativas. Mas alguns de nós ficam roxos e não se importam de ficar mais roxos. Eu pensei nesse exemplo porque este fim de semana mesmo, lá estava eu andando de uniciclo na rua, não prestei atenção, tropecei e caí com tudo no chão. O que eu fiz no dia seguinte? Tomei um remédio pra dor e resolvi andar 20 quilômetros pela cidade, porque depois da queda eu senti meu corpo arregando e ficando com medo, então eu fui ensinar uma lição pra ele, que quem manda sou eu.

O prazer de um autodidata é provar pra ele mesmo que ele suporta a dor. A gente sente dor, igual todo mundo, mas em vez de evitar a dor, a gente faz esforço pra se acostumar a sentir dor. É bem doloroso quando você faz um curso, lê um livro, e seu código ainda não funciona ou você nem sabe como fazer um código diferente do que foi ensinado. É super frustrante. E sua primeira reação é o que? O curso é que não deve ter sido bom. Ou deve ter outro livro que vai ensinar de verdade o que precisa saber. Desculpe se eu sou o primeiro a dizer isso: a menos que você esteja disposto a encarar a dor, engolir o choro, esquecer a frustração, e começar a cair e ficar roxo na frente dos outros, não adianta nenhum curso, nenhum livro, nada, você nunca vai aprender. Ou você pára de desperdiçar dinheiro indo atrás de fórmula mágica, ou engole a dor, pára de mimimi, se compromete e foca no objetivo.

Vou repetir: programação é uma profissão de prática. Qualquer atividade manual como culinária, artes, esportes, como subir num uniciclo, tudo é prática. Eu aprendi o básico, sei andar num uniciclo, cobrir longas distâncias, e não cair, mas eu ainda não sei o avançado. Eu não sei pular rampas por exemplo, estou treinando agora a andar numa perna só. E porque eu faço isso? Não tenho a mínima idéia, eu simplesmente quero.

Até hoje todo mundo chama os invasores digitais russos ou chineses de hackers. O termo acabou sendo distorcido e hacker passou a significar, ou algo ruim e criminoso, ou algo tecnicamente muito difícil que exige um QI superior, como você vê num Mr. Robot da vida. Mas isso é o que antigamente a gente chamava de Cracker. Só que a definição original de hacker é só uma pessoa curiosa. Na verdade mais que só curioso, alguém que é curioso é alguém que faz a pergunta. Mas um hacker é alguém que também procura a resposta. Todo bom programador é um hacker.

Eu sempre achei que a forma mais eficiente de aprender é primeiro tentando fazer, de qualquer jeito, sem objetivos. Sem instrução nenhuma. Existem algumas etapas que você provavelmente vai passar. A primeira é a do zero. Não estou dizendo pra não fazer curso. Faça. Se você ainda não sabe, use pra aprender o básico do ambiente. Como eu uso o editor de textos que o curso apresentou? Como eu salvo o código? Como eu faço pra esse código rodar. Por que vocês acham que os vídeos técnicos que eu fiz primeiro são de como instalar o sistema operacional e configurar as formas de rodar as primeiras linguagens?

Mas você precisa também passar por um período, alguns dias por exemplo, de copiar código de livro, de tutorial ou de qualquer lugar do GitHub, sem se importar se você tá fazendo certo ou errado. Você tá nos primeiros dias. Sério, não tem importância nenhuma saber se você tá fazendo direito ou não. Vou repetir: não importa. A vantagem de código é que ele não custa nada. Você não gasta nada. Se der erro você não perde nada. Não se machuca. Eu gosto de correr antes de aprender a andar. Se cair do uniciclo não machucasse, a primeira coisa que eu ia fazer era pular de uma rampa, depois aprender a andar em linha reta. Mas eu provavelmente ia quebrar uma perna, então não dá pra fazer isso. Mas com código dá.

Corre e depois anda. Copia um monte de código. Parece idiota isso, mas abre um código do GitHub de um lado, o editor do outro lado e vai copiando, da mesma forma como você copiaria um texto de um livro no Word. A intenção é ganhar memória muscular. Ao fazer isso várias vezes, você vai instintivamente começar a ganhar noção de como os códigos são escritos, como programadores melhores que você dão nome pras coisas, com que estética. A silhueta do que é um código vai começar a se formar na sua cabeça. Nesse ponto não importa se esse código vai servir pra alguma coisa ou não. Só digita muito, por horas, dias. Você precisa se familiarizar com o máximo possível de código num período curto de tempo.

Eu aprendi a datilografar desse jeito. Lembram no episódio de Henry Jones que eu disse que eu copiava enciclopédia? Não era uma vez só não. Tinha verbetes que eu copiava múltiplas vezes, porque eu achava que não tinha ficado bom da primeira vez. Mas pra que fazer isso? Não tem nenhum motivo, só porque eu gostava da sensação de sair do ponto onde eu era devagar até ficar rápido copiando. Foda-se o conteúdo do que eu tava copiando. Eu tô dizendo pra você fazer a mesma coisa, mas não só pra ficar rápido. Copiando muitos textos eu pouco a pouco fui entendendo o que é o tamanho adequado de um parágrafo? Como é a composição das frases? Que palavras são mais ou menos usadas?

Pouco a pouco, treinando desse jeito, você vai percebendo uma coisa interessante: padrões. No sentido de repetições. Diferentes códigos de diferentes pessoas tem certos padrões embutidos nelas. Algumas são estruturais, algumas são estéticas. Pouco a pouco você vai diferenciando quais são obrigatórias, quais são opções estéticas. Nomenclatura das coisas. Tamanho das funções. Complexidade do código. Diferentes formas de resolver o mesmo problema.

Quando a gente é iniciante dificilmente pensa “quero fazer um programa X” e daí vai magicamente conseguir. Você não vai, e mesmo se chegar perto ou conseguir, vai estar uma droga. É o contrário. Você vai copiando muitos códigos, entendendo o que cada trecho faz. Aos poucos você aprende … ahh é assim que se abre um arquivo. ahh é assim que se grava um arquivo … ahh é assim que eu posso passar uma URL e baixar o conteúdo. Uma hora você pensa … peraí, se eu consigo abrir e salvar coisas num arquivo e se eu consigo baixar coisas da internet … isso é um programa que podia ser útil, vou fazer um programa que baixa os artigos dos sites que eu gosto e guarda em arquivos.

O objetivo aparece sozinho depois que você começa a aprender o que cada trecho diferente de código faz. Inverte sua expectativa. No fundo não importa o que você acha que quer fazer porque na prática você ainda não sabe o que é possível fazer, então suas idéias sempre vão ser medíocres e provavelmente tudo que você consegue imaginar já existe pronto. A menos que você já seja um estudioso de outra área, seja de física, matemática, direito, qualquer outra coisa, suas idéias iniciais sempre vão ser simplórias. Por isso Não importa tanto o objetivo do código, só importa você codar.

Estou sendo bem repetitivo porque parece que não é tão óbvio. Quantas horas você já gastou digitando código? A diferença entre hoje e na minha época é que hoje você tem um troço chamado GitHub onde pode baixar todo tipo de exemplo de código possível e imaginável. Eu nunca mais ia dormir se aos 13 anos eu tivesse um GitHub. Falando em não dormir, o que eu vou dizer agora é o clichê do clichê mas eu vou dizer mesmo assim. Pessoas como eu amam fazer as coisas a noite. Estudar ou qualquer coisa. E existe uma grande razão pra isso: todo mundo tá dormindo de noite. Ninguém te liga. Ninguém te manda mensagem. Ninguém te atrapalha nem te interrompe. Se você mora com outras pessoas na mesma casa, elas provavelmente estão dormindo.

A melhor coisa pra estudar ou produzir coisas criativas é estar completamente focado. É o estado que as pessoas olham pra mim e me chamam de autistas. Porque quando eu quero entrar nesse modo eu literalmente ignoro todo mundo. Meu celular fica permanentemente em “Não perturbe”. Eu literalmente não atendo meu celular. Mesmo mensagens em whats ou direct ou email, eu raramente respondo na hora. Eu respondo quando eu estiver com vontade de responder, nunca antes. E por isso também eu gravo e edito meus vídeos a noite. Não tem barulho, não tem maldito cachorro barulhento do vizinho, não tem barulho de carro, nada pra atrapalhar. Você precisa encontrar seu espaço isolado e usar ele pra estudar e produzir. E não existe mais viciante e mais improdutivo do que redes sociais. Redes sociais é a definição de perda de tempo. Não tem absolutamente nada em nenhuma rede social que exige sua atenção imediata. E se você se acostumar a não querer engajar em alguma coisa na hora que você vê, e espera 5 minutos, quando voltar vai ver que não era assim tão importante que merece seu tempo de comentar. Threads de redes sociais são basicamente coisas inúteis, mas é bom pra quando você vai no banheiro e já tá enjoado de candy crush.

A idéia não é você sair contribuindo em projetos de código aberto também. Se tiver a oportunidade pode fazer, mas não é esse o objetivo principal pra você que é iniciante. O objetivo é você pegar fluência no código. Fluência não é fazer tudo certo em todos os passos. É você dar a cara pra bater e errar sem se intimidar em sentir vergonha. Fluência em uma língua nova, tipo inglês, é a mesma coisa, é a atitude de simplesmente falar, mesmo se estiver errado, e não ter vergonha e se intimidar quando alguém te corrigir.

Você vai notar que a recomendação aqui é igual do vídeo de como aprender inglês. Porque é a mesma coisa. Em vez de tentar decorar gramática, decorar vocabulário e tentar escrever um texto todo certo da primeira vez, e se frustrar, porque obviamente você não vai conseguir. Eu acho mais fácil ler e ouvir o máximo possível de tudo que é lugar. Igual quando você aprendeu português quando era criança. Você aprende a falar igual o que se fala na televisão e igual os adultos ao redor falam. Você não aprendeu nenhuma regra gramatical, você aprendeu via reconhecimento de padrões, ou patterns.

Nós seres humanos somos muito bem equipados pra detectar patterns via nossos sentidos. O que significa isso? Significa que somos bons em detectar coisas que se repetem ao nosso redor. Mas é uma faca de dois gumes. Ilusões de ótica, por exemplo, brincam com os bugs nesse nosso sistema. Muitas vezes esse sentido nos engana, e aí criamos superstições. Por exemplo, associamos muito tempo atrás a correlação de que passar embaixo de uma escada dá azar. Provavelmente porque algumas pessoas que foram vistas passando debaixo de uma escada depois sofreram algum infortúnio. E o pattern de “passar embaixo de escada e sofrer” acabou pegando. A maioria das besteiras que dão trending no Twitter são isso: falácias lógicas por viés de confirmação, uma falha de correlação, vítima do nosso excelente sistema de detecção de patterns. O principal: só porque você nota uma grande repetição de alguma coisa, não a torna boa, pode ser o que chamamos de anti-pattern.

Eu já expliquei no meu vídeo de inglês sobre a diferença entre patterns e padrões. Mas vou repetir aqui de novo pra relembrar. Em inglês existem três palavras diferentes que traduzem pra padrão em português. Temos Standard que é “o” padrão, como um regulamento ou regra a ser seguida. Temos Default que é a escolha padrão, ou seja, dentro de várias opções se você não escolher nenhuma o sistema pode escolher o default. Default pode ser também quando você não paga uma dívida e dá default nela. Finalmente, o que a gente usa em tecnologia que é “um” padrão ou repetição, isso é um Pattern. Patterns não representam uma regra ou regulamento ou o melhor jeito, são simplesmente coisas que se repetem várias vezes.

Isso é importante explicar aqui porque várias vezes muitos iniciantes me falam que estão estudando o livro de Design Patterns do Gang of Four, e me perguntam se isso vai ajudar eles a virarem programadores melhores. Minha resposta é simples: se você é iniciante, isso vai ajudar muito pouco pra quase nada. Patterns é uma coisa que você vai entendendo melhor ao longo do tempo e não adianta só estudar uma vez, você vai revisitando de anos em anos e vai entendendo melhor a cada nova revisitada.

Entendam, a idéia de patterns foi inspirada no livro A Language Pattern do arquiteto Christopher Alexander. Arquiteto de construções de verdade mesmo. Ele compila os patterns vistos em arquitetura que podem ajudar na composição de novos designs usando uma linguagem comum usada a séculos em construções pelo mundo. É um catálogo de organização urbana com mais de 250 patterns que descrevem a visão do Alexander de como uma cidade perfeita poderia ser. Do layout das ruas, até o café da esquina.

O que é um pattern em arquitetura. Vejamos um problema trivial: como entrar e sair de uma casa? Um buraco com uma tábua que abre e fecha. Nome do pattern? Porta. Dá pra implementar de outras formas? Claro, pode ter uma câmera e um computador pra abrir e fechar sozinha. Pode ser redonda em vez de retangular. Pode ser uma porta com outra porta no meio.

Agora, você não precisou ter o livro do Alexander pra saber o conceito da porta. Se você construir uma casinha do zero e esquecer da porta, você não vai conseguir entrar na casa. Mas você sempre pode pegar uma marreta e abrir uma porta na força pela parede. É meio idiota mas funciona. Em código é mais fácil. Se você esquecer da porta, sempre pode refatorar ou reescrever o trecho do código que precisava da porta. O custo do código é proporcionalmente quase zero se comparado a corrigir um erro no mundo físico, de tijolo e madeira.

Meu ponto é que os patterns surgem da observação de centenas de construções. E criam uma linguagem pra descrever os elementos dessas construções. Milhares de pessoas ao longo da história vieram implementando essas construções e agora só ganharam um nome pra podermos falar delas. Eu pensei isso quando o livro do Gang of Four saiu pela primeira vez em 1994. Lembre-se que antes disso a gente já fazia bons softwares e não havia uma formalização de patterns. Ela é útil e importante, mas não é crucial, especialmente no começo.

O livro ganhou notoriedade porque coincidiu com o nascimento do mercado de Java. Então pra uma novo mercado de programadores, orientação a objetos e design patterns pareciam uma coisa nova que andavam juntos e eram a “regra”, o “standard” a ser seguido. Mas na realidade, comece a programar, observar o código de outras pessoas, e você naturalmente chega na maioria dos patterns do livro. De command, a visitor, a observer, a builder. A grande maioria dos patterns, aliás, foi derivado de frameworks de interfaces gráficas como Motif nos Unix. Se você já teve a oportunidade de criar ou usar uma toolkit de elementos gráficos como um tcl/tk ou Qt ou Gtk ou WPF ou Apple UIKit, vai facilmente ver muitos dos patterns do gang of four neles.

E esses não são os únicos patterns. Hoje em dia, por alguma razão, o Domain Driven Design do Eric Evans, que foi lançado em 2003 foi ressuscitado por causa do famigerado pattern Repository. No mundo Ruby on Rails a gente se inspirou no Patterns of Enterprise Application Architecture do Martin Fowler pra pegar emprestado o pattern que ele cunhou como ActiveRecord. Todo guideline visual de interfaces gráficas da Apple, do Gnome, e outros são patterns de como implementar aplicações gráficas coerentes.

Tudo isso e muito mais são patterns. Mas eu acho muito pouco útil estudar os patterns sem ter experiência anterior em programação. Eu acho mais útil estudar patterns depois que você já treinou escrevendo muito código e lendo muito código dos outros. Daí o estudo dos patterns vai ajudar a criar uma linguagem pra descrever patterns de programação que você já estava acostumado a ver mas só não sabia os nomes. Foi o que aconteceu comigo. Ah, isso que eu fazia se chama Visitor, bom saber. Ah, esse outro jeito aqui é um chain of responsability, que fancy, bom saber também.

Se você com pouca experiência começa estudando e decorando os patterns primeiro e depois vai querer tentar aplicar, você vai usar tudo errado. Patterns são ferramentas. Você não deve usar todas ao mesmo tempo. Cada problema tem uma ferramenta pra escolher e nem sempre essa escolha é simples. Até hoje muita gente discute ActiveRecord versus Repository. Eu acho engraçado povo discutindo isso em 2019 sendo que foi ponto de grande discussão em 2003 ao ponto de eu ficar enjoado de ouvir sobre Repository e na época era versus DAO ou Data Access Objects que a Microsoft usava bastante.

Vejam, 16 anos depois e até agora as pessoas ainda não chegaram num consenso sobre acesso e abstração de dados. Além de ActiveRecord, Repository, DAO ainda temos outros patterns como Data Mapper, Table e Row Data Gateway e outros patterns. Patterns não são regras, não são “o” jeito certo de resolver todos os problemas, são apenas repetições, cada qual emergiu pra resolver um problema diferente numa situação diferente.

Por isso eu digo que tanto faz que curso você faça, que livro você leia, no fundo eles são quase todos iguais porque todos vão ensinar mais ou menos do mesmo jeito: do jeito linear, passo a passo, que raramente é o que você vai encontrar no mundo real. No mundo real você tem um problema pra resolver, e sua solução vai depender do quanto você treinou com quantas ferramentas e técnicas diferentes. Pra chutar uma combinação de elementos que pode ou não resolver o problema da forma mais eficiente possível, dentro das limitações e circunstâncias em que você se encontra. Quanto menos você treinou, menos opções você vai ter. Se você só treinou um jeito, você sempre só vai querer resolver de um jeito, e normalmente não é o jeito mais eficiente. E por isso eu falo pra não se apaixonar por uma linguagem ou uma ferramenta. Daí vem o ditado: pra quem só conhece martelo, todos os problemas parecem pregos.

Alguns anos atrás eu comecei a estudar Elixir, Crystal e Rust. Eu li a documentação dos sites deles primeiro. Eu procurei os poucos tutoriais que eles tinham disponíveis 4 anos atrás. E eu simplesmente fui codando, qualquer coisa. Códigos sem nenhum propósito além de exercício. A minha vantagem quando aprendi essas linguagens é que eu já tinha experiência de programação em outras linguagens, então eu não levei mais que 30 dias pra aprender cada uma. A que eu até hoje tenho menos fluência é Rust porque foi o que eu menos treinei. Elixir foi o que tinha melhor material pelo fato que ele pôde aproveitar as décadas de existência e maturidade do Erlang que está por baixo dele, então o framework OTP já era bem compreendido e com inúmeros exemplos, patterns e anti-patterns conhecidos e bem documentados. Crystal foi quase trivial porque ele se valeu de usar quase a mesma sintaxe de Ruby e usar os patterns de Go pra concorrência, então se você já sabe Ruby ou se você já sabe Go, pular pra Crystal é uma questão de poucos dias.

Quanto mais você vai desistindo a cada dificuldade que aparece e desiste de ir até o fim pra resolver, mais difícil as coisas vão ficando. Se você aprender a aprender, que é hackeando seu caminho, resolvendo problemas que o material não previu, ou seja, aprendendo a ser autodidata, a vantagem é que quanto mais você aprender assim e criar seu próprio ritmo, menos difícil vai ficando aprender coisas novas. A maioria das coisas novas é uma melhoria de coisas anteriores. Então as primeiras linguagens que eu aprendi em 1990, que foram Basic e dBase, são hiper simples pros padrões de hoje, mas eu levei meses e meses pra aprender. Porque eu não tinha nem material, nem base de referência. Linguagens ordens de grandeza mais complicados como um Elixir, pra mim, é uma questão de semanas pra me tornar produtivo nelas. Não me tornar um expert, cuidado, me tornar produtivo.

A idéia não é falar mal dos cursos e livros, só apontar que é impossível criar um curso ou livro que consiga te mostrar como é programação na vida real. Eles virariam livros de milhares de páginas e extremamente tediosos de ler. A estrutura de cursos e livros é tentar transmitir um conhecimento no menor tempo e esforço possíveis. É como um livro de artesanato, ele pode te dar passo a passo de como pregar madeira e prego e fazer uma cadeira. Mas se você nunca usou um martelo nem nunca cortou madeira na vida, na realidade você vai quebrar um monte de tábuas, entortar um monte de pregos, provavelmente vai martelar o próprio dedo e se cortar um monte de vezes até conseguir fazer uma cadeira que não vai se parecer nada com a foto do livro. No final a diferença é só isso: quem desiste, o caminho acaba aí. Não tem outro caminho a não ser ir em frente, independente da sua frustração ou da sua vergonha.

Sobre conhecimento de fundação. Eu diria que se tem uma matéria de faculdade que é obrigatório e separa os amadores e hobistas dos que vão fazer uma carreira de verdade em programação é Algoritmos e Estruturas de Dados. Qual é a diferença entre um Tuple ou uma Lista Ligada? Qual a diferença de um String de conteúdo imutável e um String Buffer que você pode adicionar e modificar o conteúdo? Aliás, se é tudo binário, qual é a diferença de um integer e um string? O que de fato é a diferença entre um float e um double? Toda linguagem tem essas coisas, é a base de TODAS as linguagens. Um Java parece difícil porque ela tem umas 20 classes diferentes só pra Listas. Por exemplo, qual a diferença de um ArrayList, um LinkedList, um Stack, um SortedSet, uma Queue?

Daí você precisa aprender: qual a forma mais fácil de estruturar os dados pra ser fácil recuperar o que você precisa depois? Vai passar pelas coisas triviais como Quicksorts ou Mergesorts até chegar em coisas mais legais como Bloom filters e até hash rings e consistent hashing. Quando você entende esses elementos, coisas como computação distribuída, replicação de bancos de dados como NoSQL e tudo mais começam a clicar na sua cabeça mais fácil. Mas pra chegar nisso você precisa sair do básico. Entender as estruturas de dados e algoritmos mais simples primeiro, de um mero struct de C, union types, nomes como markov, levenshtein, huffman e assim por diante.

Algoritmos e Estruturas de Dados eu não vejo como você poderia aprender organicamente, sem um material formal. Vai precisar estudar a teoria e praticar centenas de vezes pra realmente ganhar fluência. Por isso eu acho que linguagens como C ou Pascal eram boas pra começar, porque você era obrigado a entender essas coisas pra fazer qualquer coisa. A maioria das linguagens modernas esconde essas coisas de você, então você não nota que vai precisar até muito tarde.

Esquece estudar Design Patterns ou Arquiteturas de Sistemas antes de aprender Estruturas de Dados e Algoritmos. Estou repetindo isso várias vezes pra vocês colocarem isso na cabeça. Antes de dominar o básico, esquece o avançado, não vai acontecer. É que nem querer aprender culinária e achar que não precisa aprender Mis en place ou descascar batata. Tudo que você constrói precisa de fundações sólidas. Quanto mais porcaria for sua fundação pior vai ser seu puxadinho. Você vai bater num teto muito rápido e não vai conseguir crescer, e seu puxadinho toda hora arrisca desabar. Se preocupe em fundações sólidas, não em hype da moda.

Hype da moda, linguagem ou framework da moda, tudo isso é simples. Sério, se você tem boas fundações, aprender um novo framework “tem” que ser simples. Aprender uma nova linguagem tem que ser simples. Claro, ganhar fluência exige tempo, mas você não vai ficar coçando a cabeça toda hora ficando frustrado porque não consegue começar a aprender. Você tem dificuldade de aprender porque tem preguiça e tá postergando sofrer a fundação, que é chato, teórico, difícil e parece que não tem utilidade. Mesma coisa técnica de usar a faca direito pra cortar as coisas. Você teima em não aprender, e não consegue cortar mais rápido sem cortar os dedos juntos. Porque você é burro, a gente já sabe o jeito certo, isso é o básico, a fundação, o que todo mundo que vai cozinhar já devia saber.

Aliás, caso não seja óbvio, frameworks são implementações de patterns pra resolver um determinado tipo de problema. Por exemplo, frameworks de GUI pra interfaces gráfica como o UIKit da Apple ou frameworks web como Rails e Laravel pra aplicativos web. Ou frameworks como OTP do Erlang pra sistemas distribuídos. Frameworks são manifestações em forma de implementação de patterns reusáveis de programação.

Outra coisa interessante é que muitos design patterns podem ser considerados defeitos nas linguagens. A gente costuma chamar esse tipo de boilerplates, que são trechos de código que todo mundo meio que convencionou a fazer toda vez. É uma sensação de .. “porque eu estou tendo toda hora que fazer esse mesmo código em todo lugar em vez da linguagem ou mesmo do framework fazerem isso por mim?” .. É quando você é obrigado a criar funções ou classes vazias ou arquivos pra lá e pra cá, só pro negócio compilar ou rodar.

Eu vou dizer que ainda não tô totalmente contente com essa minha explicação até agora. Mas os pontos principais pra resumir: Primeiro, estude obrigatoriamente Algoritmos e Estruturas de Dados. Segundo, desligue redes sociais, coloque seu celular em modo de não perturbe o tempo todo. Terceiro, não se preocupe em codar coisas com objetivo no começo, os objetivos do exercício não importam, o único objetivo é codar e codar. Quarto, não importa qual curso e qual livro você vai escolher pra aprender a primeira linguagem, tanto faz mesmo, a diferença entre a maioria dos cursos mais conhecidos é marginal. Quinto, treine, treine, treine e treinar não é fazer projetinho do zero. Nada de bom sai de uma cabeça vazia. Treinar é copiar qualquer código sem nenhum objetivo, quebrar esse código, combinar códigos de pessoas diferentes, mas principalmente, copiar a maior quantidade de código dos outros quanto possível. Só depois de copiar e copiar trechos por centenas de horas você vai começar a identificar sozinho alguns patterns. Quando finalmente você se sentir confortável com os puxadinhos de código que começam a funcionar de forma precária, talvez você possa estudar os diversos design patterns que existem por aí só pra dar nome pros seus puxadinhos. E é assim que você começa.

Eu falei isso no vídeo de Conhecimentos Gerais no começo da série Começando aos 40. Eu acabei de dizer que a coisa mais importante é se expôr à maior quantidade de código dos outros quanto possível, mesmo se não entender nada da primeira vez que ler. É como aprender uma nova língua e desligar as legendas dos filmes. A idéia é você sofrer mesmo, e aprender a lidar com essa angústia de não estar entendendo nada. Pra isso você pode e deve usar o GitHub que está dando sopa com milhões de projetos em todas as linguagens e frameworks que você pode imaginar. É a biblioteca de Alexandria do código. Pra isso, a primeira coisa que você deve aprender é a usar Git, e o Google tá aí pra isso. Hoje em dia tem muito tutorial simples. Se você ainda não sabe, aprende. Qual é a desculpa?

E é isso aí, eu queria deixar uma resposta mais completa pra essa indagação do que eu estava conseguindo dizer nas mensagens diretas. Espero que tenha ajudado a criar um modelo mental do que você devia estar fazendo pra superar essa fase inicial de aprendizado em qualuqer coisa. Se ficou com dúvidas não deixe de mandar nos comentários, se tiver outras dicas também são muito bem vindas. Se curtiram o vídeo mandem um joinha, não deixem de assinar o canal e cliquem no sininho pra não perder os próximos episódios. A gente se vê, até mais.

DESCRIPTION

Continuando na vibe de iniciantes na carreira de TI eu sei que ainda tem muita dúvida sobre os diferentes cursos da faculdade como Ciências da Computação, Engenharia de Software ou Sistemas de Informação.

Além disso todo mundo começando tem dúvidas sobre os diversos níveis de experiência como Júnior, Pleno ou Sênior.

Como iniciante, como eu deveria pensar sobre esses assuntos? Hoje eu resolvi compilar uma longa explicação sobre o que eu costumo ver ao longo de uma carreira, desde a faculdade até a evolução de júnior até sênior.

Links:

• AkitaOnRails [Off-Topic] Opiniões, Verdades, Democracia e Ética (https://www.akitaonrails.com/2011/05/04/off-topic-opinioes-verdades-democracia-e-etica)

Akitando:

• Dúvida: Devo Fazer Faculdade? (https://www.youtube.com/watch?v=XWVcF7BoCSc)
• Devo Fazer Faculdade? (22 Anos Depois) (https://www.youtube.com/watch?v=iRjEa7N8wEo)
• O que Eu Devo Estudar? (https://www.youtube.com/watch?v=Ll1uAZ-WRa0)
• O Mercado de TI para Iniciantes em Programação (https://www.youtube.com/watch?v=O76ZfAIEukE)
• Você não sabe nada de Enterprise! Conhecendo a SAP (https://www.youtube.com/watch?v=FXhcfJnlD2k)
• Não Terceirize suas Decisões (https://www.youtube.com/watch?v=D3L8IOncLkg)

SCRIPT

Olá pessoal, Fabio Akita

Eu percebi pelos comentários que muita gente assistindo meu canal é iniciante de alguma forma em computação, seja porque está na faixa dos 20 anos realmente começando do zero ou porque está na faixa perto dos 40 querendo dar cento e oitenta graus e mudar de carreira completamente.

Então no episódio de hoje eu quero explorar um pouco mais sobre a temática da evolução na carreira. Por exemplo, muita gente ainda tem dúvidas sobre a famigerada tríade que todo RH fala mas quase nenhum sabe definir, o que é júnior, pleno ou sênior. Também um pouco sobre as diferenças nos diversos cursos de faculdade, tipo engenharia de software ou engenharia da computação. No final um pouco sobre o contexto onde os dois pontos anteriores. Pra variar é tema que eu deveria quebrar em uns 3 episódios separados mas queria tirar isso do caminho de uma vez só, então preparem-se que vai ser bem longo!

Como eu disse no episódio anterior sobre Não Terceirize suas Decisões a idéia aqui não é dar nenhum passo a passo pra vocês. Não quero que ninguém pense que eu estou recomendando fazer de um jeito ou de outro. O que eu vou contar hoje vai ser muito mais minha opinião do que uma definição formal, então se você já é experiente e já está avançado na carreira, provavelmente vai discordar de mim em muitos pontos e nesse caso não deixem de compartilhar sua visão nos comentários abaixo. Carreira não é uma receita de bolo certinha, o máximo que podemos fazer é dar perspectiva.

Vamos começar do começo. Eu vou dizer que até eu fico meio confuso com os diferentes cursos em faculdades. Existem faculdades que usam o mesmo nome de curso mas ensinam coisas diferentes, acho que principalmente em Sistemas de Informação. Existem faculdades que ensinam de formas diferentes. Fora os diferentes níveis de qualidade e reconhecimento. Então dependendo de onde você estudar, vai ter diferenças consideráveis. Infelizmente eu não posso ajudar muito aqui, não existe nenhuma forma objetiva de comparar curso a curso de todos os lugares.

Quando eu comecei a escolher cursos pra faculdade lá por 94 haviam principalmente 3 cursos diferentes. Engenharia da Computação, Ciências da Computação e Processamento de Dados. Até onde eu entendia, Engenharia da Computação é de fato uma engenharia, na realidade eu chutaria que é uma especialização de Engenharia Elétrica. Esse é o curso praqueles interessados no hardware em si, microprocessadores, placas lógicas e você teoricamente deve aprender a desenhar circuitos, desenhar placas, propriedade dos materiais e até processos de fabricação.

Normalmente os diversos cursos de engenharia todos começam igual, você tem dois anos da mesma grade e no meio você escolhe pra qual engenharia vai se especializar, tipo civil, naval, produção, elétrica, mecânica, etc. Pelo menos na USP era assim. Os primeiros anos é muita matemática, e ainda assim menos do que nos cursos de matemática mesmo, mas é cálculo, álgebra, física. Confunde um pouco porque você tem programação no currículo, mas eu imagino que é mais voltado à programação de mais baixo nível. Porta lógicas, circuitos integrados, semicondutores, talvez se fale em coisas como CMOS e MOSFET, VLSI, etc. Se você quer trabalhar na indústria de eletrônicos e automação por exemplo, seria esse o curso.

Ciência da Computação foi o que eu fiz, e eu diria que é uma especialização da Matemática Aplicada. A matemática pura, como você pode imaginar, não se preocupa tanto com a aplicação. Já computação é uma aplicação da matemática, por isso eu digo que seria uma especialização. Os dois primeiros anos de Ciências da Computação é muito parecido com os cursos de matemática mesmo e por isso muita gente não gosta porque se vê muito pouco de programação nesse período. Só a partir do 5o período você começa a ver mais coisas como montadores, compiladores, sistemas operacionais.

O objetivo de um curso de ciências não é ensinar o que o mercado do momento precisa. Você até tem matérias opcionais, que tentam introduzir alguma coisa mais prática, mas não é esse o foco. Computação, como eu disse, é uma aplicação da matemática, toda a base de conhecimento que torna um computador possível vem de décadas atrás, começando com a arquitetura de Von Neumann. Não importa se o computador de hoje é ordens de grandeza mais rápido que um dos anos 80, fundamentalmente eles ainda operam da mesma maneira. Mesma coisas como linguagens de programação. Tanto faz qual é a linguagem mais moderna de hoje, um Java de hoje fundamentalmente funciona da mesma forma que um Basic nos anos 70, só é mais complicado. Em vez de aprender só uma linguagem, você deveria aprender como todas elas funcionam no nível dos compiladores, por exemplo.

O que na minha época era Processamento de Dados ou mesmo Análise de Sistemas hoje em dia acho que é chamado de Sistemas de Informação. O grosso da computação aplicada na indústria continua sendo muito de “processamento de dados”. Por exemplo, numa multinacional de 10 mil funcionários, todos eles batendo cartão de ponto, imagine contabilizar as horas trabalhadas de todos, na mão. Ou imagine fazer o fechamento contábil de uma rede de varejo no papel. Ou no Brasil que você tem uma tonelada de regulamentações pra seguir, Reinf, SPED, ECF e por aí vai.

Eu não acompanhei a transição dos cursos de Processamento de Dados pra Sistemas de Informação mas o objetivo é parecido, que é a automatização de processos envolvendo informação na forma de sistemas, por isso Sistemas de Informação. Teoricamente você se forma tecnólogo ou bacharel e pode atuar como um analista de automatização de processos de informação. No mundo corporativo que é formado de diversas áreas como recursos humanos, vendas, financeiro, manufatura, etc todas precisam ser integradas, automatizadas, e um analista de sistemas de informação seria o profissional trabalhando nisso. E já que mencionei tecnólogo e bacharel vale esclarecer. Eu entendo que ambos são nível superior, e um bacharel é mais generalista do que um tecnólogo, e cursos de tecnólogo são mais curtos e mais focados.

E isso me leva pra outro curso que me parece que começou a aparecer mais nos anos 90 que é Engenharia de Software. Pelo menos pra mim esse sempre foi mais estranho. O maior problema de software, do ponto de vista das metodologias de programação, é que eu nunca consegui enxergar tanto como uma “engenharia” da mesma forma como engenharia civil ou mecânica por exemplo. Acho que de todas as engenharias, a de software é a única que não lida com hardware …

Software em si não obedece leis da física. Quantidade de código não aumenta seu “peso”. Ele não tem cheiro, não tem textura, nada, é totalmente abstrato. Poderíamos escrever software pra uma máquina infinita teórica, com poder de processamento infinito, armazenamento infinito e velocidade de transferência de dados infinitos. Seria como na matemática pura. No mundo real, pra não dizer que não existe nenhuma lei, software é de fato limitado pelos ciclos do processador, pela capacidade de armazenamento e pela velocidade de transferência dos dados entre os diversos componentes.

Mas do ponto de vista do código em si, ele não tem limites. Eu posso literalmente escrever qualquer coisa. Tecnicamente, as linguagens também não tem limites, sendo todas Turing Complete eu posso escrever qualquer software em qualquer linguagem. Eu gosto da definição de engenheiro como sendo aquele que aplica os princípios da ciência e da matemática pra desenvolver soluções economicamente viáveis pra problemas técnicos. É o elo que liga as descobertas científicas às aplicações comerciais.

A parte da ciência que o engenheiro usa vem da ciência da computação cuja função é resolver problemas computacionais ou melhorar a performance das soluções existentes, é realmente mais voltado a uma forma de pensar mais de pesquisa, não necessariamente que a pessoa precise virar um pesquisador. Seja novos algoritmos. Seja novos componentes de computação como novas linguagens ou novos sistemas operacionais ou novos protocolos de rede. Veja os produtos que um Google lança como Protobufs, a virtual machine Dalvik, os algoritmos de pesquisa, bibliotecas de gerenciamento de memória melhores, tudo trabalho de pesquisa de ciências da computação. Daí você tem ferramentas como a linguagem Go, o framework Flutter, um Kubernetes, tudo trabalho de engenharia. E finalmente a aplicação dessas tecnologias pra criar produtos como o Google Analytics, o Gmail, o Google Maps, que poderia sair da mão de analistas de sistema e engenheiros trabalhando juntos.

Porém, os papéis não são tãaaao bem divididos assim. Existem cientistas com cabeça de produto, existem engenheiros com cabeça de pesquisa, existem analistas com cabeça de engenharia. Pode ter gente que saíram de diferentes cursos convergindo pros mesmos papéis. A beleza do mundo de tecnologia é que me parece mais fácil um cientista da computação ir pra engenharia de software do que um arquiteto de verdade virar engenheiro civil. Posso estar falando uma grande bobagem, mas é como a analogia se encaixa na minha cabeça.

De todos os cursos, o mais fácil de escolher talvez seja engenharia da computação, porque você já tem na cabeça que quer lidar com hardware, entrar na indústria de automação, produção, eletrônicos e coisas assim. Talvez a dúvida seja se você quer engenharia elétrica com especialização em computação ou engenharia da computação propriamente dita. Mas eu não estudei engenharia o suficiente pra saber qual o melhor.

Se seu foco for programação, você pode virar um programador mais cientista, ou mais engenheiro, ou mais analista. A grosso, bem grosso modo, é como eu dividiria se quisesse simplificar beeeem simplificado. Generalizando eu diria que a maioria dos autodidatas que já começou trabalhando por conta e aprendendo sob demanda, acaba sendo mais um programador analista, porque falta a fundação formal de ciências e engenharia. Elas podem ser aprendidas sozinho, mas a maioria dos autodidatas jovem sequer sabem da existência dessa fundação.

Como eu sou de ciências da computação, eu sempre vou ter um viés pra ciências. Mas não existe necessariamente uma correlação entre o curso que você escolher e seu sucesso no futuro. O sucesso depende mais do tipo de pessoa que você é, do que o curso em si. Todos os cursos são só bases pra começar. Eu sempre vou defender que você aprenda matérias que historicamente sobreviveram ao teste do tempo. Uma matéria como, digamos, Flash que tenha aparecido na grade de um curso no começo dos anos 2000, hoje é inútil por exemplo. Quanto mais específico em alto nível, mais rápido tende a ficar defasado, mas mais prático no dia 1. Quanto mais específico em baixo nível, mais tende a ter valor ao longo do tempo mas menos prático vai ser no dia 1, como cálculo ou estatística.

Como eu também sou defensor de jogar o jogo do longo prazo, eu defendo que um curso de programação cujas matérias tendem a te acompanhar por mais tempo no futuro seja ciências da computação e depois as engenharias, e um bacharelado antes de um tecnólogo. Mas isso é um compromisso de longo prazo, ou seja, você realmente não tem intenções de mudar de área. Mas eu sei que muita gente não tem essa certeza aos 17 anos. Por isso eu não sou contra cursos como sistemas de informação e tecnólogos. Você sempre pode estudar ciências depois. Vai ser bem mais difícil, especialmente se você estiver trabalhando, mas não é impossível dado que existem centenas de casos de pessoas acima dos 30 ou 40 anos fazendo exatamente isso.

Suas opções ficam mais limitadas, claro, é sempre um trade-off. Não existe uma decisão correta com resultado garantido, você vai ter que jogar. Suas chances sempre vão ser fifty-fifty, cara ou coroa. Alguém decidido a não mudar de caminho, como eu, que decidi por ciência como primeira opção e me segurei nela desde então, é só um cara teimoso. Por sorte eu dei certo. Nem todo mundo precisa ser teimoso, e eu conheço muita gente mais bem sucedida que eu que mudou de caminho várias vezes. Tudo depende de que tipo de pessoa você é.

Um médico tem como prioridade salvar o paciente que está na sua frente na melhor das suas habilidades e usando os recursos que existem hoje. Um pesquisador de laboratório tem como prioridade salvar o máximo de pacientes no futuro, aprimorando ou inventando tratamentos e ferramentas que vão equipar os hospitais e consultórios no futuro. Nenhum dos dois está errado e um precisa do outro pra continuar progredindo.

Um cientista da computação pode ter como prioridade a pesquisa de como aprimorar o gerenciador de memória de uma linguagem pra que ele use menos recursos e performe melhor no mesmo hardware. O correto é ele usar cálculo e estatística nesse processo. O engenheiro de software pode ter como prioridade os diferentes processos e técnicas de como usar as linguagens pra desenvolver aplicações com o melhor custo benefício. Ele pode usar princípios da engenharia de produção. Um analista de sistemas tem como prioridade usar essas linguagens e essas técnicas pra automatizar o problema real de uma empresa hoje, assim como um médico. Porém, diferente de um médico que tem um CRM e não tem autorização pra inventar um novo tratamento e testar em pacientes, um analista pode sim dar uma de engenheiro ou cientista e testar alguma coisa experimental, embora não seja essa sua prioridade.

Alguém com formação em ciências ou engenharia teria mais capacidade de desenvolver o software que equipa o sistema de estacionamento automático de um carro, mas provavelmente não um analista. Por outro lado, alguém com formação em ciência não tenha paciência pra analisar e resolver os problemas de dia a dia de uma empresa como um analista. E um analista talvez não tenha paciência pra ficar inventando soluções como um engenheiro.

Eu posso ficar o dia inteiro fazendo comparações e não vamos ter raspado a ponta do iceberg. É importante você, que é iniciante, entender que independente do que você escolheu e estudou, ao final da faculdade, você ainda não está nem perto de estar pronto. Programação, seja com perfil mais de cientista, ou mais de engenheiro, ou mais de analista, continua sendo uma profissão de prática. Agora são mais longos anos de prática na área.

E aqui começa outro problema pra mim. Júnior, pleno, sênior. O único mais ou menos fácil de definir é estagiário porque a CLT define isso. Existe um TCE ou termo de compromisso de estágio assinado entre a empresa contratante, o estudante que é o estagiário e a instituição de ensino. Se você não sabia disso, pesquise a respeito. De qualquer forma é uma atividade remunerada mas não de carteira assinada, com carga horária menor do que o normal, supervisionada, com tempo máximo de 2 anos.

Eu diria que a nova lei prejudicou a vida dos autodidatas porque não existe mais a oportunidade de estágio fora de vínculo com uma instituição de ensino. Independente se a instituição tem estágio obrigatório ou não, se possível faça, a partir dos 2 últimos anos do curso. A maioria faz no último ano. E eu sei que em cursos de federais de ciências da computação pode ser difícil porque o curso começa difícil e vai ficando mais difícil até o trabalho de conclusão de curso e muitos tem período integral. A intenção dos cursos de bacharelado em ciências da computação me parece ser mais formar pesquisadores e não tanto inserir no mercado de trabalho.

Se você for recém-formado ou mesmo recém-iniciado a trabalhar na área, tendo tido educação formal ou sendo autodidata, você é um júnior. Basicamente quer dizer que você tem pouca ou nenhuma experiência observada na área. De repente você é um gênio prodígio com QI 500 ou sei lá, mas ainda não há resultados observáveis. Não existe um tempo fixo pra você deixar de ser júnior. As primeiras experiências vão te ajudar a decidir melhor que área você prefere seguir. Se você é mais analista, mais engenheiro ou mais cientista e o que vai continuar estudando sozinho na sequência.

O analista e o engenheiro costumam ter mais opções, especialmente no começo. Um cientista puro que é bom em pesquisa mas não tem paciência pra resolver os problemas “mundanos” vai ter mais dificuldade e em 2019 tende a ir pra áreas como data science, machine learning ou algo assim em tech startups, ou a tentar entrar em empresas realmente grandes que tem condições de ter área de pesquisa e desenvolvimento, como os Google ou Microsoft da vida. A maioria das empresas médias e pequenas não tem o porte necessário pra suportar pesquisa ainda.

Eu por exemplo, apesar de ter estudado ciências tenho mais perfil de engenharia e principalmente de analista, eu tenho zero paciência pra escrever papers, fazer experimentos elaborados demais, e apesar do meu foco ser bom por longos períodos, eu logo mudo de foco de novo. Por alguma razão meu interesse acabou se voltando em resolver problemas mais “reais” e menos abstratos, parte disso porque eu fui consultor corporativo por muitos anos.

Mas eu estou me adiantando. No geral, os níveis de experiência em programação, pra mim, funciona assim: o mesmo problema dado pra um júnior, um pleno e um sênior, podem ser resolvidos com qualidade similar. O que vai variar é o tempo. O júnior não tem experiência, até achar a melhor combinação de programação e arquitetura que resolve o problema da forma mais eficiente, vai levar muitas tentativas e muitos erros. O pleno, por já ter tido mais experiência, vai ter uma gama menor de tentativas e erros, e um sênior provavelmente já viu problema semelhante e já vai ter meio caminho andado pra resolver o problema.

Intuitivamente qualquer não-programador poderia assumir que o código de um júnior vai ser pior do que de um pleno, que por sua vez vai ser pior que de um sênior. E também que o melhor código sempre vai ser do sênior. Eu não gosto muito dessa definição, ela só quer dizer que alguém deixou o júnior subir código em produção sem ninguém avaliar antes. E isso é verdade na maioria das empresas. Todo mundo só vê artigo de blog, papers, palestras de médias e grandes empresas, o 1% do mercado. Mas os 99% que não tem tempo nem recursos pra produzir esse material é justamente porque também não tem muito recurso pra supervisionar os funcionários mais inexperientes e por isso a qualidade geral do código tende a ser baixa.

Eu fico repetindo aqui sobre a dificuldade de definir porque é muito mais fácil encontrar definições que vem de empresas grandes, que podem se dar ao luxo de dar todo o suporte possível aos júniors. Mas essa não é a realidade. A realidade são pequenas empresas, com no máximo 5 ou 6 desenvolvedores, ou menos, entuxados de trabalho até o pescoço, vendendo o almoço pra comprar a janta. Esquece a pompa, esquece metodologia, esquece boas práticas. Especialmente quando os donos também são júniors ainda. Então é um navio sem capitão, à mercê da próxima onda.

A grande maioria das microempresas, infelizmente, não vai sobreviver. Dependendo de qual estatística você procurar, 4 em cada 5 devem fechar antes de completar 5 anos. Não é fácil ser empreendedor, especialmente no Brasil, onde você tem um sócio obrigatório, que não trabalha, só atrapalha, e leva 20% do seu faturamento independente se você teve lucro ou não, e ele deixa o prejuízo pros sócios de verdade, que trabalham. Nem vou entrar nesse mérito hoje.

Como se tudo isso já não fosse obstáculo suficiente, muitas grandes consultorias e fábricas de software tem mania de vender júnior como se fosse pleno, pleno como se fosse sênior e sênior como se fosse expert. É uma estratégia arriscada que funciona quando você é do tamanho de uma Accenture da vida. Por outro lado, num mercado como dos Estados Unidos, o que a gente aqui chama de sênior, pra eles ainda é mid-level, o que a gente chama aqui de pleno ainda é júnior e o nosso júnior seria um trainee talvez. A educação formal nos Estados Unidos, é no geral melhor mesmo.

Considerando um programador júnior com formação em faculdades dos Estados Unidos, nativo e cidadão americano, o salário varia na faixa de uns 40 mil dólares ao ano. Pense em algo na faixa de uns 12 mil reais por mes aqui. Considerando impostos, seria o salário de um pleno, talvez indo pra sênior aqui em São Paulo. Agora, na Accenture da Índia, um programador sênior ganharia na faixa de uns 600 mil rúpias, que é a moeda de lá. Uma rupee é 6 centavos no Brasil, então ele faz o equivalente a menos de 3 mil reais de salário, que seria faixa de júnior.

De novo, esses valores são só exemplos, porque salários varia de lugar pra lugar. Mas tem programadores na Índia que ganham tanto quanto um programador nos Estados Unidos, são raros mas tem. Mesma coisa no Brasil. Tudo depende do que você produz. Se você é o raro tipo de pessoa que tem capacidade e experiência pra produzir código de deep learning e redes neurais que ninguém mais consegue, eu nem sei porque você tá aqui vendo meu canal. Mas se você faz o mesmo tipo de código que todo mundo faz, obviamente seu salário sempre vai ser mais baixo. Sempre vai ter alguém na Índia que faz melhor e mais barato que você, se lembre disso.

Por outro lado, Índia é exatamente outro lugar que júnior é vendido como sênior. Deve ter um sênior lá a cada esquina, literalmente. Por isso a reputação é baixa e o valor é proporcionalmente baixo também. No caso geral, valor não é algo que você determina o que você acha que merece. Valor é determinado por o que essa entidade chamada “mercado” determina. Ache isso justo ou não. É sempre uma negociação. Se você não estiver disposto a negociar, no geral, vai ganhar o que vale, e costuma ser menos do que você pensa. Quanto mais cedo você aceitar isso, menos vai gastar de psicólogo.

Eu levantei esse ponto da remuneração porque na prática, o que todo mundo que discute sobre junior, pleno e sênior quer saber é quando vai ganhar mais, ou porque o cara do lado que parece que sabe menos que você ganha mais que você. E de novo eu vou repetir o que eu já disse em vídeos anteriores. Tirando os casos óbvios de abuso na empresa ou pura negligência mesmo, se você for júnior, a menos que você realmente esteja ganhando tão pouco que mal dá pra sobreviver, não é algo que você deveria se preocupar, ou pelo menos não é o que deveria estar no topo da sua lista de prioridades. A prioridade pra um júnior é estar perto de pessoas mais experientes e num lugar com desafios. Onde você tem alguém que critique o que você está fazendo, aponte o que você está fazendo errado.

Eu estou falando tanto de júnior porque infelizmente saltar de júnior pra pleno e de pleno pra sênior não é uma coisa objetiva. Não é que nem num videogame que de repente você tá com novecentos e noventa e nove pontos de XP e com mais um ponto tcharam deu level up. Não tem isso. Durante sua carreira você vai gradativamente subindo de nível de conhecimento, nível de responsabilidade, qualidade, reputação e vários outros pontos. No final do dia, quanto mais seus colegas e seus superiores vão te dando mais e mais confiança, e quanto mais você consegue corresponder entregando com mais e mais qualidade, mais você continua subindo. Quanto mais você cortar passos, tiver entregas irregulares, quebrar confiança, menos você avança. Ninguém dá muito a mínima quando você as coisas certas, mas basta uma coisa errada e todo mundo nota. E é assim mesmo que as coisas funcionam. Se fosse fácil, qualquer um fazia.

E confiança também funciona assim: quebre uma vez e conseguir de volta custa bem caro. Quando você é claramente júnior, tanto de idade quanto de tempo de experiência, erros são mais toleráveis porque as expectativas não são tão altas assim e erros são esperados. É uma fase onde a medição é se você pelo menos é esperto pra aprender com os erros e não errar na mesma coisa toda vez. É meio óbvio, mas vale dizer.

À medida que o tempo passa, você passa por mais desafios, e vai chegando na tal fase mid-level ou pleno, que apesar de não existir um tempo pré-definido, numa carreira normal, costuma ser depois dos 3 anos de casa e vai durar mais alguns anos. Aqui você corre o perigo de cair na armadilha do que chamamos de Dunning-Kruger effect. É um viés cognitivo onde as pessoas têm a incapacidade de auto avaliar as próprias inabilidades, em resumo, elas se acham melhores do que realmente são. E na minha experiência, eu já vi vários júniors de potencial caindo nisso e regredindo, o que é um desperdício.

Eu nunca parei pra pesquisar tanto desse efeito. Esse nome acho que foi cunhado só por volta de 2011 que foi quando todo mundo ficou blogando a respeito. Mas eu mesmo passei por algo assim na fase que eu era júnior também. Felizmente eu tomei vários tapas na cara e voltei pra realidade, mas quando a gente é novo, dinâmico, estuda sem parar e dá aquela impressão que você é melhor que todo mundo ao redor porque todo desafio que cai no seu colo parece que você consegue resolver, é extremamente satisfatório. E a tendência é você sentar em berço explêndido e estagnar, ou pior, regredir. Você precisa fazer um esforço consciente de imaginar que você sabe menos do que realmente sabe sem se tornar um vitimista de Síndrome do Impostor, quando na verdade você é só um impostor mesmo.

E esse é o truque. Na realidade você é as duas coisas: muito bom em poucas coisas, mas muito ruim em várias outras coisas. Só que isso é normal. Você dificilmente vai automaticamente bom em tudo só porque subiu de nível em uma coisa. Quando se é júnior é fácil porque você é júnior em tudo. Mas quando você está indo pra pleno ou mid-level, você é pleno em algumas coisas mas não em tudo. E quando novos desafios aparecem que você ainda não teve oportunidade de enfrentar, você fica confuso porque “como assim você que é pleno e experiente tá tendo dificuldade de júnior de novo?” É uma transição que pode ser meio desconfortável pra alguns. E muita gente começa a naturalmente tender pra lei econômica do menor esforço: entre tarefas que você já sabe fazer muito bem e tarefas desafiadoras que você não sabe fazer ainda, você começa a escolher só as que sabe fazer.

E é uma das razões de porque eu sempre odiei ser elogiado, especialmente por quem não é tecnicamente melhor que eu. É um incentivo muito forte pra te manter na zona de conforto. Por que você vai sair dessa zona e se arriscar a fazer alguma coisa onde você ainda é júnior, correndo o risco de falhar e as pessoas que te elogiavam depois te olharem com aquele olhar de “nossa, eu esperava mais de você”, fazendo você se sentir um impostor? Aí quando você fala que não é tão bom assim, as pessoas ainda vem com o olhar de “nossa, olha o falso modesto”.

Tem gente que naturalmente não liga muito pra isso, eu era o tipo que ligava e às vezes ainda caio na bobagem de ligar, então tive que aprender a desligar isso e ignorar sinais externos desnecessários. A única avaliação que interessa é sua auto-avaliação. Avaliação externa que tem importância é a crítica, porque ela pode indicar um defeito na sua auto-avaliação. Mas elogios não significam nada e ainda confundem sua auto-avaliação, e não dão dica nenhuma da direção certa ou errada.

Como eu disse no vídeo sobre não terceirize suas decisões, este é um caso clássico. Você está terceirizando a avaliação que você mesmo devia fazer pra outra pessoa que não sabe 100% dos detalhes de tudo que você faz. Só você sabe tudo que você faz todo dia, toda hora. Se você considera que faz “muita coisa” mas parece que ninguém dá bola, você devia avaliar se o que você faz tem de fato o valor que você acha que tem. Talvez você faça coisas demais que tem pouco valor. Aliás, você só pode produzir ou não produzir alguma coisa. O valor quem determina é quem paga, você pode pedir mais, mas de novo, é uma negociação. Digamos que você resolveu fazer mil origamis, é um puta esforço e dá um puta trabalho. Pra você deve valer muita coisa. Tente vender, vai valer só uma fração do que você acha, “se” tiver alguém que quer comprar.

Aí o cara preguiçoso que corta caminho pode parar pra pensar, por exemplo, “ah, vou parar de fazer testes, é o tipo de coisa que ninguém vê que existe, eu gasto mais tempo pra fazer, no final é tudo a mesma coisa”. Lembram quando eu falei que 2 + 2 é 4 independente se alguém disser que é 5? Manter a qualidade do seu próprio trabalho é a mesma coisa: independe de sinais externos. Se alguém disser que não precisa fazer, você sabe que tem que fazer. Porque ao longo do tempo, se seu código é o que sempre causa bugs, sempre volta pra consertar; o que vai quebrando com o tempo é sua reputação. Por outro lado, se você faz o que ninguém pediu que é manter a qualidade, e sempre seu código funciona de primeira, nunca volta, e ninguém nunca elogia mas também nunca critica, ao longo do tempo sua reputação de confiável é que aumenta. Qual dos dois você acha que com o tempo tem mais chances de subir de carreira?

Esses são alguns tipos de micro-decisões que você vai exercitar ao longo do período entre júnior e pleno. O sênior pra ser sênior primeiro precisa ser de confiança, tanto do ponto de vista de integridade quanto de qualidade do que faz. Aqui a intuição falha a maioria das pessoas. Muita gente associa gente que fala bem com gente que entrega bem. Nunca ouça a opinião de pessoas sem skin in the game, eu já disse isso antes. Mais do que fazer um bom código, que é meio esperado, um sênior é sênior porque eu deveria poder confiar nas decisões que ele toma. O valor de um sênior começa na sua capacidade de tomar de decisões - que se não ficou claro, também implica que ele assume a responsabilidade da decisão. Decidir sem ter o ônus do fracasso não serve pra nada, não tem skin in the game.

De nada adianta um programador que sabe fazer um código bonito, eficiente, se ele é um péssimo tomador de decisões, ou pior, sequer consegue se decidir e fica em cima do muro, ou posterga, ou empurra com a barriga. Isso eu espero de um júnior. De um sênior se espera que ele tome a decisão certa na hora certa, e ninguém precisa pedir. A gente pede pro júnior. O sênior pede pro júnior. E essa é a outra coisa que um sênior esperto sabe fazer: delegar e orientar.

Eu sei que um cara é sênior quando ele aprende que eficiência em código tem um limite. Às vezes, em situações específicas, um júnior pode até fazer um código melhor e mais rápido que um sênior. Mas o sênior esperto é o cara que consegue pegar dois júniors do seu lado, e com as orientações certas, eleva o resultado desses júniors mais próximo do que se esperaria de um pleno. Ou seja, o sênior de verdade sabe escalar horizontalmente. E quanto ele sabe fazer isso é quando chegamos no famigerado conceito do desenvolvedor 10X.

Tem duas formas de se encontrar um desenvolvedor 10 X, em situações técnicas especiais, onde estamos falando de um sênior especialista, o cara que consegue criar um novo protocolo de rede, um novo garbage collector, um novo classloader, numa situação técnica incomum pra maioria das empresas, e sozinho, com pouco código até, faz de conta, consegue eliminar o uso de 90 máquinas das 100 que você precisava antes. Normalmente você precisa de escala e situações especiais pra ter essa oportunidade, por isso você não vê todo dia.

Mas mais comum é o caso do sênior que escala horizontalmente, e consegue fazer sei lá, 5 júniors performarem como 5 plenos. Eu disse no começo que pra mim um junior, um pleno ou um sênior são capazes de entregar a mesma qualidade de código, a diferença é o tempo que eles vão levar, proporcional à inexperiência. Se o sênior, com 2 tentativas consegue achar a melhor solução, o júnior precisaria testar 20 jeitos diferentes, porque ele nunca fez antes. Mas se o sênior ajuda ele a eliminar as 18 opções que ele já sabe que não funcionam, o júnior consegue focar só nas 2 que que tem mais chances de funcionar, e o resultado vai ser ordens de grandeza melhor.

Muita gente pergunta sobre a especialização. Eu não considero isso algo fácil de escolher, especialmente no começo. Ao longo do tempo, depois que você deixa de ser júnior e passa algum tempo como mid-level, acho que naturalmente você vai indo pra uma direção ou pra outra. Alguns simplesmente não tem capacidade de orientar os outros, mas se tiver a sorte de encontrar um ambiente que precise de especialistas, ele pode dar certo assim também. Mas como eu disse antes, a maioria dos lugares fora do 1% não tem tantos problemas nessa escala pra serem resolvidos, algo que exija alguém desenhar uma nova linguagem por exemplo. Sendo prático, na maioria dos lugares, o ganho maior vem da escalabilidade horizontal.

Não significa virar um gerente, não é delegar 100% do seu trabalho, é orientar, é fazer parte do código e delegar o restante, é ser alguém que consegue mostrar em código uma prova de conceito ou um modelo pra seguir. É o perfil de alguém que naturalmente viraria o que hoje se chama de tech lead ou líder técnico, que tem a visão do que precisa ser feito e com isso vai delegando e encaixando as peças, testando, pesquisando e orientando os demais.

Mas existem outras categorias e alguns anti-patterns aqui. Você precisa ter muito cuidado pra não se tornar um cavaleiro solitário, o cara que trabalha sozinho, que não aguenta ouvir críticas, que não muda de posição e toma decisões erradas e se recusa a aceitar que tomou decisões erradas. Esse tipo rapidamente vai entrar no time do Go Horse. E dependendo do tipo de empresa que entrar, especialmente nas pequenas onde não tem ninguém muito melhor, vai virar o herói e o vilão ao mesmo tempo, consertando os bugs que ele mesmo criou. E vou dizer que existem centenas nessa posição.

Outra categoria tão ruim quanto. Em empresas que crescem muito rápido, particularmente tech startups, é muito fácil um procrastinador se esconder. Como os processos mudam toda hora, a estratégia muda toda hora, é até difícil pra equipe notar que um dos membros está se escondendo ou mesmo sabotando. Alguns podem até notar, mas como as prioridades mudam toda hora, ninguém quer nem discutir. E como é muito comum a atitude clichê do “não vamos procurar culpados”, é um excelente ambiente pros maus profissionais se esconderem e até se tornarem bem sucedidos, especialmente se for o tipo que fala bem. Ele passa rapidamente nos ranks de programação e consegue encontrar uma oportunidade de liderança onde não precisa codar, e como ele mesmo não tem parâmetro técnico pra medir as pessoas, ele vai medir pelos parâmetros errados do tipo, se ele se dá bem com a pessoa ou não. E assim a qualidade técnica de uma empresa que não muito tempo atrás era até boa apesar do caos, rapidamente se torna ruim.

Pra fechar a cagação de regra, por isso eu falo pra esquecer metodologias, processos, métricas e tudo mais no começo. Dado tudo que eu falei, se tem uma recomendação que eu faria primeiro a qualquer empresa, de qualquer tamanho, é que nenhum código deve ser imune à revisão, não importa de quem seja. Todo código deve ser revisado por alguém da equipe, de preferência mais de uma. Todo júnior precisa que alguém aponte o que ele fez de errado, o mais rápido possível. Todo sênior precisa se acostumar a orientar os outros e revisar o código é o primeiro passo. E pra escalar não tem nada melhor que pressão peer to peer, todo mundo olhando todo mundo. Se isso for rotina, fica muito fácil pra equipe inteira notar muito rápido quem está entregando código, em qual qualidade e com que frequência, e não deixar os problemas graves se acumularem a níveis ingerenciáveis.

E daí basta ser consenso que ninguém quer trabalhar do lado de alguém que está fugindo de entregar o que devia e está bloqueando e atrapalhando a equipe inteira, porque ninguém gosta de toda hora ter que ficar consertando o erro dos outros, nem de estar num ambiente com pessoas ruins. Portanto, antes de qualquer tipo de ritual, qualquer tipo de métrica, simplesmente institucionalize a revisão de código geral. A regra é simples: quem fez o código não pode mergear ela na master. Coisas como falta de testes, gambiarras e falta de cuidado em geral começam a aparecer bem mais rápido.

Ahh Eu sei que já ficou bem longo, mas eu preciso conectar com outro parâmetro que eu acho importante. Eu mencionei mercado, eu falei sobre os cursos de faculdade, os níveis de experiência mas não falei sobre o contexto, mas prometo que vai ser rápido. Entenda o seguinte: toda tecnologia tem um ciclo de adoção, e pra variar é outra curva em S. Toda adoção tende a começar devagar, se ela consegue pular o penhasco dos early adopters, ela vai entrar na early majority e começa a acelerar rápido. Aqui já ficou óbvio e você começa a correr pra não ficar pra trás. Uma hora ela atinge um pico de adoção e a partir daí o crescimento acelerado pára e vai indo bem mais devagar e em alguns casos começa a decair.

Neste exato momento tem tecnologias que já estão no fim da curva, e costumam ser as mais populares que você acha que ainda vai durar muito tempo. Mas quando já tem dezenas de cursos, eventos, posts, e todo mundo fala nela é porque ela já passou do early majority e virou mainstream. Pode já estar no fim do Late Majority. Quem sempre vai ganhar mais é quem souber “surfar” como eu vivo dizendo. É quem pega pelo menos no final do early adopter e salta pro early majority já tendo experiência. Enquanto todo mundo tá começando a aprender, você já aprendeu e já sabe usar então você é quem tem mais valor no mercado nesse momento. No pico da curva é quando cada nova pessoa entrando vai valendo menos e menos, e uma hora a curva inverte, e se você cometer o erro de entrar em negação e ficar defendendo tecnologia em curva invertida, vai ser que nem quem defendia Blackberry ou Windows Mobile em 2011. Quem saltou e pegou o early adopter de iPhone em 2009 e aprendeu Objective-C se deu muito bem porque o pico foi entre 2010 e 2014, desde então a curva desacelerou já.

No mundo ideal você sempre gostaria de ser o especialista de alguma coisa antes dela chegar no pico de adoção. No mundo real é difícil de adivinhar quais vão ser as tecnologias da próxima curva. Então eu pessoalmente sempre gostei de ser pelo menos um pleno na tecnologia que entrou em early majority e early adopter em algumas que estão no início da curva. E repetindo isso a cada nova curva. Daí se uma das que eu escolhi aprender, com sorte, entrou no early majority e eu já sei, posso surfar nela de novo. E a que eu era pleno, com sorte, ainda existe e agora eu sou sênior nela. E agora não posso descansar, preciso ver quais vão ser as próximas. São ciclos que duram cerca de 10 anos, então de 5 em 5 preciso ver alguma coisa. Eu aprendi Objective-C em 2010 por exemplo, e nessa época eu era pelo menos um pleno em Ruby, que estava no pico da sua curva.

O grande segredo óbvio é que você nunca vai ser totalmente pleno e nem totalmente senior. Você pode ser sênior de uma coisa, mas junior em outra. E isso vai variando ao longo do tempo. Aposte todas as fichas na coisa errada e você vai ser expert de uma tecnologia morta, que pode não significar muito em pouco tempo. Se isso tá parecendo mercado financeiro, você não tá muito errado.

Se você for conservador demais, vai deixar tudo na poupança e não mexer, achando que tá seguro, sem saber que você cresce menos que a inflação e ao longo do tempo na verdade você está deteriorando e cada vez valendo menos e menos e com cada vez menos chances de recuperaçao. Se você for hypeiro demais e colocar tudo numa ação arriscada ou IPO, já já você pode perder tudo ou muito mais que gostaria. Se quiser balancear você vai ter uma parte em renda fixa, outra parte em ações, e uma pequena parte em opções. Eu penso em carreira mais ou menos da mesma forma. Não é uma escolha fixa, por isso eu mesmo não me considero expert em nada, minha estratégia foi ir diversificando, meio que por acidente, meio chutando, mas aos poucos fui acertando.

Sobre ganhar mais ou menos, você vai ter que aprender a negociar. Pra negociar você tem que ter alguma coisa a oferecer. E repetindo pela última vez: o que você “acha” que você vale não é o preço final, é o preço inicial da negociação. Tudo na vida é negociável, só que se você não tem disposição pra tomar uma decisão, alguém vai decidir por você. Entenderam porque eu disse que não terceirizar decisões é a coisa mais importante? E também como em finanças, existem decisões que vão dar certo e existem decisões que vão dar errado e você vai ter algum prejuízo. Use de aprendizado e não erre na mesma coisa de novo.

Tem muito mais coisas que eu posso falar sobre esses temas mas acho que por hoje já é bastante coisa. Se vocês tem experiências diferentes e outras perspectivas, não deixem de mandar nos comentários abaixo. Se curtiram o vídeo mandem um joinha, não deixem de assinar o canal e clicar no sininho pra não perder os próximos episódios. A gente se vê, até mais.

Descrição no YouTube

Neste terceiro episódio da série “Começando aos 40” vou finalmente começar a tocar em assuntos mais práticos, pra começar o que eu considero que é o absolutamente básico que você precisa começar a dominar o quanto antes.

Neste e nos próximos 2 episódios, pelo menos, vou dar uma visão mais estruturada do que considero que a carreira de “desenvolvedor Web” envolve para que você tenha uma idéia ‘macro’ do que deve planejar para estudar e treinar.

Agora é a hora de arregaçar as mangas e treinar!

Links:

• Developer Roadmap (https://github.com/kamranahmedse/developer-roadmap)
• git-remote-dropbox (https://github.com/anishathalye/git-remote-dropbox)
• Building a Continuous Delivery Pipeline with Git & Jenkins (https://stackify.com/continuous-delivery-git-jenkins/)
• A beginner’s guide to continuous integration (https://about.gitlab.com/2018/01/22/a-beginners-guide-to-continuous-integration/)
• TodoMVC (http://todomvc.com/)
• Arch Linux (https://www.archlinux.org/)

AkitaOnRails Blog:

• Jogar Pedra em Gato Morto: por que Subversion não presta (https://www.akitaonrails.com/2007/09/22/jogar-pedra-em-gato-morto-por-que-subversion-no-presta)
• GIT: Muito Promissor (https://www.akitaonrails.com/2007/09/22/git-muito-promissor)
• Micro Tutorial de Git (https://www.akitaonrails.com/2008/04/02/micro-tutorial-de-git)
• Dicas de Git (https://www.akitaonrails.com/2009/07/05/dicas-de-git)
• [Screencast] Começando com Git (https://www.akitaonrails.com/2010/08/17/screencast-comecando-com-git)
• Chatting with Chris Wanstrath (Err the Blog/Github) (http://www.akitaonrails.com/2008/04/21/conversando-com-chris-wanstrath-err-the-blog-github)
• Arch Linux - Best distro ever? (http://www.akitaonrails.com/2017/01/10/arch-linux-a-melhor-distro-de-todas)
• Optimizing Linux for Slow Computers (https://www.akitaonrails.com/2017/01/17/otimizando-o-linux-para-computadores-lentos)
• From the Macbook Pro to the Dell XPS. Arch Linux for Creative Pro Users (http://www.akitaonrails.com/2017/01/31/do-macbook-pro-para-o-dell-xps-arch-linux-para-usuarios-criativos)
• Running Arch Linux over Windows 10! (http://www.akitaonrails.com/2018/04/29/rodando-arch-linux-sobre-o-windows-10)

Script

Olá pessoal, Fabio Akita

Neste terceiro episódio da série “Começando aos 40” vamos finalmente começar a falar sobre o currículo básico pra quem quer se tornar um desenvolvedor Web. Veja que não existe somente Web, você pode escolher desenvolvimento mobile para fazer apps para smartphones ou mesmo algo mais tradicional como aplicativos nativos Desktop

Todo mundo que tá iniciando tem que começar do zero, um pouco de HTML, um pouco de CSS, um pouco de Javascript. Quem está fazendo algum curso de tecnólogo começa com um pouco de Java, talvez um pouco de C# ou PHP.

Mas praticamente todos esses cursos falham em mostrar TUDO que você realmente vai precisar pra montar uma carreira. Claro, como eu já disse antes, sabendo um pouco do básico, você já começa a ser capaz de começar a trabalhar. E a importância de trabalhar numa empresa com uma equipe é porque justamente você ainda não vai ser capaz de fazer um projeto do começo ao fim sozinho, simplesmente porque em 1 ou 2 anos é impossível saber tudo que se precisa.

E o que exatamente é esse TUDO que se precisa? Eu disse que essa série vai ser bem longa. No episódio de HOJE vamos começar com os conhecimentos mais básicos que você vai precisar. Vamos lá.

(…)

Um ou dois anos atrás eu esbarrei num repositório no GitHub chamado Developer Roadmap, ele tem sido atualizado uma vez por ano e a versão 2019 está lá. O autor por acaso é de uma empresa de cursos chamada Hackr.io que eu nunca parei pra ver então não sei dizer se os cursos são bons ou não. Esse roadmap é um mindmap, que é uma representação gráfica de idéias em conceitos, na prática é um monte de caixinhas ligadas num gráfico. O que eu achei interessante é que ele lista caixinhas obrigatórias pra cada carreira e caixinhas opcionais mas desejáveis e, no geral, eu concordo com as divisões e prioridades que ele colocou, então é uma boa referência pra vocês.

E note que eu disse que ele atualiza todo ano. Nos últimos 2 anos não mudou tanto, mas se ele tivesse começado 5 ou 10 anos atrás, vocês iriam ver que a carreira mudou bastante nesse período. Lembra no episódio anterior que eu falo sobre o tempo? Pois é, considere que esse roadmap pode mudar muito ainda daqui 2 anos ou mais. Se você for aprender TUDO que está nesse roadmap, se estudar e treinar com afinco, vai precisar de uns 3 a 5 anos, no mínimo. E eu diria que esse roadmap é básico, tem muito mais além disso ainda. Mas não se assuste, você não precisa saber tudo de uma vez só, mas tenha na cabeça que nossa carreira vai exigir que você esteja estudando constantemente. Não existe fazer um curso de 6 meses e achar que já sai tudo.

Este roadmap se divide em QUATRO partes. Primeiro, e o tema deste episódio, são conhecimentos gerais que todo mundo precisa saber. Daí ele separa em carreira de desenvolvedor Front-end que se preocupa mais com a parte visual que as pessoas normalmente vêem, o HTML e CSS final, Javascript e tudo que envolve usabilidade. Então você tem Back-end que é a carreira mais complexa em termos de coisas pra aprender e se preocupa com o software que roda por trás, as regras de negócio, as integrações, os bancos de dados. Finalmente uma carreira nova que chamamos erroneamente de Devops, vou explicar porque em outro episódio. E como eu disse antes, essas não são as únicas carreiras, só as primeiras TRES dentro do mundo de Web.

A idéia é você usar esse Roadmap como um checklist. Cada caixinha amarela é um corpo de conhecimentos grande. Você vai encontrar cursos inteiros pra cada caixinha. Mas lembre-se do que eu já falei no meu episódio sobre Faculdade: você não deve tentar aprender 100% de cada assunto de uma só vez. Aprenda no máximo 20%. Os primeiros 20% que vai te permitir resolver 80% dos problemas. Vou dar um exemplo. Na primeira parte, de conhecimentos gerais, a primeira caixinha é GIT.

GIT é um versionador de arquivos. Essa ferramenta foi desenvolvida inicialmente pelo criador do kernel do Linux, o famoso Linus Torvalds e o atual mantenedor é Junio Hamano. Pense assim: como centenas de desenvolvedores podem editar os mesmos códigos num projeto como o Linux e não virar uma bagunça colossal? É por causa de ferramentas como o GIT.

Nos anos 90 e começo dos 2000 haviam várias, como CVS que era uma grande porcaria mas era o que tinha, substituído pelo Subversion ou SVN que era menos porcaria e eu usei muito e inclusive fiz um patch pra ferramenta TortoiseSVN pra ele funcionar em Windows em projetos com Visual Studio que não suportava diretórios que começa com ponto. Haviam ferramentas comerciais bem porcaria como Rational Clearcase ou a droga do Microsoft SourceSafe. Eram todos versionadores centralizados, e daí nos anos 2000 começamos a ir para versionadores distribuídos como BitKeeper, Perforce, Darcs, Bazaar que era usado pela Canonical, Mercurial.

Eu comecei a evangelizar Git no Brasil por volta de 2007 como você pode ver em meus blog posts mais antigos linkados na descrição abaixo. E nós da comunidade Ruby on Rails ajudamos muito o GitHub - que é feito em Ruby on Rails - a crescer rapidamente. Por causa disso GIT se tornou o padrão embora em ambientes comerciais alguns ainda fiquem presos a ferramentas como o Microsoft Team Services. Mas esquece, 99% do mundo de desenvolvimento usa GIT pelo simples fato que a maior parte dos melhores software open source do mundo estarem lá no GITHUB.

O GIT em si possui centenas de comandos e permutações. Você usa GIT pra baixar código dos repositórios preservando um histórico de “commits” que são trechos de alteração de código. Você pode navegar pra trás no tempo num sistema desses e recuperar o estado do código como ele era ontem ou semana passada ou ano passado. E cada modificação que você faz você empacota nesses “commits” e empurra (ou dá push) pra um repositório elegido como central que todos usam, embora GIT em si não precise de um servidor central. O fluxo de trabalho com GIT que a maioria dos desenvolvedores Web usam é derivado do que nós da comunidade Rails desenvolvemos junto com o GitHub, o mecanismo que chamamos de Pull Requests e Forks. A comunidade do Kernel do Linux usa um fluxo de trabalho diferente por exemplo.

Agora, os tais 20% que eu falei antes? Você precisa saber talvez uma dúzia só de comandos como “git init” pra iniciar um repositório, “git add” pra acumular as modificações que fez agora, “git commit” pra empacotar essas modificações, “git push” pra enviar as modificações pra outro repositório de origem, “git pull” pra puxar as últimas modificações desse repositório. Se você dominar esses comandos já consegue participar de um projeto. Só que isso é o ultra básico, porque existem vários coisas importantes que você vai precisar aprender como o que são branches e como trocar de branches, como fazer cherrypicking, como reescrever commits, as diferenças entre rebasing e merge, o que é stage, pra que serve squash de commits, pra que serve bisect, pra que serve reflog, diferenças entre reset e clean, e assim por diante.

Mas você pode ir aprendendo um comando de cada vez. O Git é praticamente um sistema de arquivos avançado, sua estrutura de dados é baseado num DAG que é um Direct Acyclic Graph e se você entender como ele funciona internamente você pode usar o GIT pra fazer coisas avançadas. Por exemplo, você poderia criar um produto que é um mini-clone do Dropbox usando GIT. Você pode integrar o GIT com sistemas de deployment, ou seja, que toda vez que você dá push no repositório ele toma uma ação como atualizar o servidor ou rodar os testes do repositório num sistema de Continuous Integration. As opções são infinitas.

Mas atenha-se em aprender os primeiros 20%, a primeira uma dúzia de comandos. Não se preocupe, se você for curioso, você vai aprender tudo do GIT eventualmente. Mas se tentar aprender TUDO de uma só vez, você vai ficar meses estudando a teoria e não vai entender tudo. Gaste uma semana em tutoriais iniciais do GIT. O próprio GitHub tem o site Github Guides que vai te dar o básico. E obviamente treine em dezenas de arquivos na sua própria máquina. Erre dezenas de vezes pra ver o comportamento de cada comando, teste os limites de cada comando. Mas de onde vamos arranjar esses arquivos e projetos pra você treinar?

O Roadmap está correto em colocar GIT em primeiro lugar porque uma das coisas que você logo no começo PRECISA fazer é fuçar MUITO o GitHub. Agora, entenda uma GRANDE verdade de qualquer curso ou tutorial: TODOS os passos que eles mostram SEMPRE funcionam, porque a demonstração foi preparada pra funcionar. Começa com algum exercício do tipo, “vamos fazer um aplicativo de lista de tarefas” daí ele vai te dando passo a passo tudo na ordem certa pra no final você ter um pequeno aplicativo. Mas os passos só funcionam dentro de um ambiente muito controlado, quase de laboratório, se divergir um pouquinho vai dar errado e você não vai saber o que tem que fazer.

Pra quem só está iniciando, claro que é importante ver as coisas sendo construídas de forma ordenada. Só entenda que isso é irreal. Todo tutorial e curso não tem absolutamente nada a ver com a vida real. Na vida real você quase sempre vai participar de um projeto que já existe, ou começar com outras pessoas, e vai baixar código que já existe e ter que participar do código dos outros. E esse código não vai estar perfeito, aliás, normalmente vai estar MUITO longe de perfeito, as coisas vão quebrar, as instruções não vão funcionar, e você vai ficar em dúvida se é o código do projeto que tá quebrado ou você que não tá entendendo alguma coisa trivial.

Muito do processo de programação é tentativa e erro. Um dos grandes defeitos de cursos e tutoriais é que eles mostram só o passo a passo perfeito. Tutoriais não ensinam a lidar com erros e isso é um enorme problema. Eu mesmo cansei de receber mensagens de pessoas que falam “Akita, tava seguindo esse tutorial e deu um erro, você sabe como resolve?” Daí eu falo “me manda a mensagem de erro que tá aparecendo aí”. Daí eu pego essa mensagem, jogo no Google, e mando o primeiro link que aparece e pergunto “e aí, era isso?”, aí a pessoa responde “puuuuuta Akita você é foda mesmo, resolveu!” …. Aí eu fico … “filho da mãe, eu virei proxy do Google”!!

Sério, se você é iniciante, assuma que 99% de todos os erros que você encontrar, você certamente não é o primeiro. Muita gente já passou pelo mesmo erro que você tá passando e eles já foram documentados nas Issues do GitHub, ou em sites como Stackoverflow, Stackexchange, fóruns como Reddit. Antigamente, nos anos 80 e começo dos 90, a gente simplesmente não tinha onde procurar online, porque nem tinha internet!! Então quando tinha um erro, a gente precisava aprender a descobrir tudo sozinho. Por isso o povo dependia de empresas como Microsoft, BEA, IBM ou outros que costumavam ter uma comunidade interna somente pra quem pagava a assinatura e você tinha acesso a bancos de conhecimento que vinham em CDs como o MSDN. Mas hoje em dia, o Google vai te responder 90% das coisas que você vai precisar.

Isso tudo dito, em vez de ficar só fazendo passo a passo de vários tutoriais, vá no GitHub e procure alguma coisa como “clone instagram javascript”, vai aparecer vários. Alguns muito parecidos, alguns uma porcaria. Não importa. E agora que você já aprendeu o básico de Git, clone o projeto na sua máquina e tente rodar. Você vai sofrer um bocado da primeira vez e vai cair na segunda caixinha amarela do Roadmap que diz “Basic Terminal Usage”.

Essa caixinha junto com outras como “SSH” vai te dar MUITO trabalho. Entenda outra verdade: quando você for subir seu primeiro projeto de verdade para o público, ele não vai estar na sua máquina, vai estar num servidor. Seja você um programador front-end ou back-end você PRECISA o quanto antes aprender mais sobre sistemas operacionais.

A maioria de vocês provavelmente está usando Windows. E não tem nenhum problema. Eu uso Windows também. Porém você obrigatoriamente deve aprender sobre distribuições baseadas em Linux. Você pode fazer isso do jeito difícil ou do jeito ultra difícil. O jeito difícil, se sua máquina aguentar é baixar e usar o programa Virtualbox ou versões pagas como VMWare ou Parallels.

Hoje em dia se tornou muito comum rodar Linux em máquinas virtuais. Todo novo CPU suporta o que chamamos de instruções VT-X no caso da Intel ou AMD-V no caso da AMD que são funções da CPU para fornecer o máximo de performance de acesso ao hardware quanto possível em ambientes virtualizados. Significa que você consegue rodar uma distribuição de Linux como Ubuntu, Fedora ou Arch inteira dentro de um Virtualbox.

A maioria das pessoas nunca instala seu próprio sistema operacional, nem configura nada. Simplesmente compra a máquina e usa do jeito que veio. Isso é horrível. Um programador escreve software. Software é código que diz à máquina o que fazer. A máquina é controlada por um sistema operacional. Se você não conhece o sistema operacional, sua programação sempre vai ter muito achismo e chutes. Você acaba se tornando supersticioso e em vez de resolver os problemas procura alguma mandinga.

É impossível aprender tudo só em poucos dias ou semanas, por isso o melhor caminho pra começar é de cara tirar a rodinha da bicicleta e começar a apanhar. Não comece com uma distribuição fácil como Mint ou Ubuntu. Comece instalando um sistema operacional manualmente do zero e pra isso não há nada melhor do que uma distribuição Linux como o Arch Linux, que me lembra um pouco minha época de Slackware 1.0 no meio dos anos 90.

Se você ainda não sabe disso, Linux é o nome do kernel, o binário responsável por iniciar a máquina, configurar os dispositivos e oferecer serviços pros aplicativos podem falar com a máquina. Existem dezenas de distribuições que usam o kernel Linux. O que varia em cada uma é a seleção de aplicativos, formas de configuração, gerenciamento de pacotes e ecossistema. Na dúvida você vai acabar escolhendo algo como Ubuntu, Mint, Elementary, Fedora, CentOS, openSUSE, Manjaro, dentre outros.

Um Ubuntu ou mesmo Fedora são muito simples, eles já fazem tudo pra você e no final é como se tivesse instalado um Windows ou MacOS, você vai só apertando “próximo”, “próximo” e no final não aprendeu nada porque os instaladores estão bons o suficiente pra fazer quase tudo sozinhos. Mas o Arch Linux não, ele vai exigir que você realmente preste atenção, estude e vá configurando cada componente sozinho. A cada passo você não vai saber o que precisa fazer e pra ajudar existe o site ArchWiki que tem páginas inteiras detalhando cada pequeno componente do sistema em detalhes.

O Arch vai te forçar a ficar na linha de comando e digitar comandos que, mesmo que você não entenda exatamente o que está fazendo, vai te dar a primeira sensação de que você está colocando as mãos de verdade no computador. Vai ver dezenas de mensagens de erro e vai perder horas em tentativa e erro a cada passo, e quando chegar ao final vai ter aquela satisfação de que você fez alguma coisa funcionar sozinho.

Quando eu falo que as pessoas ficam supersticiosas imagina quando alguma coisa não funciona, e o que é a primeira coisa que todo mundo pensa? Ahh reboota a máquina que volta a funcionar. Nãaaao porque você vai rebootar? Primeiro tenta entender se precisa rebootar. Normalmente é quando você muda alguma configuração que algum serviço precisa, um daemon por exemplo.

Falando em daemons você vai precisar entender que você sempre tem pelo menos 2 níveis de permissão no sistema, o acesso geral de administrador ou root e o mais limitado, do seu usuário. Um Spotify roda sob os privilégios do seu usuário e não tem privilégios pra afetar coisas importantes do núcleo do sistema, como rebootar a máquina. Mas existem serviços ou daemons - e nao DA-E-MONS daemons, que aliás, não tem nada a ver com diabo mas com antigos demônios que performam tarefas em background -, que o sistema operacional começa a iniciar depois do boot e rodam sob privilégios maiores pra poder controlar coisas como sua rede, seu sistema de arquivos geral, tudo em background sem você perceber.

Um programa que você manualmente abriu como seu editor de textos você pode matar a qualquer momento. Mas daemons, precisam de privilégios pra reiniciar, e aí você começa a aprender sobre ferramentas como o “sudo” que você vai ver em vários tutoriais, que permitem que seu usuário temporariamente tenha privilégios de administrador. No Windows isso é aquela janela de confirmação que escurece sua tela toda pedindo uma confirmação e que obviamente você nunca lê e só dá ok.

Mais do que isso, pra rodar linguagens como Javascript, Ruby, Python, PHP, Java, você precisa saber quais versões instalar porque códigos antigos podem precisar de versões mais antigas de cada linguagem. Se tentar rodar na mais nova provavelmente vai falhar. Se você tem o Python mais novo instalado na sua máquina como a versão 3, mas você entra numa empresa que precisa dar manutenção num projeto mais antigo que ainda não foi atualizado, usando digamos Python 2.6, como você faz pra ter múltiplas versões rodando na máquina ao mesmo tempo? Você vai ter que aprender que quando digita o comando “python” na linha de comando ele vai olhar uma coisa chamada PATH, uma variável de ambiente, que diz em quais diretórios procurar pelo executável. Se quiser ter múltiplas versões, basta instalar algum gerenciador dessas variáveis VIRTUALENV ou o mais poderoso ASDF que vai gerenciar o PATH e outras variáveis do ambiente pra você. Mas pra isso você precisa ter essa noção que cada linguagem é um conjunto de executáveis, coisas como interpretador, compilador, debugger, bibliotecas. Onde eles ficam na sua máquina? Como você, como programador, não sabe onde fica cada componente da linguagem que está usando? Você PRECISA saber, então corre atrás disso.

Portanto, as duas coisas mais importantes que você PRECISA aprender e treinar logo de cara é como gerenciar código usando ferramentas como GIT e serviços como GitHub e onde fica cada ferramenta que você vai usar no sistema operacional. Você precisa aprender a ter controle sobre sua própria máquina, porque a principal função de um programador é controlar as máquinas para que façam exatamente o que você quer, e a forma de dar essas ordems é através de programas gerados com o código que você escreve. Se você não consegue controlar seu sistema operacional e sequer sabe onde estão suas ferramentas e porque elas funcionam, é a máquina que vai controlar você e não o contrário. Sem isso você sempre vai fazer algum código, muitas vezes vai chutar e se realmente funciona você continua sem saber porque, e desse jeito nunca vai evoluir como programador. Coloque isso na sua cabeça, a máquina serve a você e não o contrário. Domine suas ferramentas e faça com que elas sirvam a você.

E como podem ver, hoje falamos somente das duas primeiras caixinhas. Durante a série algumas serão mais curtas, algumas serão mais longas, mas o assunto claramente é longo. Aproveitem pra dar uma olhada no Developer Roadmap e já joguem dúvidas nos comentários abaixo, talvez eu possa aproveitar algumas nos próximos episódios. Se curtiram o vídeo deixem um joinha, compartilhem com seus amigos, assinem o canal e cliquem no sininho. A gente se vê semana que vem, até mais!

Descrição no YouTube

Errata a 25:16 a legenda está “colégio” mas é “faculdade” :-)

Novamente um episódio que ficou um pouco longo então será o único desta semana.

Desta vez quero explorar como eu aprendi inglês e aproveitar pra explicar porque é tão importante inglês na nossa área e também porque NÃO é tão complicado como muita gente pensa. Trabalhoso, sim. Caro ou complicado, não.

Uma tangente neste assunto será tocar no que muita gente pensa sobre “padrões” e o erro nesse pensamento. Fiquem ligados!

Links:

• Off Topic: Somos Matematicamente Ignorantes (http://www.akitaonrails.com/2008/03/01/off-topic-somos-matematicamente-ignorantes)
• [Off-Topic] A Revolta de Atlas: Dinheiro é a raíz de todo o mal? (http://www.akitaonrails.com/2011/02/03/off-topic-a-revolta-de-atlas-dinheiro-e-a-raiz-de-todo-o-mal)
• Descartes’ Error: Emotion, Reason, and the Human Brain (https://www.amazon.com.br/Descartes-Error-Emotion-Reason-Human/dp/014303622X)

Script

Olá pessoal, Fabio Akita

Já que eu tenho falado sobre estudo acho que vale a pena entrar no tema do temeroso Inglês. Todo programador sabe que deveria já saber inglês mas fica empurrando, empurrando, até o dia que começa a perder oportunidades, e aí percebe como já é tarde demais.

Vamos dizer o óbvio: pare com as justificativas, qualquer razão que você está usando pra não evoluir no inglês não é nada mais, nada menos, que puro … bullshit, a fucking big pile of turd.

Ah, isso é imperialismo, temos que ser patriotas, valorizar a língua nacional, bla bla bla mi mi mi fuck you se você diz imbecilidades como essa.

Tamos entendidos? Então vamos avançar

(…)

TUDO que sai de mais importante na área de tecnologia sai primeiro em INGLES. Sabe o que acontece se você depende de material em português? Você precisa esperar essa tecnologia ganhar público, alguém se arriscar a traduzir material em português e publicar aqui. E todo mundo sabe que todo projeto open source, principalmente nas primeira iterações, muda o TEMPO TODO.

Ou seja, do ponto de vista de retorno financeiro, Não é um bom negócio publicar livros de versões 1.0 de projetos open source porque o 2.0 vai sair em 6 meses e o livro vai ter pouco tempo de vida. Livro técnico é absolutamente chato de escrever - eu sei, eu já escrevi um. Especialmente porque se você demora muito, tem que ficar revisando todos os capítulos anteriores quando sai um update. E depois que publica ainda tem que ficar correndo atrás se sai outros updates que quebram os exemplos que você colocou no livro, ou seja, é um puta trampo de manter o livro atualizado ao mesmo tempo que o software ainda está inacabado e evoluindo.

Mundo open source é assim mesmo. E se por acaso um novo projeto consegue ganhar o seu público de early adopters e começa a ter demanda, sabe quem ganha mais dinheiro? Quem aprendeu sobre o software antes mesmo de ter saído a versão 1.0. Depois que saiu a versão 4, 5 etc que já tem livro, já tem curso, já tem toneladas de screencast, é quando o taxa/hora vale menos, 2x, 5x, 10x menor do que era pago pra quem se arriscou e aprendeu na versão 0.1 alfa.

Vocês já entenderam uma coisa meio óbvia? As pessoas ficam procurando “o que a maioria das pessoas está fazendo”. Eu penso assim: puts, se a maioria das pessoas tá fazendo uma coisa, é porque essa coisa vale muito pouco e nunca vão me pagar muito, justamente porque tem um milhão de indianos que vão cobrar 10x menos que eu pra fazer a mesma coisa.

Claro, o mais seguro é primeiro ir atrás de alguma coisa bem óbvia. Por isso eu falei no episódio de “O que devo estudar” pra ir num Java, C# ou PHP da vida. Mas qual o próximo passo? Ora, quem ganha mais na indústria? As moscas brancas. Os cisnes negros. Mas é muito raro você escolher, conscientemente, a tecnologia que ainda vai se popularizar, e acertar em cheio. Precisa de muita experiência pra isso, e mesmo assim você pode estar errado.

Se eu fosse resumir, você precisa saber duas coisas importantes: história e línguas. Mas não do jeito que você pensa. Todo mundo fica atrás só dos headlines, da notícia de hoje. Eu estou mais interessado em juntar as peças das notícias de ontem, de 1 ano atrás e de 1 década atrás. Eu fico constantemente comparando essas coisas. Não tem uma receita, mas quanto mais você estuda a história da sua área, mais você vai entendendo pra onde as coisas tem mais probabilidade de ir. Isso se chama reconhecimento de patterns, vou voltar nisso no fim do vídeo.

Agora, finalmente, línguas, que é o tema de hoje. Existem dezenas de formas de fazer isso e de novo, não vou dizer o óbvio. O óbvio está em todos os canais de YouTube de línguas e uma rápida procurada no Google vai te trazer uma tonelada de cursos online. Baixa lá o Duolingo e Just fucking do it!

Mas o que eu quero fazer é explicar como Eu encaro o aprendizado de qualquer coisa usando meu aprendizado de inglês como exemplo.

Sabe que tipo de pessoa aprende coisas mais rápido? Uma criança. Todo mundo já ouviu falar que toda criança é uma esponja, que aprende tudo que você ensina pra elas? Eu sempre ouvi falar isso e como toda cagação de regra que eu ouço eu parei pra pesquisar e refletir sobre isso.

Eu me considero uma criança em muitos aspectos, até hoje. Uma delas é que eu não tenho muito apego a nada. Portanto eu tenho muito pouco a perder. E isso é uma criança: ela não nada pra perder, ou melhor, ela nunca parou pra considerar que tem coisas pra perder, e por isso não tem medo de arriscar nada. Tudo pra ela é uma oportunidade, lembra que eu venho repetindo muito isso nos episódios anteriores?

No caso de línguas, todo adulto começa pensando que tem muito a perder. O adulto começa a pensar no que os outros vão pensar, como os outros vão julgar. Será que vão dizer que estou demorando muito pra aprender e acharem que sou devagar? Será que vão dizer que eu não consigo falar e achar que sou incapaz? Será que vão ficar tirando sarro de mim e vou virar a piada do grupo? Daí você pára e pensa, se vou aprender tem que ser sério! Se é pra ser sério, precisa ser num curso top. Só que curso top é caro e eu não tenho dinheiro agora, e se for pra pagar caro precisa reservar muito tempo senão não compensa. Hm, como não tenho nem dinheiro e nem tempo, vamos deixar pro próximo semestre que aí vai dar tempo de guardar dinheiro e organizar minha vida pra ter tempo …. Daí passa seis meses e o que acontece? Nada.

Agora tente se lembrar de você quando criança ou qualquer criança que você conheça, seu sobrinho, seu filho, seu neto? Aos 2 anos de idade, quantos cursos top de português ela fez? Quantas horas em salas de aula com professores especializados ela fez? Quantas certificações em cursos especiais ela tirou?

Não é possível que você nunca tenha pensado que em 2 anos, uma criança sai do zero pra razoavelmente fluente numa língua, o suficiente pra você entender sentenças inteiras e em mais 2 anos ela tá quase tão fluente quanto você (ou melhor, se bobear). Obviamente, não adianta falar com ela de coisas técnicas específicas, falar em bolsa de valores, física, engenharia, tudo vocabulários que ela não vai saber. Mas largue essa criança num shopping center e certamente ela vai conseguir se comunicar com tudo mundo. E se ela não entender alguma coisa? Ela vai perguntar e perguntar e perguntar, até ficar satisfeita com a resposta, que é exatamente o que VOCÊ não faz.

Não subestime esse processo. Todo mundo quer esse processo na verdade, por isso você vai fazer intercambio. Todo mundo tem essa intuição de que se você fizer uma imersão num país estrangeiro, você vai magicamente, aprender mais rápido. Qualquer metodologia que te incentive a se concentrar acima do normal num período limitado de tempo funciona da mesma forma, indo pro exterior ou não. Ir pro exterior pra mim é mais status do que necessidade. Mas claro, se puder, com certeza vá, a experiência maior é a vivência mais do que o estudo. Trabalhe num bar, pague seu curso e passe 1 ano morando fora. Você provavelmente não ia precisar ver meus vídeos se tivesse feito isso :-)

Claro, você precisa ter um mínimo de estrutura. Nem que seja as porcarias de aulas de inglês que tivemos na nossa escola, que ensinou só o basicão do verbo To Be e meia dúzia de palavras. Mas isso deve ser o suficiente.

Eu mencionei num dos vídeos que quando eu comecei a fazer faculdade, meu inglês não era fluente. Eu lia devagar e não tinha nenhuma fluência pra falar, nem pra arriscar frases. O que me motivou foi no primeiro de aula o professor listar livros estrangeiros na bibliografia e eu ter colegas de classe que já tinham morado fora ou feito intercambio e estavam na minha frente. Eu já disse também que é o tipo de coisa que me deixa motivado a correr atrás.

E foi exatamente o que eu fiz. E aprendizado é que nem dieta, ou você faz all-in, sem compromisso, ou não faz. Do, or do not, there is no fucking try.

Vamos lá, assim como 99% da população, eu só comprava livros e revistas em português, eu só assistia filme dublado ou com legenda, eu ouvia música mas sequer prestava atenção nas letras e eu evitava tudo que tinha inglês. Eu fiz aqueles cursos de bairo, no caso Fisk, mas eu desisti porque não via evolução. Era essa minha situação no ano em que entrei na faculdade. Eu nunca fiquei 100% perfeito na fluência, mas ouçam vocês mesmos:

Ok, so I spent the next 10 years under lockdown. In my mind, I have decided that just enrolling in an ordinary English course would be too damn slow. I am not advocating that classes are not good, it’s just not right for someone like me, I am a stubborn son of a bitch that wants to dictate my own pace, which is usually faster than average.

Moreover, I wanted to speak as close to a native American as I possibly could without having to live there. What if I consumed the exact same things every day as if I was living in a USA city somewhere?

If I moved there, there wouldn’t be any Portuguese resources anywhere. So I’d be forced to browse in the web in English, go to Barnes & Noble and buy English-only books and magazines. I’d like to go to the Chinese Theater in LA to watch the blockbuster premieres, all in English.

So, it was only a matter of emulating the exact same environment in my own routine. I never bought or read a single book or magazine in Portuguese ever again. I spent a good portion of my small salary by importing computer books. I was paying 5x more buying magazines such as Wired, or PC Magazine. I rented movies at Blockbuster, and I had to put a box in front of the TV set to hide the Portugues subtitles. And fortunately, I am the kind of nerd that watches the favorite movies many times over.

Did you read my blogs and facebook or twitter timelines? To this day, more than 20 years later, I keep writing in English as much as I can. This procedure became my routine. To this day, I avoid consuming Brazilian sources, it’s just a habit. I don’t read Brazilians books, I don’t watch Brazilians tv-shows. It’s considered normal nowadays to not watch the open TV because of Netflix, but I have been doing that since the mid-’90s. Let’s say I was ahead of this curve by at least a decade. YouTube, Netflix, Amazon Kindle, just made my life easier.

When I was in college, I did all my programming in English. It always felt wrong to mix Portuguese variable names with English-based statement syntax. It’s just wrong. Don’t do it. If for nothing else, only realize that if you use Portuguese, you won’t ever be able to open source it. I am not saying that you should open source everything, but why are you closing that door so soon? And you can’t ever hire programmers from other countries to help out either. Writing code in Portuguese limits the reach of that code.

I spent around 5 or 6 years consistently doing precisely that. From my first year in college to the dotcom era. Remember that PSN dotcom I mentioned I worked for? So they wanted me to fly to their Florida office to get acquainted with the other developers. This was 2001, and it was the very first time I set foot in the USA.

Remember when I mentioned that you want to be ready when the opportunity arises? That’s precisely my point. If I had procrastinated, I would have missed that chance.

And let me tell you: no amount of theory will save you in practice. I realized my limitations when I arrived there. Jesus Christ, the freaking Cubans, and their Spanish-mixed English are stupidly hard to understand. And I had people from Texas in the office, also a crazy difficult accent to follow. I think I can deal with them way better today, but for my very first attempt, I had to ask people to repeat slowly many times. And don’t think for a second that I didn’t.

Over the years, I met people that have been teaching me. And this is super important. You feel ashamed when someone tries to correct your misspellings. And you lose an opportunity. Whenever someone corrects me, I engage. I say “hey thanks, so, is this the correct way, let me try again,” and if the person is willing, we end up spending a few minutes with training. That’s how I finally figured out the proper way of saying tree and three, and words like three, there, those, there. That was an afternoon coffee with a friend of mine from the USA.

Remember when I mentioned children? The sad thing about adults is that we lose our inner child. Learning is essentially letting your adult self aside and bring back the curious child back. Never feel ashamed, never hold your questions back. Children are interested, their parents even get upset when children ask too many questions. Let them. This is the only way to learn stuff: to question everything, no matter how silly it sounds. The only dumb thing is not to ask questions.

And again, will it be worth it? Will you ever be able to speak fluently like a native American? You could. It all depends on training and commitment. As you can tell by now, I can’t. This is the closest I could get.

The interesting thing you don’t think about? The Americans don’t care. They can tell I’m not a native. But I’m understandable, and that’s enough. In their minds what they immediately think is: “damn, this guy speaks better English than I could ever speak any other language.” That’s right, most Americans only speak English, they respect anyone that can speak more than one language, and they appreciate you even more for being understandable to them.

Americans are used to different accents, they have Latinos, people from Mexico, Republica Dominicana, they have Chinese, they have Italians, and so on and so forth. There are dozens of dialects and accents throughout the country.

And if you add English from Great Britain, the Netherlands, Australia, it’s all different. Your particular accent, my own accent, doesn’t sound nearly as bad as you think it does.

You are an adult, what the heck are you ashamed for? Mockery? Oh, come on. This is bullshit. The only reason you’re not studying and doing your best right now is your own laziness. You’re just lazy, admit it. It’s pathetic. If you really wanted you could start right now, for zero bucks. Change your Operating System default language to English - seriously, I have a hard time with Windows in Portuguese because I can’t find anything, I am used to English and the order of things in English. Then, erase all your Portuguese bookmarked websites. Change the default language of your web browser to English. None of this cost any money.

Install tools like Grammarly to correct your terrible written English. Read as much as you can, every day, in English. Listen to as much as you can. I subscribe to hundreds of English-only YouTube channels, I have zero Portuguese channels. Netflix? Start with subtitles in English - it’s so awesome that there is this option; if only I had it my VHS days. When you go rewatch a movie you like, turn the subtitles off. And instead of not paying attention because you feel uncomfortable, do the opposite, pay extra attention, pause the video whenever you learn a new word. Get your smartphone and Google it. The tools we have today make the learning process so much easier. I do that myself. For example, I just learned a new word that I never used before: “unrequited,” which means “unreturned, like a feeling not reciprocated,” and that was from Woody Allen’s Cafe Society movie. Old movies always teach me words I never used.

As a disclaimer, also keep in my that I always read a scripted text in my channel, and this section was no exception ;-)

Now, let me switch back to Portuguese!

Eu acho que eu soou diferente quando eu falo em inglês e português, porque você não pode falar inglês com o mesmo ritmo que fala português do mesmo jeito que seria bizarro você cantar, por exemplo, um Fly me to the Moon do Frank Sinatra com ritmo de Funk. Pensa como fica. Você precisa respirar diferente. E é mais fácil “ver” isso quando assiste séries e filmes, comece a prestar atenção na linguagem corporal dos atores. Eu já fiquei horas fazendo careta pra TV pra imitar a posição da boca e o jeito de inspirar e expirar as palavras. E sobre respiração, uma coisa que eu vejo 90% das pessoas fazendo errado: fale as palavras até o fim, não tente conectar uma palavra na outra como fazemos falando português corrido. Fale inglês como um gaúcho ou sulista fala português, pausado, correto, palavras até o fim, com pausa. Só isso já é meio caminho andado pra ser entendido.

Mas se você não está convencido, vou dizer uma última coisa que eu acho muito importante, inclusive tem a ver com programação. No mundo da programação, você frequentemente vê o povo falando de padrões de programação ou padrões de arquitetura.

Quando alguém fala “padrão” parece dizer no sentido de “é a melhor forma” de fazer alguma coisa. E isso está errado. Em inglês temos 3 palavras diferentes: standard, default e pattern. Os 3 traduzem em português pra padrão, mas eles querem dizer 3 coisas completamente diferentes.

O que você pensa por padrão, normalmente é o que o americano pensa quando diz “standard”. Um standard a ser seguido.

Ou você tem default, que é a escolha padrão, ou quando você não escolhe, o que é escolhido é o default.

Finalmente, pattern é simplesmente alguma coisa que aparece várias vezes. Pode ser certo ou errado. Um pattern pode simplesmente indicar uma tendência. Por exemplo, se todo mundo resolver começar a usar calça vermelha. Isso é uma moda, posso dizer que é um pattern. Ou dizer que toda boa pizza “costuma” ter queijo, é um pattern. Mas não é um padrão ou 100% das pizzas precisariam ter queijo. Entendem a diferença?

Por isso, toda vez que em programação você ver algum livro ou matéria falando em “padrão de arquitetura”, não pense que esse deve ser O jeito certo de fazer. É só um jeito que, naquele momento que o texto foi escrito, o autor viu com alguma frequência, o suficiente pra chamar de pattern. Em 1 ano pode já estar obsoleto porque assim como tendências, patterns também ficam velhos, outros patterns aparecem.

Se você parar pra entender o básico sobre como o cérebro funciona, do ponto de vista neurológico, um de nossos melhores mecanismos é nossa habilidade de aprender e detectar patterns. É parte do que chamamos de instinto, quando sentimos que vamos ser atacados, e fugimos sem pensar. Ou mesmo quando vemos textos como este:

(…. texto bagunçado)

Nós não lemos palavras de letra em letra, nós identificamos o pattern e vamos lendo em clusters, às vezes pulamos uma sentença inteira se for um cliche ou um chavão. Porque o pattern economiza nosso processamento, é meio como uma rede neural artificial funciona, ou o que chamamos hoje de machine learning, é basicamente identificação de patterns.

Patterns também tem efeitos colaterais, é de onde temos as ilusões de ótica por exemplo, onde vemos patterns que não existem ou patterns que nos confundem:

(… ilusao de otica)

Psicologicamente é de onde vem muito de nossas neuroses e até mesmo teorias da conspiração que é basicamente vermos patters que não existem, adicionar causalidade a coisas que não tem correlação. Tudo é parte dessa identificação de patterns.

Quando aprendemos inglês nos inserindo no ambiente como eu fiz artificialmente, mesmo que eu não entenda tudo que estou lendo ou ouvindo, se eu praticar deliberadamente a repetição, eu eventualmente vou “sentir” quando algo soa correto ou não. Eu não lembro a regra gramatical. Quando eu leio uma frase eu sei que “soa estranho” ou não. I won’t do it, ou I’m not gonna do it, são literalmente a mesma coisa, mas naturalmente eu digo um ou outro sem pensar muito. E eu argumentaria que pro dia a dia, isso é um bom nível, quando você naturalmente fala uma frase de acordo com o contexto da conversa sem precisar conscientemente pensar na construção dessa frase, que é exatamente como você fala sua língua nativa: você não precisa fazer um esforço consciente muito grande pra simplesmente falar.

Em resumo, o que normalmente chamamos de Padrão não é Standard. É Pattern. E você saberia disso se lesse os livros em Inglês, em vez das traduções em português, onde é impossível traduzir o contexto exatamente como o autor gostaria. Toda tradução perde parte do sentido, não importa quão bom seja o tradutor, especialmente porque algumas coisas tem carga filosófica ou cultural que não tem como traduzir.

Um dos exemplo que eu mais gosto é quando traduzem “making money” pra “ganhar dinheiro”. Tecnicamente está correto. Você diz: “I’m going to work to make money” que traduziria pra “Eu vou trabalhar pra ganhar dinheiro”. Em português a frase implica que sua opção é trocar seu trabalho por dinheiro, em inglês não se diz “ganhar”, se diz “make” que é “fazer”, a frase em inglês implica a opção de você produzir onde antes não existia alguma coisa, que é a essência de empreender.

E na minha cabeça essa é uma das maiores diferenças culturais dos Estados Unidos pra qualquer outro lugar do mundo: lá, filosoficamente falando, o objetivo era construir e criar onde nada existia antes. No resto do mundo é dividir e tomar o que existe, ganhar o dinheiro, ganhar as terras, ganhar o poder, não construir.

E com isso eu espero que tenha conseguido explicar o que eu acho sobre aprendizado e em particular o que eu acho que pode ajudar na sua jornada pra aprender outra língua. Eu fiz mais ou menos a mesma coisa pra aprender Japonês. Em ambos os casos eu fiz sim curso, até o básico e saí do curso, aqueles cursos de bairro sabe? Como auto-didata eu acho que não fui tão ruim, o que vocês acham? E quais são as suas histórias não convencionais de como aprenderam línguas? Não deixe de compartilhar nos comentários abaixo, se gostaram mande um joinha, compartilhe com seus amigos, assine o canal e clique no sininho. A gente se vê, até mais.

Descrição no YouTube

Uma das maiores dúvidas de jovens programadores é sobre que linguagem aprender primeiro. Qual vai ter mais chances de ter emprego e ter mais oportunidades?

Parece que se aprender linguagens novas como Go ou Elixir vão ter menos oportunidades, mas porém parecem ser o futuro. Como conciliar aprender linguagens novas que tem menos mercado ao mesmo tempo que trabalhar com linguagens mais tradicionais como Java?

Vou dar meus 2 centavos de perspectiva nesse assunto.

Links:

• The Pragmatic Bookshelf (https://pragprog.com/search?q=elixir)
• The Little Elixir & OTP Guidebook (https://www.manning.com/books/the-little-elixir-and-otp-guidebook)
• Elixir Sips (http://elixirsips.com/)
• Elixir Weekly (https://elixirweekly.net/)
• Azul Systems (https://www.azul.com/careers/llvm-compiler-engineer/)

AkitaOnRails:

• [Off-Topic] O Mito do “Legado” (http://www.akitaonrails.com/2012/08/15/off-topic-o-mito-do-legado)

Script

Olá pessoal, Fabio Akita

Quando comecei este canal eu fiquei com uma dúvida. Se eu deveria me focar nas tecnologias mais novas. Fazer vídeos sobre Javascript ou Elixir ou Kubernetes ou algo assim.

O motivo de porque eu não tenho interesse nisso é porque uma rápida procurada no Google vai te dar muito mais informação, em muito mais detalhes, e muito melhor estruturado do que eu poderia tentar fazer neste canal.

Vamos lá, Se você quiser aprender Elixir, o que você deve fazer? Simples, comece no site elixir-lang.org. Ele tem um excelente tutorial para iniciantes, pra começar a aquecer na linguagem.

Dali você pode ir direto pro site The Pragmatic Programmer. Eles tem diversos excelentes livros sobre Elixir como o Programming Elixir. Outra boa editora é a Manning que tem o clássico The Little Elixir & OTP Guidebook. E tem várias outras que você pode procurar. Na real, o próprio google te dá boas primeiras opções. Tente procurar “Best Elixir Books” e eis os primeiros resultados:

Você pode começar aprendendo Elixir, Ecto e Phoenix direto e, como eu expliquei em outro vídeo, quando você aprende os primeiros 20% do conhecimento, você já está produtivo o suficiente pra começar a fazer aplicações. Não se engane, você ainda é um iniciante, mas já dá pra começar. Idealmente você vai aprofundar mais, ler mais sobre a história, ir atrás da origem do Erlang e como é o real funcionamento da Beam VM.

Se quiser ir mais devagar, pode assistir screencasts como os do Daily Drip. Eu aprendi muito com os vídeos do Josh Adams. E, claro, assinar mailing lists como o Elixir Weekly pra se manter atualizado.

Daí você quer colocar a aplicação num servidor. Você vai encontrar diversos tutoriais pra Digital Ocean, pra AWS, pro Heroku e assim por diante. E finalmente, se olhar posts do meu blog de 2015, vai ver todas as minhas explicações detalhadas sobre Elixir. Eu aprendi tudo que eu precisava.

E isso sem contar os inúmeros fóruns de reddit a hackernews com mais centenas de dicas de opiniões a respeito.

Ou seja, é relativamente simples aprender o básico de Elixir pra se tornar produtivo.

Se você ainda tem dúvidas o problema não é falta de material, é preguiça de usar o Google direito e de sentar a bunda na cadeira e começar a estudar sozinho.

A pergunta que a maioria das pessoas tem na cabeça é o imediatismo: mas tem emprego pra isso? Será que vou perder meu tempo e não achar nenhum emprego? E se você começar com essa pergunta toda vez, você está perdendo seu tempo. Porque essa pergunta vale pra Elixir, vale pra Ruby, vale Python, pra qualquer coisa.

Talvez não tenha. Talvez você acabe usando Elixir pra fazer a mesma coisa que faria mais rápido e melhor usando Javascript ou PHP. Talvez você tenha mais opções de emprego se simplesmente aprender C# ou Java.

Agora tudo depende de você. Existem motivos muito objetivos de porque em 2006 eu comecei a evangelizar Ruby mas porque hoje eu não evangelizo Elixir, ou Go, ou Rust. Talvez eu fale sobre isso em outro episódio. Mas vou levantar um ponto: quando eu decidi que ia aprender Ruby E trabalhar com Ruby, havia zero mercado de trabalho no Brasil. Não é um exagero, existia zero empresas usando, existia zero vagas de trabalho, existia zero material em português. Nenhum livro, pequenos fóruns de entusiastas, quase nenhum blog ou site falando a respeito. Esse foi até um dos motivos pra eu ter escolhido Ruby com tanta convicção, embora não tenha sido o motivo principal ;-)

Naquela época eu tinha um emprego muito bom de consultor Java no mundo Enterprise. Eu já ganhava bem pra época, já tinha investido uns 5 anos subindo na carreira de consultor. Mesmo assim eu literalmente joguei tudo fora. Quando eu me coloquei no objetivo do Ruby, eu pedi demissão e comecei do zero.

E calma! Eu não recomendo que ninguém me copie, as circunstâncias foram muito específicas. Eu avaliei com muito cuidado e fiz uma aposta de alto risco. Eu levaria os próximos 10 anos me recuperando, era um plano de longo prazo.

Mas meu ponto é o seguinte: eu decidi aprender Ruby em 2006. Meu primeiro emprego remoto com Ruby foi em 2007. E eu abri minha empresa de Ruby em 2011. Em 2018 minha empresa tem 7 anos, 80 funcionários sendo 75 desenvolvedores não só fazendo Ruby como Javascript, um pouco de Python e até Java eventualmente. Em nenhum momento minha preocupação principal foi ter ou não ter emprego.

Aprender Ruby ou Aprender Elixir não é o objetivo, é só um meio. Se você acha difícil aprender Ruby, Elixir, Go, Javascript ou qualquer coisa assim, esse é o primeiro ponto que você vai ter que melhorar.

A recomendação que eu daria pra um total iniciante, talvez seja não aprender primeiro nenhuma das linguagens novas. Invista seu tempo em Java ou .NET ou mesmo PHP. Nem todo mundo teve a chance de crescer numa capital como São Paulo, Porto Alegre, Recife. Nós temos opções em lugares assim. Mas se tem uma coisa que eu aprendi percorrendo o país inteiro é que nós somos a exceção.

O normal, principalmente em cidades do interior, em estados do Norte como Roraima, Amapá, é não ter nenhuma opção. Alguns poucos conseguem se mudar pras capitais, mas muitos não tem essa opção. Tem filhos. Tem família pra cuidar.

E pior ainda: em alguns lugares do país não existe internet banda larga que permita um trabalho remoto de qualidade. Obrigado pelo seu desserviço à nação Anatel.

É um dos motivos de porque minha empresa abre fora de capitais. Eu deteste falar da minha própria empresa porque sempre vai soar como propaganda, mas considere que eu tenho 11 escritórios e talvez uns 3 ou 4 funcionários em home office até estabelecermos um novo escritório. Em capitais eu tenho São Paulo, Natal, Teresina e Goiânia. Os outros são: Santa Maria e Novo Hamburgo no Rio Grande do Sul, arredores de Criciúma em Santa Catarina, Guarapuava no Paraná, Batatais, Sorocaba e Campinas no estado de São Paulo, arredores de Belo Horizonte, e Anápolis em Goiás.

A constatação mais óbvia: existem pessoas de qualidade em qualquer lugar do país. Um programador de São Paulo não é automaticamente superior a um programador de Teresina. A gente faz o que pode. Mas voltando ao ponto. Eu não faço isso porque sou um divino ser altruísta ou algo assim. Não, eu faço isso porque é lógico: é uma troca voluntária com mútuo benefício.

Voltando ao meu ponto: aprenda Java, aprenda C#, aprenda Javascript ou PHP. Você mora no interior, cidade de 200 mil habitantes, tem uma talvez duas empresas com alguma vaga na área de informática. Talvez seja uma agênciazinha, customizando Wordpress e Magento. Ou alguma instituição pública precisando dar manutenção num sistema velho em .NET. Não importa.

Isso não é pomposo. Não parece divertido. Mas você só pensa assim porque fica assistindo caras como eu falando das maravilhas que empresas de São Francisco usam.

Aqui não é São Francisco ainda. Não faça isso com você. Eu disse num video anterior que nos primeiros 5 anos de carreira acho que nem tinha e eu não participava de eventos, de fóruns, de comunidades, e isso me blindou e evitou que eu perdesse tempo questionando tudo que eu fazia. Questionar só funciona quando você tem alguma experiência. Dos 20 aos 25 eu ainda não tinha. Teria sido um desastre se eu ficasse toda hora correndo atrás do hype. Eu tive a sorte de poder correr atrás só do meu esforço.

Se você se sente mal em entrar numa empresa da sua cidade pra dar manutenção num sistema legado em PHP, você está começando sua carreira em enorme desvantagem, porque você está desperdiçando seu tempo se lamentando. Porque vocês acham que eu não estou fazendo vídeos sobre Elixir mas sobre o ASP que que eu fazia em 2001? Quando eu comecei a aprender Ruby já era 2006, eu já tinha mais de 10 anos de carreira.

Se você vai ficar empacado só no Java velho no sistema legado pra sempre é uma opção sua. Eu não tinha dinheiro na faculdade. Eu não tive dinheiro guardado a maior parte da minha carreira. O que eu fiz? Fiquei culpando a sociedade por não dar chances o suficiente? Não, eu aproveitei cada emprego em que eu entrei, eu fazia o trabalho, mas com o pouco que eu tinha eu comprava livros. Fazia upgrade no meu micro xing ling. Eu tava fazendo ASP em startup onde eu chegava a varar muitas noites e fazia muita hora extra, mas eu chegava em casa e baixava a JDK e Eclipse e treinava. No episódio sobre o Diário de Henry Jones eu disse que escrevi meu livro de Rails em 2006 enquanto eu estava trabalhando como consultor em Java. Eu escrevi em 2 meses nas horas vagas não porque eu era bom, mas porque eu não tinha outra alternativa.

Prática deliberada? O primeiro segredo é não ter ídolos. O segundo segredo é encarar sua vida inteira como um processo deliberado. Por consequência, o terceiro segredo é jogar o jogo do longo prazo. Hoje eu tenho quase 30 anos de carreira. Eu tive a sorte de começar cedo, aprendi a programar aos 12 anos, eu saí da faculdade mais cedo pra entrar no mercado mais cedo, consciente de todas as desvantagens que eu também ia ter fazendo isso, e eu venho sistematicamente compensando os pontos que eu era ruim.

Eu também queria abrir minha própria empresa antes dos 30 anos. Mas eu esperei. Até os 34 anos. Quando você pratica deliberadamente com seriedade, você sabe no que você é bom e no que você é ruim. Aos 30 eu sabia que ainda não era bom.

As histórias que eu estou contando e as que ainda vou contar, não é só pra você: que nasceu em classe média alta numa capital abastada do país com acesso às melhores universidades e opções. Eu conheci pessoas que vieram de situações muito piores do que as minhas e já me superaram. Cada um tem seus problemas, mas alguns tem o mérito de conseguir superar as expectativas.

Voltando ao Elixir, ou ao Go, ou ao Rust. Não foque em ter um emprego. Esse não é o propósito. Aprenda porque é legal aprender, porque você está praticando algo diferente que contribui pro seu banco de conhecimento e experiência, o único bem que ninguém jamais vai conseguir roubar de você. Dinheiro, posses, tudo isso você pode perder, mas conhecimento e experiência você vai ter pra sempre. E pode ser que você nunca use num projeto. Isso não importa.

Ao mesmo tempo, e esse é o primeiro desafio, evolua seu Java, seu C#. .NET em particular, está bacana hoje em dia, depois que a Xamarin foi adquirida pela Microsoft e eles estão migrando do .NET Framework pra .NET Core, que inclusive roda nativamente não só em Linux como smartphones iOS e Android, o pacote está interessante hoje em dia. No mundo Java você sempre tem a encheção da Oracle, mas alternativas como o próprio OpenJDK ou a nova JDK da Azul Systems, baseado em LLVM, e o dialeto Kotlin da Jetbrains, também aumentaram o padrão do jogo.

O mundo PHP não é o mais atraente mas pelo menos com frameworks como Laravel, você tem opções razoáveis.

E mesmo se você se ver obrigado a usar versões mais antigas por causa do legado da sua empresa, não se aflija.

Deixa eu te contar um dos grandes segredos da nossa área: qualquer imbecil consegue começar um projeto novo do zero. Mas só caras realmente bons conseguem melhorar sistemas legados.

A característica mais importante de qualquer profissional não é saber usar bem suas ferramentas, isso é o básico. É a capacidade de absorver o ambiente, entender as limitações desse ambiente, e tomar as melhores decisões o mais rápido possível e executar. Quem consegue fazer isso sempre vai estar na frente do rato de laboratório que sabe escrever Erlang de cabeça mas não consegue avaliar a situação real e toma decisões caras e de pouco resultado prático.

Eu não escolheria isso de propósito, mas considere que qual o melhor lugar pra aprender essas coisas? Num lugar ruim, com gerentes ruins, com clientes e usuários cabeça duras. Aí você tem 2 escolhas: se conformar e só seguir a inércia e ficar no mesmo lugar, ou aprender a escolher e lutar uma pequena batalha de cada vez, não com o objetivo de salvar a empresa ou o produto ou os usuários, mas pra exercitar sua capacidade de lidar com esses problemas. Era o que eu fazia, por isso eu gostava tanto de consultoria apesar do stress. Eu fui forjado em projetos impossíveis.

Mas, pra sobreviver, você precisa começar sabendo usar as ferramentas mais básicas direito. Exercite seu Go, seu Rust, seu Haskell, nas horas vagas. Continue se exercitando sem parar e sem objetivos de curto prazo. Mas domine a ferramenta do seu trabalho. Você só ganha voz pra tomar decisões de verdade no dia que sua competência técnica é reconhecida porque ela é óbvia. Se você precisa explicar, ela ainda não é óbvia.

Deixe eu contar uma pequena história. Em Dezembro de 2002 a Janeiro de 2003 um dos comerciais da minha consultoria disse que me vendeu pra um trabalho pontual numa grande empresa. Ele tinha ouvido falar que eu sabia ASP - e nessa época eu já estava só em Java - mas o cliente tinha um sisteminha super porco que outra consultoria fez em ASP. Era algum tipo de sistema de RH, pra banco de horas extras ou coisa assim, era tosquinho mesmo. Eu acho que comecei dando suporte por e-mail e depois fiquei alguns dias alocado direto no cliente.

Eu cheguei lá e abri o código. Sério, correram lágrimas de sangue quando eu vi. Fazia tempo que eu não via um código que tinha sido tão maltratado. Era praticamente o guantanamo do código. Por exemplo, eles tinham feito componentes COM+ que abriam conexão com banco de dados mas não fechavam, tinha vazamentos pra tudo que é lado, era tudo um linguição da pior espécie, com um monte de SQL misturado no meio do HTML. Acho que ele precisava integrar com o SAP mas nem isso funcionava. Felizmente eu era especialista nisso. Enfim, era um desastre. Mas eu me empolguei porque o cliente falou que antes de mim uma outra consultoria tinha vindo tentar consertar e desistiu. E nada aumenta mais minha motivação do que uma tarefa impossível. Não tem nada que tem mais valor do que um problema que ninguém quer nem consegue resolver. Você tem que aprender a gostar de ter as mãos sujas, enlameadas, se arrastar no pântano, e sair vivo no final.

E tinha outra coisa que me chamou a atenção. Quando estavam me mostrando o usuário do sistema disse que quase tudo funcionava, menos uma funcionalidade que não lembro se era um gerador de relatório ou alguma besteira assim. Essa informação era super importante. Eu disse: repete, é só esse botão aqui, se ele cuspir o que você precisa que é nesse formato x y aqui, pra você tá tudo ok? E ele falou: sim. BINGO

Veja o que é a situação de um consultor: um consultor é um agente externo, nós caímos de para quedas no projeto e na empresa dos outros, pra resolver coisas que ninguém interno sabe resolver, porque senão já teriam resolvido. Nós temos menos conhecimento de tudo, e menos tempo pra resolver o que ninguém conseguiu resolver. É sensacional porque você sempre começa em desvantagem e você é obrigado a fazer mais com menos.

Aquele código era um zumbi ambulante, precisava jogar tudo fora e começar de novo. Reescrever o código todo, eu ia passar os próximos 3 meses lá, fácil. Mas só aquele botão … eu ajeitei outros bugs críticos ao redor que impediam o sistema de ficar de pé e aí me foquei especificamente naquele maldito botão - nem lembro se era um botão, mas era algo simples nesse nível.

Sei lá, em 1 semana eu consertei. Chamei o usuário e falei pra ele fazer o processo todo. E foi até o fim. HA, um trabalho de 1 mes resolvido antes, e depois que meu concorrente tinha jogado a toalha. Se você nunca passou por isso, passe, não tem nada mais satisfatório do que resolver um problema que outra pessoa disse que não dá pra resolver.

Isso foi em Janeiro de 2003, daí em maio, esse cliente chamou minha consultoria de novo. Os caras gostaram tanto do meu trabalho que decidiram dar a chance da gente participar na RFP ou Request for Proposal deles, que é uma competição entre diversas consultorias. Normalmente só participaria consultoria maior, mas resolveram dar essa chance depois do resultado que eu tinha mostrado. Foram semanas de reunião, eu analisei centenas de páginas de casos de uso, diagramas, que outra consultoria tinha gasto meses escrevendo, escrevi gantt charts, fiz contas, e cheguei numa proposta de trabalho.

Pra vocês verem como isso demora, foi um processo que acho que levou de maio até pelo menos outubro ou novembro. No final eles falaram que ficou caro, me chamaram de última hora pra dizer “cara, a gente quer colocar vocês, mas o concorrente ta propondo bem mais barato e ainda ia trazer um consultor gringo”. Eu tinha 26 ou 27 anos, o projeto dependia só de eu dizer sim ou não. Eu disse não, eu já estava no limite e apostar mais baixo que isso era garantia de fracasso. Então depois de meses de análise, perdemos a RFP.

Em janeiro de 2004 eles ligam de novo pra gente. Em resumo, o tal consultor gringo acabou não podendo vir e como isso estava no contrato que venceu, o cliente disse: beleza, vou aceitar o gringo não vir, mas então eu exijo que vocês contratem o japonês da outra consultoria. Ha, satisfação receber esse e-mail da concorrente.

O nome desse cliente era Suzano Bahia Sul Papel e Celulose, o projeto era a implementação SAP do módulo de recursos humanos pra gerenciar os mais de 4000 funcionários que eles tinham na época. Meu sub-projeto era criar todos os aplicativos Web J2EE que iam expor todos os serviços como banco de horas, benefícios e tudo mais que seriam acessíveis diretamente pelo funcionários a partir de totens colocados nas fábricas. Incluindo reescrever aquele sisteminha tosco ASP que eu originalmente consertei.

O projeto era de tempo e custo fechado, mas a minha quarteirização negociamos pra ser de hora aberta ;-) e adivinhem o que aconteceu? Eu montei minha própria equipe e passei os próximos 2 anos mais ou menos trabalhando lá. No final levou o tempo e o custo que eu tinha dito que ia levar na RFP. A outra consultoria que era bem maior estava comprando o projeto pra ter um case. No final todo mundo saiu ganhando.

E é assim que as coisas funcionam: eu não planejei nada disso. Se eu tivesse feito bico, esperneado, reclamado, recusado a fazer o servicinho porcaria em ASP porque eu já era um Javeiro hipster ou qualquer besteira assim, nada disso teria acontecido.

É impossível juntar os pontos no presente. Só no futuro que tudo se conecta. Hoje você pensa, se eu ficar fazendo PHP e ganhando só o salário que eu ganho pelos próximos 10 anos, mesmo com aumentos, eu nunca vou pra frente. Mas isso só vai acontecer se você não fizer nada. É impossível dizer o que você vai fazer daqui 10 anos então não faça essa conta, é inútil, é perda de tempo. Em vez de ficar perdendo tempo com essa indagações inúteis, se prepare. Porque quando a oportunidade chegar, é tarde demais, você precisa estar preparado pra pegar a oportunidade quando ela chega.

Todo mundo reclama que ninguém dá oportunidade. É o contrário, existem muitas oportunidades, mas ou você não está preparado ou você está escolhendo as oportunidades que parecem mais confortáveis pra você. Ah vá, isso é mimimi, especialmente na primeira década da sua carreira, tudo é uma boa oportunidade. E eu já disse isso antes: se não está doendo, você não está treinando o suficiente. Ai, eu não vou evoluir na minha carreira de Java se ficar fazendo esse quebra galho em ASP … quem diria que isso é o que daria o meu maior projeto em Java até então poucos meses depois?

E vocês? Já foram surpreeendidos no futuro tendo feito coisas no passado que pareciam que não faziam sentido mas em retrospectiva tudo se conectou? Compartilhe com a gente nos comentários abaixo. Se curtiram mandem um joinha, e uma coisa que ia ajudar muito é se vocês ajudassem compartilhando os vídeos do canal pros seus amigos! Não deixem de assinar o canal e clicar no sininho. A gente se vê, até mais!

Obs: YouTube bloqueou este video por copyright do Anime então subi no Odysee

Descrição no Odysee

Por coincidência, depois dos episódios sobre Talento e Matar Semi-Deuses da semana passada, comecei a assistir este anime de 2007: Kaiji.

Fiquei impressionado com a forma como eles montaram uma alegoria que descreve como é a vida real da maioria das pessoas.

Este episódio vai continuar explicando o meu conceito de “prática deliberada” usando a história deste anime como pano de fundo.

Assista no Crunchyroll: https://www.crunchyroll.com/kaiji

Script

Olá pessoal, Fabio Akita

Esta semana vou fazer um vídeo só. O motivo? Este daqui vai ser super longo, mas espero que eu consiga passar minha mensagem. Tenham paciência comigo e vamos lá.

Não era minha intenção falar sobre animes, pelo menos não agora, mas o assunto cruzou com a série sobre Talento que falei semana passada. Se ainda não assistiu clique no link acima. Você já vai entender porque.

Gyakkyou Burai Kaiji: Ultimate Survivor foi ao ar em 2007 e 2008, produzido pelo lendário estúdio MadHouse, então sabemos que a qualidade de animação é excelente e, no melhor estilo MadHouse, é mais dark e adulto do que os animes que a maioria de vocês estão acostumados.

O autor original é Nobuyuki Fukumoto, que escreveu Kaiji em 1996. Antes desse anime também saiu outro que já entrou pra minha lista pra assistir, Touhai Densetsu Akagi que assim como Kaiji é um thriller psicológico, mas de Mahjong, tudo do mesmo autor e do mesmo estúdio.

Kaiji não é um battle manga como Naruto ou Dragonball, mas eu diria que é a mesma adrenalina, a tensão psicológica é definitivamente alta, nenhum capítulo que vi até agora (e eu estou no 18o no momento em que gravei este vídeo) é um filler ou enrolação, e é o tipo que você não se aguenta de esperar pra ver o próximo episódio.

Eu expliquei em detalhes sobre prática deliberada no vídeo anterior, mas uma coisa muito difícil de explicar é como de fato isso funciona. E um dos problemas é que você começa pensando em algo pequeno e isolado. Se começou a academia, você pensa, vou aplicar prática deliberada no cross-fit ou na maratona ou qualquer coisa assim.

Mas prática deliberada é nada mais, nada menos, que disciplina. A boa e velha. E disciplina não é uma coisa que você liga e desliga pra uma atividade. Esse é um dos maiores problemas: eu disse que o importante não é o resultado, é o processo. Processo é o caminho que leva você do ponto A ao ponto B..

E pra piorar a situação, a maioria das pessoas talvez só entenda isso quando tiver chegado perto da metade da vida. Aos 20 anos é impossível ter essa noção de forma clara. O máximo que você vai conseguir, é fazer o que eu fiz: dar um salto de fé.

(…)

No mundo moderno, todo mundo é imediatista, nós evoluímos ao ponto em que podemos nos dar ao luxo de sermos imediatistas, pense nisso. Todo mundo até se compromete a se matar por um curto período de tempo contanto que exista um resultado palpável logo na sequência. Por exemplo, se matar por 1 ano estudando como se não houvesse amanhã, mas sabendo que na sequência o prêmio é passar no vestibular da melhor universidade.

Mas a vida não funciona assim. E embora eu corra o risco de soar como um tiozão dando sermão, considere algumas verdades fundamentais:

1. a vida não é justa, ela não foi feita pra ser justa. Não há absolutamente nada na fundação da vida que um dia vai garantir igualdade e justiça pra todos. Igualdade e justiça são abstrações da nossa civilização. Veja qualquer ecossistema natural e pergunte ao rato se ele acha justo ser caçado pelo gato, ou o cervo pelo leão. O ciclo da vida é injusto. A natureza é injusta, por isso ela entra em equilíbrio. Equilíbrio não é estático, é um sistema dinâmico, um dia da caça outro do caçador.

2. a vida é meritocrática, meritocracia não tem como premissa a igualdade. Mérito é pura e simplesmente fazer o melhor com o que você tem. Só isso. Se você tem menos que outro competidor e mesmo assim conseguiu superá-lo, isso é mérito. Não existe mérito automático. Mérito é uma conquista, é o cervo que conseguiu correr um pouco mais rápido que o leão e sobreviveu aquele dia. Ë seleção natural.

3. as pessoas não reagem como você gostaria que elas reagissem. enfie isso na sua cabeça e você vai ser mais feliz. Você se frustra com as pessoas não porque elas não te entendem, ou porque são burras ou mal caráter, é você que não entende as outras pessoas. Isso se chama “falta de empatia”. Você pensa “porque esse infeliz não faz o óbvio que é certo?” … só que o “óbvio” e o “certo” são conceitos da sua cabeça. Pra outra pessoa “o certo” é outra coisa diferente e, nesse caso, ele está simplesmente agindo segundo o que ele acredita, não o que você acredita. E isso é lógico. Você se frustra porque assume que todo mundo deveria pensar igual. Bem vindo ao conceito de liberdade e livre arbítrio.

Existem outros fatores importantes mas pro vídeo de hoje esses 3 são suficientes. Eu precisaria de vários vídeos explicando em detalhes o porque dessas afirmações serem verdadeiras acima de dúvida razoável e o que fazer em cada uma delas na prática. Provavelmente eu vou fazer isso.

Mas, e aqui eu retorno ao tópico deste vídeo. Kaiji. Em 2 curtos episódios essa série explicou esses pontos de maneira mais simples e mais eficaz do que eu conseguiria em 10 vídeos. Claro, é um anime, é superficial, mas talvez justamente por isso seja tão efetivo.

Kaiji é um sandbox, é basicamente um simulador social. Um experimento social tenta colocar as pessoas num ambiente controlado, remover todas as variáveis externas e deixar as pessoas se comportarem em situações extremas. É quando o melhor e o pior das pessoas vem à tona.

Breaking bad é um dos temas do anime. Kaiji é um jovem de 20 e poucos anos, como muitos de vocês assistindo. Sem um tostão no bolso, gosta de procrastinar, não sabe o que fazer da vida, e fica esperando uma grande chance cair no colo. Todo mundo já fez isso.

Kaiji é uma alegoria ou uma parábola, não é pra levar ao pé da letra. Ela serve de perspectiva pra você. Vai rolar um pouquinho de spoilers a partir de agora mas não se preocupe é só de um trecho da série. Não vai estragar a série toda.

Nesse ponto você precisa saber que por diversos motivos Kaiji se endividou com um grupo tipo Yakuza. Das duas uma, ou ele vai ter que viver como escravo da Yakuza e dar praticamente todo o pouco salário que ganha só pra conseguir pagar os juros da dívida pelos próximos 16 anos ou ele participa de uma série de jogos desse grupo, jogos desenhados pra entreter caras ricos e entediados que querem se divertir.

(clip)

Só que esses jogos são tudo ou nada. Se você ganha, se livra de todas as dívidas e ainda pode sair com algum dinheiro. Se você perde, na pior das hipóteses sai com ainda mais dívida ou, na melhor das hipóteses, você morre.

Nesse jogo estão diversos outros caras endividados. No começo eles se simpatizam até porque estão todos no mesmo barco. Mas quando a coisa realmente aperta, no final cada um pensa por si só.

(clip)

Cada etapa desses jogos são decisões de moral, o que eu faço? Morro ou mato? Todo mundo em algum momento se sente numa situação dessas. Todo mundo se acha o bastião da moral e dos bons costumes, menos quando está ele mesmo numa situação ruim, daí o que as pessoas fazem? Acham justificativas. Todo discurso bonitinho de moral cai por terra na primeira dificuldade, por isso eu tenho zero paciência pra quem gosta de cagar regra de moralidade. Nenhum de nós jamais vai ser 100% moralmente perfeito. Julgar os outros pela moral é perda de tempo.

E nessa série, assim como na vida real, quando você acha que venceu a batalha, descobre que a guerra é muito maior. Você acabou de fazer o que achou que deveria, inclusive traindo sua moral. “Foi por um bem maior” você pensa, e vem o balde de água fria, com um desafio ainda pior.

(clip)

Eu comecei a ver essa série porque um dos tops da Crunchyroll agora é o Mr Tonegawa que é um spin off do Kaiji. E o tal Mr Tonegawa aparece aqui também e o cara é sensacional, agora entendi porque ele tem uma série só dele. Eu gosto de pensar que eu tenho um Tonegawa na minha cabeça me dizendo mais ou menos as mesmas coisas. Durante muitos momentos da minha vida eu fui como um Kaiji e tendo um Tonegawa martelando dentro da minha cabeça sempre me ajudou. Vamos ver:

(clip tonegawa)

Eu não sei como funciona pra todo mundo porque eu só conheço dentro da minha cabeça. Mas eu me identifiquei muito. De qualquer forma, de volta ao jogo, nesse cenário de atravessar caminhando na barra entre os dois prédios, você poderia pensar: porque eles só não agarram na barra e vão se arrastando então? Ah esse autor pensou em tudo.

(clip eletrico)

Também me identifiquei com isso porque eu tenho a mania de colocar obstáculos que nem existem só pra ver se eu consigo superar. E são coisas pequenas, às vezes eu me coloco um prazo absurdo. Ou me forço a fazer coisas que nem precisaria, tipo agora, fazer 2 vídeos por semana. É meu Tonegawa eletrificando minha ponte antes de eu caminhar.

Todo mundo deveria ter um Tonegawa. Pra ocasiões onde ficamos empacados:

(clip esperando)

Se ainda não passaram por isso, vocês vão passar, aquele momento em que ou vai ou racha, que não tem mais volta. Você tenta de tudo pra ter pensamento positivo, se animar, “acreditar” que é possível.

(clip acreditar)

Mesmo frente à uma situação quase impossível, você vai encontrar alguém que vai te dizer que é possível. Interessante como um monte de gente que nunca atravessou a ponte de verdade consegue dizer pros outros que vai conseguir. Nunca entendi esses coaches modernos.

Eu dei muita risada ne sse clip porque pareceu um desses coaches, vendedor de metodologia, eu sempre vejo eles dessa forma:

(clip metodologia)

E da mesma forma como quando eu vejo um vendedor de metodologia, coach, guru, especialista, empreendedor serial … o Tonegawa na minha cabeça pensa a mesma coisa:

(clip tonegawa)

Eu falo com um certo desdém de todos esses títulos pomposos mas na realidade eu não acho que eles estão querendo de fato enganar ninguém, eles estão até sendo sinceros. Como o Kaiji. Mas são ingênuos, porque a realidade é muito pior do que se imagina, como disse Tonegawa, eles vão durar os primeiros 5 metros. E todo coach que se preza fica com as pessoas só durante os primeiros 5 metros da ponte. E vamos ver um empreendedor de primeira viagem querendo atravessar a ponte, agora que ele aprendeu a metodologia.

(clip entrando na ponte)

Todo workshop, evento, meetup, é igual o que acabamos de ver o Kaiji dizer, mas poucos chegam nessa conclusão a tempo e mesmo quando entendem isso, continuam como um bando de Lemmings. Mas dê um pouco de tempo e a realidade bate na sua porta, brutalmente e imediatamente como um demônio. De novo, Tonegawa já sabia disso:

(clip tonegawa)

Quando eu disse no vídeo anterior que é muito difícil só ir aprendendo enquanto você vai fazendo, tipo, acabei de sair da faculdade, não tenho idéia do que estou fazendo mas vou abrir uma empresa, uma startup, vou aprendendo enquanto vou fazendo. Você vai em eventos, vê grupos empolgados como o Kaiji acima, risca seu tênis pra alinhar na ponte, segue a metodologia, mas na hora H é assim que você vai se sentir:

(clip dando pra trás)

Finalmente, a maioria nunca realmente treinou pra isso. É na hora H na zona de pânico de Noel Tichy, que você vai arriscar tudo. É uma aposta, um jogo de cassino. Se você não tiver estrutura pra aguentar, você vai ceder.

(clip oota)

Pra cada uma história de sucesso precoce que você vê publicado num Techcrunch ou Buzzfeed existem dezenas de caras como Ootas que não geram notícia nenhuma, que no começo acharam que poderiam ir até o fim, mas foram derrotados e esquecidos pela realidade.

E aí, você vê outros iguais a você falhando, fracassando, caindo, e você entra em desespero. E é pior ainda se tentar voltar atrás.

(clip voltando atrás)

E agora?

No cenário desse jogo, existe o Tonegawa que representa um grupo de mafiosos Yakuza, e vários ricos que estão assistindo a isso enquanto jantam e bebem, apostando em quem vai ganhar e nem aí pra quem vai perder.

Eu sei que é uma metáfora extrema, mas pensem neles como seus investidores, venture capitalists, fundos de investimento. O que você acha que eles vão fazer se você falhar? Cair com você?

E como Tonegawa disso, 200 mil dólares é muito dinheiro. E você acha que soltando fogos de artifício de segunda categoria e clamando frases de efeito, vai fazer jus a esse investimento? Se cair, você cai sozinho.

E se você já se comprometeu até o pescoço, e no meio da travessia descobre que não tem peito suficiente pra continuar, que opções você tem?

(clip pede pra desistir)

Pior ainda, sabe o que começa a acontecer na maioria dos grupos de amadores que se juntam só com frases de efeito e palavras bonitas mas que tem pouca ação?

(clip todo mundo caindo)

Como eu disse, o caminho pra grandeza é solitário. Por mais que seria bacana se fosse possível que todos andássemos juntos e ritmados pro mesmo lugar, a realidade é que cada um trilha seu caminho.

(clip solidao)

Cada um trilha seu caminho. O caminho pra cima é solitário, o caminho do empreendedor - e quando eu digo empreendedor não quer dizer só quem abre empresa, é qualquer um que decide empreender qualquer coisa, incluindo você mesmo. Esse caminho é o mais solitário de todos.

Mas voltando pra realidade. Essa alegoria é terrivelmente cruel. É cruel mas é uma boa ilustração do que os espera no mundo real.

Se você conseguiram se engajar na história do Kaiji, talvez se sintam tensos agora, estejam torcendo pra que eles consigam atravessar, talvez estejam com raiva do Tonegawa por ser tão frio.

Mas não se esqueçam de uma realidade: o Tonegawa e esse grupo não forçou ninguém a estar nessa situação. Os jogadores se colocaram nessa situação sozinhos. Na verdade, esse jogo é uma benção pra eles. Lembram do que o Tonegawa disse? Todas as más decisões que eles tomaram na vida os levou até aquele ponto. Vítimas da sociedade? Não, isso é só uma desculpa.

Mesmo que não seja verdade, encare dessa forma: onde você está nesse exato momento é o resultado de todas as decisões que você tomou até agora. Só porque você não consegue imaginar outros caminhos alternativos, não quer dizer que eles não existem. Onde eu estou neste momento é o resultado de todas as boas e de todas as más decisões que eu tomei, sozinho. Se eu tenho problemas, não é culpa de ninguém a não ser de mim mesmo, e o mesmo vale pra todos vocês.

A vida real é injusta. Ela não foi feita pra ser justa. Alguns começaram com muito mais vantagens que nós; e muitos deles, mesmo com todas as vantagens também estão atravessando a ponte como nós. Não importa o que você tem se não consegue tomar as decisões que precisa, no momento que precisa.

Sua vida é o conjunto de todas as suas decisões. Livre arbítrio tem essa desvantagem: se tudo der errado, a culpa é sua, e só sua. Não importa quantos tweets mal criados você poste apontando dedos pra todo mundo.

Mas a vantagem do livre arbítrio é que nunca é tarde. O Tonegawa não é o vilão da história. E é essa uma das coisas que eu mais gostei dessa série até agora. O vilão da história são as más decisões dos protagonistas. O Tonegawa representa a consciência que você deveria tentar ouvir. Ele diz só a verdade. A verdade cruel que nós não queremos ouvir.

Eu também sinto dó de mim mesmo algumas vezes. Quando eu explico coisas como no vídeo anterior, fica parecendo que eu fiz o caminho certinho, passo a passo sem errar nada. É o contrário, eu só sei que aquele funciona porque eu tentei outros que não funcionam como o Kaiji. Eu também atravessei aquela ponte. Eu vi com meus próprios olhos as pessoas caindo dela. E eu me vi no mesmo desespero quase caindo também. E não quer dizer que eu não vou ter que subir nessa ponte de novo. E acredite, você nunca está preparado o suficiente.

No vídeo anterior eu disse o seguinte: “Os melhores fixam objetivos que não são sobre o resultado mas sobre o processo de chegar no resultado.” Pois bem, eu não quis dizer o processo só de uma atividade isolada como programar ou fazer academia. Sua vida inteira é um processo em andamento.

O objetivo? Chegar no dia da sua morte sabendo que você não deixou de fazer o que deveria ter feito, seja lá o que isso for.

Ufa, esse episódio ficou dark né? A realidade não é sempre colorida, mas é melhor entender isso antes do que depois. Você já teve que atravessar essa ponte? Como foi pra você? Compartilhe com a gente nos comentários abaixo, se curtiram mandem um joinha, assinem o canal e clique no sininho. A gente se vê, até mais!

Descrição no YouTube

No episódio anterior vocês entenderam o que aconteceria se Einstein ou Darwin não tivessem existido.

Mas se ainda resta dúvidas, hoje vamos desconstruir Mozart e na sequência, através das pesquisas condensadas por Geoff Colvin, definir o que de fato diferencia uma má prática de uma boa prática se o objetivo é um dia alcançar níveis de Mozart.

Esta segunda parte conclui a primeira etapa do que eu chamo de “Aprendendo a Aprender”, a parte teórica, pra ficar mais fácil entender o que eu quero contar nos próximos episódios dessa série.

Já aviso que a segunda metade deste episódio pode soar muito agressivo, mas é necessário pra que eu delimite preto-no-branco antes de partir pras nuances de cada parte em vídeos posteriores, então não leve tudo ao pé-da-letra, entenda que circunstâncias eu estou endereçando hoje: como se atinge o status de semi-deus?

Links:

• Talent Is Overrated (https://www.amazon.com.br/Talent-Overrated-Separates-World-Class-Performers/dp/1591842948)

• The Leadership Engine (https://www.amazon.com.br/Leadership-Engine-Winning-Companies-Leaders/dp/0887309313)

• AkitaOnRails [Off-Topic] Talento é Altamente Supervalorizado: Humanizando Einstein e Matando Deuses (http://www.akitaonrails.com/2017/06/08/off-topic-talento-e-altamente-supervalorizado-humanizando-einstein-e-matando-deuses

Script

Olá pessoal, Fabio Akita

Eu espero que no episódio anterior eu tenha conseguido fazer você pensarem um pouco mais sobre o que vocês acham que sabem.

Nesse ponto vocês já devem ter entendido que eu sou naturalmente um cético. Eu não gosto de mágica. Eu não gosto de ideais inalcançáveis. Meu hobby é destruir utopias e trazer semi-deuses de volta ao nosso nível. Por isso eu não defendo nenhuma ideologia. Como disse nos episódios de programação, eu sou promíscuo com linguagens e ferramentas de programação, o mesmo vale pra qualquer outra coisa: nada está acima de questionamento, e toda idéia que se torna obsoleta merece ser jogada fora e substituída.

Esse é o núcleo de Aprendendo a Aprender. Ë isso que o famoso meme do Bruce Lee quer dizer sobre esvaziar seu copo, como você quer aprender alguma coisa se seu copo já está cheio de preconceitos? Jogue tudo fora, não acredite firmemente em nada, questione tudo. É mais fácil dizer do que fazer. Número 1? Pare de ser defensivo, se permita destruir você mesmo. Se permita aceitar suas fraquezas, físicas ou mentais. Se você não acha que tem fraquezas e não sabe quais são, como quer melhorar? Como você vai melhorar se você já acha que sabe tudo? Então vamos continuar quebrando mais alguns preconceitos.

Einstein era talentoso? Eu acho que sim, mas não do jeito que muitos pensam. Talento não é uma coisa que você nasce com. Não há nada no nosso DNA que define um gênio ou um talento.

Claro, sempre vai existir o fator serendípede e sorte. Estar no lugar certo, na hora certa e ter relacionamento com as pessoas certas, pode fazer toda a diferença. Mas isso Não é genialidade e nem talento e muito menos algo definido no seu DNA.

Esse conceito de “algo magicamente especial” ainda é resquício do racismo nazista de um Josef Mengeles, de que existe uma raça superior, ou gênero superior, ou mesmo um indivíduo superior. No geral, eu acho que não. Pra mim é tudo igual, o que existe é quem sabe usar suas capacidade melhor do que os outros que tem a mesma capacidade e desperdiçam.

No outro lado do espectro existem aqueles que já acreditam em outro meme, o meme das 10 mil horas de prática, conceito que se tornou famoso pela primeira vez por causa do livro Outliers, de Malcolm Gladwell.

De Bill Gates a Oppenheimer, aos Beatles, o livro tenta descrever como o esforço continuado e focado - 10 mil horas (aproximadamente 5 anos em tempo integral) dessas pessoas ajudam a explicar muito do sucesso deles.

Hoje eu vou explorar esse conceito e dizer como isso funciona em detalhes que o livro de Gladwell não explica.

(…)

Geoff Colvin, em seu excelente livro Talent é Supervalorizado: o que realmente separa os empreendedores de classe mundial de todo mundo, tenta ir além de Gladwell e seus Outliers e explica porque só simplesmente treinar 10 mil horas não é suficiente. Hoje vou citar alguns trechos do seu livro que explicam meu ponto de vista. Vamos lá.

Pesquisas em muitas áreas mostram que muitas pessoas não só falham em se tornar extremamente bons no que fazem, não importa quantos anos gastam fazendo isso, mas frequentemente nem ficam muito melhores do quando começaram. Não há muita correlação entre anos na área e excelência em qualidade, muitos seniors não são muito melhores no geral do que trainees que acabaram de ser treinados. E pior, em alguns casos, profissionais com mais anos e mais experiência podem começar a mostrar resultados piores do que iniciantes.

A história de “nascer com talento” parece explicar a raridade, e ajuda a nos conformar com nossa própria performance. Ou você tem talento ou não tem. Por isso não pensamos muito nisso, porque é um problema já resolvido.

Não existe talento natural. Se existe uma explicação pra performance excepcional é uma coisa que os pesquisadores chamam de “prática deliberada”, essa é a chave. A maioria das organizações é terrível em aplicar princípios de performance excepcional. Muitas empresas parecem arranjadas quase perfeitamente para prevenir as pessoas de tomar vantagem desses princípios.

A maior dificuldade de prática deliberada é mental, não física, mesmo em esportes.

Falando em esportes, considere os recordes olímpicos de 100 anos atrás - que representavam o pico da performance da humanidade do planeta - hoje em dia esses recordes é o normal que colegiais normais conseguem atingir. O ganhador da corrida de 200 metros masculino nas olimpíadas de 1908 fez um tempo de 22.6 segundos, hoje em dia o recorde de colegiais é mais rápido em mais de 2 segundos, uma margem enorme. O tempo dos melhores colegiais na maratona bate os medalhistas de ouro de 1908. E se você estiver pensando que é porque as crianças hoje nascem com físico melhor, não é isso.

Em mergulho por exemplo, a cambalhota dupla foi quase proibida até as olimpíadas de 1924 porque era considerado muito perigoso. Hoje em dia, chega a ser entediante.

Isso importa por causa do seguinte: atletas de hoje são superiores não porque eles são de alguma forma fisicamente diferentes, mas porque eles treinam de maneiras mais eficientes. Esse é o conceito mais importante.

Padrões em disciplinas intelectuais estão crescendo pelo menos tão rápido quanto esporte. Roger Bacon, o grande acadêmico inglês e professor no século 13 escreveu que uma pessoa precisaria de 30 a 40 anos para se tornar mestre em matemática da forma como ele entendia. Hoje a matemática que ele estava falando - lembrando que nessa época o cálculo nem tinha sido inventado - é ensinado rotineiramente a milhões de estudantes colegiais. Ninguém pensa nisso, mas considere o que isso significa.

O conteúdo intelectual é o mesmo, o cérebro das pessoas não é diferente, 700 anos não é nem de longe tempo suficiente para um upgrade de poder cerebral humano. Em vez disso, assim como nos esportes, o padrão do que fazemos é que simplesmente cresceu tremendamente.

Quando Tchaikovsky terminou de escrever seu famoso Violin Concerto em 1878, ele pediu ao famoso violinista Leopold Auer para fazer a performance de estréia. Auer estudou e recusou - ele achou que o trabalho era impossível de tocar. Hoje qualquer jovem violinista graduando em Julliard consegue tocar. A música é a mesma, os violinos são os mesmos, e os humanos não mudaram. Mas as pessoas aprenderam a tocar melhor.

Mozart é o maior exemplo da tal faísca divina de grandeza. Compondo música aos 5 anos de idade, performando publicamente como pianista e violinista aos 8 anos, produzindo centenas de trabalhos, alguns dos quais considerados como alguns dos grandes tesouros da cultura Ocidental, tudo no curto período de tempo até sua morte aos 35 anos. Se isso não é talento, de escalas monumentais, então nada mais é.

Vale a pena examinar os fatos um pouco mais de perto. O pai de Mozart foi Leopold Mozart, um famoso compositor e artista. Ele também foi um pai dominador que fez seu filho começar um programa intensivo de treinamento em composição e performance aos 3 anos de idade.

Leopold era muito bem qualificado para esse papel de professor do pequeno Wolfgang não só por sua própria eminência, ele estava profundamente interessado em como música era ensinado para crianças. Ao passo que Leopold era um músico mais ou menos, ele era muito excelente como pedagogo. Seu livro autoritativo em instrução de violino, publicado no mesmo ano que Wolfgang nasceu, se manteve importante por décadas.

Então, desde muito cedo Wolfgang recebeu instruções pesadas de um professor expert que viveu com ele. Claro que suas composições desde cedo ainda parecem impressionantes, mas eles levantam algum questionamento.

É interessante notar que os manuscritos não estão na caligrafia da criança; Leopold sempre “corrigiu” eles antes de qualquer um ver. É interessante também notar que Leopold parou de compor ao mesmo tempo que começou a ensinar Wolfgang.

Em alguns casos é claro que as composições do jovem garoto não eram originais. Os primeiros 4 concertos de piano de Wolfgang, compostos quando ele tinha 11 anos, na realidade não tem música original dele. Ele juntou composições de outras pessoas. Ele escreveu seus próximos 3 trabalhos desse tipo, hoje não classificados como concertos de piano, aos 16 anos. E esses também não contém música original, mas ao invés disso arranjos dos trabalhos de Johann Christian Bach, com quem Wolfgang estudou em Londres. As sinfonias mais precoces de Mozart, trabalhos curtos que escreveu quando tinha 8 anos, tem estilo próximo do de Bach, com quem estava estudando nessa mesma época.

Nenhum desses trabalhos é considerado grande música ou perto disso hoje. Eles são raramente tocados. Só são interessantes por causa da fama posterior de Mozart. Eles parecem o trabalho de alguém sendo treinado como compositor pelos métodos usuais - copiar, arranjar, e imitar o trabalho dos outros - com os produtos resultantes trazidos à atenção do mundo e talvez um pouco polido por um pai que gastou muito da sua vida promovendo seu filho.

O primeiro trabalho de Mozart considerado hoje como uma obra de arte, com seu status confirmado pelo número de gravações disponíveis, é seu Piano Concerto No. 9 composto quando ele tinha 21 anos. Essa é certamente uma idade jovem, mas devemos lembrar que nesse ponto Wolfgang passou 18 anos de treinamento pesado, treinamento de expert.

Isso vale pausa pra consideração. Qualquer faísca divina que Mozart possa ter possuído não o permitiu de criar trabalho de nível mundial mais rápido ou mais fácil, que é algo que nós frequentemente assumimos que faíscas divinas deveria proporcionar.

Os métodos de composição de Mozart não eram a maravilha que nós pensamos que fosse. Por quase 200 anos muitas pessoas acreditaram na habilidade miraculosa de compor peças inteiras na cabeça, e depois só escrever facilmente no papel. Essa visão vem de uma famosa carta onde ele diz exatamente isso: “o todo, mesmo sendo longo, está quase terminado e completo na minha mente … colocar no papel é feito rapidamente … e raramente o papel difere do que estava na minha imaginação”

Esse relato certamente faz parecer um super humano. O problema é que essa carta é uma fraude, como muitos já estabeleceram. Mozart não concebia trabalhos inteiros em sua mente, perfeito e completo. Manuscritos que sobreviveram mostram que Mozart constantemente revisava, retrabalhava, riscando e reescrevendo seções inteiras. Embora isso não torne o resultado menos magnífico, ele escreveu música da mesma forma que humanos ordinários escrevem.

Pesquisadores construíram o índice de precocidade para pianistas. Eles descobriram o número de anos de estudo necessário para um pianista sob programas de treinamento moderno antes de performar publicamente vários trabalhos, e então compararam isso com o número de anos necessários para vários prodígios pela história. Se o estudante médio precisa de 6 anos de preparação e considerando que um prodígio fez isso depois de 3 anos, ele teria pontuação de 200%. O índice de Mozart é cerca de 130%, claramente acima da média. Mas prodígios do século XX pontuam 300% a 500%. Outro exemplo de padrões que cresceram. O efeito do treinamento melhorado de hoje superaram o gênio de Mozart.

Ufa! E UAU significa que Mozart é uma fraude então? Não, não, ele simplesmente não é um semi-deus também. Mas o resultado do seu trabalho é sólido, ele realmente foi um dos grandes músicos que já existiu, mas tudo isso foi resultado de longos anos de muito trabalho. 10 mil horas? Eu diria que foi muito mais, 20 mil, 50 mil ou mais.

Aprendendo a Aprender até aqui funciona assim: primeiro, aceite que não existem semi-deuses. Eu sempre disse que é importante ter objetivos inalcançaveis pra você nunca achar que chegou ao fim. Mas se você estabelece um teto infinito logo no começo, não há nem porque começar. Você nunca vai ser um deus, desista. Mas outros humanos? Sim, aí já dá pra começar.

Quem não pensa muito no assunto acha que é uma questão de praticar, e praticar, e praticar. 10 mil horas. Está errado. É muito mais que isso.

Pra começar, praticar é hobby. É jogar futebol com os amigos antes da cerveja na sexta a noite. Você nunca vai ser um Neymar. E ninguém pensa em se tornar um Neymar, claro, mas pense que treinar algumas horas por semana não basta. Se você encara sua carreira da mesma forma, você está praticando errado.

Já Prática deliberada não é a prática que você imagina. Ela é especificamente desenhada para aumentar performance.

Pelo menos no começo é quase sempre necessário que um professor desenhe as atividades mais adequadas para melhorar a performance do indivíduo. Eu disse isso no meu vídeo sobre The Mythical Man Month. Seu professor pode ser uma pessoa, pode ser o trabalho de outras pessoas. Eu sempre encarei todas as pessoas do passado como excelentes professores. Eles vão economizar anos da sua vida porque, agora é sua vez de evoluir em cima do que eles tinham.

Prática deliberada requer que se identifique certos elementos definidos de performance que precisam ser melhorados, e então trabalhar com real intenção nisso.

Noel Tichy, um professor na escola de business da Universidade de Michigan e ex-chefe do centro de desenvolvimento de gerenciamento da famosa Crotonville da General Electric ilustra o ponto desenhando 3 círculos concêntricos. Ele nomeia o círculo interno de “zona de conforto”, o do meio de “zona de aprendizado” e a mais externa de “zona de pânico”. Somente escolhendo atividades na zona de aprendizado é que se faz progresso. Nós nunca vamos conseguir avançar na zona de conforto, porque é a zona onde fazemos atividades que já sabemos fazer. E zonas do pânico são tão difíceis que não sabemos como chegar perto. Identificar a zona de aprendizagem, que não é simples, e então se forçar a continuamente se manter nela, o que é ainda mais difícil, essas são as características primárias e mais importantes de prática deliberada.

Alta repetição é a diferença mais importante entre prática deliberada de uma tarefa e performar a tarefa na realidade, só quando conta. Você não vai evoluir só no horário do seu trabalho. Seu trabalho é sua zona de conforto, com raras ocasiões onde você vai fazer alguma coisa que desafia o que você já sabe. Mas é muito lento, muito demorado e altamente ineficiente desse jeito. Nenhum emprego, em nenhum lugar, vai ser suficiente. Se você leva treinamento a sério, vai precisar de muito mais treino.

Generalizando, a prática deliberada mais efetiva são aquelas que podem ser repetidas em alto volume.

Prática deliberada é sobretudo um esforço de foco e concentração. É isso que o torna “deliberado”. Continuamente procurando exatamente os elementos de performance que são não satisfatórios e então forçando na melhoria especificamente desses elementos. Digamos, em programação, muita gente acha difícil escrever bons testes. Porque não pratica? Escreva centenas de testes. Não só pros projetos do seu trabalho, que como eu já disse, é insuficiente. Escreva, escreva, escreva. Vai sair um monte de porcaria no começo. E pra evoluir você precisa fazer o que Mozart fazia: copiar, testar, avaliar, corrigir e recomeçar, e recomeçar, e recomeçar, centenas de horas.

Ao que parece, 4 a 5 horas por dia parece ser o limite máximo de prática deliberada, e é frequentemente concluído em sessões de não mais que 1 hora a 90 minutos de cada vez. Mesmo atletas de elite dizem que o fator que limita seu tempo de prática é a habilidade em sustentar concentração. E concentração só acontece quando você está sozinho, sem ninguém te atrapalhando. Prática deliberada é essencialmente uma atividade solitária, nunca de grupo. É quando você está 100% desligado do mundo. Portanto, se você está mais focado na sua timeline do twitter ou responder o whatsapp, você não está praticando.

Fazer coisas que sabemos como fazer é agradável, e isso é exatamente o oposto de prática deliberada. Em vez de fazer o que somos bons em fazer, nós insistentemente perseguimos o que não somos bons em fazer. Então nós identificamos as atividades mais dolorosas e difíceis que nos farão melhores e fazemos isso repetidamente. A cada repetição nos forçamos a ver - ou fazemos outros verem - exatamente o que ainda não está certo para podermos repetir as partes mais dolorosas e difíceis do que acabamos de fazer. E continuamos nesse processo até estarmos mentalmente exaustos. Se não está doendo, você não está treinando. No pain, no gain.

Parece um pouco depressivo que a coisa mais importante que podemos fazer para melhorar nossa performance não é divertido, mas console-se com este fato: TEM que ser exatamente assim. Se as atividades que levam à grandeza fossem fáceis e divertidas, então qualquer um faria. Isso é até uma boa notícia, significa que a maioria das pessoas não vai fazer isso.

Os melhores fixam objetivos que não são sobre o resultado mas sobre o processo de chegar no resultado.

A capacidade de auto-regulação mais importante que os melhores usam durante seu trabalho é auto-observação. Por exemplo, corredores de endurances em uma corrida tendem a pensar em qualquer outra coisa menos no que estão fazendo, por isso hobistas como eu e muitos outros colocam um fone de ouvido e tentam se distrair ouvindo música. É doloroso fazer uma maratona de quilômetros e conscientemente não querer se distrair. Nós preferimos tirar nossas mentes disso. Corredores de elite, por outro lado, focam intensamente neles mesmos, dentre outras coisas, eles contam suas respirações e simultaneamente contam seus passos de forma a manter certas taxas. Sério, isso dói em mim só de pensar. Por isso os melhores são melhores, porque eles dominam a dor. E não dor física, mas dor mental.

Pesquisadores chamam isso de meta-cognição - o conhecimento sobre o seu conhecimento, pensar sobre seu pensamento. Os melhores fazem isso sistematicamente, é uma parte estabelecida da sua rotina. Pense em você saindo de você e se monitorando enquanto faz a atividade.

Agora, o ponto final por hoje: A maioria se contenta com “ah, você fez bem”

Atividades de prática são inúteis sem feedbacks úteis. Mas não qualquer feedback. De forma similar, as oportunidades de prática que encontramos no trabalho não servem pra nada se não avaliarmos depois. E devem ser auto-avaliações, porque a atividade de prática aconteceu nas nossas mentes, somente nós podemos saber completamente o que queríamos fazer ou julgar como realmente ficou. Mas isso só funciona se você é altamente consciente dos seus objetivos. Se você nem sabe porque está fazendo o que está fazendo, como vai se auto-avaliar?

Os excelentes se julgam de forma diferente das outras pessoas. Eles são mais específicos, assim como quando definem objetivos e estratégias. Os medianos se contentam em se dizer que foram bem ou mal e só. Os melhores se julgam contra padrões relevantes pro que querem atingir. Algumas vezes comparam suas performances com seus melhores resultados até então; algumas vezes se comparam com competidores que estão encarando ou pretendem encarar; algumas vezes se comparam com o melhor resultado conhecido na área. Qualquer um deles pode fazer sentido; a chave, em toda prática deliberada, é escolher uma comparação que colabore para estender além dos seus limites.

Uma parte importante da auto-avaliação é decidir o que causou os erros. Os medianos acreditam que seus erros foram causados por fatores externos ao seu controle. Meu oponente teve sorte; a tarefa era difícil demais; eu não tenho mesmo habilidade natural pra isso. Os melhores, ao contrário, acreditam que eles foram os responsáveis por seus erros. Sempre. Qualquer um que passa muito tempo culpando os outros, os colegas, os chefes, os políticos, a sociedade, nunca vai sair da mediocridade.

Eu nunca peço e nunca pedi feedback pros outros, sempre achei meio irrelevante. Eu sempre soube o que eu queria fazer em cada momento. Você sabe porque você faz o que você faz? Porque se você não sabe, jamais vai conseguir se auto-avaliar, e nesse caso, qualquer feedback de fora é inútil pra você. Por outro lado, se você tem sabe porque você faz o que você faz, então você já sabe o que fez de errado e, de novo, um feedback externo é inútil pra você na maior parte do tempo.

Claro, feedback externo, sempre pode colaborar um pouquinho para você ver algo que não estava vendo. Mas ele não é nem de longe o mais importante. Aqui eu fecho com o que eu comecei: você precisa aprender a esvaziar seu copo. Tá entendendo o que isso significa? Se você acha que está fazendo tudo certo, como vai melhorar? Eu por outro lado, às vezes vou a extremos, eu sempre acho que estou fazendo tudo errado. É altamente tenso ser auto-crítico. Eu não dou o mínimo valor quando alguém me diz que eu fiz algo bem. Entendem? O que os outros entendem dos objetivos que eu quero alcançar? É mais irritante ainda quando eu digo que não fiz tão bem quanto queria e alguém chega - com boas intenções - e me diz que ficou bom. Não ficou. Eu sei que não tá bom. E se eu sei disso, porque eu me contentaria com alguém me dizendo que eu fiz bem?

Isso é se auto-enganar e é o extremo oposto de prática deliberada. Como eu disse, prática deliberada é brutal, é doloroso, porque você não pode ficar se enganando achando que “está suficiente”. Nunca é suficiente. No pain, no gain. Eu não sou grande coisa, e eu vivo com esse conceito em mente. Validação de terceiros é a maneira mais fácil de sabotar seu talento. Falta de auto-avaliação é o que faz você começar academia na segunda e desistir na sexta. “Já fiz o suficiente, já disseram que fiz o suficiente, tá bom”.

E qual seu objetivo? Ganhar mais dinheiro? Só isso? Tem formas muito mais fáceis se o objetivo for só esse, isso é muito pouco.

Lembram do Einstein? A teoria da relatividade é ensinado no 1o ano de faculdade, qualquer estudante minimamente competente consegue entender. Não querendo menosprezar, mas Einstein já foi superado, Mozart já foi superado, Jobs e Gates estão sendo superados na atualidade. A história não é estática e todo mundo está olhando pro futuro.

Tem gente que fala que eu sou grande coisa, eu Não sou, e não estou sendo falso humilde. Eu ficaria muito chateado se alguém achar que não dá pra me superar, eu sou facilmente superável, é um objetivo muito baixo pra esta nova geração. No século XXI eu sou nível 1, me supere, na metade do tempo que eu levei. Eu desafio todos vocês a colocar o que eu disse esta semana em prática. Não tenha ídolos, tenha referências, tenha objetivos a serem superados e logo que conseguirem, persigam outro pra superar.

Ufa, Esta semana foi bem intensa, mas como eu disse, no pain, no gain, e vocês já chegaram ao fim de suas carreiras? Estão começando suas carreiras? Qual a sua história de treinamento deliberado? Compartilhem com a gente nos comentários abaixo, se curtiram mande um joinha, assinem o canal e cliquem no sininho. A gente se vê, até mais.

Descrição no YouTube

Finalmente vou começar a estruturar um pouco minha idéia sobre “Aprendendo a Aprender” que eu venho soltando nos vídeos anteriores. Esta semana vou contar algumas histórias e matar alguns conceitos que vocês talvez ainda tenham.

Antes de começar, você precisa esvaziar seu copo, e a única forma de fazer isso é quebrar algumas coisas que você acreditava que eram verdade até agora, e só então construir em cima disso.

Muitos acreditam na noção de talento natural, alguém que já nasce com o tal “dom” ou “gênio”. Neste video quero responder uma pergunta: e se Einstein ou Darwin não tivessem existido? Teríamos ficado sem a Teoria da Relatividade e a Teoria da Evolução??

Links:

• How Einstein Ruined Physics (http://www.darkbuzz.com/herp/)

• New Book Says Einstein Highly-Overrated and Ruined Physics (https://www.sott.net/article/251049-New-Book-Says-Einstein-Highly-Overrated-and-Ruined-Physics)

• Olinto de Pretto (http://www.pax-tibi.com/olinto-de-pretto/)

• Alfred Russell Wallace letters (http://wallacefund.info/gallery?f%5B0%5D=im_field_smg_galleries%3A2471)

• AkitaOnRails [Off-Topic] Talento é Altamente Supervalorizado: Humanizando Einstein e Matando Deuses (http://www.akitaonrails.com/2017/06/08/off-topic-talento-e-altamente-supervalorizado-humanizando-einstein-e-matando-deuses)

Script

Olá Pessoal, Fabio Akita

Se você ainda não viu meus vídeos sobre faculdade e linguagens veja a playlist linkada acima e nas descrições.

Um tema que eu repito constantemente é que você aprenda a aprender. Bom, todo vídeo que fala sobre carreira fala algum clichê desse tipo: O importante é se esforçar. O importante é nunca parar. O importante é estudar isso ou estudar aquilo. O importante é a disciplina. Fuck that. Eu sei disso, você sabe disso, que diferença isso faz? Qual é a chave de verdade?

Se não ficou claro ainda, todos os meus vídeos mostram pequenos aspectos disso na prática. Daqui algum tempo vocês vão poder ver todos os meus vídeos em sequência e vão ver que eles vão se encaixando.

Mas hoje quero fazer uma pausa e contar uma história diferente.

No ano passado em 2017 eu fiquei numa discussão com o povo do escritório acerca de talento. É uma coisa que me irrita pessoalmente. Neymar, Mozart, Einstein, pense em grandes nomes do esporte, das ciências, da música, ou qualquer coisa produtiva. Você sempre vai encontrar nomes absurdamente fora dos padrões, muitos elevados ao status de semi-deus.

São nomes inalcançáveis. Se você assistir um filme biótipo ou qualquer documentário ou mesmo biografias, vai parecer que você está lendo sobre alguém que sequer poderia ser um Homo Sapiens, um Hiper Sapiens??

Eu tenho um sério problema com esse conceito. Pessoalmente eu não acredito em talentos naturais. Esse vai ser o tema do próximo vídeo

O outro ponto que muita gente levanta principalmente nas discussões políticas sobre pró ou contra aborto - que aliás, pros propósitos deste canal, não me interessa muito pra que lado você pende nessa discussão, me interessa a implicação: imagina se um Einstein não tivesse nascido. Ou se um Darwin não tivesse nascido. Você certamente já pensou isso ou ouviu isso. E se eu te disser que se Einstein ou Darwin não tivessem existido, ainda assim teríamos a mesma Teoria Geral e Especial da Relatividade e a Teoria de todas as Teorias, a Teoria da Evolução das Espécies via Seleção Natural?

(…)

Este episódio é sobre o livro do físico Roger Schlafly intitulado “How Einstein Ruined Physics” ou “Como Einstein arruinou a física”. Citando o artigo de Mark Green de 2012 para o site Sott.net. Vamos lá.

Einstein é considerado o maior gênio do mundo por ter criado a teoria da relatividade. O livro de Schlafly explica sobre a relatividade, como ela foi descoberta e como ela se encaixa na longa história de tentar entender movimento e simetria. O livro mostra que o papel de Einstein é terrivelmente mal interpretada.

Ele é famoso por ter unificado o espaço e o tempo na teoria da relatividade, e por ter revolucionado a ciência somente com puro pensamento. De fato, seu famoso paper de relatividade meramente postulou o que havia sido previamento provado, e ele mesmo nem entendia porque espaço e tempo estavam sendo unificados.

Milhões acreditam que Albert Einstein foi o maior cientista que já viveu. Obviamente soa uma enorme redundância dizer isso, certo?

O que tornou Einstein tão grande? A história é mais ou menos assim: Albert Einstein, um jovem funcionário de um escritório suíço de patentes, sozinho transformou a física de uma ciência tridimensional estática para um incrível universo de espaço-tempo quadridimensional através de brilhantes e solitários experimentos de pensamento envolvendo gravidade, movimento, espaço e tempo. Einstein também fez incursões no entendimento da natureza da luz e energia e foi o primeiro a compreender a equivalência entre energia e massa. As descobertas de Einstein não só transformaram a física moderna mas nossa visão de como vemos o universo.

Schlafly discorda. “É tudo um mito. Einstein não inventou a relatividade ou a maioria das coisas que lhe dão crédito”. Wow!

Relatividade é a culminação de uma procura antiga para entender o movimento da Terra. A história nos leva da Grécia antiga como Aristóteles, através de debates medievais sobre Copérnico e Galileo, até a procura recente por matéria negra e energia.

Schlafly faz uma revisão impressionante de contribuições que foram meio esquecidas de físicos notáveis e matemáticos. Uma pequena lista de grandes figuras incluem o matemático francês e prêmio Nobel Henri Poincare (que o filósofo britânico Bertrand Russell chamou do maior homem que a França já produziu), o pioneiro físico holandês e prêmio Nobel, Hendrik A. Lorentz, e o físico e matemático escocês James Clerk Maxwell. De acordo com Schlafly, Maxwell foi o primeiro a cunhar o termo “relatividade” e criou a primeira verdadeira teoria relativista de massa e energia. Maxwell escreveu o massivo 2 volumes Treatise on Electricity and Electro Magnetism em 1873, que na opinião de Schlafly gerou “as mais importantes equações da história da ciência”.

O tratado subsequente de Poincare sobre relatividade dá os teoremas que foram “matematicamente idênticos ao de Einstein”, diz Schlafly, e a maioria do trabalho de Poincare precede Einstein. Lorentz e Poincare tiveram todos os maiores aspectos da teoria da relatividade, e publicaram antes de Einstein", ele diz.

E mesmo assim esses monstros da ciência foram quase totalmente esquecidos enquanto a reputação de Einstein atingiu status de semi-deus, por que?

E=MC2

Como um jovem, Albert Einstein não somente viveu num tempo de explosivo crescimento na ciência de física teórica, mas seu trabalho como um físico em um escritório de patente suíço lhe deu acesso único às emergentes descobertas científicas. Durante esse tempo, Einstein aprendeu sobre o que constitui direito de propriedade intelectual. A famosa equação de Einstein E=MC2, por exemplo, na realidade foi publicado por Olin to de Pretto, um obscuro jornal italiano 2 anos antes de Einstein. Mas Einstein vai dizer que ele pensou na equação independentemente. Mas Poincare também publicou sua equação antes de Einstein.

De fato, Schlafly argumenta que Einstein pegou emprestado muitas idéias de outros e clamou para si, incluindo o postulado que a velocidade da luz é constante e também a relatividade especial, a idéia que energia e massa são intercambiáveis. “O entendimento de Einstein sobre relatividade especial .. era inferior à de Poincare”. Em cada ponto essencial da relatividade especial, Poincare publicou a mesma idéia anos antes, e de forma melhor.

Claro que ele está brincando, certo? Não, Isso Não é piada.

A timeline das descobertas que antecedem o paper de 1905 de Einstein sobre relatividade especial, no mínimo, é ampla evidência do progresso durante essa era. Isso pode explicar porque Einstein nunca recebeu um prêmio Nobel pelo seu trabalho em relatividade, já que ele nem cunhou o termo e nem fez avanços no conceito. De fato Lorentz recebeu o Nobel por seu trabalho em relatividade 3 anos antes. Não foi até 1921 que Einstein ganhou o Nobel, e foi primariamente por suas contribuições no entendimento do efeito fotoelétrico.

O conceito de movimento e tempo sendo uma “quarta dimensão” precedeu Einstein por pelo menos uma década, H. G. Wells especulou o conceito no seu romance de 1894 The Time Machine. Nesse mesmo ano Lorentz escreveu um paper cientítico onde “ele propôs o conceito de tempo local num objeto em movimento”. Poincare escreveu um tratado em 1898 e 1900 explorando o relacionamento entre movimento e tempo.

Uma popular bolha de desentendimento é que a equivalência de massa-energia expressa na famosa equação E=MC2. O relacionamento da equação com o projeto Manhatan na segunda grande guerra é um exemplo desse desentendimento.

E=MC2 não é sequer necessário para a bomba atômica. Ela não dá nenhuma pista em como dividir o átomo, ou como criar um reação nuclear em cadeia, ou qualquer dos passos necessários para fazer a bomba atômica. Relatividade não é sequer necessário para entender a liberação de energia numa bomba de urânio ou plutônio, já que essa liberação pode ser amplamente explicada por considerações eletromagnéticas. Previsões sobre massa relativistica estavam sendo testadas pelo alemão Walter Kaufmann em 1901, antes de Einstein escrever qualquer coisa a respeito.

Ufa, essa história é bizarra, certo? Leiam o livro de Schlafly para a história completa e todas as evidências. O principal: claro que Einstein era muito inteligente. Qualquer um menos equipado jamais teria entendido os trabalhos que Schlafly diz que ele pegou emprestado. Mas, isso tira muito da mitologia sobre Einstein e o trás de volta pra Terra.

Pra finalizar, vou contar outra história um pouco mais curta.

Em maio de 1831 Robert FitzRoy tinha acabado de perder ume eleição. Ele tinha esperança de um novo posto para organizar um projeto missionário à Tierra del Fuego. Em junho de 1831 ele conseguiu ser re apontado como comandante do Beagle.

Ele estava ciente do stress da solidão do comando. Ele conhecia as histórias do suicídio do Capitão Stokes e de seu tio Viconde Castlereagh, que cortou o próprio pescoço em 1822. Fitzroy falou com seu amigo Francis Beaufort, hidrógrafo pedindo para encontrar algum cavalheiro para companhá-lo na viagem. Essa companhia deveria compartilhar do mesmo gosto científico e usar a oportunidade da viagem para pesquisar história natural. Mas alguns que o Beaufort tentou recrutar recusaram, incluindo o professor J. S. Henslow da Universidade de Cambridge.

A jornada do Beagle duraria 5 anos e iria vasculhar as costas da América do Sul, eventualmente até pararia no Brasil, na Bahia, por exemplo. Beaufort conseguiu encontrar um estudante jovem, de 22 anos, que ainda estava planejando uma carreira como clérigo. FitzRoy eventualmente aprovou esse jovem Charles Darwin pra posição.

FitzRoy e Darwin ficariam nessa jornada até 1836. Essa viagem e as inúmeras pesquisas que ele faria culminariam num trabalho de uma vida inteira depois da volta. O talvez mais importante livro de todos os tempos On The Origin of Species só seria publicado 23 anos depois, em 1859.

E como diria o dito popular: o resto é história.

Ou não?

Não há dúvidas que Darwin chegou à sua conclusão de forma independente, tendo ficado 20 anos escrevendo em privacidade. Mas em paralelo a isso, também de forma independente, outro pesquisador contemporâneo estava chegando às mesmas conclusões. Este é Alfred Russel Wallace, que chegou a enviar cartas a Darwin, datadas de 10 de outubro de 1856, que incluem o artigo “On the Law which has regulated the Introduction of New Species” ou “Sobre a Lei que regulou a introdução de Novas Espécies”.

Isso causou uma crise de consciência em Darwin e o incentivou a acelerar a publicação das suas próprias pesquisas. Calma, nesse caso ninguém roubou a idéia de ninguém. E na prática a versão de Darwin estava bem mais avançada. O próprio Wallace disse que sente que Darwin merece o crédito que recebeu.

Na história recente, graças ao massivo acesso a informação - seja de boa ou má qualidade das redes sociais por exemplo - vocês vêem mais discussões acaloradas a respeito. Steve Jobs vs Steve Wozniak. Thomas Edison vs Nikola Tesla. Bill Gates e Paul Allen.

Quem é o verdadeiro gênio?

Eu gosto de grandes estórias tanto quanto qualquer um. Mas eu encaro tudo como estórias. Toda estória enaltece um personagem protagonista. Documentários também são estórias.. A História formal deve ser desprovida de julgamento e relatar fatos, mas documentários e biografias contam uma estória, um folclore, uma semi-ficção, a visão pessoal do autor do documentário ou do autor da biografia.

Lembre-se disso: uma biografia não é um relato factual, um livro de 400 páginas raramente vai ser suficiente pra relatar todas as nuances de 60 anos ou mais da vida de alguém. Eu escrevi mais de 2000 páginas sobre mim mesmo, e eu não sou ninguém, e mesmo se escrevesse mais 10000 páginas, não seria suficiente. Biografias e documentários escolhem meia dúzia de eventos e amarram num folclore, é muito simplista.

O problema disso, ao longo de décadas contando e recontando a mesma história, e reduzindo tudo em resenhas, um parágrafo aqui e ali, referências em filmes e cultura popular, e acabamos criando mitos e semi-deuses. Já diria Joseph Goebbels: “se você contar uma mentira grande o suficiente e continuar repetindo ela, as pessoas eventualmente vão começar a acreditar nela.”

Steve Jobs é nosso contemporâneo e ele já tem status de semi-deus. Resultados impressionantes? Inegável. Mas ele foi um homem do nosso tempo, longe de um semi-deus.

Meu ponto é que a história real normalmente é bem menos glamurosa.

De Einstein, ou Darwin não tivessem existido? Ainda tínhamos Poincare, Lorentz, Wallace e outros contemporâneos que não estavam num lugar certo na hora certa. Conhecimento não é algo que nasce espontaneamente, magicamente, na cabeça de um único indivíduo. Normalmente é a consolidação de décadas ou séculos de pesquisas independentes feitas por centenas ou milhares de pessoas ao longo da história. Alguém eventualmente consegue condensar esses trabalho num momento Eureka e isso cria a ruptura pra uma nova era. Se não fosse Darwin, seria Wallace, ou outra pessoa completamente diferente, em outro lugar, em outro ano, mas é impossível parar o conhecimento.

Inovação nunca é o resultado do trabalho de somente uma pessoa isolada numa caverna. Inovação, genialidade, talento, são apenas momentos numa história ininterrupta da humanidade que resolvemos apontar um nome e uma data para representar um momento de ruptura para uma nova era.

O status de semi-deus não é inatingível. Algumas vezes é uma questão de serendípede. Algumas vezes é uma questão de trabalho árduo e no próximo episódio vou definir o que esse trabalho árduo realmente significa através de um livro do pesquisador Geoff Colvin que, aliás, deixa uma frase que sumariza este episódio, de seu livro Humans are Underrated: “O tipo certo de narrativa dita por uma pessoa é mais poderosa que a lógica”

O que acharam desse episódio? Vocês já tinham esse ponto de vista? Não deixem de mandar seus comentários abaixo, se gostaram desse vídeo mandem um joinha, assinem o canal e cliquem no sininho. A gente se vê, até mais!

Descrição no YouTube

Continuando no tema de “Devo fazer faculdade?” e de histórias pessoais hoje quero falar um pouco da minha faculdade e meu início de carreira, mais de 20 anos atrás, como era a minha época. E vocês sabendo como eu estou hoje, veja o contraste de como era pra mim e como isso afetou o que faço até hoje.

• Os Bastidores da Internet no Brasil (https://www.amazon.com.br/Os-Bastidores-Internet-no-Brasil/dp/8520417086)

Os links abaixo não são relacionados, mas são bons assuntos paralelos que eu menciono neste vídeo:

Links sobre Imigração Japonesa:

• Os Japoneses no Vale do Ribeira e Sudoeste Paulista (https://www.youtube.com/watch?v=7euLZybjG_Q)
• Jornal da Cultura: Casos de tortura e morte de imigrantes japoneses é tema da Comissão da Verdade (https://www.youtube.com/watch?v=xQz-n6QP8-w)
• Expulsão de Japoneses da Cidade de Santos - 1943 (https://www.youtube.com/watch?v=OyXiXwhCjHI)
• Yami no Ichinichi - O Crime que abalou a Colônia Japonesa no Brasil" (versão português) (https://www.youtube.com/watch?time_continue=1&v=QDf_egB3MG4)
• 1988 80 ANOS DE IMIGRAÇÃO JAPONESA NO BRASIL (https://www.youtube.com/watch?v=27_cRZRPeXg)
• Ultrapassando fronteiras - Os 120 anos de Japão e Brasil (https://www.youtube.com/watch?v=9o1d4BZgz6E)

Internet no Brasil nos Anos 90

• Fantástico - Primeira transmissão pela internet - 1997 (https://www.youtube.com/watch?v=14SH8Wp9z1U)
• Jornal da Band de 1995 sobre atividades pioneiras na internet (https://www.youtube.com/watch?v=P47e5puQl6I)
• O INICIO DA INTERNET NO BRASIL ( Internet World 1996 ) (https://www.youtube.com/watch?v=AJr0No21Ibk)
• Lançamento do windows 95 - matéria do Jornal Nacional (https://www.youtube.com/watch?v=Ys06xUGOwdA)
• Jornal Hoje 1981 - O Computador no Brasil (https://www.youtube.com/watch?v=NSVoKeiBSm0)
• A Febre do Videogame 1991, Globo Repórter (https://www.youtube.com/watch?v=8GirQPUdlTM)

Script

Olá pessoal, Fabio Akita

Acho que eu me empolguei em compartilhar histórias pessoais então vou terminar esta semana com mais uma.

Novamente, continuando na vibe do vídeo “Devo fazer faculdade?” Aquele episódio foi feito para um público bem específico: aqueles que já escolheram o que fazer e que tem recursos (dinheiro, tempo) para escolher uma boa faculdade.

Minha conclusão é simples: se você pode fazer, faça. Existem milhares de pessoas que gostariam de fazer e não podem, por inúmeras razões.

O episódio de hoje é praqueles que pelo menos gostam da área, mas pensam em sair da faculdade ou se vêem tensos porque sentem que não tempo pra estudar mais ou estão indecisos sobre o que estudar. Mais especificamente, eu sempre fui uma pessoa introvertida e anti-social. Eu não saberia dizer como é para pessoas extrovertidas ou sociáveis. A idéia não é dar uma resposta ou encher vocês de teorias, vou tentar contar como foi pra mim. Mais de 20 anos depois, o que eu tenho a dizer?

(…)

Como vocês podem ver, eu sou japonês …, portanto venho de uma linhagem de imigração que começou com meus avós saindo de um Japão em crise lá pelos anos 40 e vindo para cá. Imagine que houve uma época em que um japonês, fugir pro Brasil, fazia sentido!!

A comunidade japonesa assim como muitas outras colônias de imigrantes começou aqui do zero. Na pobreza. Sem posses, sem propriedade, trabalhando na enxada, de sol a sol. É o que muitas famílias aqui e ao redor do mundo fazem até hoje: tentam deixar para próximas gerações uma situação melhor do que a que se tem no momento.

E deu certo! Graças aos esforços dos meus avós, meus pais puderam estudar, frequentar faculdades. Então chegou a vez da minha geração, perdido no começo do anos 90, sem saber exatamente o que fazer. Toda família de japoneses tinha altas expectativas de seus filhos virarem engenheiros ou médicos. O que eu devia fazer?

Sabe qual é o problema de jovens que herdam opções? A gente costuma escolher errado por falta de experiência.

E aqui vai uma informação sobre mim que muitos não sabem porque eu raramente falo sobre isso. Eu não terminei a faculdade. Pois é, também sou um “drop out”. Vamos dizer que quando anunciei isso provavelmente meus pais não ficaram muito contentes.

Como eu expliquei em outros episódios, eu já programava antes, e embora não achasse isso na época, obviamente eu era um amador. Pra mim isso foi o mais importante da faculdade: jogar na minha cara que eu não sabia nada ainda.

Exemplo de choque? Primeiro dia de aula, o professor coloca na lousa uma bibliografia de livros de referência, parte em inglês (!!) E vou dizer que quando eu entrei na faculdade eu male-male sabia inglês. Tinha zero fluência pra falar. E sempre que ia na livraria procurar livros eu escolhia em português. Mais um choque, ver colegas que tiveram formação melhor que eu e já sabiam inglês muito melhor que eu. Obviamente meu ego tomou um nocaute logo no começo. Nada aumenta a motivação mais do que quebrar a cara com força.

Essa história toda foi só explicar um ponto: eu sou um drop-out, porém minha primeira recomendação não é dizer pra largar a faculdade. O que eu experimentei na faculdade me ajuda até hoje.

No meu segundo semestre resolvi virar monitor na sala de computação do CCE na politécnica. O trabalho era basicamente ficar lá sentado, e ajudar a desenroscar papel em impressora matricial. Ganhava na época R$ 50 (equivalente hoje a uns R$ 200). Mas o real motivo era porque antes de entrar na faculdade eu estava envolvido com BBS de pirataria. E ser monitor me dava acesso à rede de banda larga da universidade. Mas tinha um porém, eu só podia usar via terminal remoto numa conta UNIX. Portanto, pra procurar e fazer download das coisas, precisava aprender a usar UNIX. Relembrando, não tinha Google na época, nem tutorial em blog post. Ah sim, Linux era novidade naquela época também e nem de longe tão evoluído como é hoje. Foi assim que aprendi tudo que pude sobre ambientes UNIX. De quebra, tinha Apache instalado lá, e foi assim que sem querer tive meu primeiro contato com Web e como fazer HTML. Naquela época só cientista da computação sabia fazer HTML, imagine só.

Alguns meses depois, um belo dia olhei o quadro de recados da sala, tinha alguém oferecendo emprego numa agenciazinha perto da faculdade. Foi assim que fui aplicar o HTML que tinha acabado de aprender e a fazer CD-ROMs. Outro dia conto mais dessa história, mas foi onde tive acesso a Mac e onde comecei a aprender coisas como Photoshop e algumas noções de design que me são úteis até hoje.

Eu não pensava muito em objetivos de carreira: quero aprender X porque parece que vou ter uma carreira melhor. Eu era simplesmente entusiasmado com tudo. Tudo que aparecia de novo eu queria aprender, pensando assim eu não ficava julgando se o trabalho era “digno” de um bacharel de ciência da computação ou não. Recortar gif? Eu fazia. Consertar a rede do escritório? Eu fazia.

Até o fim do colégio, eu não refletia muito sobre o que eu estudava, simplesmente estudava o que me mandavam, fazia as provas e pronto. Um exemplo besta, que eu vi nas aulas de física. Eu nunca tinha parado pra pensar que as fórmulas de velocidade e aceleração era uma derivada da outra, por exemplo. Ou que as fórmulas de gravitação de Newton poderiam ser derivadas das fórmulas de Relatividade Geral. Óbvio que eu sabia que tinha muito mais no mundo do que só o que tinha nos livros do colégio, mas foi a primeira vez que parei pra contemplar o relacionamento desses conhecimentos onde antes eram só coisas para decorar.

Daí eu criei uma noção na minha cabeça que pretensiosamente eu chamava de Teoria das Pirâmides. Tudo que eu aprendi até o fim do colégio era o pequeno topo de diversas pirâmides. Pirâmide de matemática. Pirâmide de Português. Eu nunca ia saber tudo sobre tudo. Em vez disso eu falava pra mim mesmo que deveria aprender o topo de muitas pirâmides, e à medida que eu fosse avançando, iria descendo nessas pirâmides. E eu pensei em pirâmides meio como a dificuldade, o topo é menor, a parte mais fácil, a base é maior, as partes mais avançadas, quanto mais você desce na pirâmide, mais difícil fica. Muitos pensam em ir completando uma pirâmide inteira de cada vez e eu sempre achei isso ineficiente.

Antes da faculdade, e até talvez o primeiro ano, eu tentava ler os livros inteiros, mas antes dava, porque não tinha muito mais pra se ler. Na faculdade eu vi que isso não iria acontecer mais. Antes meu mundo se restringia a uma dúzia dessas pirâmides de conhecimento. Foi quando eu parei de tentar ler livros técnicos inteiros, eu só lia a introdução. (pegue o livro) E ia avançando se precisasse. Em vez de ler 1 livro inteiro, era melhor ler o começo de 10 livros. E gastava mais tempo praticando do que lendo.3

Em 1997 ou 1998 a febre das ponto com começou, com força. Trabalhar no meio da bolha da internet era super empolgante, claro, a gente nem imaginava que estava numa bolha, é como bolhas funcionam. Naquela época a população em geral ainda se perguntava se essa tal de internet ia vingar ou não. Consegue imaginar isso? Mas eu nunca parei muito pra pensar nisso também, só achava divertido. E mesmo parecendo retórica, realmente nunca foi pelo dinheiro. Era simplesmente que naquela época eu achava tudo que era novo empolgante.

Sair da faculdade, olhando em retrospecto, talvez tenha sido prematuro. Mas naquela época eu estava com DPs em algumas matérias. O curso de ciência da computação da USP é tempo integral, significa que eu ficava com buracos no meu horário: tinha aulas de manhã cedo e depois aulas só no meio da tarde. Era impossível trabalhar no ritmo de agência onde não raras as vezes eu dormia no escritório. Eu tinha um professor que inclusive recomendava que eu deixasse de trabalhar e focasse só na faculdade.

Lembra da parte que eu falei do meu ego inflado? Então, eu me coloquei na seguinte posição: eu ia sair da faculdade, mas não ia parar de continuar estudando. Mas eu ia fazer meu próprio curriculo por assim dizer. Intuitivamente eu sabia do valor de certos conhecimentos, mesmo tendo pouca ou nenhuma aplicação prática naquele momento. A faculdade me ajudou a enxergar a diferença entre conhecimento de base e conhecimento temporário.

Quando eu digo isso parece que eu desenhei um plano detalhado de estudo, mas não é isso. Além do ego, eu sou extremamente teimoso com o que eu acredito, e significa que eu vou tentar provar meu ponto nem que seja por força bruta. Levou anos pra eu aprender a escolher minhas batalhas e ser mais eficiente.

Eu era novo, em 1999 eu ainda tinha 22 anos. Eu comecei a programar de alguma forma 7 anos antes mas eu ainda era muito inexperiente. Essa idéia de focar na introdução das coisas, daí praticar e através da prática voltar pra teoria, indo e vindo, eu tinha confiança que era um jeito mais eficiente do que ficar 1 semestre num único curso aprendendo só a teoria.

Eu nunca li nada sobre carreira. Na verdade eu nunca nem procurei sobre isso. Eu não pensava muito em que tipo de carreira eu queria ou em que tipo de empresa queria trabalhar. Eu nunca fiquei escolhendo, mandando curriculos bonitos. Nunca participei de processos seletivos de trainee em grandes empresas porque eu nunca nem tentei e nunca gastei um dia me lamentando do tipo “essa empresa é pequena eu devia estar numa empresa maior” ou qualquer coisa do tipo.

Mais uma razão de porque eu não me sinto confortável dando muita recomendação de carreira: eu nunca planejei a minha. Eu nunca pensei que era algo que dava pra planejar. Olhando em retrospecto, justamente porque eu não pensava muito, tudo que aparecia eu ia fazendo, sem pensar muito se tinha valor ou não. Não me preocupava se o ritmo de trabalho era insalubre, não me preocupava se estava varando noite aprendendo alguma coisa útil pro futuro ou não.

Na minha época não existiam eventos de programação, conferências. Não tinha meetups. Eu não sabia muito o que estava sendo discutido no mundo. Não existia o conceito de influencer, celebridade, ou algo assim. Então eu não tinha muita referência, por outro lado eu não me sentia perdendo alguma coisa ou indo no caminho errado pelo simples fato que eu nunca parei de aprender coisas novas.

Por conta dessa falta de contatos, por outro lado, eu não tinha muito viés. Eu não julgava tecnologia. Pra mim tecnologia era tecnologia, tudo igual. Eu não era anti-Microsoft ou pró-Open Source ou algo assim. Quando eu estava fazendo ASP eu não ficava pensando, ah isso é inferior a Perl, eu deveria estar fazendo Perl. Eu fazia o oposto, no trabalho alguém falava, tem que fazer em Perl, você sabe? Eu respondia algo do tipo, não, mas posso aprender. Nunca tive aquela sensação de estar fazendo algo inferior ou usando a coisa errada, da mesma forma como eu não tenho julgamentos de valor quando estou usando um martelo ou uma chave de fenda. Tudo era ferramenta que eu não sabia usar, toda oportunidade de praticar era bem vinda.

Existe uma enorme armadilha no começo de carreira: a minha teoria das pirâmides tem outro detalhe: só de aprender o topo da pirâmide, você consegue entregar um projeto. Hoje em dia eu ilustro isso como o problema dos 80/20. Com 20% do conhecimento você consegue resolver 80% dos problemas. Mas pra resolver os últimos 20%, vai precisar dos 80% de conhecimento que ainda não tem.

Com meus pífios 20%, eu entregava projetos. O perigo era eu achar que já era bom, eu entendia isso. O que me mantinha no chão é que pra entregar esses projetos eu varava muitas noites corrigindo bug. Na minha cabeça, se eu não consigo entregar com menos bugs e se eu não consigo entregar só no horário do trabalho, era minha falta de experiência. Esse era meu termômetro de competência.

Ah mas não era culpa do meu chefe que me mandava fazer mais do que eu conseguia? Claro que tinha isso também. Mas por outro lado, se era esse o caso, eu considerava incompetência minha não saber julgar isso antes de começar a fazer. Depois que já deu merda é fácil dizer o que tava errado.

Novamente, não estou recomendando que você seja explorado no trabalho. Muitas vezes eu sabia que devia ganhar mais, eu via que não me pagavam as horas extras que eu fazia, e num dos empregos eu cheguei a ficar 3 meses sem receber salário antes de pedir demissão. Eu ficava com raiva disso, mas não o suficiente pra ficar encanado. Não era R$ 200 a mais ou R$ 1000 a mais que ia resolver minha vida. Eu pensava nos R$ 10 mil, nos R$ 20 mil no futuro. Não lembro de onde foi mas uma vez eu ouvi uma frase de que quem gasta muito tempo pensando nos centavos deixa de ganhar os dólares.

Eu imaginei que se eu realmente merecesse algum reconhecimento isso viria eventualmente. Fazer um trabalho bem feito 1 vez não é motivo pra reconhecimento, fazer um trabalho bem feito por 10 anos começa a ser. E você só vai saber disso se durar 10 anos sendo consistente. Se a única coisa que você faz é reclamar, se justificar, é isso que vai definir o que você vai ser.

Todos os empregos ruins que eu já passei não importa, ficaram pra trás, 10 ou 15 anos pra trás, algumas dessas empresas faliram, as pessoas que eu não gostava já nem sei mais por onde andam. Eu continuo aqui, fazendo coisas que eu jamais tinha imaginado na faculdade. Qualquer plano que eu tivesse feito na época da faculdade, teria falhado.

Aprender a aprender é a única coisa que você precisa. Todo o resto é secundário. Eu não acredito em receitas de carreira, funções bem definidas. Eu não estou nem aí se eu devia ou não devia fazer alguma coisa. Logo no começo eu vi que as pessoas contavam comigo não pelo conhecimento que eu tinha, mas porque com ou sem bugs, eu ia até o fim pra entregar. Ninguém gosta de alguém que acha que sabe tudo mas na hora do vamos ver só tem justificativas. Eu aprendi isso logo no começo e em vez de ficar me questionando toda hora, eu simplesmente fui indo.

E, por hoje já ficou bem comprido! Já me pediram pra falar especificamente de materiais e livros recomendados, estou planejando isso pra outro episódio. E quais são as suas experiências na faculdade? Já tem 10 anos de carreira? As coisas estão indo como você planejou? Não deixe de compartilhar nos comentários abaixo. Se gostaram deste vídeo mande um joinha, assinem o canal e clique no sininho. A gente se vê, até mais!

Descrição no YouTube

O que o diário de Henry Jones (Indiana Jones e a Última Cruzada) tem a ver com minhas atividades de blogueiro, palestrante e agora YouTuber? Quero contar uma história pessoal que se inicia em 1984 e dura até hoje.

Não subestime uma criança, você nunca sabe o que pode se tornar uma inspiração que pode durar uma vida inteira.

Links:

• AkitaOnRails - [Off-Topic] Disney, História do Computador e o Encarte Perdido (http://www.akitaonrails.com/2011/09/25/off-topic-disney-historia-do-computador-e-o-encarte-perdido)
• Meu Passado Otaku – A revista de anime que publicou… um Boletim de Ocorrência (!!!) (https://maisdeoitomil.wordpress.com/2016/03/07/meu-passado-otaku-a-revista-de-anime-que-publicou-um-boletim-de-ocorrencia/)

Script

Olá pessoal, Fabio Akita

Quem me acompanha pelo Instagram sabe que passei as últimas 2 semanas numa peregrinação blockchain. Vou compilar o que aprendi provavelmente semana que vem.

Pensei em começar a contar algumas histórias pessoais, meio inspirado pelo meu episódio de “Devo Fazer Faculdade?”.

A história de hoje é como Indiana Jones me levou a virar blogueiro e, por consequência, começar este canal do YouTube.

(…)

Eu lembro até hoje, em 1989 meu pai me levou no cinema pra assistir Indiana Jones e a Última Cruzada. Eu já era fã de Indiana desde 1984 quando assisti tanto Star Wars o Retorno de Jedi e Indiana Jones e o Tempo da Perdição. Obviamente eu queria ver a Última Cruzada.

Chegamos atrasados pra sessão, quando entramos no cinema já tinha passado a introdução com o Indiana Jones adolescente e já estava na parte em que ele estava recuperando a Cruz de Coronado no navio. Lembro que a sessão estava cheia e assistimos tudo da primeira fileira, vou dizer que foi bem ruim pro pescoço, depois desse dia nunca mais me atrasei pra uma sessão de cinema. Enfim, resolvemos ficar depois do filme até a sessão seguinte pra ver a introdução que perdemos.

Eu gosto bastante desse filme por várias razões, assisti dezenas de vezes desde então, mas um conceito que ficou na minha cabeça sobre esse filme foi o diário de Henry Jones. Eu fiquei fascinado com o conceito de um pequeno livro que contém todo o conhecimento do personagem sobre o assunto do Graal, que ele veio escrevendo ao longo dos anos e que no final tinha as chaves pra resolver os 3 desafios do templo do sol.

Acho que todo mundo tem pequenos ganchos aleatórios como esse. Só faz sentido pra um jovem eu porque naquela época não existia o conceito de Web. Aliás, a palavra “internet” simplesmente não existia. Pra mim existia livros, revistas. Como uma criança de 12 anos eu ficava fascinado que era possível comprimir o conhecimento em volumes de uma enciclopédia. Eu não tinha a Britânica, mas tinha uma versão menor, o Mirador.

Eu não era particularmente estudioso nem nada disso. O que ressoou pra mim é que o diário de Henry Jones não era um enciclopédia. Era um compêndio sobre o Graal, um apanhado dos insights sobre um único assunto.

Outro gancho foi que na época eu tinha outro fascínio: computadores. Eu nunca brinquei na rua, só lia gibi e jogava videogame. Eu não refletia muito sobre computadores, pra mim eram simplesmente brinquedos caros que eu não tinha acesso. Porém, eu tive a sorte de ter um gibi de edição especial da Disney com a História dos Computadores de 1984. A história era muito bem contada, ia desde a origem dos números, do ábaco, passava por coisas como Leibnitz, Konrad Zuze, ENIAC, até o computador moderno - que naquela época eram representados pelos Macintosh e os primeiros IBM PC.

E como eu tinha uma enciclopédia, você pode imaginar que o verbete que eu lia mais vezes era a história dos computadores, que preenchia os detalhes que não tinha no gibi da Disney. Foi quando aprendi sobre Babbage, Lovelace, Turing e tantos outros.

Em a Última Cruzada, o diário era o compilado do trabalho de uma vida inteira de pesquisa. Em 1989 eu tinha 12 anos, na minha cabeça de criança, eu queria um livro como aquele, mas era super frustrante que obviamente eu não tinha nada pra escrever que desse mais que 2 páginas. Minha vida não era particularmente interessante.

Eu gastei algum tempo datilografando a história dos computadores. Coitados dos meus pais, quando criança eu ficava datilografando de noite e isso fazia barulho. Quando meu pai comprou meu primeiro computador, ele também comprou uma impressora matricial, uma Epson FX-1050. Eu era uma criança barulhenta de certa forma.

Foi assim que nasceu um pouco minha vontade de escrever e também meu interesse em história da computação. Meu Graal se tornou a computação. Nunca quis me tornar um especialista, foi só uma daquelas idéias que você tem quando criança que persistem mesmo quando você vira adulto.

Em paralelo, durante os anos 90 eu tinha outra obsessão: mangás e animes. Isso daria um episódio por si só, mas pra resumir aqui, além de consumir eu queria muito escrever a respeito. Eu conheci um grupinho e algumas pessoas que começaram a publicar uma revista chamada Animax, foi logo depois da revista Herói. A Herói era muito mal escrita, num nível que me dava raiva, então eu escrevi algumas matérias pra Animax, em particular sobre Evangelion. E como eu tinha acesso a um servidor web da faculdade, eu fiz um site chamado Animax Plug-in pra publicar matérias sobre meus animes favoritos da época como Evangelion, Gundan Wing, Ranma ½. Foi assim que comecei a escrever publicamente. Não lembro exatamente porque parei.

Eu gosto de explicar as coisas no contexto da história. Por exemplo, não era suficiente pra mim falar de Evangelion, eu precisava explicar a Gainax e seus trabalhos anteriores, Nadia and the secret of blue water, Gunbuster, Wings of Honneamise. E toda vez que escrevi sobre assuntos de computação a primeira coisa que me vinha na cabeça era escrever a história. Eu tenho essa obsessão de pensar em como as coisas chegam onde estão baseado nos eventos anteriores.

Por exemplo, por volta de 2002 eu quis dar um workshop de Java pra consultoria SAP onde eu trabalhava. Era pra ensinar o básico. Mas, claro, em vez de fazer slides mostrando como instalar o JDK, baixar o Eclipse e fazer um Hello World, eu comecei a apostila falando da história do Java. Claro, porque isso seria interessante … só que não.

Eu tenho um grande defeito. Eu nunca quis ser um escritor, eu era programador. Eu queria escrever alguma coisa pra mim. Melhor, sempre que escrevo penso no que eu de daqui 10 anos diria. Eu primeiro penso em mim, e é secundário se outra pessoa vai ou não gostar. Por isso eu nunca fui muito didático, nem escrevo só sobre assuntos da moda, porque o momento não necessariamente vai interessar o eu de aqui 20 anos.

Em 2006 eu publiquei meu primeiro livro de verdade, o Repensando a Web com Rails. Não era a primeira vez que eu aprendo uma nova linguagem, mas foi a primeira vez que eu fiquei empolgado além do meu normal, o suficiente pra largar minha carreira anterior e cair de cabeça nisso. Novamente, um assunto que daria facilmente outro episódio, mas pra resumir, meu objetivo com o livro era muito simples. Naquela época ninguém dava atenção a um assunto se não tivesse um livro publicado, por isso eu senti a necessidade de publicar em papel. Por outro lado eu não queria que fosse um livro caro e também não queria fazer um livro curto. Então eu cortei meus royalties. Eu faturei exatamente zero reais mas isso ia deixar o livro um pouco mais acessível. E eu não fiz isso por nenhum motivo altruísta, o livro nunca foi o objetivo final, era só um meio. Esse conceito pra mim é importante: eu não faço as coisas porque penso num bem maior ou porque vou ganhar dinheiro, eu faço porque eu quero.

Outra característica: eu tenho alguns momentos obsessivos quando escrevo ou programo. Meu estilo de vida sempre foi insalubre, e eu também não recomendo isso pra ninguém. De novo, eu não faço isso porque me espelho em alguém, por isso espero que ninguém se espelhe nas minhas partes ruins. Em vez de copiar o que eu faço, faça melhor do que eu, é melhor. Toda vez que eu varo noite eu fico frustrado comigo mesmo, porque só significa que eu ainda não sou bom o suficiente pra acabar antes. Não existe mérito em varar noite. Isso dito, como eu trabalhava tempo integral na consultoria SAP eu escrevi o livro nas horas vagas durante o dia, todas as noites, todos os fins de semana e todos os feriados durante um período de mais ou menos 2 meses pra escrever umas 500 páginas. O primeiro capítulo do livro e muitos dos capítulos seguintes começam com algumas páginas de história. Não é simplesmente um passo-a-passo, eu sinto essa necessidade de argumentar qualquer coisa que eu digo em vez de só dizer “faça porque eu disse”.

O blog akitaonrails.com começou como akitaonrails.blogspot.com antes de ter domínio e era mais para publicar notícias e dicas de Rails que eu ia vendo por aí. Levou ainda algum tempo pra começar a escrever conteúdo realmente original. De 2006 até hoje se passaram 12 anos. Eu nunca virei um blogueiro profissional de milhões de acessos. É um blog de nicho, mas mais importante, assim como foi com o livro de Rails, com meu site de anime, com as apostilas, até as datilografias da história da computação: eu nunca escrevo pros outros. Eu escrevo pra mim. Se meu blog só tivesse 1 acesso, de mim mesmo, era suficiente. Eu nunca cobrei pra escrever. Meu blog não tem ads. Meu canal de YouTube não vai monetizar. Porque no fundo, eu fico tentando escrever o diário de Henry Jones. Se eu ficasse pensando em matérias pra monetizar, eu ia escrever sobre coisas que interessam os outros mas não eu mesmo.

Meu blog é a primeira vez que eu cheguei perto de alguma coisa parecida com esse diário. É a coletânea de todas as minhas reflexões sobre pesquisas de assuntos que me interessam em particular e que eu escrevi de tal maneira que mesmo lendo 10 anos depois os argumentos sejam minimamente válidos, e que eu não me contradiga.

Novamente, meu objetivo nunca foi virar um escritor profissional e ganhar pra escrever. Minha obsessão é esse maldito diário. O canal do YouTube é a versão em vídeo do meu blog. O formato mudou. No começo eu tinha interesse em ter um volume em papel, como o diário original do Jones. Do papel pra sites, de sites pra blogs, agora de blogs pra vídeo. A mídia mudou, mas o objetivo continua sendo o mesmo.

Em retrospecto, tudo que eu faço eu faço pra mim, nunca pros outros. Eu sempre fiz tudo sem buscar validação. Eu não preciso muito que os outros digam que estou fazendo certo ou errado. Eu escrevi e gravei sobre porque você não deve procurar fazer só o que ama. Como eu disse naquele vídeo, eu não amo ficar varando noite pra editar vídeo, mas eu gosto de assistir o resultado tipo “da hora, pra um amador como eu, até que esse vídeo não tá vergonhoso, mas eu sei que posso fazer melhor”.

Deve ser muito frustrante quem faz as coisas esperando a validação de alguém. Eu não entendo muito quando as pessoas reclamam que ninguém elogia ou dá feedback positivo no trabalho delas. Me soa muito com uma extrema falta de capacidade de auto-crítica. Eu dou feedback pra mim mesmo. Eu nunca fiz nada porque alguém me motivou. Eu me motivo sozinho. Eu me sentiria muito mal se pra tudo que eu fosse fazer eu precisasse ser validado.

E tudo isso de certa forma nasceu daquele diário de Henry Jones, ele não foi feito pra ser lido por milhões, ele foi feito pra ser lido por uma única pessoa. A experiência pra mim era ver se eu conseguia chegar perto. E, claro é até engraçado pensar em ultrapassar um personagem fictício, é coisa da cabeça de uma criança de 12 anos. O diário de Henry Jones é só um prop de cinema que tem meia dúzia das 300 páginas de verdade. Eu provavelmente já mais que ultrapassei o volume. Agora vocês sabem porque eu consigo escrever conteúdos aqui pro canal: eu venho fazendo isso faz 20 anos. Eu escrevi 500 páginas de um livro. Eu escrevi 1000 posts. Eu produzi dezenas de palestras. Eu venho treinando faz tempo.

Esta história não é uma recomendação, tampouco uma receita. É só isso, uma história. Eu acho que todo mundo tem alguma história que os motiva de alguma forma. Qual é sua história? Compartilhe nos comentários abaixo. Se gostaram desse vídeo mandem um joinha, não esqueçam de assinar o canal e clicar no sininho pra não perder as próximas histórias.

Descrição no YouTube

A eterna dúvida de “devo ou não fazer faculdade” ou “não sei se continuou ou se desisto”. Existem vários ângulos diferentes pra isso, hoje vou pegar a posição dos que já escolheram a programação como carreira e explorar se deve ou não fazer faculdade e pra que ela serve.

Em outros episódios vou explorar posições diferentes como quem ainda não sabe se gosta de programação, ou aqueles que acham que devem sair pra empreender logo.

Links:

• AkitaOnRails: Off-Topic: Devo fazer faculdade? (http://www.akitaonrails.com/2009/04/17/off-topic-devo-fazer-faculdade)

Script

Olá pessoal, Fabio Akita

Fiquei muito surpreso como todo mundo gostou do vídeo Procure o que AMA … Só que não. Se não assistiu ainda, clique no link acima.

Já que tanta gente gostou do tema, quero continuar com outro que deve deixar muitos igualmente divididos. HOJE o vídeo é pra você que está em cima do muro quanto à questão de faculdade. Você deve fazer faculdade? Agora que está fazendo, mas se sente frustrado, deveria desistir?

…

Se você ainda tem até dúvidas se quer ou não entrar na computação, assinem o canal que devo fazer um vídeo sobre isso em breve também. Hoje é mais pra quem já entrou de cabeça na programação mas tem dúvidas sobre o assunto faculdade.

Esse assunto é bem extenso, mas, vou tentar me ater às dúvidas mais importantes primeiro.

Vamos à primeira pergunta que vocês devem se fazer

AoR: Cara, programar é muito fácil. Eu descobri o tal de Khan, academy isso e aquilo, canal de YouTube que ensina umas coisa super mean. Já consigo fazer site e colocar lá na hospedagem. Consigo fazer uma lojinha online pro meu tio. Já sei tudo que preciso pra trampar. Pra que perder tempo com faculdade? Qualquer um consegue programar sem precisar de faculdade.

Você já respondeu sua própria pergunta. É trivial fazer o baśico, qualquer um consegue, você tem mais do que razão nisso! Você consegue, seu vizinho consegue, o indiano e o chinês, o ucraniano também. Sabe como isso se chama? mão de obra barata. Seu salário não tem porque aumentar, porque cada vez é mais fácil aprender e cada vez mais gente sabe fazer a mesma coisa. Lei da oferta e da procura. Quanto maior a oferta, menor o preço que você vai poder cobrar. Seu emprego tende a desaparecer ou continuamente valer menos. Se você parar só nas coisas fáceis como vai subir na carreira? Ah, você acha que é só começar a trabalhar que vai aprendendo só no horário do trabalho? Boa sorte com isso.

Daí, alguns chegam a esta segunda pergunta:

AoR: Antigamente parece que as empresas exigiam mais diploma e tudo mais. Mas hoje em dia tem tanta startup, empresa mais moderna e ágil, que a maioria nem se importa mais tanto assim se tem diploma ou não. Se mostrar que consegue fazer o trampo eles contratam. Então, pra que se preocupar em faculdade?

Pára de pensar em universidade só pra pegar diploma e que o diploma só é útil pra conseguir o primeiro emprego..

Pensa diferente. Entrar nas universidades federais mais conceituadas é difícil. Viram meu vídeo anterior? Já que vai se matar no 3o colegial de estudar pro vestibular então corre a última milha e se mata um pouco mais pra passar nas melhores. Não se conforma com a sobra.

Se entrar, se esforça 4 ou 5 anos pra não ficar deixando matéria pra trás e estuda o máximo que puder. Se você tem condições pra fazer isso, então faz! É a última vez que você vai ter um tempo tão longo dedicado só pra estudar.

Agora pensa comigo: tudo isso dói, dói bastante, especialmente se como eu você não for daqueles que já cresceram com facilidade pra estudar. Mas não dói só pra você, pros outros também dói. E é muito mais fácil criar respeito por alguém que se esforça igual ou mais. E porque isso é importante?

Você precisa se colocar num grupo de pessoas acima da média. Muitas delas que você conhecer na faculdade, daqui 10 anos podem virar diretores de empresa, empreendedores ou influenciadores. Pensa diferente: é que nem comprar ações da Apple em 1983. Sabe quanto vale agora? Compre ações baratas, esse capital social vai se tornar valioso daqui 10 anos. Sabe as histórias que você ouve sobre Harvard e tudo mais? Não é porque você vai aprender alguma coisa secreta que só se aprende lá, mas porque as pessoas que se formam em Harvard tendem a se tornar juízes federais, senadores, donos de multinacional. Isso é mais importante do que o diploma. Só que nenhum deles vai respeitar ou lembrar que você existe se você foi só o medíocre invisível da turma.

Me diga com andas e direis quem és.

Agora vamos à terceira pergunta:

AoR: ah, mas e salário? Mesmo se eu me formar na melhor universidade meu salário não vai ser tão melhor assim. O cascalho é o mesmo, então, pra quê me importar? Não é melhor eu, que sempre fui autodidata, estudar as coisas mais novas que as empresas precisam pra melhorar meu salário? Puta perda de tempo ficar estudando matemática, vou assistir meu screencast super MEAN, que eu ganho mais.

Tsc, tsc .. isso é um erro muito comum: a ânsia de ganhar muito dinheiro logo no começo. Eu sei que alguns assistindo talvez venham de lugares que tenham problemas financeiros mesmo, não estou ignorando isso. E eu gosto de dinheiro tanto quanto qualquer pessoa. Mas eu prefiro dinheiro inteligente.

Se você entendeu o tópico anterior vai entender esse também. Pára de pensar em dinheiro nos primeiros anos de sua carreira. Mais específico: não pensa nisso por no mínimo uns 5 anos se puder. Talvez a primeira década inteira. E isso é extremamente difícil de imaginar se você estiver pra prestar vestibular porque sua vida escolar inteira durou 10 anos. Ou seja, metade da sua vida é uma década nesse ponto e eu estou falando pra você esperar o equivalente a mais meia vida!

Pra mim uma década é só 25% da minha vida. Quanto mais velho você fica, mais o tempo fica mais curto. Minha carreira tem quase 3 décadas já. E eu ainda não virei nenhum playboy milionário com ferrari na garagem, sorry, mas não tenho do que reclamar, estou bem confortável, obrigado. A quantidade de dinheiro que vai te satisfazer depende muito da sua ambição e não existe nenhum problema em ter objetivos grandes, na verdade eu diria que todo mundo precisa ter objetivos inalcançáveis, justamente pra nunca alcançá-los e nunca se entediar ou se conformar.

Tudo no começo da sua carreira é uma oportunidade. A universidade é uma oportunidade de ter acesso a pessoas que estudaram muito as carreiras inteiras: seus professores. Não os subestime. Eles estudaram muito mais do que você jamais vai estudar, provavelmente, é a especialidade deles. Use isso a seu favor.

Nos primeiros empregos, não importa tanto onde você vai trabalhar. Numa empresa grande e prestigiada você vai ver como é um dia a dia organizado, com papéis bem definidos, hierarquias tradicionais e como viver dentro do seu próprio quadrado num lugar onde o status quo muda pouco ou quase não muda. Você precisa dessa experiência, mas saia antes que você se acostume e fique confortável demais.

Numa empresa pequena, startups, você vai ver um dia a dia desorganizado, pessoas que batem cabeça com coisas óbvias, muitas dúvidas e inseguranças, e é a oportunidade onde você pode se testar em muitos papéis diferentes. Mas saia, antes que você se acostume em ser desorganizado.

Importante: fique em lugares onde há pessoas melhores que você. Se você se tornou o cara mais indispensável numa empresa que claramente não sabe pra onde está indo, só aí eu questionaria sua posição. O maior problema: você vai achar que é melhor do que realmente é.

Acredite, você ainda não é. Tem chão, entendido isso, vamos pra quarta pergunta

AoR: Porra, tenho que esperar 5 anos ainda?? Então mais um ponto pra eu largar a facul o quanto antes. Pra que diabos tenho que perder meu tempo com essas porcarias de cálculo, álgebra, estatística, nada disso é Java, nada disso é Node, eu preciso aprender a codar. Matemática não ajuda a codar. Em tempo, você vai vir a se arrepender disso. Matemática é uma das maiores armas que você pode ter nessa carreira. A maioria das pessoas hoje é ignorante com números. A maioria sequer sabe fazer contas básicas sem uma calculadora.

Matemática é um universo.. É uma das áreas de conhecimento mais antigas da humanidade e evoluindo até hoje. Esquece Java. Matemática é a linguagem mais difícil que você vai aprender. Ela te dá a gramática e o vocabulário pra decodificar a natureza e o mundo. Sem matemática você vai passar o resto da sua vida olhando pro mundo como um analfabeto olha pra uma enciclopédia.

As matérias de matemática vão te dar as ferramentas pra resolver problemas. Com matemática você decodifica o mundo. Esse treinamento vai fazer você imediatamente decodificar problemas de forma mais lógica. É um treinamento, deliberado. É muito fácil pra mim ver quem teve um treinamento assim e quem não teve.

E eu não estou dizendo que com o devido esforço, bater muita cabeça, você eventualmente não vai aprender sozinho, só estou dizendo que vai ser muito mais difícil. Novamente, se você tiver a oportunidade de ter esse treinamento mais cedo do que os outros, certamente você vai ter a vantagem.

AoR: tá, tá, mas quer saber, tem outro problema, as matérias de programação na faculdade são muito defasadas, a gente sai da faculdade e nem sabe programar de verdade ainda. Já entendi, essa tal de matemática até pode ser importante, mas eles deviam preparar a gente melhor pro mercado de trabalho.

Não. Aqui todo mundo vai discordar de mim mas eu tenho uma posição faz muitos anos e até hoje eu não mudei de posição. Nenhuma faculdade - com exceção talvez das técnicas e de tecnólogos - deveria ensinar ferramentas e linguagens que se usa no mercado de trabalho hoje. Eu inclusive sou a favor de ensinar programação somente com linguagens já mortas ou que raramente se usa de verdade, como Lisp, Smalltalk, Fortran. Eu acho que é um grande desserviço tentar ensinar Java, C# ou Python como principais.

Não, a faculdade tem que ensinar outra coisa: os fundamentos que regem todas as linguagens, todos os sistemas operacionais, a arquitetura geral de computadores e software. Caso vocês não saibam, as linguagens tem muito mais em comum do que você pensa, sua linguagem favorita não é tão especial quanto você pensa, é apenas mais uma dentre centenas. Você precisa aprender a fundação. Aprender uma nova linguagem, pra quem entendeu a fundação, é SIMPLES.

Um dia conto essa história mas pra dar um pequeno exemplo, quando eu fiz bacharelado em ciência da computação eu já era freelancer em dBase III e Clipper - talvez você nunca nem tenha ouvido falar dessas linguagens, mas eu programava nelas por pelo menos 3 anos antes da faculdade, e no primeiro semestre eu aprendi que tudo que eu achava que já dominava era nada, era pouco e eu pensava errado. Eu reprendi tudo do zero. E aprendi usando uma linguagem que já não se usava, Turbo Pascal. E isso foi antes da invenção do Delphi então foi por acaso que o que aprendi de Turbo Pascal acabou se tornando útil na prática também. Na verdade o fato do Delphi ter aparecido foi ruim porque o caminho confortável foi adotar Delphi. Eu tive sorte que não foi minha primeira linguagem senão talvez eu tivesse ficado no Delphi mais tempo do que deveria. O fato de antes da faculdade ter aprendi linguagens que durante a faculdade se tornaram obsoletas me fez ver o fato que o conhecimento de linguagens tem prazo de validade. Então eu entendi que não deveria nunca me sentir confortável com uma só linguagem e isso me ajudou a me focar nos fundamentos.

Em quase 3 décadas eu aprendi dezenas de linguagens. Relaxa, depois de fazer uma boa faculdade e prestar atenção no estudo dos fundamentos, aprender novas linguagens deveria ser simples pra você. O que você precisa aprender na faculdade é o processo de filtrar o que é conhecimento de base, que você vai levar pro resto da sua carreira e o que é conhecimento temporário, que vai servir por um período curto. A faculdade é onde você tem que treinar a coisa mais importante de todas: as técnicas de como aprender a aprender. Nenhum curso, técnico, tecnólogo, bacharelado, qualquer coisa, jamais vai te ensinar TUDO que você precisa. Ela vai te dar o 1% mais importante que vai te ajudar a aprender os próximos 99% mais rápido e melhor do que todo mundo. E esse 1% vai te custar 4 anos. Pra todo mundo que não fizer faculdade, prepare-se pra perder o dobro disso até cair a ficha. No mínimo.

Finalmente, vamos pra quinta e última pergunta deste episódio.

AoR: Bom, tá, vou pensar nisso. Mas então, como você explica que o Steve Jobs largou a facul, o Bill Gates largou a facul, o Mark Zuckerberg largou a facul. Ou seja, eu deveria é largar logo a facul também e ir empreender se um dia quiser ser que nem eles, não acha?

Essa é velha, mas ainda tem gente que pensa assim. Você deve conhecer várias pessoas que se formaram e não viraram Bill Gates, então parece confirmar que a faculdade é mesmo uma perda de tempo.

E esse é um dos exemplos da falta de treinamento matemático. Se X não fez Y e virou Z, mas se X faz Y e não vira Z, então, portanto, por consequência, se X quiser Z precisa cortar Y da equação!! … Dá zero pra ele!

De onde você tirou que a única coisa que difere você do Zuckerberg ou do Gates é o fator faculdade? Vocês são pessoas completamente diferentes. Nasceram em lugares diferentes, de famílias diferentes com histórias diferentes. Zuckerberg e Gates saíram de Harvard. Você sabe o que você precisa pra entrar em Harvard, em primeiro lugar? Você já viu a família do Gates?

Deixa eu só dar o exemplo da mãe do Gates, Mary Maxwell Gates. Segundo nossa amiga Wikipedia, ela foi a primeira presidente mulher do United Way de King County, uma das ONGs de caridade mais antigas dos Estados Unidos, de 1887. Também foi a primeira mulher a ser chair do comitê executivo nacional dessa United Way junto com o CEO da IBM John Opel, e a primeira mulher no board de diretores do Banco First Interstate de Washington. Lembra a velha história de como o Bill Gates vendeu a licença do MS-DOS pra IBM e tornou a Microsoft gigante com isso? Quem você acha que apresentou o Bill Gates pra IBM?

Pare de se comparar com celebridades. Talvez um dia você se torne uma, quem sabe? Mas não vai ser fazendo exatamente o que eles fizeram. E eu não digo isso pra colocar vocês pra baixo, pelo contrário, eu acho que as melhores celebridades, aquelas que realmente duram e não são só 15 minutos de fama, são os que anos antes já estavam acostumados a ser esforçados. Se eu pegar um cara preguiçoso e colocar do lado de uma Kardashian a semana toda, ele vai desaparecer dois dias depois e ninguém vai se lembrar dele. Porque virar celebridade é difícil, manter a fama, é outra ordem de grandeza mais difícil. Você está reclamando que é difícil fazer faculdade, e ainda quer se comparar com Zuckerberg ou Gates? Faça-me o favor

E é isso aí! Este episódio já ficou muito longo e o assunto é mais longo ainda então por hoje vou parar por aqui. Mas tenho mais a dizer sobre isso. Como disse no começo, hoje foi mais pra você que já escolheu a área de programação. Em outro episódio quero tocar mais no assunto de quem ainda não sabe o que fazer da vida. E você, fez faculdade? O que acha sobre o assunto? Mande nos comentários abaixo mais sobre sua experiência. Se gostou desse episódio mandem um joinha, assinem o canal e não deixem de clicar no sininho pra não perder os próximos episódios. A gente se vê, até a próxima!