The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
If you feel you have stopped improving as a developer, start by naming the specific work that feels stuck. “Getting better” might mean finding bugs faster, making sounder design decisions, writing more reliable tests, or communicating technical trade-offs more clearly. The evidence does not establish that most developers reach a uniform plateau—or that one method reliably breaks it. It does suggest that time in the job alone is a weak stand-in for performance on particular tasks.
Why can years of experience feel like progress without proving it?
Routine work builds familiarity, but familiarity is not the same as deliberate improvement. A task can become easier because you have seen similar problems before, while a different task—such as debugging unfamiliar code or evaluating system-level trade-offs—remains difficult.
A 2017 exploratory study by Dieste and colleagues analyzed 10 quasi-experiments involving graduate and postgraduate students and industry professionals. Participants used iterative test-last development on two problems; researchers measured external code quality and productivity. The study’s abstract reports that industry programming experience did not appear to affect those outcomes and that years of experience were a poor predictor of programmer performance. Academic experience and task-specific knowledge appeared more predictive in those experiments. Read the Monash University research record.
That result is limited to the study’s experimental tasks and measures. It does not show that experience never matters, or that tenure says nothing about design, collaboration, leadership, or other engineering work. It is a reason not to use years worked as the only measure of growth.
#1 Best Overall
What does “better developer” mean for your work?
Software-development expertise is not one universal score. Baltes and Diehl’s 2018 conceptual theory treats expertise as task-specific: competence in one kind of work does not automatically establish competence in another. It also recognizes that experience and knowledge can transfer from related tasks, while noting that self-assessments depend on context and that software performance is hard to measure objectively. The theory is not a diagnostic tool for predicting an individual’s career path. Read the paper.
Translate “I’m stuck” into a capability and an outcome you can observe. For example:
Rank #2
- Debugging: identify the cause of a recurring class of failures with less speculative code change.
- Design: explain the trade-offs behind a proposed interface or architecture, including what would make you choose differently.
- Testing: catch relevant regressions with tests that cover behavior rather than implementation details alone.
- Systems reasoning: trace how a change could affect dependencies, performance, reliability, or operations.
- Language fluency: use the target language’s semantics and ecosystem appropriately, rather than translating habits from another language unchanged.
- Teamwork: make technical decisions and risks legible to teammates, and incorporate useful review feedback.
These are examples, not a definitive competency checklist. A Microsoft Research report drew on interviews with 59 experienced engineers across 13 divisions and identified 54 attributes associated with great engineers—an indication of how broad engineering contribution can be, not a universal scorecard. Read the report appendix. A separate two-month in-situ qualitative study of developers in their first six months at Microsoft observed coding, debugging, designing, and team engagement, reinforcing that work extends beyond writing code. Read the study.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Fix the driver behind crashes, sound loss and screen glitches3Clear out junk files and repair common Windows errorsHow can you practice a skill instead of repeating familiar work?
Choose a narrow skill gap, then set up work that makes practice and feedback possible. This is a practical application of deliberate-practice ideas, not a developer coaching routine proven by the cited overview.
- Pick a recurring difficulty. Use a recent code review, incident, bug, or project delay to identify the task that caused uncertainty or rework.
- Define an observable goal. Replace “be better at architecture” with something checkable, such as documenting two viable designs and the trade-offs before choosing one.
- Choose a realistic stretch task. Work on something just beyond your current comfort zone, with enough time to investigate and revise rather than only deliver the first workable answer.
- Get timely, specific feedback. Ask a teammate to review the decision or result against the goal. Useful feedback points to what worked, what did not, and why.
- Review the gap and repeat with an adjustment. Compare your result with the goal, note the misconception or missed signal, and try a revised approach on a later task.
In a 2008 overview, psychologist K. Anders Ericsson described deliberate practice as focused training that includes immediate feedback, time for problem-solving and evaluation, and repeated performance to refine behavior. The overview discusses expertise in areas including chess, music, typing, and sports in relation to medicine; it is not a trial showing that a particular practice plan improves software developers. Read the overview.
Practice can stall when a learner’s misconception or loss of confidence makes a task feel unmanageable. In a 2013 programming-education paper, Scott and Ghinea proposed adaptable learning support, “soft scaffolding,” detailed informative feedback, and support for learners’ self-enhancement alongside skill development. That work offers useful considerations for learning design, not proof that a particular workplace intervention will work for every developer. Read the paper.
Rank #4
Why can switching programming languages make you feel less experienced?
Knowledge from one language can help with another, but familiar assumptions can also mislead. A 2020 study by Shrestha, Botta, Barik, and Parnin examined Stack Overflow questions across 18 programming languages. Among 450 inspected questions, the researchers reported 276 instances of interference attributed to faulty assumptions carried over from another language; they also interviewed 16 professional programmers. These figures describe that study’s sample, not the prevalence of language-transition problems among developers generally. Read the study.
When moving to a new language, treat “this worked in my previous language” as a question to verify. Compare how the target language handles the concepts relevant to your task, and check its documentation and ecosystem examples before applying a familiar pattern. The study documents interference; it does not test these steps as a remedy.
Best Value
- Used Book in Good Condition
How can you tell whether you are actually improving?
Use evidence tied to the skill you chose, not a vague sense of confidence or a calendar measure. Depending on the task, evidence could include fewer repeated review comments on a specific issue, more reliable identification of a bug’s cause, clearer explanations of design trade-offs, or tests that catch the failure modes you set out to cover. No single indicator captures all engineering ability; interpret it in the context of the work and ask for feedback from people who saw the process as well as the result.
Quick Recap
- What work that once required help or repeated correction is now routine?
- Which current task still produces uncertainty, avoidable rework, or missed risks?
- What specific feedback could reveal the gap between your approach and the outcome you want?
- What observable result in your next project would count as progress on that gap?
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
