📘 JavaScript or Python? Wrong question.
This is the #1 thing beginners ask me, and almost every answer online is bad - because it compares the languages instead of asking what you want.
Here's the honest version.
🔹 Pick JavaScript if you want to see things.
You want a website, a button that does something, an app people can open in a browser. JS is the only language that runs natively in the browser - that isn't an opinion, it's just how the web works. Feedback is instant, and for a beginner, instant feedback is worth more than clean syntax.
🔹 Pick Python if you want to process things.
Data, automation, scripts, AI, scraping, anything where the result is a number or a file rather than a screen. The syntax stays out of your way, which matters a lot in your first three months.
What actually decides it:
▪️ Want a job in web dev? → JavaScript. Non-negotiable.
▪️ Want data / AI / automation? → Python.
▪️ Want to automate boring parts of your current job? → Python.
▪️ Genuinely no idea? → JavaScript. You'll see results faster, and seeing results is what keeps beginners from quitting.
And the part nobody says out loud: after the first one, the second takes about three weeks. You're not choosing a career. You're choosing which syntax you'll be confused by first.
The real risk isn't picking wrong. It's spending four months picking. Full comparison, with the job-market side and where AI fits in 👇
https://coddytech.net/blog/javascript-vs-python-which-to-learn
#learn @codingforweb
This is the #1 thing beginners ask me, and almost every answer online is bad - because it compares the languages instead of asking what you want.
Here's the honest version.
🔹 Pick JavaScript if you want to see things.
You want a website, a button that does something, an app people can open in a browser. JS is the only language that runs natively in the browser - that isn't an opinion, it's just how the web works. Feedback is instant, and for a beginner, instant feedback is worth more than clean syntax.
🔹 Pick Python if you want to process things.
Data, automation, scripts, AI, scraping, anything where the result is a number or a file rather than a screen. The syntax stays out of your way, which matters a lot in your first three months.
What actually decides it:
▪️ Want a job in web dev? → JavaScript. Non-negotiable.
▪️ Want data / AI / automation? → Python.
▪️ Want to automate boring parts of your current job? → Python.
▪️ Genuinely no idea? → JavaScript. You'll see results faster, and seeing results is what keeps beginners from quitting.
And the part nobody says out loud: after the first one, the second takes about three weeks. You're not choosing a career. You're choosing which syntax you'll be confused by first.
The real risk isn't picking wrong. It's spending four months picking. Full comparison, with the job-market side and where AI fits in 👇
https://coddytech.net/blog/javascript-vs-python-which-to-learn
#learn @codingforweb
👍1
📊 84% of developers use AI. 3% trust it.
Stack Overflow just published the 2026 Developer Survey - 49,000+ developers, 177 countries. The numbers are the strangest I've seen in years.
▪️ 84% use AI tools in their workflow
▪️ 29% trust the accuracy of what it produces - down from 40% in 2024
▪️ 46% actively distrust it
▪️ 3% say they "highly trust" AI-generated code
▪️ Among experienced developers: 2.6%
Read that again. Adoption went up. Trust went down. At the same time. That's not a contradiction - it's what expertise looks like. The more you use
a tool, the better you know where it breaks.
And here's the number that explains everything:
🔸 66% say their biggest frustration is code that is "almost right"
🔸 45% say debugging AI output takes longer than writing it themselves
Not wrong code. Almost right code. Wrong code fails loudly and you fix it in a minute. Almost-right code passes review, ships, and breaks in production three weeks later.
So the skill that matters in 2026 isn't prompting. It's the ability to look at working code and know it's wrong. That skill only comes from writing code yourself first. There's no shortcut, and the survey is 49,000 developers agreeing with that.
📎 Source: survey.stackoverflow.co
Forward this to someone who thinks learning the basics is optional now.
#learn @codingforweb
Stack Overflow just published the 2026 Developer Survey - 49,000+ developers, 177 countries. The numbers are the strangest I've seen in years.
▪️ 84% use AI tools in their workflow
▪️ 29% trust the accuracy of what it produces - down from 40% in 2024
▪️ 46% actively distrust it
▪️ 3% say they "highly trust" AI-generated code
▪️ Among experienced developers: 2.6%
Read that again. Adoption went up. Trust went down. At the same time. That's not a contradiction - it's what expertise looks like. The more you use
a tool, the better you know where it breaks.
And here's the number that explains everything:
🔸 66% say their biggest frustration is code that is "almost right"
🔸 45% say debugging AI output takes longer than writing it themselves
Not wrong code. Almost right code. Wrong code fails loudly and you fix it in a minute. Almost-right code passes review, ships, and breaks in production three weeks later.
So the skill that matters in 2026 isn't prompting. It's the ability to look at working code and know it's wrong. That skill only comes from writing code yourself first. There's no shortcut, and the survey is 49,000 developers agreeing with that.
📎 Source: survey.stackoverflow.co
Forward this to someone who thinks learning the basics is optional now.
#learn @codingforweb
🤯 Developers felt 20% faster with AI. They were 19% slower.
This is my favourite study of the last two years, and almost nobody in my feed has seen it.
METR ran a proper randomized controlled trial. Not a survey - an actual RCT:
▪️ 16 experienced open-source developers
▪️ Real repos: 22,000+ stars, 1M+ lines of code
▪️ 246 real issues - bugs, features, refactors
▪️ Each task randomly assigned: AI allowed or AI not allowed
▪️ Tools: Cursor Pro with Claude Sonnet
Before starting, developers predicted AI would make them 24% faster.
After finishing, they believed AI had made them 20% faster.
Measured result: they took 19% longer.
A ~40-point gap between what they felt and what actually happened. The researchers called it "a substantial and persistent gap between perceived and actual performance."
Why it happens - and this is the useful part:
AI removes the feeling of effort, not the effort. You stop staring at a blank file, so the work feels lighter. But you replace writing with reading, reviewing, correcting, re-prompting. That's slower, and it doesn't feel slower, because reading feels easier than writing.
⚠️ This is not an anti-AI post.
The same study notes: these were experts in codebases they knew by heart - the exact scenario where AI helps least. Elsewhere, the picture flips: teams that use AI agents properly cut PR turnaround from 9.6 days to 2.4 days.
The lesson isn't "don't use AI." It's this:
👉 Your sense of your own speed is not evidence. Time yourself once. Do it this week on one real task. The result will surprise you in one direction or the other - and either way you'll know something about your workflow that 99% of developers only guess at.
📎 Source: metr.org - "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
Forward this to the person on your team who's most sure AI made them faster.
#learn @codingforweb
This is my favourite study of the last two years, and almost nobody in my feed has seen it.
METR ran a proper randomized controlled trial. Not a survey - an actual RCT:
▪️ 16 experienced open-source developers
▪️ Real repos: 22,000+ stars, 1M+ lines of code
▪️ 246 real issues - bugs, features, refactors
▪️ Each task randomly assigned: AI allowed or AI not allowed
▪️ Tools: Cursor Pro with Claude Sonnet
Before starting, developers predicted AI would make them 24% faster.
After finishing, they believed AI had made them 20% faster.
Measured result: they took 19% longer.
A ~40-point gap between what they felt and what actually happened. The researchers called it "a substantial and persistent gap between perceived and actual performance."
Why it happens - and this is the useful part:
AI removes the feeling of effort, not the effort. You stop staring at a blank file, so the work feels lighter. But you replace writing with reading, reviewing, correcting, re-prompting. That's slower, and it doesn't feel slower, because reading feels easier than writing.
⚠️ This is not an anti-AI post.
The same study notes: these were experts in codebases they knew by heart - the exact scenario where AI helps least. Elsewhere, the picture flips: teams that use AI agents properly cut PR turnaround from 9.6 days to 2.4 days.
The lesson isn't "don't use AI." It's this:
👉 Your sense of your own speed is not evidence. Time yourself once. Do it this week on one real task. The result will surprise you in one direction or the other - and either way you'll know something about your workflow that 99% of developers only guess at.
📎 Source: metr.org - "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity"
Forward this to the person on your team who's most sure AI made them faster.
#learn @codingforweb
This media is not supported in your browser
VIEW IN TELEGRAM
🎯 After 13 years of writing code, here's the only skill I'd optimise for now...
Every week someone asks me the same question: what's the point of learning to code if AI writes it? I used to give a long answer. I'll share a short one, and the 2026 data supports every part of it.
Look at what we know:
▪️ 84% of developers use AI - but only 3% highly trust its output
▪️ 66% say their #1 frustration is code that's "almost right"
▪️ 45% say debugging AI output takes longer than writing it themselves
▪️ 45% of AI-generated code ships with a security vulnerability
▪️ In a controlled trial, experts felt 20% faster and were 19% slower
Every single one of those numbers points to the same place. The bottleneck is no longer writing code. It's judging code. Producing a function is now free. Knowing whether that function is correct, safe, maintainable, and actually solving the right problem - that is the entire job now. It's what 97% of developers don't trust AI to do, and it's what nobody can outsource. So if I were starting today, I'd optimise for one thing:
👉 Read more code than you write.
Concretely, and this costs nothing:
1️⃣ Open a repo you use and read one file properly. Not skim - read it until you could explain every line to someone else.
2️⃣ Every time AI gives you code that works, ask it: "what's wrong with this?"
Then verify its answer yourself. It will be wrong sometimes. Catching that is the skill.
3️⃣ Break working code on purpose. Change one thing, predict the failure, check if you were right. Being right consistently is what expertise actually is.
4️⃣ Review a pull request in an open-source project. Badly, at first. Do it twenty times.
None of that is glamorous, none of it makes a good screenshot, and all of it compounds. The developers who'll be valuable in 2030 aren't the ones who prompt best. They're the ones who can look at code that runs perfectly and say, "This is wrong, and here's why." That was always the job. AI just deleted everything else.
💬 What do you think - is judgement really the bottleneck, or am I wrong here?
Forward this to someone who's wondering if it's still worth learning.
#learn @codingforweb
Every week someone asks me the same question: what's the point of learning to code if AI writes it? I used to give a long answer. I'll share a short one, and the 2026 data supports every part of it.
Look at what we know:
▪️ 84% of developers use AI - but only 3% highly trust its output
▪️ 66% say their #1 frustration is code that's "almost right"
▪️ 45% say debugging AI output takes longer than writing it themselves
▪️ 45% of AI-generated code ships with a security vulnerability
▪️ In a controlled trial, experts felt 20% faster and were 19% slower
Every single one of those numbers points to the same place. The bottleneck is no longer writing code. It's judging code. Producing a function is now free. Knowing whether that function is correct, safe, maintainable, and actually solving the right problem - that is the entire job now. It's what 97% of developers don't trust AI to do, and it's what nobody can outsource. So if I were starting today, I'd optimise for one thing:
👉 Read more code than you write.
Concretely, and this costs nothing:
1️⃣ Open a repo you use and read one file properly. Not skim - read it until you could explain every line to someone else.
2️⃣ Every time AI gives you code that works, ask it: "what's wrong with this?"
Then verify its answer yourself. It will be wrong sometimes. Catching that is the skill.
3️⃣ Break working code on purpose. Change one thing, predict the failure, check if you were right. Being right consistently is what expertise actually is.
4️⃣ Review a pull request in an open-source project. Badly, at first. Do it twenty times.
None of that is glamorous, none of it makes a good screenshot, and all of it compounds. The developers who'll be valuable in 2030 aren't the ones who prompt best. They're the ones who can look at code that runs perfectly and say, "This is wrong, and here's why." That was always the job. AI just deleted everything else.
💬 What do you think - is judgement really the bottleneck, or am I wrong here?
Forward this to someone who's wondering if it's still worth learning.
#learn @codingforweb
👏1
💭 Tutorial hell is dead. Welcome to prompt hell 😵💫
You remember tutorial hell. You watch a 12-hour course, you follow along, everything works, you feel like you're learning. Then you open an empty file to build something yourself, and you have no idea what to type. That's mostly gone now. AI killed it. Nobody's stuck watching tutorials - you just describe what you want, and something appears.
So we invented a worse version 😈
Prompt hell is this: you ship things. Real things. A working app, a dashboard, an API that people use. From the outside, you look like a developer who's doing fine. And you cannot build anything without AI. Not "it's slower without it." Cannot 😣
The difference from tutorial hell is what makes it dangerous. In tutorial hell, you knew you were stuck - the blank file told you every day. In prompt hell, everything works, so there's no signal, no discomfort, nothing telling you something's wrong. You can stay there for two years.
Here's the test. Three questions, answer honestly:
1️⃣ Can you read a function you shipped last month and explain every line - not what it does, but why it's written that way?
2️⃣ When something breaks, is your first move to think, or to paste the error?
3️⃣ Could you build a small version of your last project with no AI at all - badly, slowly, but finish it? If it's no, no, no - that's prompt hell. It's not a character flaw. It's what happens when the tool removes the struggle, and the struggle was the part that taught you.
I'm not going to tell you to stop using AI. That advice is useless, and nobody follows it.
What actually works is narrower:
🔹 Write first, then ask. Attempt it yourself for ten minutes. Badly is fine. Then bring the AI in. The ten minutes is where the learning happens - everything after is editing.
🔹 Never accept code you can't explain. Not "I trust it." Explain it. If you can't, ask the AI to explain it, then check the explanation against the docs. It's wrong more often than you'd like.
🔹 Break things on purpose. Take working code, change one thing, predict what fails, check. Being right consistently is expertise. There's no other definition.
🔹 Once a week, build something small with nothing. No AI, no Stack Overflow. Thirty minutes. It'll be humbling the first few times. That humbling is the measurement you no longer get anywhere else. The developers who'll matter in five years aren't the ones who refused to use
AI, and they're not the ones who used it most. They're the ones who kept the struggle on purpose, after it stopped being mandatory.
Nobody's going to make you do that. That's the whole problem - and the whole opportunity.
💬 Honest answers only: how did you score on the three questions?
Forward this to someone who's shipping fast and quietly worried about it.
#learn @codingforweb
You remember tutorial hell. You watch a 12-hour course, you follow along, everything works, you feel like you're learning. Then you open an empty file to build something yourself, and you have no idea what to type. That's mostly gone now. AI killed it. Nobody's stuck watching tutorials - you just describe what you want, and something appears.
So we invented a worse version 😈
Prompt hell is this: you ship things. Real things. A working app, a dashboard, an API that people use. From the outside, you look like a developer who's doing fine. And you cannot build anything without AI. Not "it's slower without it." Cannot 😣
The difference from tutorial hell is what makes it dangerous. In tutorial hell, you knew you were stuck - the blank file told you every day. In prompt hell, everything works, so there's no signal, no discomfort, nothing telling you something's wrong. You can stay there for two years.
Here's the test. Three questions, answer honestly:
1️⃣ Can you read a function you shipped last month and explain every line - not what it does, but why it's written that way?
2️⃣ When something breaks, is your first move to think, or to paste the error?
3️⃣ Could you build a small version of your last project with no AI at all - badly, slowly, but finish it? If it's no, no, no - that's prompt hell. It's not a character flaw. It's what happens when the tool removes the struggle, and the struggle was the part that taught you.
I'm not going to tell you to stop using AI. That advice is useless, and nobody follows it.
What actually works is narrower:
🔹 Write first, then ask. Attempt it yourself for ten minutes. Badly is fine. Then bring the AI in. The ten minutes is where the learning happens - everything after is editing.
🔹 Never accept code you can't explain. Not "I trust it." Explain it. If you can't, ask the AI to explain it, then check the explanation against the docs. It's wrong more often than you'd like.
🔹 Break things on purpose. Take working code, change one thing, predict what fails, check. Being right consistently is expertise. There's no other definition.
🔹 Once a week, build something small with nothing. No AI, no Stack Overflow. Thirty minutes. It'll be humbling the first few times. That humbling is the measurement you no longer get anywhere else. The developers who'll matter in five years aren't the ones who refused to use
AI, and they're not the ones who used it most. They're the ones who kept the struggle on purpose, after it stopped being mandatory.
Nobody's going to make you do that. That's the whole problem - and the whole opportunity.
💬 Honest answers only: how did you score on the three questions?
Forward this to someone who's shipping fast and quietly worried about it.
#learn @codingforweb