Compare rates, not positions. Someone who started years earlier will be ahead for a while; that says nothing about how fast you are learning. Measure yourself against your past self, learn from people ahead of you instead of ranking against them, and make career decisions from your own plan.
What people tell me
I started learning to code later than most people around me. Some of my classmates or colleagues have been programming since school and they solve things in minutes that take me hours. Whenever I work next to them or see their projects, I feel slow and stupid. I know they had a head start, but the comparison still affects my confidence and sometimes makes me question whether I should continue.
A composite of the messages behind this question, with personal details left out.
Key takeaways
- Someone with a five-year head start will be ahead for a while. That is arithmetic, not talent.
- Measure your rate of progress against your own past, not your position against theirs.
- People ahead of you are a resource. Ask how they think, not just what they know.
- Late starters often bring focus, maturity and other experience that early starters lack.
- Make decisions from your plan and your goals, never from a ranking.
Positions versus rates
If someone has been coding for seven years and you have been coding for one, they will almost always be faster today. That is not a comparison of ability. It is a comparison of time. Judging yourself by it is like a runner who started ten minutes late judging their pace by how far behind the leader they are.
The number that matters is your rate: how much you are learning per month. And your rate can be excellent even while your position is behind. In my experience mentoring people who started late, many of them grow faster than early starters did at the same stage, because they are more deliberate about what they learn.
What early starters really have
It helps to be specific about what a head start gives someone:
| What they have | Is it permanent? |
|---|---|
| Speed with syntax and tools | No, it evens out with practice |
| Pattern recognition from many small programs | Largely closable in one to two years of steady work |
| Comfort being stuck | Learnable, and you are learning it now |
| Deep knowledge in some areas | Yes in those areas, but nobody knows everything |
| Confidence | Often more about familiarity than skill |
Most of this is closable. And the parts that are not do not decide whether you have a good career.
What late starters often bring
People who start later often come with things early starters are still learning: clearer goals, better time management, experience with other people, communication skills or knowledge of another domain. A developer who understands accounting, healthcare or teaching can be far more useful on some teams than one who only knows code. Do not throw those away in your head just because they are not programming.
Change what you measure
Comparison is hard to stop by willpower. It is easier to replace it with a better measurement. Once a month, answer these questions in writing:
- What can I build now that I could not build a month ago?
- What did I understand this month that confused me before?
- How long does a task like X take me now compared with before?
- What did I finish?
Keep the answers. After three months you will have evidence of your own progress, and that evidence is much harder for a bad day to argue with.
Learn from them instead of ranking against them
The people ahead of you are one of your best resources. Instead of watching their speed and feeling bad, ask about their process:
- "How did you know where to look for that bug?"
- "What would you read to understand this properly?"
- "How would you structure this if you were starting fresh?"
Most experienced people enjoy these questions. You get their years of experience in a few minutes, and the relationship becomes a collaboration rather than a competition.
Protect your decisions from the comparison
The real danger is not the uncomfortable feeling. It is making bad decisions because of it: switching paths, quitting, or rushing into advanced topics before the basics are solid. Make decisions against your own plan. Ask whether you are doing the work you set for this month, not whether you are as fast as the person beside you.
When it still hurts
Some days it will. On those days, do one small, concrete thing: fix one bug, finish one exercise, read one section. Action lowers the volume of comparison more reliably than any argument. And remember that nobody who is good today was good at the start.
An example of measuring your rate
Take one kind of task you do often, for example adding a new page with a form that saves to the database. Time yourself the first time you do it and write the number down. A month later, do a similar task and time it again. For many people the first attempt takes a full day and the one a month later takes two or three hours. That drop is your learning rate made visible. The person who started years earlier does not appear anywhere in that measurement, and they do not need to.
What to say when you feel slow next to someone
Instead of hiding that something takes you longer, try: "I am still getting faster at this. Would you mind showing me how you would approach it?" Or after a pairing session: "That was useful. What should I read to understand why you went straight to that file?" People with more experience rarely judge honest questions like these. They remember being where you are, and most are glad to help someone who is clearly trying.
If you are still stuck
Read How do I deal with feeling I am not good enough for a tech career?, What actually changes in your first two years as an engineer and What to do when you are stuck learning to code. If you want someone to look at your specific situation, join Sefism and, as a member, book a 1:1 session.
Was this answer helpful?
Read next
- What Actually Changes in Your First Two Years as an EngineerInterviews test the small part of the job that is easy to test, and the rest is learned on site. Reading code as the main skill, how to ask a question that costs nothing, why small shipped changes beat large ones in progress, using code review as the fastest teaching you will get, and the four things that actually get people promoted, three of which are not about writing code.
- What to Do When You Are Stuck Learning to CodeThere has never been more good material for learning to program and the failure rate has not improved, which tells you the bottleneck is not access to explanation. It is that watching someone else solve a problem feels exactly like learning and is not. Sixteen heuristics for the first year, mostly about what to do at the point where you are stuck.
Your situation is not quite this one?
Members get written answers to their own questions, a roadmap built for them and feedback on their projects. Early access is open to X and Instagram followers and university students. Prefer to talk? A free call works too.