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

bilingual · en / pt

← /blog

career: there is no silver bullet

2026-09-05·en·49 min read·carreiraestudosaprendizadoplataformastech

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:

  1. 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.

  2. 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.

  3. 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.

  1. 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:

  1. 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.

  2. 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:

  1. Do I already know which field I want? If not, go cheap and broad. If you do, invest in depth.
  2. 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

  1. Try several fields with small projects before choosing, and accept that maybe you won't choose yet.
  2. Invest in learning how to learn before investing in a platform. It's the only kind of study that compounds.
  3. Build boring fundamentals (algorithms, data structures, statistics, English) while everyone else chases the hype. In 2026 this pays off more, not less.
  4. Use AI without hiding it and without becoming a passenger: if you can't explain it, it's not yours.
  5. Pick a platform for your own moment and budget, pay for the shortest period possible, and test before committing.
  6. 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.
  7. Measure your worth by how much you unblock other people, not by how much you produce alone.
  8. Check the date on everything you read about career. Method ages slowly, market ages fast.
  9. 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):

Foundation (same as above):

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

Augusto Galego

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

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.