$cat ~/posts/carreira-nao-existe-bala-de-prata

bilíngue · en / pt

carreira: não existe bala de prata

2026-09-05·pt·48 min read·carreiraestudosaprendizadoplataformastechpt

Every week someone shows up in my DMs with some variation of the same question:

"I already took a course and want to move into this field, what do I do now?" "Is it worth paying for a platform or can I just learn from free content?" "What actually matters when someone decides to call you in for an interview?"

And every week I answer with a giant message right there in the DM, buried at the bottom of the conversation two days later. So this post is the answer. If you're here because I sent you the link, this is exactly what I was about to type, just better organized and without the typos.

Fair warning: if you came looking for a ready-made recipe, you'll leave frustrated. Not because I don't want to give you one, but because it doesn't exist.

the disclaimer almost nobody gives

Before anything else, four things you should know about who's writing this:

I'm not senior and I'm not a reference. I'm at the start of the road to actually specializing in the field I chose to follow. What I have is the experience of someone who tried a lot of things in a short amount of time and made a lot of wrong calls along the way, which is enough to spare you a few of them, not enough to hand you a map.
My reality has privileges yours might not have. My Udemy access is granted by Sidia. My Coursera is paid for by my department, SITA. If I tell you "take this Coursera specialization" and leave that out, I'm giving you advice that's free for me and costs you a salary. That changes everything when you weigh cost against benefit.
Most of what's here I didn't invent. I learned it in practice, taking hits, and by watching people who'd already taken those hits before me, mainly three references who'll show up throughout this post: Fabio Akita, Augusto Galego, and Lucas Montano.

Akita is the base: his channel and blog shaped a lot of how I think about studying and career. I'll link his episodes throughout the text, because on several points the best I can do is point you to the source. The title of this post is basically a quote: in one episode he warns you to never trust a single magic answer, a silver bullet. There you go.

Galego is a CTO at an American startup and talks about algorithms, data structures, and international career, mainly through his YouTube channel (the blog exists, but the channel is the main medium). He gets in for one more reason: his material is from 2025 onward, meaning it was written already inside the world section 4 describes. And Montano is a tech lead at Disney, currently working on Disney+ Android, and also runs his own product and SaaS on the side; he shows up a lot in section 1, answering career questions live alongside a handful of other engineers. It's worth reading all three in parallel and feeling in practice what changes and what doesn't over time. There are other one-off references throughout the text, and they're all listed at the end.

Check the date on everything, including this post. The material I'll link is from 2018 to 2022. It's excellent and still holds up, but part of it was written in a world without ChatGPT, before the tech layoff wave, and before remote work was the norm. There's a whole section further down just about what aged and what didn't. Read it with the date in hand. This post will age too.

Hold on to that, because it's the thread running through the whole post: context changes the answer. Always.

1. figure out what you want (or don't)

There's a weird pressure in tech to pick your field right at the start, as if picking wrong would condemn the next ten years. It's not quite like that.

The problem is that nobody discovers they like something by reading about it. You can read fifty threads about data engineering and have no idea whether you can handle the actual day-to-day of data engineering. The only way to find out is by doing, and doing it small.

A recipe that works well: pick four or five fields that catch your attention (front-end, back-end, data, security, infra, mobile, ML, whatever), and build one small, complete project in each. Two weeks each, nothing ambitious. The goal isn't to get good, it's to feel the texture of the work. What gives you a spark and what puts you to sleep.

And here's the part almost nobody says: it's completely valid to end up with no conclusion at all. If after trying things out you're still unsure, you didn't fail the exercise. Staying a generalist is a legitimate position, and in the Brazilian market it's often the most hireable one: small teams, a dev who covers several fronts is worth gold. Specialization comes when it makes sense, not when the internet tells you to.

If it's exactly this doubt that's stuck on you, specialist or generalist, Montano made a few videos about it. The format is almost more instructive than the content itself: instead of giving his own answer, he took the same question to a handful of guests, among friends, speakers, content creators, and managers of large teams. It's worth watching the answers side by side.

Filipe Deschamps answers that it depends on two variables, always the same two: the person and the context they're in. And that early on it tends to be easier to move across several topics, precisely so you can find out what you like: his analogy is a kid entering school, they don't walk in a specialist, they see a bunch of subjects and only pick later. If you want a blunt answer: start as a generalist, if only because it opens more doors.

Another guest engineer pulls the opposite way: not purely one or the other, but you need to be at least a specialist in something, if you're a generalist, you'll land a generalist's job. Except the generalist part, to him, isn't knowing five languages and doing web, mobile, and backend at the same time, because that scatters your time and you end up good at nothing. The generalist part is what surrounds the code: development process, what makes software reliable, what makes it easy to maintain, and the team's tooling. He also thinks juniors should focus on soft skills before anything else: responsibility, punctuality, communication, caring about the company's problem.

And Montano closes with the question that sums it all up: why would you pick a field right away if you've never tried any other? His honest answer, after hearing everyone out, is that it depends case by case, and he admits right there that "it depends" sounds like a non-answer. Except it's true, and he follows up with what to actually do about it.

Notice that the three of them disagree on the details and converge on the same practical advice: build a project start to finish, as simple as it gets. Follow your curiosity by studying deeply, but step out of study mode to put it into practice, because it's by solving your own problem that you actually learn. And there's a line from Montano in there I wish I'd heard earlier: that insecurity about not knowing how to do things doesn't go away by watching one more course, it goes away by solving a real problem. As you solve things, experience comes, confidence comes, and at some point you bump into what fits you. Specialization isn't chosen at the start; it emerges in the middle.

In other words: if you're stuck on this doubt today, it's probably too early for it to have an answer, and the way to make it have an answer isn't to think more, it's to build something.

Akita has two episodes that hit this directly: Don't Outsource Your Decisions (2019) and What Should I Study? Will I Get a Job? (2018). The argument is uncomfortable and precise: when you ask an influencer what to study, you're outsourcing a decision about your own life to someone who knows neither your history nor your goals. Nobody can answer that for you, not him, not me.

There's a follow-up to that I only saw well put by Galego, in Starting Things Gives You the Framework to Think About Starting, which changed how I respond to this kind of message: advice only works after you've started. His argument is that real guidance depends on shared vocabulary, before you've put your hands on something, you don't have the frame of reference to receive the answer, even when it's the right one.

That's exactly why "give me some tips to get into the field" almost always produces a useless answer. It's not the responder's ill will: there just isn't enough common ground yet for the conversation to happen. And the practical consequence is kind of liberating: starting isn't the step after deciding, it's the step that enables deciding. Build the ugly little project, the half-finished tutorial, the ugly clone of something. After that, the same question you were going to ask turns into a specific question. And a specific question gets a good answer.

And if what you're feeling isn't doubt but being completely without direction, he has a whole piece just about that: If You Feel Lost as a Dev (Dec/2025).

If the doubt is more structural (college, which course, what the hell junior/mid/senior even means), #64 covers it better than I could. One line I took with me: seniority isn't about writing prettier code, it's about your decisions being trustworthy, and about you owning the burden of them.

a detail that saves you months: a similar field is not the same field

This is the mistake I see the most. Data scientist, ML engineer, data engineer, and BI analyst all get lumped into the same "data field" basket. They all touch Python, they all touch SQL, they all brush against machine learning at some point. Except the day-to-day is radically different:

Analyst/BI: business questions, dashboards, communicating with decision-makers.
Data scientist: statistics, experimentation, modeling, drawing conclusions from data.
Data engineer: pipelines, ETL, getting the data there clean and on time.
ML engineer: taking the model and putting it into production, API, architecture, scale, monitoring.

A course that promises "full training" usually skims all of these. That's great for figuring out which one you want, and terrible if you think you've already seen all of them. What's a two-hour module in an overview is someone's entire career axis in real life.

This is the classic case inside Sidia itself. My own role there is a developer role, not an internship, so I can't really speak precisely about the internship process, I never went through it; but in general, I believe the career fundamentals are similar. Sidia has many departments and each one demands something different. For internships, the most common opening is QA, with its own fundamentals (documentation, requirements, test types like smoke test, e2e, and regression testing, what a black, white, and grey box test is, and CFTL as a certification that's basically mandatory for anyone aiming at that field). For development, most open roles are junior or senior; mine was for a technician/trainee role, an opening that rarely gets posted externally. Development internships open up occasionally too, but they're much scarcer than QA ones, because there are way more testing departments than development ones. "Working at Sidia" sounds like one thing from outside, but internally these are entirely different tracks.

and when is it time to give up on something?

That's the other side of the coin and almost nobody talks about it. If experimenting is good, experimenting forever isn't: at some point you have to decide where to stop putting energy.

Montano cites, in the same video, a concept he took from Seth Godin's book The Dip: the skill of recognizing when you're in a dead end. A dead end is a situation where putting in more time and more effort won't get you a better result. It can be a project, a company, a study track. And he's honest about the hard part: pulling the plug and quitting is usually harder than setting the goal in the first place.

The practical distinction I use is this: is it hard because it's the boring part of the road, or is it hard because there's no road? In the first case, more effort solves it and quitting would be dumb. In the second, more effort just increases the loss. The pain of learning that Akita describes is the first kind; the dead end is the second. Mixing the two up is what makes people quit things that would've worked out and keep pushing on things that never would.

"and about college, what do I pick?"

This is the question that comes up the most from people in high school or thinking about switching fields, and the answer is the same as the whole post: it depends. Except here "it depends" actually has content, it's not a dodge: this choice determines your foundation more than any course, bootcamp, or certificate you'll take afterward. And a foundation is the most expensive thing to make up for later.

Lucas Montano answers this question in his 2025 year-end video, and I'll come back to his answer in a bit, because it's the opposite of mine, and we're both right. First, the map, roughly:

Computer Science: the heaviest on math and theory, calculus, linear algebra, probability and statistics, discrete math, theory of computation, algorithms, operating systems. It's the best foundation for AI/ML, research, systems, compilers, computer graphics, anything that demands mathematical grounding. It's also where the most people drop out, precisely because the first two years barely have any programming.
Software Engineering: focused on process, architecture, requirements, testing, quality, and system lifecycle. More directly aimed at the development market, less math depth.
Information Systems: the bridge between technology and business, programming and databases, but also management, process, and systems analysis. Good if you want product, applied data, or entrepreneurship. In exchange, it's the one that goes the least deep into math among the bachelor's degrees.
Computer Engineering: computing alongside electronics and hardware. If your interest is embedded systems, robotics, or IoT, that's the one.
Associate's degrees and other technologists: two to three years, applied focus, fast entry into the market. Excellent if you need to start working soon. The bill you pay later is the foundation, which you'll have to build on your own, from outside.

Two things to take from this:

The course's name matters less than its curriculum. Two colleges with the exact same course name can have wildly different curricula. Before deciding, pull up the curriculum and count how many math courses it has, and which ones. That tells you more about your future than the name on the diploma.
You can make up the foundation later, but it costs more. That's exactly why Akita insists the first two math-heavy years he did saved him years of self-teaching later, and why his advice in episodes #64 and #90 is "if you can, go to college," not for the diploma, but for the foundation no commercial course cares to sell.

My own case, since it's worth being concrete. I'm doing Information Systems, and at the time the choice made complete sense: what I wanted was to study offensive security on my own, on the side, and the course gave me a broad base and room for that. It was a good decision for the person I was at that moment.

Except the goal changed. I'm heading toward AI engineering now, and knowing what I know today, I would definitely have done Computer Science or Computer Engineering, precisely for the math foundation those two give you and that I'm now having to chase down on my own.

Now the counterpoint, which is the reason I brought up the video. Someone asked Montano what he'd do if he were 22 today, and he answered he'd do exactly the same thing: he did Information Systems and says today he'd pick an associate's degree instead, a curriculum that includes programming, systems analysis, and even entrepreneurship. Zero regrets.

Notice what just happened. Same question, same original degree, opposite answers. And neither of them is wrong: each of their goals is different. His career was built in applied software engineering, today he's a tech lead at Disney, on Disney+ Android, and on top of that he still builds product and ships SaaS. Neither of those two fronts will demand calculus and linear algebra day to day; they demand something else, architecture, product decisions, delivery, and business, and that's exactly what a curriculum like an Information Systems or associate's degree gives you early. I'm heading toward a place where the math is the job, and that's where the math flips.

If you wanted a demonstration that there's no silver bullet, here it is: two people answering the same question in opposite ways, both right, because the answer was never about the course, it was about where each of us wanted to end up.

And that's not regret, it's the whole point of this post. I had no way of knowing, at the time I was choosing, that I'd want this later. Nobody gets the future right: you decide well with the information you have in hand and adjust when it changes, which is literally the systematic trial-and-error cycle from #119 applied to a years-long decision instead of a weeks-long one. The real mistake would be pretending the gap doesn't exist and moving forward without filling it.

And if you're already in a course and hit the feeling that you picked wrong: relax, because there's no right one. There's the foundation X it gave you and the gap Y you'll have to fill on your own. Spotting that gap early is worth far more than switching courses, and how to fill the gap is the subject of the next section.

2. learning how to learn is the most important skill in your career

If I could pick just one thing from this whole post for you to take away, it would be this.

Frameworks change. Languages change. The stack that got you hired will be deprecated in five years. What doesn't get deprecated is your ability to absorb new things fast and well. And nobody teaches that, not college, not the courses you bought.

Here I have to send you straight to the source: the Definitive Guide to Learning How to Learn (2020) is, in my opinion, the best content in Portuguese on the subject. The thesis is harsh and it's this: learning how to learn is learning how to fend for yourself. No step-by-step, no teacher chewing it up for you, no pat on the back. It's diving into a problem you don't know how to solve and not giving up despite the frustration.

And there's the companion piece, The Pain of Learning (2019), which splits beginners into two groups: those who, when they hit a step that doesn't work, freeze waiting for someone to fix the procedure; and those who get annoyed and go figure out why it broke. The difference between the two isn't intelligence, it's attitude toward pain. That one hit me hard when I saw it.

His most counterintuitive practical advice, and one I tested and it works, is: before trying to build your own little project from scratch, copy a ton of other people's code. Open a GitHub repo on one side, your editor on the other, and type. No goal, no worrying about whether it's right. The idea is to build familiarity and start noticing patterns: how people better than you name things, structure functions, solve the same problem three different ways. The project's purpose shows up on its own afterward, once you already know what's possible.

On the more "academic" side, it's worth knowing what cognitive science research has consistently tested:

Active recall: closing the material and trying to reproduce it. It's by far the highest-return technique that exists.
Spaced repetition: reviewing at growing intervals instead of all at once.
Interleaving: mixing types of problems in the same session instead of doing thirty identical ones in a row.
Explaining it as if to someone else (Feynman): exposes gaps in understanding in seconds.
Deliberate practice: training specifically what you're bad at, not what you already know (which is what's fun).

That last point has a pair of episodes all to itself, Talent: Killing Demigods, part 1 and part 2 (2018). The argument is that "talent" tends to be the name we give to a massive volume of deliberate practice we didn't get to see happen. It's not motivational comfort: it's the difference between thinking you weren't born for it and understanding you simply haven't put in the hours yet.

And on the other side, what almost everyone does and gets little out of: rereading and highlighting. Both produce a strong sense of learning, fluency, without proportional learning. It's the most common trap for people who study by video: you understand everything while watching and can't reproduce any of it afterward.

While I'm at it: that whole "I'm a visual/auditory/kinesthetic learner" thing doesn't hold up under evidence. What changes isn't your style, it's the type of content. A mind map is better for network topology because the thing is spatial, not because you're a visual learner.

But, and this "but" is the reason for the post's title, all of these techniques are generalist by definition. They were tested against the average of everyone. Your reality has variables no study controlled for: how many hours you have, what time of day your brain actually works, whether you need a project to keep your interest or whether a project scatters you.

So: start from what's proven and adapt by testing it on yourself.

In my own case, I only really retain something when I turn the content into a very detailed visual, a diagram, a mind map, and copy it by hand into a physical notebook. In theory that's incredibly slow and inefficient. In practice, it's the difference between me remembering and me not remembering. I found that out by testing, not by reading about it.

A quick test I use to know if a session was worth it: if at the end I can't reproduce the main idea without looking, I didn't study, I watched.

the method behind all of this is trial and error (but systematic)

If you want the deep foundation for why there's no silver bullet, the episode is #119 — Learning at the Edge of Chaos (2022). It walks through determinism, chaos theory, Deming, Toyota, Six Sigma, and Agile to arrive at a simple, almost anticlimactic point: the only known way to solve an unknown problem is a trial-and-error cycle, plan, execute, measure, adjust, repeat. PDCA, Kaizen, Scrum sprints, and the scientific method are the same idea with different names.

Applied to studying, that means: stop trying to build the perfect two-year plan. Plan a week or two, execute, and at the end genuinely check whether you learned (active recall, a project, explaining it to someone). Did it go badly? Change one variable and run it again. The rule is don't make the same mistake twice, not don't make mistakes.

At this point Montano has a practice I found simple and too good to leave out. He and his wife write goals every year, and the rule he uses is: "don't set anything you don't control." In other words, the goal is about what depends on you, how many videos to post, how many kilometers to run, and not about the outcome, which depends on the world. Translated to studying: "get a junior role by June" is a bad goal, because half of it isn't yours. "Ship two end-to-end projects by June" is a good one, because it's 100% yours.

And he adds a second part I found even more useful: at the end of the year, the value of the exercise isn't checking off what you accomplished, it's looking at what you abandoned and asking why. Nine times out of ten the answer tells you more about what you actually want than the original list did.

There's a practical corollary in there worth gold, and I'll circle back to it below: if you don't know whether you'll like a ten-month course, don't buy ten months. Buy one month and test it. And if the platform only sells a closed package with no way out, that's already information about the platform.

the 20% trap

This point is Akita's and I think it's the most valuable of all for beginners: with about 20% of the knowledge you can already solve about 80% of the problems and ship something that works. The danger isn't the 20%, it's thinking the 20% is the whole thing. The last 20% of problems will demand exactly the 80% of foundation you skipped. (He also uses the same number the other way around: no course teaches you more than about 20% of any subject, the rest is on you.)

Translated to day-to-day: you finish an ML course, train a model, it gets 92% accuracy, and you think you've made it. Then the first real problem shows up, imbalanced data, leakage between train and test, a model that degrades in production, and you find out the missing 80% is exactly statistics, algebra, and engineering. There's no shortcut. And, as he hammers home in #65, algorithms and data structures come before design patterns, architecture, and whatever's trendy.

oh, and english

A point I almost forgot to include, and it's pure foundation: English. Everything that matters in tech comes out in English first, and depending on translated material means always arriving late: by the time there's a course, a book, and a tutorial in Portuguese, the thing has already become a commodity and is worth less in the market.

#32, How I Learned English and Understanding Patterns (2018) is about this and about pattern recognition, and the logic is the same as learning to program: you didn't learn Portuguese by memorizing grammar, you learned it through massive exposure and by not being embarrassed to get it wrong. English isn't a course you take, it's something you build into your routine.

Along the same foundational lines, #38 — Basic Knowledge for Beginners (2019) covers what almost no commercial course touches: processes, threads, memory, schedulers, containers. It's the kind of thing that lets you switch languages without suffering, and its absence is the real reason so many people get stuck when they switch stacks.

3. where should you study? what's the best platform?

Short answer: there's no best one. There's the one with the best cost-benefit for your moment, your budget, and your field.

I have to be honest about a partial disagreement here. Akita's position, in #65 and #83, is basically that it doesn't matter much: the difference between the well-known courses is marginal, they all teach the same linear way, and the course hands you a small slice of what you need, you hunt down the rest yourself.

I agree with the core of that. But I think the comparison still matters for a practical reason: you have finite money and time, and picking wrong costs you. The difference is that picking a platform is a logistics decision, not a learning one. Once you accept that the course is the small slice, that's when it's worth optimizing which small slice you buy.

Before paying for anything, answer two questions:

Do I already know which field I want? If not, go cheap and broad. If you do, invest in depth.
Do I need structure or depth? Structure is sequence, order, someone telling you what comes next. Depth is the subject down to the bone. Few platforms give you both.

And carry along the rule from #119: pay for the shortest period possible and test before you commit.

One thing I haven't seen almost anyone do in these comparisons that makes a big difference: every platform has an area where it's naturally strong, and that's not an accident, it has to do with who founded it and who produces content on it. So the right question isn't "which platform is the best," it's "which platform has gravity in the field I want."

Here's what I think of each one, based on what I've actually used.

Coursera is strong in AI/ML, data, cloud, and computing fundamentals, and there's a structural reason for that: it was co-founded in 2012 by Andrew Ng, adjunct professor of Computer Science at Stanford and founder of DeepLearning.AI. Practical result: the most recognized ML and deep learning tracks in the world are there, several with him as the instructor himself, some in direct partnership with Stanford Online, the Machine Learning Specialization, for instance, is DeepLearning.AI plus Stanford Online. If your field is AI/ML engineering, Coursera isn't just another option, it's the center of gravity for the field. Add to that the cloud and data tracks made by Google, AWS, and IBM, and the boring foundation nobody else sells, like algorithms and data structures taught by Stanford. Its weak spot is the web market stack: whatever front-end material it has tends to be academic or dated, and if you want React in 2026, that's not the place. The price in Brazil remains the biggest problem.

Udemy is strong in specific tools and niches, for the opposite structural reason: it's a marketplace, so the instructor or publisher sets the ceiling, not the platform. That's bad for consistency and great for niche, you can find a course on a specific library that no big platform covers. My best example is Maven Analytics' AI/ML track, which lives on Udemy: the NLP course is the last one in it, fourth or fifth in the sequence, and it's denser than a lot of what's on expensive platforms. You can get real depth there, but you get it because I chose well, not because it was Udemy. Its weak spot is sequence and curation, there's no "Udemy track," there's an instructor's track, and you have to know how to find it. The certificate carries zero signaling weight either.

Alura is strong in the Brazilian market stack and in getting started from zero: content produced in Portuguese aimed at what Brazilian companies actually use, with a defined track and suggested order. It's probably the best Portuguese-language entry point for applied front-end, back-end, and data. Its weak spot is the frontier and theoretical depth, for advanced ML or offensive security it's not the place.

Rocketseat is strong in the JavaScript/TypeScript axis: React, Node, React Native, that's its niche and it's good at it. Outside that axis, it barely exists. And to be honest, the real value there, in my view, is the pace and the community more than the content, which isn't a small thing, because a lot of people get stuck exactly for lack of pace. The price isn't low.

DIO is strong in exposure and weak in training: cheap or free, bootcamps carrying a company's stamp. The content is shallow on average in any field, and I don't recommend it as actual training. What it does well is being a showcase and a networking spot, and sometimes the bootcamp is a real door into a hiring process. Treat it as an opportunity channel, not as study.

There's also cybersecurity, more specifically offensive security. I could cite other specific niches here, but honestly the only one I actually studied and explored for real was this one. TryHackMe is the best entry point, guided, gamified, hands-on from day one. HackTheBox is the same field with way less hand-holding, great once you have a foundation, frustrating before that. Solyd Offensive Security and Desec Security are Brazilian pentest schools, content in Portuguese and grounded; if English is still a barrier for you, start here. And it's worth noticing a structural advantage almost no other field has: the default format there isn't a video lecture, it's a lab. You don't watch about hacking, you try to hack and fail until you get it. That solves, by design, the problem I mentioned in section 2 about consuming content and thinking you learned. The closest equivalent I know in another field is Kaggle for data, and it doesn't come close to being as well done.

YouTube and free content are strong in fundamentals and conceptual explanation. It depends entirely on who's producing it, but when it's good, it competes on equal footing with paid courses, and sometimes wins. In algorithms and data structures, Augusto Galego has plenty of good free material. In AI, two names I recommend without a second thought: Andrej Karpathy, who builds a neural network and a language model from scratch right in front of you, line by line; and Umar Jamil, an ML engineer who does exactly what almost nobody does for free, implements Transformer, LLaMA, Stable Diffusion, and similar things from scratch in PyTorch, explaining the math along the way and breaking down entire papers. For the math behind deep learning, Akita himself recommends 3Blue1Brown in #83. It's worth pausing on this, because it's the strongest argument in the whole section: in AI, a lot of the best material in the world is free and made by people working at the frontier of the field. If content were the bottleneck, nobody would have an excuse, the bottleneck is something else, and that's the subject of section 2. Its weak spot here is structure, zero: you need to show up with your own roadmap already built or you'll spend six months watching disconnected videos.

Official documentation is strong whenever the target is a specific tool, and it's massively underrated. The best spaCy course I ever took was the official one, free, written by the people who built the library. Before buying a course on tool X, check whether the team behind X hasn't already written one. Its weak spot: it teaches you the tool, not the field. PyTorch's documentation doesn't teach you ML.

And books and articles are strong in foundations and in the frontier, exactly where everything else is weak. I'd put it this way: a course gives you vocabulary, a book gives you a mental model, a paper shows you the frontier. If all you consume is video, you end up with vocabulary and think you have a mental model.

Summing up the section: a paid platform buys you structure and sequence, not knowledge. Knowledge is still produced by the hours you sit down and put in. No annual plan sells you that.

4. reading this in 2026: what aged and what didn't

This section is the most important in the post and the reason I wrote it instead of just sending links.

The material I cited above is from 2018 to 2022. In other words: it was written before ChatGPT existed for the public, before the tech layoff wave from 2022 onward, and in a world where remote work was still the exception. Reading it in 2026 without adjusting for context is as wrong as ignoring it.

the most glaring case: AI

In August 2020, #83 answered the question "will GPT-3 replace programmers?" The short answer: no; AI generating better AI was science fiction decades away; real deep learning was expensive and closed off, so you wouldn't build a career on it, at most you'd consume other people's API.

Six years later, that specific prediction didn't hold up. Language models went from "generate a blue HTML button" to a tool that refactors entire modules and became routine work at most teams. Open-weight models showed up, so not everything is a black box owned by three companies. And "AI/ML Engineering" became a real career, with openings, salaries, and a track, it's literally the field I'm following, which makes me a walking counterexample to that paragraph.

But, and this is what matters, the argument underneath the prediction aged far better than the prediction itself. What he was actually saying is that what makes you obsolete isn't the tool, it's your inability to learn on your own. That got more true, not less.

Put that together with the supply-and-demand law he lays out in #90 (2021): anything that becomes too easy stops being worth as much, because anyone can do it. And sure enough: AI brutally lowered the cost of producing code that runs. If anyone can produce code that runs, producing code that runs stops being the differentiator. What became scarce is judgment: knowing whether something is correct, whether it's secure, whether it'll be maintainable six months from now, and above all whether the problem you solved was the right problem.

And I'm not the only one saying this. In the 2025 year-end video, Montano answers a recent Computer Science graduate and gets straight to the point: foundation matters more now, not less. His argument is concrete, what you'll need to spot in whatever AI produces isn't a technology choice, it's protocol choice, architecture decisions, security and cryptography problems. Things that slip by if you don't have study behind you, and that also improve how you talk to the model.

And he speaks from the position of someone who uses it: his SaaS is, in his own words, 100% vibe-coded, an AI wrote the code. Even so, the conclusion is that different devs get different results from the same model, and that's exactly the differentiator going forward. In other words: the tool leveled the access, not the people.

what that changes about your portfolio (in practice)

In 2020, the honest portfolio was "I did everything by hand." By 2026 that's changed shape:

Most companies already assume you use AI. Hiding that you did is more suspicious than admitting it.
Several actually want to see how you use it: what you asked for, what you accepted, what you rejected, how you ensured quality, and how you reviewed what came out.
Some hiring processes explicitly ask for a project built with AI somewhere in it, because what they're measuring is your ability to steer the tool without becoming a passenger in it.

So the advice updates: don't hide it, document it. In the README, tell the story: where the AI sped you up, where it got things wrong, where you disagreed and why. A project where you show you understood every decision is worth more than a "pure" project that's poorly explained. And to be blunt: if you can't defend a single line of your own repo in an interview, the problem isn't the AI, it's that the project isn't yours.

the 20% trap, just faster now

That point from the previous section got worse. Before, you needed a whole course to reach the feeling of "I already know how to do this." Now you get to that feeling in a single prompt. The illusion of competence became instant and much more convincing.

The fix is the same as always, just more urgent: can you rebuild it without help? Can you explain every decision? If not, you have an output, not a skill. And, funny enough, this makes Akita's more "old-fashioned" advice, boring foundations, algorithms, data structures, math, more valuable than it was in 2019, because it's exactly what lets you review what the machine spat out.

other things that changed

Low-code became a different thing under the same name. In #83 the comparison was with instant noodles: operating a tool isn't cooking. The analogy still holds, but the tool's ceiling rose a lot. The line between "tool operator" and "programmer" moved, so it's worth periodically reassessing which side you're actually on, and not assuming you're on the good side just because you type code. Montano describes this shift well: tools like Lovable, Replit, and v0 basically ran over the low-code/no-code market, and yes, you can build genuinely complex things with them knowing little programming. The caveat he raises is what matters: the more complex and abstract what you delegate is, the bigger the mistake you might be creating without seeing it, including security vulnerabilities.
The market. #72 — Programming Is Not Easy (Feb/2020) and #76 were written warning the bubble would pop and the market would separate wheat from chaff. A lot of that did happen. The junior entry door today is narrower than it was when those pieces came out, and part of the explanation is that entry-level tasks are exactly what AI absorbed first. Building a foundation stopped being a "good investment" and became a requirement. On the current bubble, Montano's take from Dec/2025 strikes me as the most balanced: there is a bubble, yes, but in the valuations and accounting of big tech, he gives the example of GPUs, bought with one depreciation expectation and booked on the balance sheet with a much longer one. What he doesn't believe in is a bubble in the sense of "it pops and nobody uses it anymore." His prediction is that AI will stop being seen as AI and become an invisible tool, the same way nobody thinks of Google as "a search engine" anymore.
Remote work. In 2020 he argued that working from home hurts beginners, because juniors need to be near experienced people. The principle still holds, but today remote and hybrid are the norm, and you can't use that as an argument to pick in-office work at any cost anymore. What changes is that now you have to build that closeness on purpose: ask for code review, push for pair programming, ask in a public channel instead of suffering alone in private.
Certificates. He dismisses the paper and he's right on the merits. Except today the first filter on a lot of job openings is automated, and certificates and keywords have a function in that filter, which isn't the same thing as having a function in your actual training. Those are two different conversations, and it's worth not mixing them up.

the general rule for reading any of this

Content about method, how to learn, how to think, how to organize yourself, ages slowly, sometimes over decades. Content about market and tools ages in months. Whenever you open any career post, mine included, check the date first and classify it: is this method or is this circumstance? The answer changes how much you should trust it.

5. a certificate is not competence

This is the other question that comes up the most: what actually makes a difference to get called for an interview, whether for an internship or a full-time role?

In my own case, the answer is full of "I don't know" and "I think." At the screening stage, I think it was because I already had almost everything the role asked for on my résumé. Afterward, from what I was told, I was the favorite among candidates from the start because I had the most hands-on experience and showed the most technical depth, that's what I was told, everything past that is pure guesswork. What I think sealed the deal was the technical test: it had a few "extra" requirements on top of the standard ones, and I nailed all of them, with a technical defense that left no gaps afterward. A colleague who evaluated my test mentioned that other candidates left a lot of things "to do," so maybe just having something finished, even imperfect, already counts for something. And in the technical interview specifically, they asked a lot about the details of the projects I had on my own résumé. But that's just what I think about the specific role I got, in the specific department I got into; it can vary in infinite ways in a different process, a different department, a different company. Notice the shape of this whole answer: it's the same disclaimer from the start of this post, applied to myself.

Without going into detail about the test itself, for obvious ethical reasons, the whole process is considered hard by people who go through it. For me, it wasn't. There was anxiety, sure, but the test itself wasn't hard. And the reason is simple: from the day I decided I was going after that role, I'd been studying almost obsessively. I don't recommend doing the same, the pace I kept isn't healthy at all and I know it. But the point that remains is a different one: the level of preparation that matters isn't the one that makes the test feel easy, it's the one that takes the fear out of the test. Hard or easy is relative to the person; fear is what freezes you.

My own take, minus the guesswork, is that what actually carries weight is your résumé showing experience at least somewhat similar to what the role asks for, or at least something that indicates you're competent in that subject. And "experience" here is broader than most people think: a personal project counts, an extension project counts, freelance work counts, formal employment counts, and, in the case of a research and development institute like Sidia, undergraduate research counts too, depending on the department. Anything is valid, as long as it's demonstrable.

A certificate on its own says nothing about what you can actually build. It says you watched. Akita is harsher than me on this point, he mentions in #76 that he studied, passed a well-known certification exam, and threw the paper in a drawer, because it was only after years of practice that he considered himself actually competent in it.

That doesn't mean a certificate is useless, and here I think 2026's context calls for a caveat: it solves a specific, real problem, getting past an automated filter and signaling direction. I'm working through a certification track myself. Just don't confuse the sign for the road.

Because of that, the most profitable thing you can do with any course is this: after every module, redo it with data or a problem you picked yourself. IBGE, dados.gov.br, Kaggle, some API you actually use. In the end, two or three end-to-end projects are worth more than a fifty-module certificate, and unlike the certificate, you can actually talk about them for thirty minutes in an interview without freezing up.

An end-to-end project, to me, is: real data (preferably messy), a decision you made along the way, a result you can show, and something written about it somewhere, a decent README, a post, LinkedIn, whatever.

And if you're stuck on "but I don't have a good idea": stop looking for one. Someone asked Montano exactly that and his answer was to just build something, he tells the story of how none of his friends believed in his SaaS, and some kept questioning the product even after it was already making money. The definition of a good idea he uses is brutally simple: a good idea is one someone pays for. Until you build it, you have no way of knowing which of your ideas that is, which, again, is the same argument from Galego back in section 1, and from Akita when he tells you to write code with no purpose and throw it away. Three different people, the same advice: start.

the 10x developer myth (and why it matters more now)

There's a cousin of this certificate discussion, which is the obsession with individual productivity. In the second half of that same video, Montano takes apart a list of "10x dev" traits that went viral on Twitter, things like hating meetings, having no fixed schedule, staying up all night, knowing every line they've shipped by heart, and using a dark theme in the IDE. He disagrees with almost all of it, for good reasons.

The first is simple: 10x is a figurative number. There's no way to actually measure it, because productivity depends too much on context.

The second is what matters. He says that across his whole career, the few times he actually ran into someone who produced way above average, that person tended to become the product's bottleneck. They wrote code fast and stalled the project, because they didn't communicate, they closed themselves off, and in doing so shrank their own feedback loop. The result is the worst of both worlds: producing fast, with quality, the wrong thing. That's not productivity, it's waste at high speed. Netflix has a name for this profile, they say they don't tolerate "brilliant jerks," because the cost of having one on a team outweighs the gain.

He does acknowledge one case where absurd productivity is real: domain knowledge. A dev who spent ten years building an electronic invoicing system in Brazil is going to be way faster than average in that domain, because the business knowledge is fused with the code knowledge, they know the libraries, the rules, the formulas by heart. It's a strong argument for staying somewhere long enough to learn the business, not just the stack. But even that doesn't guarantee the product works out.

The conclusion he draws is the part I hold onto the most: the real multiplier isn't you producing ten times more, it's you making other people more productive. Automating testing, builds, manual tasks, including in areas that aren't tech. Sharing knowledge instead of hoarding it. Knowing how to prioritize. Setting the ego aside and quickly admitting when you're wrong in a technical discussion, something he says he sees rarely, especially in senior people.

And why this matters more now: AI is being sold as exactly the promise of individual 10x. It does deliver something close to that on the part of writing code, which, as should be clear by now, is the part that least determines whether a project succeeds.

6. wrapping up: what I'd do if I started today

Try several fields with small projects before choosing, and accept that maybe you won't choose yet.
Invest in learning how to learn before investing in a platform. It's the only kind of study that compounds.
Build boring fundamentals (algorithms, data structures, statistics, English) while everyone else chases the hype. In 2026 this pays off more, not less.
Use AI without hiding it and without becoming a passenger: if you can't explain it, it's not yours.
Pick a platform for your own moment and budget, pay for the shortest period possible, and test before committing.
Turn consumption into output. Always. If it didn't become a project, it didn't become a skill, and insecurity doesn't go away by watching one more course, it goes away by solving a real problem.
Measure your worth by how much you unblock other people, not by how much you produce alone.
Check the date on everything you read about career. Method ages slowly, market ages fast.
Be suspicious of anyone handing you a ready-made recipe, including me.

There's a nice irony in ending this way. Akita, the biggest reference in this piece, would tell you not to ask me these things, and he'd be right. The difference between asking for perspective and asking for orders is everything. This post is perspective: it's here to give you more context when you decide, not to decide for you.

If a silver bullet existed, I wouldn't be at the start of my own road, chasing specialization like everyone else. What exists is method, context, and consistency. It's less sexy and it works a lot better.

And if there's such a thing as luck in this story, it's this: luck is being prepared for the opportunity when it shows up, and it always shows up at some point. Nobody controls when the opportunity knocks. What you can control is whether, when it does, you have something built to show for it.

If you have any question about the ML, DL, and LLM side of things, feel free to reach out and I'll help however I can. On the rest, I'll probably point you to someone better, and that's part of it too.

p.s. — the question I left out on purpose

You probably noticed that, in an entire post about a career in tech, I never answered the most commonly asked question of all. That was on purpose.

If you made it this far and you're still thinking "okay, but at the end of the day, which language should I pick to have better odds in the market?", then go back to line one and read it all again, because you didn't get anything I was trying to say.

And I'm saying that without any irony. This is the purest form of asking for a silver bullet that exists: it assumes there's a single, external answer, the same for everyone, that doesn't depend on who you are or where you want to go. Except the stack that pays best today might not pay in three years, and it'll take you more than three years to get good at it. The stack with the most openings is, by definition, the one with the most people competing for it. And neither one answers the only question that actually matters here, which is whether you can stand a thousand hours doing that thing.

Choosing a language is the lowest-consequence decision in this entire post. You'll switch languages several times in your life. What doesn't get replaced easily is a foundation, a study method, and the ability to fend for yourself, and that's what I talked about the whole time, precisely so I wouldn't have to talk about stacks.

So pick any one. Seriously. Pick the one your friend uses, the one from the video you liked, the one that showed up in the job posting you saw yesterday. Build a project start to finish with it. The answer you're looking for doesn't come from outside, it shows up after the third or fourth thing you build.

One last disclaimer, since AI came up a lot in this post: leaning too heavily on AI for your personal project, the same project that's supposed to be where you build the foundation with your own hands, might not be so great in the medium and long term. I'm still working out exactly where that line sits, and the topic deserves a whole post of its own, not a loose paragraph tacked on here at the end. That's for next time.

references

Dates matter here, keep them in mind.

Fabio Akita

Everything's available in video and text on his blog.

Method (ages slowly, read all of it):

#119 — Learning at the Edge of Chaos (2022): why there's no formula for success, and why systematic trial and error is the only method that works.
#76 — Definitive Guide to Learning How to Learn (2020): if you only read one, read this one.
#65 — The Pain of Learning | Which Courses/Books? (2019): practical study method and why foundation comes before patterns.
#63 — Don't Outsource Your Decisions (2019): the reason this post can't decide for you.
#26 and #27 — Talent: Killing Demigods (2018): deliberate practice, and why talent is less magic than it looks.

Foundation (same as above):

#38 — Basic Knowledge for Beginners (2019).
#32 — How I Learned English and Understanding Patterns (2018).

Career and market (read alongside section 4 of this post):

#90 — What Courses Don't Teach You About Markets (2021): supply and demand applied to your career.
#64 — Starting Out in an IT Career (2019): college and what actually separates junior, mid, and senior.
#29 — What Should I Study? Will I Get a Job? (2018).
#83 — Which Courses Do You Recommend? What About Low-Code? What About GPT-3? (2020): great on courses, and the clearest example of why dates matter.
#72 — Programming Is Not Easy (2020): written right at the turn of the cycle; read it as a snapshot of an era that mostly held up.

Augusto Galego

Much more recent material, which makes him a good counterpoint in time to the one above.

Starting Things Gives You the Framework to Think About Starting (2025): why advice only works after you've started, and why guidance depends on shared vocabulary.
If You Feel Lost as a Dev (Dec/2025): for when the feeling is having no direction at all.
His algorithms and data structures course, which is helping me more than a lot of things I've paid for, plus, beyond that, a good amount of free content on the same subject.

Lucas Montano

Tech lead at Disney (Disney+ Android), lives abroad and runs his own product on the side, worth knowing where he's speaking from when he answers career questions.

Specialist vs. Generalist + the 10x dev myth: two great halves, in the first he compiles answers from several engineers to the same question (including Filipe Deschamps) and shows how they diverge; in the second, he takes apart the viral "10x dev" trait list. Worth it for the method as much as the content.
2025 year-end Q&A (Dec/2025): the most recent and the densest, foundation in the AI era, which degree he'd pick today, vibe coding and its limits, the bubble, how to set goals, and the concept of the dead end. It's the most-cited video in this post after Akita's #76.

Toda semana chega alguém no meu direct com alguma variação da mesma pergunta:

"Já fiz um curso e quero migrar pra essa área, o que eu faço agora?" "Vale mais a pena investir numa plataforma paga ou dá pra aprender só com conteúdo gratuito?" "O que pesa de verdade quando alguém decide te chamar pra uma entrevista?"

E toda semana eu respondo com uma mensagem gigante ali mesmo na DM, que dois dias depois já tá perdida lá embaixo na conversa. Então esse post é a resposta. Se você chegou aqui porque eu te mandei o link, era exatamente isso que eu ia digitar, só que melhor organizado e sem os erros de digitação.

Aviso desde já: se você veio procurar receita pronta, você vai sair frustrado. Não porque eu não quero dar, mas porque ela não existe.

o disclaimer que quase ninguém dá

Antes de qualquer coisa, quatro coisas que você precisa saber sobre quem tá escrevendo:

Eu não sou sênior e não sou referência. Eu tô no começo do caminho de me especializar de verdade na área que escolhi seguir. O que eu tenho é experiência de quem experimentou bastante coisa em pouco tempo e tomou muita decisão errada pelo caminho, o que serve pra te poupar algumas, não pra te dar um mapa.
Minha realidade tem privilégios que a sua pode não ter. Minha Udemy é liberada pela Sidia. Minha Coursera é paga pelo meu departamento, o SITA. Se eu te falar "faz essa especialização da Coursera" e omitir isso, eu tô te dando um conselho que pra mim é gratuito e pra você custa um salário. Isso muda tudo na hora de avaliar custo-benefício.
Boa parte do que tá aqui eu não inventei. Aprendi na prática, tomando na cara, e assistindo gente que já tinha tomado antes, principalmente três referências que vão aparecer o post inteiro: Fabio Akita, Augusto Galego e Lucas Montano.

O Akita é a base: cujo canal e blog moldaram muito do que eu penso sobre estudo e carreira. Vou linkar os episódios dele ao longo do texto, porque em vários pontos o melhor que eu posso fazer é te mandar pra fonte. Inclusive o título desse post é praticamente uma citação: num dos episódios ele avisa pra você nunca acreditar numa resposta mágica única, uma bala de prata. Pois é.

O Galego é CTO numa startup americana e fala sobre algoritmos, estrutura de dados e carreira internacional, principalmente no canal dele no YouTube (o blog existe, mas é o canal que é o meio principal). Ele entra por um motivo a mais: o material dele é de 2025 pra cá, ou seja, escrito já dentro do mundo que a seção 4 descreve. E o Montano é tech lead na Disney, trabalhando hoje no Disney+ Android, e também toca produto e SaaS por fora; ele aparece bastante na seção 1, respondendo perguntas de carreira ao vivo com dezenas de outros engenheiros. Dá pra ler os três em paralelo e sentir na prática o que muda e o que não muda com o tempo. Tem outras referências pontuais ao longo do texto, e todas estão listadas no final.

Olha a data de tudo, inclusive deste post. O material que eu vou linkar é de 2018 a 2022. É excelente e continua valendo, mas parte dele foi escrito num mundo sem ChatGPT, antes da onda de demissões em tech e antes de remoto ser padrão. Tem uma seção inteira mais pra baixo só sobre o que envelheceu e o que não. Leia com a data na mão. Esse post aqui também vai envelhecer.

Guarda isso, porque é o fio condutor do post inteiro: contexto muda a resposta. Sempre.

1. descubra o que você quer (ou não)

Existe uma pressão esquisita em tech de escolher a área logo no começo, como se escolher errado fosse condenar os próximos dez anos. Não é bem assim.

O problema é que ninguém descobre que gosta de alguma coisa lendo sobre ela. Você pode ler cinquenta threads sobre engenharia de dados e não fazer ideia se você aguenta a rotina real de engenharia de dados. A única forma de descobrir é fazendo, e fazendo pequeno.

Uma receita que funciona bem: escolhe quatro ou cinco áreas que te chamam atenção (front, back, dados, segurança, infra, mobile, ML, o que for), e faz um projeto pequeno e completo em cada uma. Duas semanas cada, nada ambicioso. O objetivo não é ficar bom, é sentir a textura do trabalho. O que te dá tesão e o que te dá sono.

E aqui vai a parte que quase ninguém fala: é totalmente válido não concluir nada. Se depois de experimentar você continuar sem certeza, você não falhou no exercício. Continuar generalista é uma posição legítima, e no mercado brasileiro é frequentemente a posição mais contratável: time pequeno, um dev que resolve várias frentes vale ouro. A especialização vem quando fizer sentido, não quando a internet mandar.

Se é exatamente essa dúvida que tá te travando, especialista ou generalista, o Montano fez alguns vídeos sobre isso. O formato é quase mais instrutivo que o conteúdo: em vez de dar a resposta dele, ele levou a mesma pergunta pra alguns convidados, entre amigos, palestrantes, criadores de conteúdo e gestores de times grandes. Vale ver as respostas lado a lado.

O Filipe Deschamps responde que depende de duas variáveis, sempre as mesmas: a pessoa e o contexto em que ela está. E que no começo tende a ser mais fácil navegar por vários temas, justamente pra descobrir do que você gosta: a analogia dele é a criança que entra no colégio, ela não entra especialista, ela vê um monte de matéria e só depois escolhe. Se for pra dar uma resposta seca: comece generalista, inclusive porque isso abre mais portas.

Outro dev convidado puxa pro lado oposto: nem só um nem só outro, mas você precisa ser no mínimo especialista em alguma coisa, se você é generalista, você vai pegar emprego de generalista. Só que a parte generalista, pra ele, não é saber cinco linguagens e fazer web, mobile e servidor ao mesmo tempo, porque isso pulveriza teu tempo e você não vira bom em nada. A parte generalista é o que está em volta do código: processo de desenvolvimento, o que faz um software ser confiável, o que faz ele ser fácil de manter, e as ferramentas do time. Ele também acha que júnior deveria focar em soft skills antes de qualquer coisa: responsabilidade, pontualidade, comunicação, se importar com o problema da empresa.

E o Montano fecha com a pergunta que resume tudo: por que você escolheria uma área logo de cara se nunca experimentou nenhuma outra? A resposta honesta dele, depois de ouvir todo mundo, é que depende de caso a caso, e ele reconhece na hora que "depende" soa como não-resposta. Só que é verdade, e ele emenda com o que fazer a respeito.

Repara que os três discordam no acento e convergem no mesmo conselho prático: fazer um projeto do início ao fim, o mais simples que for. Seguir a curiosidade estudando fundo, mas sair da zona de estudo pra colocar em prática, porque é resolvendo problema seu que você aprende de verdade. E tem uma frase do Montano ali que eu queria ter ouvido antes: aquela insegurança de não saber fazer as coisas não some lendo mais um curso, ela some resolvendo problema real. Conforme você resolve, vem experiência, vem confiança, e em algum momento você esbarra no que combina com você. A especialização não é escolhida no começo; ela emerge no meio.

Ou seja: se você tá travado nessa dúvida hoje, provavelmente é cedo demais pra ela ter resposta, e o jeito de fazer ela ter resposta não é pensar mais, é construir alguma coisa.

O Akita tem dois episódios que batem direto nisso: Não Terceirize suas Decisões (2019) e O que eu Devo Estudar? Vou Conseguir Emprego? (2018). O argumento é desconfortável e certeiro: quando você pergunta pra um influencer o que estudar, você tá terceirizando uma decisão da sua vida pra alguém que não conhece nem a sua história nem os seus objetivos. Ninguém pode responder isso por você, nem ele, nem eu.

Só que tem um complemento a isso que eu só vi bem formulado no Galego, em Começar Te Dá o Framework Para Pensar em Como Começar, e que mudou a forma como eu respondo esse tipo de mensagem: conselho só funciona depois que você começou. O argumento é que orientação de verdade depende de vocabulário compartilhado, antes de ter posto a mão em alguma coisa, você não tem repertório pra receber a resposta, mesmo quando ela é a resposta certa.

É exatamente por isso que "me dá umas dicas pra entrar na área" quase sempre gera resposta inútil. Não é má vontade de quem responde: é que ainda não existe base comum pra conversa acontecer. E a consequência prática é meio libertadora: começar não é o passo depois de decidir, é o passo que permite decidir. Faz o projetinho porco, o tutorial mal-acabado, o clone feio de alguma coisa. Depois disso, a mesma pergunta que você ia fazer vira uma pergunta específica. E pergunta específica tem resposta boa.

E se a sensação não for dúvida e sim estar completamente sem direção, ele tem um texto só sobre isso: Se você se sente perdido como dev (dez/2025).

Se a dúvida é mais estrutural (faculdade, qual curso, o que diabos é júnior/pleno/sênior), o #64 cobre isso melhor do que eu conseguiria. Um recorte que eu levei comigo: senioridade não é sobre escrever código mais bonito, é sobre as suas decisões serem confiáveis, e sobre você assumir o ônus delas.

um detalhe que economiza meses: área parecida não é a mesma área

Esse é o erro que eu mais vejo. Cientista de dados, engenheiro de ML, engenheiro de dados e analista de BI aparecem no mesmo balaio de "área de dados". Todas mexem com Python, todas mexem com SQL, todas encostam em machine learning em algum momento. Só que o dia a dia é radicalmente diferente:

Analista/BI: pergunta de negócio, dashboard, comunicação com quem decide.
Cientista de dados: estatística, experimentação, modelagem, tirar conclusão do dado.
Engenheiro de dados: pipeline, ETL, o dado chegando limpo e no horário.
Engenheiro de ML: pegar o modelo e botar em produção, API, arquitetura, escala, monitoramento.

Um curso que promete "formação completa" costuma passar por todas essas de raspão. Isso é ótimo pra você descobrir qual delas quer, e péssimo se você achar que já viu todas. O que num panorama é um módulo de duas horas, na vida real de alguém é o eixo principal da carreira.

É o caso clássico dentro do próprio Sidia. Minha vaga lá é de desenvolvedor, não de estágio, então eu nem tenho como falar com precisão sobre o processo de estágio, nunca passei por ele; mas no geral, acredito que os fundamentos de carreira são parecidos. O Sidia tem muitos departamentos e cada um cobra coisa diferente. Pra estágio, o mais comum é vaga de QA, com fundamentos próprios (documentação, requisitos, tipos de teste como smoke test, e2e e teste de regressão, o que é um teste black, white e grey box, e a CFTL como certificação praticamente mandatória pra quem mira essa área). Pra desenvolvimento, a maioria das vagas que abrem é júnior ou sênior; a minha foi pra técnico/trainee, uma vaga que raramente abre externamente. De vez em quando também abre estágio em desenvolvimento, só que é bem mais escasso do que em QA, porque existem muito mais departamentos de teste do que de desenvolvimento. "Trabalhar no Sidia" soa como uma coisa só de fora, mas por dentro são trilhas inteiramente diferentes.

e quando é hora de desistir de alguma coisa?

Essa é o outro lado da moeda e quase ninguém fala dela. Se experimentar é bom, experimentar pra sempre não é: em algum momento você tem que decidir onde parar de colocar energia.

O Montano cita, no mesmo vídeo, o conceito que ele tirou do livro The Dip, do Seth Godin: a habilidade de identificar quando você está num beco sem saída. Beco sem saída é a situação em que colocar mais tempo e mais esforço não vai te levar a um resultado melhor. Pode ser um projeto, uma empresa, uma vertical de estudo. E ele é honesto sobre a parte difícil: bater o martelo e abandonar costuma ser mais difícil do que definir a meta.

A distinção prática que eu uso é essa: está difícil porque é a parte chata do caminho, ou está difícil porque não tem caminho? No primeiro caso, mais esforço resolve e desistir seria burrice. No segundo, mais esforço só aumenta o prejuízo. A dor de aprender que o Akita descreve é a primeira; o beco sem saída é a segunda. Confundir as duas é o que faz gente desistir do que ia dar certo e insistir no que nunca ia.

"e sobre a faculdade, o que eu escolho?"

Essa é a pergunta que mais chega de quem tá no ensino médio ou pensando em migrar de área, e a resposta é a mesma do post inteiro: depende. Só que aqui "depende" tem conteúdo, não é fuga: essa escolha determina a sua base mais do que qualquer curso, bootcamp ou certificado que você vá fazer depois. E base é a coisa mais cara de recuperar.

O Lucas Montano responde essa pergunta no vídeo de encerramento de 2025 dele, e eu volto na resposta dele daqui a pouco, porque ela é o oposto da minha, e as duas estão certas. Antes, o mapa, grosso modo:

Ciência da Computação: o mais pesado em matemática e teoria, cálculo, álgebra linear, probabilidade e estatística, matemática discreta, teoria da computação, algoritmos, sistemas operacionais. É a melhor base pra IA/ML, pesquisa, sistemas, compiladores, computação gráfica, qualquer coisa que exija fundamento matemático. Também é onde mais gente desiste, justamente porque os dois primeiros anos quase não têm programação.
Engenharia de Software: foco em processo, arquitetura, requisitos, teste, qualidade e ciclo de vida de sistema. Mais direto pro mercado de desenvolvimento, menos fundo em matemática.
Sistemas de Informação: a ponte entre tecnologia e negócio, programação e banco de dados, mas também gestão, processo e análise de sistemas. Bom pra quem quer produto, dados aplicados ou empreender. Em compensação, é o que menos aprofunda matemática entre os bacharelados.
Engenharia da Computação: computação junto com eletrônica e hardware. Se o teu interesse é embarcado, robótica ou IoT, é ali.
ADS e outros tecnólogos: dois a três anos, foco aplicado, entrada rápida no mercado. Excelente pra quem precisa trabalhar logo. A conta a pagar é o fundamento, que vai ter que vir depois e por fora.

Duas coisas pra levar disso:

O nome do curso importa menos que a grade. Duas faculdades com o mesmo nome de curso podem ter grades absurdamente diferentes. Antes de decidir, baixa a grade curricular e conta quantas disciplinas de matemática tem, e quais. Isso te diz mais sobre o teu futuro do que o nome no diploma.
Dá pra compensar a base depois, mas sai mais caro. É exatamente por isso que o Akita insiste que os dois primeiros anos de matemática que ele fez economizaram anos de autodidatismo depois, e por isso o conselho dele nos episódios #64 e #90 é "se puder, faça faculdade", não pelo canudo, mas pela fundação que curso comercial nenhum se interessa em vender.

O meu caso, já que é pra ser concreto. Eu faço Sistemas de Informação, e na época a escolha fez todo sentido: o que eu queria era estudar segurança ofensiva por fora, por conta própria, e o curso me dava base ampla e espaço pra isso. Foi uma boa decisão pro cara que eu era naquele momento.

Só que o objetivo mudou. Hoje eu tô indo pra AI engineering e, sabendo o que eu sei agora, com certeza teria feito Ciência da Computação ou Engenharia da Computação, exatamente pela base matemática que esses dois dão e que eu tô tendo que correr atrás por fora.

Agora o contraponto, que é o motivo de eu ter trazido o vídeo. Perguntaram pro Montano o que ele faria se tivesse 22 anos hoje, e ele respondeu que faria exatamente a mesma coisa: ele fez Sistemas de Informação e diz que hoje escolheria ADS, currículo onde entra programação, análise de sistemas e até empreendedorismo. Zero arrependimento.

Repara no que acabou de acontecer. Mesma pergunta, mesmo curso de origem, respostas opostas. E nenhum dos dois está errado: o objetivo de cada um é diferente. A carreira dele foi construída em engenharia de software aplicada, hoje ele é tech lead na Disney, no Disney+ Android, e em cima disso ele ainda cria produto e lança SaaS. Nenhuma dessas duas frentes vai te cobrar cálculo e álgebra linear no dia a dia; elas cobram outra coisa, que é arquitetura, decisão de produto, entrega e negócio, e é exatamente isso que um currículo tipo SI/ADS te dá cedo. Eu tô indo pra um lugar onde a matemática é o trabalho, e aí a conta inverte.

Se você queria uma demonstração de que não existe bala de prata, é essa: duas pessoas respondendo a mesma pergunta de forma contrária e as duas com razão, porque a resposta nunca foi sobre o curso, foi sobre onde cada um queria chegar.

E isso não é arrependimento, é o ponto do post inteiro. Eu não tinha como saber, na hora de escolher, que eu ia querer isso depois. Ninguém acerta o futuro: você decide bem com a informação que tem na mão e ajusta quando ela muda, que é literalmente o ciclo de tentativa e erro sistemático do #119 aplicado a uma decisão de anos em vez de uma de semanas. O erro de verdade seria fingir que o buraco não existe e seguir em frente sem preencher.

E se você já tá dentro de um curso e bateu a sensação de que escolheu o errado: relaxa, porque não existe o certo. Existe a base X que ele te deu e o buraco Y que você vai ter que preencher sozinho. Identificar esse buraco cedo vale muito mais do que trocar de curso, e como preencher buraco é assunto da próxima seção.

2. aprender a aprender é o skill mais importante da tua carreira

Se eu pudesse escolher uma coisa só desse post pra você levar, seria essa.

Framework troca. Linguagem troca. A stack que te contratou vai estar depreciada em cinco anos. O que não deprecia é a tua capacidade de absorver coisa nova rápido e bem. E ninguém ensina isso, nem a faculdade, nem os cursos que você comprou.

Aqui eu preciso mandar você direto pra fonte: o Guia Definitivo de Aprendendo a Aprender (2020) é, na minha opinião, o melhor conteúdo em português sobre o assunto. A tese é dura e é essa: aprender a aprender é aprender a se virar. Sem passo a passo, sem professor mastigando, sem tapinha nas costas. É mergulhar num problema que você não sabe resolver e não desistir apesar da frustração.

E tem o complemento, A Dor de Aprender (2019), que separa os iniciantes em dois grupos: quem, ao topar com um passo que não funciona, trava esperando alguém consertar o procedimento; e quem fica com raiva e vai atrás de entender por que quebrou. A diferença entre os dois não é inteligência, é atitude diante da dor. Isso me acertou em cheio quando eu vi.

O conselho prático mais contraintuitivo dele, e que eu testei e funciona, é: antes de tentar fazer seu projetinho do zero, copie muito código dos outros. Abre um repositório do GitHub de um lado, o editor do outro, e digita. Sem objetivo, sem se preocupar se tá certo. A ideia é ganhar familiaridade e começar a enxergar padrões: como gente melhor que você nomeia coisas, estrutura funções, resolve o mesmo problema de três jeitos. O objetivo do projeto aparece sozinho depois, quando você já sabe o que é possível fazer.

Do lado mais "acadêmico", vale conhecer o que a pesquisa em ciência cognitiva já testou de forma consistente:

Teste ativo (active recall): fechar o material e tentar reproduzir. É a técnica de maior retorno que existe, disparado.
Repetição espaçada: revisar em intervalos crescentes em vez de tudo de uma vez.
Intercalação: misturar tipos de problema numa mesma sessão em vez de fazer trinta iguais em sequência.
Explicar como se fosse pra outra pessoa (Feynman): expõe buraco de entendimento em segundos.
Prática deliberada: treinar especificamente o que você é ruim, não o que você já sabe (que é o que dá prazer).

Esse último ponto tem um par de episódios só dele, Talento: Matando Semi-Deuses, parte 1 e parte 2 (2018). O argumento é que "talento" costuma ser o nome que a gente dá pra um volume massivo de prática deliberada que a gente não viu acontecer. Não é consolo motivacional: é a diferença entre achar que você não nasceu pra isso e entender que você simplesmente ainda não pagou as horas.

E do outro lado, o que quase todo mundo faz e rende pouco: reler e grifar. Ambos geram uma sensação forte de aprendizado, fluência, sem aprendizado proporcional. É a armadilha mais comum de quem estuda por vídeo: você entende tudo enquanto assiste e não consegue reproduzir nada depois.

Aproveitando: aquela história de "eu sou aprendiz visual / auditivo / cinestésico" não se sustenta na evidência. O que mudou não é o teu estilo, é o tipo de conteúdo. Mapa mental é melhor pra topologia de rede porque a coisa é espacial, não porque você é visual.

Mas, e esse "mas" é o motivo do título do post, todas essas técnicas são generalistas por definição. Elas foram testadas na média das pessoas. A tua realidade tem variáveis que nenhum estudo controlou: quantas horas você tem, que horas do dia teu cérebro funciona, se você precisa de projeto pra manter interesse ou se projeto te dispersa.

Então: começa pelo que é comprovado e adapta testando em você.

No meu caso, eu só fixo de verdade quando transformo o conteúdo em material visual bem detalhado, diagrama, mapa mental, e copio à mão no caderno físico. Na teoria isso é lentíssimo e ineficiente. Na prática, é a diferença entre eu lembrar e eu não lembrar. Descobri testando, não lendo sobre.

Um teste rápido que eu uso pra saber se a sessão valeu: se ao final eu não consigo reproduzir a ideia principal sem olhar, eu não estudei, eu assisti.

o método por trás de tudo isso é tentativa e erro (mas sistemática)

Se você quiser o embasamento profundo de por que não existe bala de prata, o episódio é o #119 — Aprendizado na Beira do Caos (2022). Ele passa por determinismo, teoria do caos, Deming, Toyota, Six Sigma e Agile pra chegar num ponto simples e meio anticlimático: a única forma conhecida de resolver problema desconhecido é ciclo de tentativa e erro, planejar, executar, medir, ajustar, repetir. PDCA, Kaizen, sprint de Scrum e o método científico são a mesma ideia com nomes diferentes.

Aplicado a estudo, isso quer dizer: pare de tentar montar o plano perfeito de dois anos. Planeja uma ou duas semanas, executa, e no fim checa de verdade se aprendeu (teste ativo, projeto, explicar pra alguém). Deu ruim? Muda uma variável e roda de novo. A regra é não errar a mesma coisa duas vezes, não é não errar.

Nesse ponto o Montano tem uma prática que eu achei simples e boa demais pra deixar de fora. Ele e a esposa escrevem objetivos todo início de ano, e a regra que ele usa é: "não lança nada que tu não tem controle". Ou seja, a meta é sobre o que depende de você, quantos vídeos postar, quantos quilômetros correr, e não sobre o resultado, que depende do mundo. Traduzindo pra estudo: "conseguir uma vaga de júnior até junho" é uma meta ruim, porque metade dela não é sua. "Entregar dois projetos de ponta a ponta até junho" é boa, porque é 100% sua.

E ele acrescenta uma segunda parte que eu achei ainda mais útil: no fim do ano, o valor do exercício não é conferir o que você cumpriu, é olhar o que você abandonou e perguntar por quê. Quase sempre a resposta te diz mais sobre o que você realmente quer do que a lista original dizia.

Tem um corolário prático dali que vale ouro e volta lá embaixo: se você não sabe se vai gostar de um curso de dez meses, não compra os dez meses. Compra um mês e testa. E se a plataforma só vende pacote fechado sem opção de sair, isso já é informação sobre a plataforma.

a armadilha dos 20%

Esse ponto é do Akita e eu acho que é o mais valioso de todos pra quem tá começando: com uns 20% do conhecimento você já consegue resolver uns 80% dos problemas e entregar coisa que funciona. O perigo não é o 20%, é achar que o 20% é o todo. Os últimos 20% dos problemas vão exigir justamente os 80% de fundamento que você pulou. (Ele também usa o mesmo número pro outro lado: nenhum curso te ensina mais que uns 20% de qualquer tema, o resto é você.)

Traduzindo pro dia a dia: você termina um curso de ML, treina um modelo, ele dá 92% de acurácia e você acha que chegou. Aí aparece o primeiro problema real, dado desbalanceado, vazamento entre treino e teste, modelo que degrada em produção, e você descobre que os 80% que faltam são exatamente estatística, álgebra e engenharia. Não tem atalho. E, como ele martela no #65, algoritmos e estruturas de dados vêm antes de design patterns, arquitetura e qualquer coisa da moda.

ah, e inglês

Ponto que eu quase esqueci de colocar e que é fundamento puro: inglês. Tudo que importa em tecnologia sai primeiro em inglês, e depender de material traduzido significa chegar sempre atrasado: quando já tem curso, livro e tutorial em português, a coisa já virou commodity e vale menos no mercado.

O #32, Como eu Aprendi Inglês e Entendendo Padrões (2018) é sobre isso e sobre reconhecimento de padrões, e a lógica é a mesma que a de aprender a programar: você não aprendeu português decorando gramática, aprendeu por exposição massiva e por não ter vergonha de errar. Inglês não é curso que você faz, é coisa que você incorpora na rotina.

Na mesma linha de fundamento, o #38 — Conhecimentos Básicos para Iniciantes (2019) cobre o que quase nenhum curso comercial toca: processo, thread, memória, scheduler, container. É o tipo de coisa que faz você trocar de linguagem sem sofrimento, e a falta dela é o motivo real de tanta gente travar quando muda de stack.

3. onde estudar? qual a melhor plataforma?

Resposta curta: não existe a melhor. Existe a de melhor custo-benefício pro seu momento, seu bolso e sua área.

Aqui eu preciso ser honesto sobre uma discordância parcial. A posição do Akita, no #65 e no #83, é basicamente que tanto faz: a diferença entre os cursos conhecidos é marginal, todos ensinam do mesmo jeito linear, e o curso te entrega uma fatia pequena do que você precisa, o resto você caça sozinho.

Eu concordo com o núcleo disso. Mas eu acho que a comparação ainda importa por um motivo prático: você tem dinheiro e tempo finitos, e escolher errado custa. A diferença é que a escolha da plataforma é uma decisão de logística, não de aprendizado. Depois que você aceita que o curso é a fatia pequena, aí sim vale otimizar qual fatia pequena você compra.

Antes de pagar qualquer coisa, responde duas perguntas:

Eu já sei qual área quero? Se não sabe, plataforma barata e ampla. Se sabe, pode investir em profundidade.
Eu preciso de estrutura ou de profundidade? Estrutura é sequência, ordem, alguém dizendo o que vem depois. Profundidade é o assunto até o osso. Poucas plataformas dão as duas.

E leva junto a regra do #119: paga o menor período possível e testa antes de se comprometer.

Uma coisa que eu não vi quase ninguém fazer nessas comparações e que faz muita diferença: cada plataforma tem uma área onde ela é naturalmente forte, e isso não é acaso, tem a ver com quem a fundou e quem produz conteúdo nela. Então a pergunta certa não é "qual plataforma é a melhor", é "qual plataforma tem gravidade na área que eu quero".

Aqui vai o que eu penso de cada uma, com base no que eu já usei de verdade.

Coursera é forte em IA/ML, dados, cloud e fundamento de computação, e tem uma razão estrutural pra isso: foi cofundada em 2012 pelo Andrew Ng, professor adjunto de Ciência da Computação em Stanford e fundador da DeepLearning.AI. Resultado prático: as trilhas de ML e deep learning mais reconhecidas do mundo estão ali, várias com ele mesmo como instrutor, algumas em parceria direta com Stanford Online, a Machine Learning Specialization, por exemplo, é DeepLearning.AI mais Stanford Online. Se a sua área é AI/ML engineering, a Coursera não é mais uma opção, ela é o centro de gravidade da área. Some a isso as trilhas de cloud e dados feitas por Google, AWS e IBM, e o fundamento chato que ninguém mais vende, tipo algoritmos e estruturas de dados por Stanford. O fraco dela é stack de mercado web: o que tem de front-end ali costuma ser acadêmico ou datado, e se você quer React em 2026 não é o lugar. O preço no Brasil continua sendo o maior problema.

Udemy é forte em ferramenta específica e nicho, pela razão estrutural oposta: é marketplace, quem define o teto é o instrutor ou a editora, não a plataforma. Isso é ruim pra consistência e ótimo pra nicho, você acha curso de biblioteca específica que plataforma grande nenhuma cobre. Meu melhor exemplo é a trilha de IA/ML da Maven Analytics, que fica lá: o curso de NLP é o último dela, quarto ou quinto da sequência, e é mais denso que muita coisa de plataforma cara. Dá pra ter profundidade real ali, mas dá porque eu escolhi certo, não porque era Udemy. O fraco é sequência e curadoria, não existe trilha da Udemy, existe trilha de instrutor, e você tem que saber achar. O certificado também não tem peso de sinalização nenhum.

Alura é forte em stack de mercado brasileiro e em sair do zero: conteúdo produzido em português mirando o que empresa brasileira usa de verdade, trilha definida, ordem sugerida. É provavelmente a melhor porta de entrada em português pra front, back e dados no nível aplicado. O fraco é fronteira e profundidade teórica, pra ML avançado ou segurança ofensiva não é ali.

Rocketseat é forte no eixo JavaScript/TypeScript: React, Node, React Native, é o nicho dela e ela é boa nele. Fora desse eixo, praticamente não existe. E sendo honesto, o valor real ali, na minha visão, é o ritmo e a comunidade mais do que o conteúdo, o que não é pouco, porque muita gente trava justamente por falta de ritmo. O preço não é baixo.

DIO é forte em exposição e fraco em formação: barata ou gratuita, bootcamps carregando selo de empresa. O conteúdo é raso na média em qualquer área, e eu não recomendo como formação. O que ela faz bem é vitrine e networking, e às vezes o bootcamp é porta real pra processo seletivo. Trata como canal de oportunidade, não como estudo.

Tem também cybersec, mais especificamente offensive security. Poderia citar outros nichos aqui, mas sinceramente o único em que eu tive experiência estudando e explorando de verdade foi esse. TryHackMe é a melhor porta de entrada, guiada, gamificada, mão na massa desde o primeiro dia. HackTheBox é a mesma área com bem menos mão na cabeça, ótimo depois de ter base, antes disso vira frustração. Solyd Offensive Security e Desec Security são escolas brasileiras de pentest, conteúdo em português e pé no chão; se o inglês ainda é barreira pra você, começa por aqui. E vale reparar numa vantagem estrutural que quase nenhuma outra área tem: o formato padrão ali não é videoaula, é laboratório. Você não assiste sobre invadir, você tenta invadir e falha até conseguir. Isso resolve por design o problema que eu falei na seção 2, de consumir conteúdo e achar que aprendeu. O equivalente mais próximo que eu conheço em outra área é Kaggle pra dados, e nem chega perto de ser tão bem feito.

YouTube e conteúdo gratuito são fortes em fundamento e em explicação conceitual. Depende inteiramente de quem produz, mas quando é bom compete de igual pra igual com curso pago, e às vezes ganha. Em algoritmos e estrutura de dados, o Augusto Galego tem bastante material gratuito e bom. Na área de IA, dois nomes que eu recomendo sem pensar duas vezes: Andrej Karpathy, que constrói rede neural e modelo de linguagem do zero na sua frente, linha por linha; e Umar Jamil, engenheiro de ML que implementa Transformer, LLaMA, Stable Diffusion e afins do zero em PyTorch, explicando a matemática junto e destrinchando papers inteiros. Pra matemática por trás de deep learning, o próprio Akita recomenda o 3Blue1Brown lá no #83. Vale parar um segundo nisso, porque é o argumento mais forte da seção inteira: em IA, boa parte do melhor material do mundo é gratuito e feito por gente que trabalha na fronteira da área. Se conteúdo fosse o gargalo, ninguém teria desculpa, o gargalo é outro, e é o assunto da seção 2. O fraco aqui é estrutura, zero: você precisa chegar com o roteiro pronto ou vai passar seis meses assistindo aula solta.

Documentação oficial é forte sempre que o alvo é uma ferramenta específica, e é subestimadíssima. O melhor curso de spaCy que eu fiz é o oficial, gratuito, escrito por quem construiu a lib. Antes de comprar curso de ferramenta X, olha se o time do X não escreveu um. O fraco: ela te ensina a ferramenta, não o campo. Documentação de PyTorch não te ensina ML.

E livros e artigos são fortes em fundamento e em fronteira, exatamente onde o resto é fraco. Eu diria assim: curso te dá vocabulário, livro te dá modelo mental, paper te mostra a fronteira. Se você só consome vídeo, você fica com vocabulário e acha que tem modelo mental.

Resumindo a seção: plataforma paga compra estrutura e sequência, não conhecimento. Conhecimento continua sendo produzido pelas horas que você senta e faz. Nenhum plano anual te vende isso.

4. lendo isso em 2026: o que envelheceu e o que não

Essa seção é a mais importante do post e é a razão de eu ter escrito ele em vez de só mandar os links.

O material que eu citei acima é de 2018 a 2022. Ou seja: foi escrito antes do ChatGPT existir pro público, antes da onda de demissões em tech de 2022 pra frente, e num mundo onde trabalho remoto ainda era exceção. Ler aquilo em 2026 sem ajustar o contexto é tão errado quanto ignorar.

o caso mais gritante: IA

Em agosto de 2020, o #83 respondeu a pergunta "o GPT-3 vai substituir programador?". A resposta, resumida: não; IA gerando IA melhor era ficção científica pra décadas à frente; deep learning de verdade era caro e fechado, então você não faria carreira nisso, no máximo consumiria API dos outros.

Seis anos depois, essa previsão específica não segurou no prazo. Modelo de linguagem saiu de "gera um botão azul em HTML" pra ferramenta que refatora módulo inteiro e que virou rotina de trabalho na maioria dos times. Apareceram modelos de peso aberto, então nem tudo é caixa preta de três empresas. E "AI/ML Engineering" virou uma carreira de verdade, com vaga, salário e trilha, é literalmente a área que eu tô seguindo, o que faz de mim um contraexemplo ambulante daquele parágrafo.

Mas, e isso é o que importa, o argumento por baixo da previsão envelheceu muito melhor que a previsão. O que ele estava dizendo de verdade é que o que te torna obsoleto não é a ferramenta, é a sua incapacidade de aprender sozinho. Isso ficou mais verdadeiro, não menos.

Junta com a lei de oferta e procura que ele desenvolve no #90 (2021): tudo que fica fácil demais passa a valer menos, porque qualquer um consegue. Pois é: a IA baixou brutalmente o custo de produzir código que roda. Se qualquer um consegue produzir código que roda, produzir código que roda deixou de ser o diferencial. O que ficou escasso é julgamento: saber se aquilo tá certo, se é seguro, se vai dar manutenção daqui seis meses, e principalmente se o problema que você resolveu era o problema certo.

E não sou só eu dizendo isso. No vídeo de encerramento de 2025, o Montano responde a um recém-formado em Ciência da Computação e vai direto ao ponto: base é mais importante agora, não menos. O argumento dele é concreto: o que você vai precisar identificar no que a IA produz não é escolha de tecnologia, é escolha de protocolo, decisão de arquitetura, problema de segurança e de criptografia. Coisas que passam batido se você não tem estudo por trás, e que também melhoram a forma como você conversa com o modelo.

E ele fala de lugar de quem usa: o SaaS dele é, nas palavras dele, 100% vibe codado, quem escreveu o código foi uma IA. Mesmo assim, a conclusão é que devs diferentes geram resultados diferentes com o mesmo modelo, e que isso é justamente o diferencial daqui pra frente. Ou seja: a ferramenta igualou o acesso, não igualou as pessoas.

o que isso muda no seu portfólio (na prática)

Em 2020, o portfólio honesto era "fiz tudo na mão". Em 2026 isso mudou de figura:

A maioria das empresas já assume que você usa IA. Esconder que usou é mais suspeito do que assumir.
Várias querem justamente ver como você usa: o que você pediu, o que você aceitou, o que você rejeitou, como você garantiu qualidade e como você revisou o que veio pronto.
Tem processo seletivo que pede explicitamente projeto feito com IA no meio, porque o que eles estão medindo é a sua capacidade de dirigir a ferramenta sem virar passageiro dela.

Então o conselho atualiza: não esconde, documenta. No README, conta o processo: onde a IA te acelerou, onde ela errou, onde você discordou e por quê. Um projeto onde você mostra que entendeu cada decisão vale mais do que um projeto "puro" mal explicado. E, sendo bem direto: se você não consegue defender uma linha do seu próprio repositório numa entrevista, o problema não é a IA, é que aquele projeto não é seu.

a armadilha dos 20%, só que mais rápida

Aquele ponto da seção anterior ficou pior. Antes você precisava de um curso inteiro pra chegar na sensação de "já sei fazer". Hoje você chega nessa sensação em um prompt. A ilusão de competência ficou instantânea e muito mais convincente.

A correção é a mesma de sempre, só que mais urgente: consegue refazer sem ajuda? Consegue explicar cada decisão? Se não, você tem um resultado, não tem uma habilidade. E, curiosamente, isso deixa o conselho mais "antigo" do Akita, fundamento chato, algoritmo, estrutura de dados, matemática, mais rentável do que era em 2019, porque é exatamente o que te permite revisar o que a máquina cuspiu.

outras coisas que mudaram

Low-code virou outra coisa com o mesmo nome. No #83 a comparação era com miojo: operar ferramenta não é cozinhar. A analogia continua boa, mas o teto da ferramenta subiu muito. A linha entre "operador de ferramenta" e "programador" mudou de lugar, então vale reavaliar de vez em quando de que lado você tá, e não assumir que é do lado bom só porque você digita código. O Montano descreve bem esse deslocamento: ferramentas como Lovable, Replit e v0 basicamente passaram por cima do mercado de low-code/no-code, e sim, dá pra construir coisa complexa com elas sabendo pouco de programação. O porém que ele levanta é o que importa: quanto mais complexo e abstrato o que você delega, maior o erro que você pode estar criando sem enxergar, inclusive vulnerabilidade de segurança.
Mercado. O #72 — Programação não é Fácil (fev/2020) e o #76 foram escritos avisando que a bolha ia estourar e que o mercado ia separar joio de trigo. Boa parte disso aconteceu mesmo. A porta de entrada pra júnior hoje é mais estreita do que era quando esses textos saíram, e parte da explicação é que tarefa de entrada é justamente o que a IA absorveu primeiro. O conselho de construir fundamento deixou de ser "bom investimento" e virou requisito. Sobre a bolha atual, a leitura do Montano em dez/2025 me parece a mais equilibrada: existe bolha, sim, mas nos valuations e na contabilidade das big techs, ele dá o exemplo das GPUs, compradas com uma expectativa de depreciação e lançadas no balanço com outra, bem mais longa. O que ele não acredita é em bolha no sentido de "estoura e ninguém mais usa". A previsão dele é que IA vai parar de ser vista como IA e virar ferramenta invisível, do mesmo jeito que ninguém mais pensa no Google como "um buscador".
Remoto. Em 2020 ele defendia que home office prejudica iniciante, porque júnior precisa estar do lado de gente experiente. O princípio continua certo, mas hoje remoto e híbrido são padrão, e não dá mais pra usar isso como argumento pra escolher emprego presencial a qualquer custo. O que muda é que agora você tem que construir essa proximidade de propósito: pedir code review, puxar pair programming, perguntar em canal público em vez de sofrer sozinho no privado.
Certificado. Ele despreza papel e tem razão no mérito. Só que hoje o primeiro filtro de muita vaga é automatizado, e certificado e palavra-chave têm função nesse filtro, que não é a mesma coisa que ter função na sua formação. São duas conversas diferentes e vale não misturar.

a regra geral de leitura

Conteúdo sobre método, como aprender, como pensar, como se organizar, envelhece devagar, às vezes leva décadas. Conteúdo sobre mercado e ferramenta envelhece em meses. Quando você abrir qualquer post de carreira, o meu incluído, olha a data primeiro e classifica: isso aqui é método ou é conjuntura? A resposta muda quanto você deve confiar.

5. certificado não é competência

Essa é a outra pergunta que mais chega: o que faz diferença pra ser chamado numa entrevista, seja pra estágio ou pra efetivo?

No meu próprio caso, a resposta é cheia de "não sei" e "acho que". Na triagem, acho que foi porque quase tudo que a vaga pedia eu já tinha no currículo. Depois, pelo que me disseram, eu fui favorito entre os candidatos desde o início porque era quem mais tinha experiência prática e demonstrava mais domínio técnico, isso é o que me contaram, o resto é achismo puro. O que eu acho que bateu o martelo foi o teste técnico: tinha alguns requisitos "adicionais" além dos padrão, e eu gabaritei todos, com uma defesa técnica sem brecha depois. Um colega que avaliou meu teste comentou que outros candidatos deixaram muita coisa por fazer, então talvez só de já ter algo concluído, mesmo que imperfeito, já conte pontos. E na entrevista técnica, particularmente, perguntaram bastante sobre os detalhes dos projetos que eu tinha no próprio currículo. Mas isso é o que eu acho em relação à vaga específica que eu passei, no departamento específico que eu passei; pode variar de infinitas formas em outro processo, outro departamento, outra empresa. Repara no formato da resposta inteira: é o mesmo disclaimer do começo deste post, aplicado a mim mesmo.

Sem entrar em detalhe do teste em si, por uma questão ética óbvia, o processo inteiro é considerado difícil por quem passa por ele. Pra mim, não foi. Teve ansiedade, isso sim, mas o teste em si não foi difícil. E o motivo é simples: desde o dia que eu decidi que ia atrás daquela vaga, eu vinha estudando praticamente obcecado. Não recomendo fazer igual, o ritmo que eu mantive não é nada saudável e eu sei disso. Mas o ponto que fica é outro: o nível de preparo que importa não é o que te deixa achando o teste fácil, é o que tira o medo do teste. Difícil ou fácil é relativo à pessoa; o medo é o que trava.

Minha visão, tirando o achismo, é que o que pesa mesmo é o currículo mostrar experiência minimamente parecida com o que a vaga pede, ou que pelo menos indique que você domina aquele assunto. E "experiência" aqui é mais amplo do que a galera pensa: projeto pessoal conta, projeto de extensão conta, freela conta, trabalho formal conta, e, no caso de um instituto de pesquisa e desenvolvimento como o Sidia, iniciação científica também conta, dependendo do departamento. Tudo é válido, desde que seja demonstrável.

O certificado sozinho não diz nada sobre o que você consegue construir. Ele diz que você assistiu. O Akita é mais ácido que eu nesse ponto, ele conta no #76 que estudou, passou na prova de uma certificação famosa e guardou o papel na gaveta, porque só depois de anos praticando é que ele se considerou competente naquilo.

Isso não quer dizer que certificado seja inútil, e aqui eu acho que o contexto de 2026 pede uma ressalva: ele resolve um problema específico e real, que é passar por filtro automatizado e sinalizar direção. Eu mesmo tô fazendo uma trilha de certificações. Só não confunda a placa com a estrada.

Por isso, a coisa mais rentável que você pode fazer com qualquer curso é essa: depois de cada módulo, refaz aquilo com dados/problema que você escolheu. IBGE, dados.gov.br, Kaggle, a API de alguma coisa que você usa. No fim, dois ou três projetos de ponta a ponta valem mais que um certificado de cinquenta módulos, e, diferente do certificado, você consegue falar sobre eles por trinta minutos numa entrevista sem travar.

Projeto de ponta a ponta, pra mim, é: dado real (de preferência bagunçado), decisão sua no meio do caminho, resultado que dá pra mostrar, e escrito em algum lugar, README decente, post, LinkedIn, o que for.

E se você travou em "mas eu não tenho uma boa ideia": para de procurar. Perguntaram isso pro Montano e a resposta foi que é só fazer, ele conta que nenhum amigo acreditou no SaaS dele, e alguns continuavam questionando o produto quando ele já estava dando dinheiro. A definição de boa ideia que ele usa é brutalmente simples: boa ideia é aquela pela qual alguém paga. Enquanto você não faz, você não tem como saber qual das suas ideias é essa, o que, de novo, é o mesmo argumento do Galego lá na seção 1, e do Akita quando ele manda você escrever código sem propósito e jogar fora. Três pessoas diferentes, o mesmo conselho: começa.

o mito do dev 10x (e por que ele importa mais agora)

Tem um primo desse papo de certificado que é a obsessão com produtividade individual. Na segunda metade daquele mesmo vídeo, o Montano desmonta uma lista de características do "dev 10x" que viralizou no Twitter, coisas como odiar reunião, não ter horário fixo, virar a madrugada, saber de cor cada linha que colocou em produção e usar tema escuro na IDE. Ele discorda de quase tudo, e por bons motivos.

O primeiro é simples: o 10x é um número figurativo. Não existe forma de medir isso, porque produtividade depende de contexto demais.

O segundo é o que interessa. Ele conta que, na carreira inteira, as poucas vezes em que encontrou alguém que de fato produzia muito acima da média, essa pessoa costumava virar gargalo do produto. Escrevia código rápido e travava o projeto, porque não se comunicava, se fechava, e com isso reduzia o próprio ciclo de feedback. O resultado é o pior dos mundos: produzir rápido, com qualidade, a coisa errada. Isso não é produtividade, é desperdício em alta velocidade. A Netflix tem nome pra esse perfil, eles dizem não tolerar "brilliant jerks", porque o custo de um deles num time é maior que o ganho.

Ele reconhece um caso em que a produtividade absurda existe de verdade: domínio. Um dev que passou dez anos construindo sistema de nota fiscal eletrônica no Brasil vai ser muito mais rápido que a média naquele domínio, porque o conhecimento de negócio está colado no de código, ele sabe de cor as bibliotecas, as regras, as fórmulas. É um argumento e tanto a favor de ficar tempo suficiente em algum lugar pra aprender o negócio, e não só a stack. Mas nem isso garante que o produto dê certo.

A conclusão dele é a parte que eu mais levo comigo: o multiplicador de verdade não é você produzir dez vezes mais, é você deixar as outras pessoas mais produtivas. Automatizar teste, build, tarefa manual, inclusive de áreas que não são de tecnologia. Compartilhar conhecimento em vez de reter. Saber priorizar. Deixar o ego de lado e admitir rápido quando errou numa discussão técnica, coisa que ele diz ver pouco justamente em gente sênior.

E por que isso importa mais agora: a IA está sendo vendida exatamente como a promessa do 10x individual. Ela até entrega algo parecido na parte de escrever código, que, como acabou de ficar claro, é a parte que menos determina se o projeto dá certo.

6. fechando: o que eu faria se começasse hoje

Experimenta várias áreas com projetos pequenos antes de escolher, e aceita que talvez você não escolha ainda.
Investe em aprender a aprender antes de investir em plataforma. É o único estudo que rende juros.
Constrói fundamento chato (algoritmos, estrutura de dados, estatística, inglês) enquanto todo mundo corre atrás do hype. Em 2026 isso rende mais, não menos.
Usa IA sem se esconder e sem virar passageiro: se não consegue explicar, não é teu.
Escolhe plataforma pelo teu momento e teu bolso, paga o menor período possível e testa antes de se comprometer.
Transforma consumo em entrega. Sempre. Se não virou projeto, não virou skill, e insegurança não some lendo mais um curso, some resolvendo problema real.
Mede teu valor pelo quanto tu destrava as outras pessoas, não pelo quanto tu produz sozinho.
Olha a data de tudo que você lê sobre carreira. Método envelhece devagar, mercado envelhece rápido.
Desconfia de quem te entrega receita pronta, inclusive de mim.

Tem uma ironia boa em fechar assim. O Akita, que é a maior referência desse texto, diria pra você não perguntar essas coisas pra mim, e ele tá certo. A diferença entre pedir perspectiva e pedir ordem é toda. Esse post é perspectiva: serve pra você ter mais contexto na hora de decidir, não pra decidir no seu lugar.

Se existisse bala de prata, eu não estaria no começo do meu próprio caminho, correndo atrás de especialização igual todo mundo. O que existe é método, contexto e consistência. É menos sexy e funciona muito mais.

E se sorte existe nessa história, é essa: sorte é estar preparado pra oportunidade quando ela aparece, e ela sempre aparece em algum momento. Ninguém controla quando a oportunidade vai bater na porta. O que dá pra controlar é se, quando ela bater, você tem alguma coisa construída pra mostrar.

Qualquer dúvida sobre a parte de ML, DL e LLM, pode me chamar que eu ajudo no que der. Nas outras, eu provavelmente vou te indicar alguém melhor, e isso também faz parte.

P.S. — a pergunta que eu deixei de fora de propósito

Você deve ter reparado que, num post inteiro sobre carreira em tecnologia, eu não respondi a pergunta mais feita de todas. Foi de propósito.

Se você chegou até aqui e ainda tá pensando "tá, mas no fim das contas, qual linguagem eu escolho pra ter mais chance no mercado?", então volta pra linha 1 e lê tudo de novo, porque você não entendeu nada do que eu tentei dizer.

E eu falo isso sem ironia nenhuma. Essa é a forma mais pura de pedir bala de prata que existe: ela assume que tem uma resposta única, externa, igual pra todo mundo, que não depende de quem você é nem de onde você quer chegar. Só que a stack que paga melhor hoje pode não pagar em três anos, e você vai levar mais de três anos pra ficar bom nela. A stack com mais vaga é, por definição, a com mais gente disputando. E nenhuma das duas responde a única pergunta que realmente importa aqui, que é se você aguenta passar mil horas fazendo aquilo.

A escolha da linguagem é a decisão de menor consequência do post inteiro. Você vai trocar de linguagem várias vezes na vida. O que não se troca com facilidade é fundamento, método de estudo e a capacidade de se virar sozinho, e foi disso que eu falei o tempo todo, justamente pra não precisar falar de stack.

Então escolhe qualquer uma. Sério. Escolhe a que teu amigo usa, a do vídeo que você gostou, a que apareceu na vaga que você viu ontem. Faz um projeto do início ao fim com ela. A resposta que você tá procurando não vem de fora, ela aparece depois da terceira ou quarta coisa que você construiu.

Um último disclaimer, já que IA apareceu bastante nesse post: usar IA pesado demais no teu projeto pessoal, o mesmo projeto que devia ser onde você constrói o fundamento com a própria mão, talvez não seja tão bom assim a médio e longo prazo. Ainda tô processando exatamente onde fica essa linha, e o assunto merece um post inteiro só dele, não um parágrafo solto aqui no final. Fica pra próxima.

referências

As datas importam, leia com elas em mente.

Fabio Akita

Tudo disponível em vídeo e em texto no blog dele.

Método (envelhece devagar, leia tudo):

#119 — Aprendizado na Beira do Caos (2022): por que não existe fórmula de sucesso, e por que tentativa e erro sistemática é o único método que funciona.
#76 — Guia Definitivo de Aprendendo a Aprender (2020): se você for ler só um, leia esse.
#65 — A Dor de Aprender | Que Cursos/Livros? (2019): método prático de estudo e por que fundamento vem antes de padrão.
#63 — Não Terceirize suas Decisões (2019): a razão de esse post não poder decidir por você.
#26 e #27 — Talento: Matando Semi-Deuses (2018): prática deliberada, e por que talento é menos mágico do que parece.

Fundamento (idem):

#38 — Conhecimentos Básicos para Iniciantes (2019).
#32 — Como eu Aprendi Inglês e Entendendo Padrões (2018).

Carreira e mercado (leia junto com a seção 4 deste post):

#90 — O que os Cursos NÃO te Ensinam sobre Mercados (2021): oferta e procura aplicada à sua carreira.
#64 — Começando na Carreira de TI (2019): faculdade e o que separa júnior, pleno e sênior de verdade.
#29 — O que eu Devo Estudar? Vou Conseguir Emprego? (2018).
#83 — Quais Cursos você recomenda? E o Low-Code? E o GPT-3? (2020): ótimo sobre cursos, e o exemplo mais claro de por que data importa.
#72 — Programação não é Fácil (2020): escrito na virada do ciclo; leia como retrato de época que se confirmou em boa parte.

Augusto Galego

Material bem mais recente, o que faz dele um bom contraponto de época ao de cima.

Começar Te Dá o Framework Para Pensar em Como Começar (2025): por que conselho só funciona depois que você começou, e por que orientação depende de vocabulário compartilhado.
Se você se sente perdido como dev (dez/2025): pra quando a sensação é de não ter direção nenhuma.
O curso de algoritmos e estrutura de dados dele, que tá me ajudando mais que muita coisa que eu paguei, e, fora isso, bastante conteúdo gratuito e bom sobre o mesmo assunto.

Lucas Montano

Tech lead na Disney (Disney+ Android), mora fora e toca produto próprio em paralelo, vale saber de onde ele fala quando ele responde sobre carreira.

Especialista vs. Generalista + o mito do dev 10x: duas metades ótimas, na primeira ele compila as respostas de vários engenheiros pra mesma pergunta (incluindo Filipe Deschamps) e mostra que elas divergem; na segunda, desmonta a lista viral de características do "dev 10x". Vale pelo método tanto quanto pelo conteúdo.
Q&A de encerramento de 2025 (dez/2025): o mais recente e o mais denso, fundamento na era da IA, qual graduação faria hoje, vibe coding e seus limites, a bolha, como definir metas e o conceito de beco sem saída. É o vídeo mais citado deste post depois do #76 do Akita.