How to Improve Your Coding Skills: 10 Habits That Separate Good Developers From Great Ones

You can write a for-loop in your sleep. You’ve finished three courses. You’ve built the same to-do app in two different frameworks. And you still can’t tell if you’re actually a good developer.

Here’s the problem. Six months of “coding every day” has barely moved the needle. You feel stuck, and you don’t know why.

The reason is simple: most people repeat what they already know and call it practice. Real improvement comes from a specific kind of practice, the kind that’s effortful and gives you fast feedback. It also comes from habits, not motivation.

This isn’t a list of skills to learn. It’s not a guide to writing your first program either. This article is about what to do differently once you can already code.

You’ll get 10 habits, each with a way to start this week, a signal that it’s working, and the common way people fake it. You’ll also get a way out of tutorial hell, an honest take on AI coding assistants, a weekly practice plan, and a way to actually measure whether you’re improving.

Why Most Developers Plateau (And What “Practice” Actually Means)

Hours don’t equal improvement. If you spend 10,000 hours writing CRUD endpoints, you become a fast CRUD-endpoint writer. That’s it. You don’t automatically become a better engineer.

Researchers Anders Ericsson, Ralf Krampe, and Clemens Tesch-Römer studied what actually separates expert performers from everyone else. Their answer wasn’t total experience. It was deliberate practice: work that targets a specific weakness, sits just beyond your current ability, gets repeated with immediate feedback, and feels genuinely uncomfortable while you do it.

Quick correction here. You’ve probably heard of the “10,000 hour rule.” That popular version isn’t what the research actually said, and Ericsson pushed back on it publicly. The number was never the point. The type of practice was.

So what does deliberate practice look like for a programmer? Simple: work on the specific thing you’re currently bad at, at a difficulty just above your comfort level, and get fast feedback on whether you got it right. It does not mean rebuilding a project you already know how to build.

The three plateaus every developer hits

Read these and figure out which one describes you right now.

The syntax plateau. You know the language cold, but you can’t decompose a problem. You read a solution and understand every line, yet you couldn’t have written it yourself.

The tutorial plateau. You follow instructions perfectly and build nothing alone. Open a blank editor with no tutorial to guide you, and you freeze.

The autopilot plateau. This is the working-engineer version. You ship tickets competently using the same three patterns every single sprint. Ask yourself: when was the last time you did something genuinely new, technically? If the answer is “over a year ago,” you’re here.

Improving coding skills vs. adding coding skills

These are two different problems. One is about which skills to acquire. That’s a checklist question, and it belongs to a different guide. The other is about getting better at what you already do. That’s a practice question, and it’s what this article covers.

If you’re looking for the checklist instead, check out the skills employers actually look for in a software developer. This article stays focused on method, not inventory.

10 Habits That Separate Good Developers From Great Ones

Here are the 10 habits, in order:

1. Practise your weaknesses, not your strengths
2. Read code written by better developers
3. Get your code reviewed, and review other people’s code
4. Build things without a tutorial
5. Learn to debug on purpose
6. Write tests before you trust your code
7. Contribute to someone else’s codebase
8. Explain what you built, out loud
9. Track your friction, not just your output
10. Rebuild something you already made, differently

Each one comes with four parts: what it actually means, how to start this week, the signal that tells you it’s working, and the failure mode people fall into when they fake it.

1. Practise your weaknesses, not your strengths

What it means: Keep a running “friction log.” Every time you Google something you should already know, or you avoid a task because it feels unfamiliar, write it down. That list becomes your practice syllabus.

Start this week: Pick whatever you’ve avoided the longest. Regex? Recursion? Async code? SQL joins? Git rebase? Spend 90 minutes on it, from scratch, without copying an answer.

Signal it’s working: The top item on your friction log changes every two or three weeks.

Common failure mode: You “practise” by re-solving problems in your strongest area because it feels productive. It isn’t. If practice feels comfortable the whole way through, it probably isn’t practice.

2. Read code written by better developers

What it means: Not skimming. Read with a question in mind. Pick a small, well-maintained open-source library you already use (a few thousand lines, not a giant framework) and trace one feature from start to end.

Start this week: Clone a repo you use regularly. Find where the function you call is defined. Follow it downward until you hit something you don’t understand, and write that down.

Signal it’s working: You start noticing why code is structured the way it is. You begin copying structural decisions, not just snippets.

Common failure mode: Jumping straight into famous codebases like the Linux kernel or React internals. You understand nothing, and you walk away thinking you’re not smart enough. You’re just too far above your current level. Start small.

If your day job runs on a legacy service-company codebase, this habit is free. Read the module sitting right next to yours.

3. Get your code reviewed, and review other people’s code

What it means: Code review is the fastest feedback loop available in software. It’s deliberate practice’s “immediate feedback” step, built right into your job.

Start this week: Ask a senior teammate for a review on your next pull request, and specifically ask them to flag anything that isn’t just a style nitpick. Then go review someone else’s PR before they ask.

Signal it’s working: The comments you get start repeating less. The comments you leave on others’ code get more specific over time.

Common failure mode: Treating review as a formality, approving quickly to avoid conflict, or only fixing what’s flagged without asking why it was flagged in the first place.

4. Build things without a tutorial

What it means: Pick a small idea, no instructions, no course. You decide the structure, you hit the errors, you fix them yourself.

Start this week: Choose a project you can finish in a weekend. A habit tracker, a simple API, a scraper for a site you actually check. No tutorial open in another tab.

Signal it’s working: You stop panicking at a blank editor. You start making small decisions confidently, even wrong ones.

Common failure mode: Picking a project so big you quit in week two, or secretly following a tutorial “just for the setup part” and never leaving it.

5. Learn to debug on purpose

What it means: Debugging isn’t a chore you rush through. It’s a skill with technique: reading stack traces properly, setting breakpoints, stepping through code line by line, forming a hypothesis before you touch anything.

Start this week: Next time you hit a bug, resist the urge to guess-and-check. Write down what you expect to happen, then step through the code with a debugger until you find exactly where reality breaks from expectation.

Signal it’s working: Your time-to-fix drops. You catch yourself forming a hypothesis before touching the code, instead of randomly changing lines and hoping.

Common failure mode: Sprinkling print statements everywhere and rerunning the whole program each time, instead of using a debugger to inspect state directly.

6. Write tests before you trust your code

What it means: A test isn’t paperwork. It’s proof. Writing one forces you to define what “correct” actually means before you claim your code works.

Start this week: Pick one function you wrote recently with no tests. Write three test cases for it: a normal case, an edge case, and a case designed to break it.

Signal it’s working: You start thinking about edge cases while you write the function, not after a bug report shows up.

Common failure mode: Writing one happy-path test and calling it “tested,” while every edge case ships untested straight to production.

7. Contribute to someone else’s codebase

What it means: Working inside code you didn’t write, with constraints you didn’t choose, teaches things solo projects never will.

Start this week: Find an open-source project you already use. Look for issues tagged “good first issue” and pick one. If open source feels intimidating, ask to shadow a bigger ticket at work instead.

Signal it’s working: You get faster at understanding unfamiliar code. Onboarding onto any new codebase starts taking less time.

Common failure mode: Endlessly browsing for the “perfect” first issue and never actually opening a pull request.

8. Explain what you built, out loud

What it means: This is the Feynman technique applied to code. If you can’t explain your solution simply, you don’t fully understand it yet.

Start this week: After finishing a task, explain it out loud to a rubber duck, a pet, or a patient friend, as if they know nothing about the problem. Notice exactly where you stumble.

Signal it’s working: Your explanations get shorter and clearer over time. You stop reaching for jargon to hide gaps in your own understanding.

Common failure mode: Explaining only the parts you’re confident about and quietly skipping the parts you don’t fully get.

9. Track your friction, not just your output

What it means: Most developers measure progress by lines of code or tickets closed. Track something better: what confused you, and how long it took to unstick yourself.

Start this week: Keep a simple log for one week. Every time you get stuck, note what it was and how long you were stuck.

Signal it’s working: The categories of things that confuse you shift over weeks. Old problems stop showing up on the list.

Common failure mode: Logging the friction and never actually going back to fix the recurring items.

10. Rebuild something you already made, differently

What it means: Take an old project and rebuild it with a constraint: a new pattern, no external library you leaned on last time, a stricter time limit.

Start this week: Pick a project from six months ago. Rebuild one part of it using an approach you’ve never tried, like switching from callbacks to async, or from a monolithic function to smaller composable ones.

Signal it’s working: The second version is measurably cleaner, and you can explain exactly why the first version was worse.

Common failure mode: Rebuilding it the exact same way and calling it practice, just because typing it again felt familiar.

How to Get Out of Tutorial Hell

Tutorial hell is what happens when you can follow any tutorial perfectly, finish it, feel good about it, and then sit down to build something on your own and freeze completely. You’ve learned to follow, not to build.

Here’s why it happens. Tutorials remove every decision for you. You never practise the actual hard part of programming, which is deciding what to do next when nobody’s telling you.

Getting out follows a clear path:

Stop starting new tutorials for anything you’ve already covered once.

If you’ve done three “build a to-do app” courses, you don’t need a fourth. You need to build one from a blank page.

Pick a project one size smaller than you think you’re ready for. 

Tutorial hell usually comes from overestimating the gap and reaching for a safety net instead of closing it gradually.

Permit yourself to build something ugly. 

The goal of your first tutorial-free project isn’t quality. It’s proving to yourself you can make decisions without a script.

When you get stuck, search for the specific error, not a full walkthrough. 

Reading documentation for one function is different from following a video for two hours. One builds a skill. The other rebuilds the trap.

Should You Use AI Tools Like Copilot While You’re Learning?

This is the one question every ranking article on this topic ignores completely, and it’s the most relevant question for 2026.

The honest answer: it depends entirely on how you use it.

AI coding assistants are excellent at removing friction. That’s exactly the problem, because friction is where learning happens. If Copilot writes your recursive function for you, and you accept it without understanding it, you’ve shipped code but you haven’t practised anything.

Use AI tools this way instead:

• Write your own attempt first, then compare. Struggle with the problem for real, then look at what the AI suggests and study the gap between your approach and its approach.
• Ask it to explain, not just generate. If it writes something you don’t fully understand, ask it to walk you through the logic before you accept the code.
• Use it to speed up the boring parts, not the parts you’re practising. Boilerplate, config files, repetitive syntax? Fine. The specific skill on your friction log this week? Do that one yourself.
• Treat accepted suggestions you didn’t understand as a red flag, not a win. Cognitive offloading feels productive in the moment and quietly erodes the exact skills you’re trying to build.

AI assistants are a tool, not a replacement for the deliberate-practice loop above. Used well, they speed up feedback. Used badly, they let you skip the discomfort that practice depends on.

A Simple Weekly Practice Plan

Pick two or three habits from the list above, not all ten. Trying to run all ten habits at once guarantees you'll do none of them well.

Here's a realistic weekly structure for someone with a full-time job or a full class schedule:

• 2 sessions of 90 minutes: deliberate practice on your top friction-log item.
• 1 session of 60 minutes: reading someone else's code or reviewing a teammate's pull request.
• 1 session of 60 minutes: building or extending a project with no tutorial open.
• 15 minutes daily: explaining what you worked on that day, out loud, to check you actually understand it.

If you're a student preparing for placements, swap one reading session for structured problem-solving practice, but don't let that become your entire week. Solving problems for interviews and getting better at building real software are related, but they're not the same skill.

How to Know Your Coding Skills Are Actually Improving

Nobody on this topic answers this question, so here's a straightforward way to check.

Time to first working version drops.

 The gap between "I understand the problem" and "I have something running" should shrink over months, not stay flat.

You debug faster and guess less. 

You form a hypothesis before touching code, instead of changing random lines and rerunning.

Your friction log rotates. 

New struggles replace old ones instead of the same three items sitting there for six months straight.

You can explain your own code to someone else without notes. 

If you can't, you understood it just enough to make it run, not enough to actually own it.

Other developers start asking you questions, not just the other way around.

If none of these are moving after a few months of consistent effort, don't just push harder. Change which habit you're focusing on, or find a mentor who can spot what you can't see yourself.

FAQ

How long does it take to get good at coding? 

There's no fixed number. It depends on how deliberate your practice is, not how many hours you log. Someone doing focused, feedback-rich practice for one hour a day will improve faster than someone coding four unfocused hours a day.

Does solving LeetCode problems make you a better developer? 

It sharpens a specific skill: pattern recognition for algorithmic problems, which matters for interviews. It does not, by itself, teach you to design systems, debug production issues, or work in a real codebase. Treat it as one tool among several, not your whole practice plan.

How many hours a day should I practise coding? 

Consistency beats duration. Ninety focused, uncomfortable minutes most days will move you further than three distracted hours occasionally.

Should I use AI while I'm still learning? 

Yes, but with your own attempt first. See the AI section above.

Conclusion

Getting better at coding isn't about grinding more hours or collecting another course. It's about picking a handful of habits that put you in that uncomfortable, just-beyond-your-level zone, and sticking with them long enough to see your friction log actually change.

Pick two habits from the ten above. Start this week. Check back in a month using the signals in the measurement section, not just a feeling.

If self-directed practice keeps stalling out, structured mentorship can close the gap faster than doing it alone.