Professionals on Habr: 10 Career Mistakes to Avoid

Career advice in the technology industry tends to focus on skills: learn this programming language, earn that certification, master these tools. What gets less attention are the meta-level mistakes — the errors in strategy, communication, and self-management that derail technically competent people. These are harder to codify because they are situational, interpersonal, and sometimes the result of personality traits that were strengths in one context becoming liabilities in another.

The following ten mistakes are drawn from the experiences of IT professionals who have shared their observations on Habr over the years. Some of these are uniquely common in the Russian IT market; others are universal. All of them are avoidable with sufficient self-awareness.

Mistake 1: Burning Bridges When Leaving a Job

The IT industry in any given city or specialization is smaller than it appears. The senior developer you treated dismissively when you quit is now CTO of a company where you are applying. The team lead you criticized publicly on social media works at a company your current employer is trying to partner with. The recruiter you ghosted after accepting a competing offer remembers.

Professionalism in departure means: giving adequate notice, completing knowledge transfer documentation, not taking proprietary code or data, and leaving without public recriminations even if you have legitimate grievances. You can discuss a bad employer privately with trusted colleagues. Broadcasting it to your social networks creates a permanent record and a reputation as someone difficult to work with.

Mistake 2: Neglecting Your Network When You Don't Need It

Most people think about professional networking only when they need a job. This is exactly backwards. A network built in desperation — when you are unemployed or urgently need a referral — is thin and transactional. A network built over years of genuine professional engagement, mutual assistance, and shared interest is durable.

The practical implication: maintain contact with former colleagues. Comment thoughtfully on their work. Share relevant information without expecting immediate return. Attend industry events even when you are happily employed. The relationships you build when you have nothing to ask for are the ones that deliver when you need them.

Mistake 3: Conflating Current Value with Future Value

A developer who is exceptionally productive in a familiar technology stack can develop a false confidence that generalizes poorly. The ten years of experience with one framework does not automatically translate to competence in a different paradigm. The person who has been a team lead in a 5-person startup may find themselves ill-equipped for the politics of a 500-person organization.

This mistake manifests most visibly in salary negotiations: candidates price themselves based on their value in their current context, not their value in the hiring organization's context. These can be very different numbers in either direction. The reverse error — underestimating your transferable value — is also common, particularly among developers who have solved genuinely hard problems but describe their work in overly technical terms that hiring managers cannot evaluate.

Mistake 4: Avoiding Visibility

Technical excellence is necessary but not sufficient for career progression. At some point, career growth requires that people in your organization know what you are working on and how well you are doing it. Many technically strong people are deeply uncomfortable with self-promotion and avoid it entirely, leading to a systematic undervaluation by their employers.

This does not require becoming insufferable. It means writing up the interesting problem you solved and sharing it with your team. It means speaking at the retrospective about what you learned. It means publishing the internal tool you built as open source and presenting it at a meetup. It means making your work legible to people who are not watching it happen day to day.

Mistake 5: Treating Every Job Change as a Salary Ratchet

The most reliable way to increase salary in many IT markets is to change jobs. This is a real pattern and sometimes the correct strategy. But pursued mechanically — changing jobs every 12–18 months primarily for salary increases — it produces a resume that signals job-hopping risk to many employers and forecloses access to work that only comes to people who have demonstrated long-term commitment.

Some of the most interesting technical problems, and some of the highest compensation packages, are found at companies that are building something complex over years, not months. These companies are rightly skeptical of candidates who have never held a job for more than two years. There is a version of career optimization that involves staying at a good organization long enough to ship something significant, then moving — rather than leaving before the interesting work has a chance to happen.

Mistake 6: Refusing Managerial Responsibilities Without Reflection

Many skilled individual contributors have a reflexive aversion to management. Some of this is justified: management in poorly-run organizations is genuinely unpleasant, and the skills required are different from those rewarded in individual technical work. But blanket refusal to develop any leadership capability is a career constraint that becomes more binding with seniority.

At the senior and staff levels, the ability to influence a team's direction, mentor junior engineers, lead technical design discussions, and manage stakeholder expectations is expected and rewarded. These are leadership skills, even if the job title does not say "manager." Refusing to develop them does not protect your technical identity; it limits your impact and eventually your earnings.

Mistake 7: Staying Too Long in a Comfortable But Dead-End Position

The opposite error from job-hopping: spending years in a role that is comfortable, pays adequately, and makes no demands for growth. The work is familiar, the colleagues are pleasant, and the commute is short. Five years pass. The technologies you are working with are no longer in demand. The skills you have not been developing are now required for the roles you would want. The market has moved, and you have not.

Career stagnation is particularly insidious because it is invisible from inside. You are busy, you are producing results, you have responsibilities. The problem is only apparent when you look at the market and discover that your skills are valued less than you thought, or when your company downsizes and you discover that the comfortable position was also the only position, with no transferable path outward.

Mistake 8: Underinvesting in Communication Skills

Technical skill has a ceiling as a differentiator. Beyond a certain level of competence, the engineers who advance are distinguished not by their technical depth but by their ability to communicate clearly with non-technical stakeholders, to write effective documentation, to give persuasive presentations, and to navigate organizational conflict constructively.

This is especially true for engineers who want to influence technical direction, not just implement it. The ability to write a clear, well-reasoned architecture proposal that a VP of Engineering can evaluate is more career-relevant than the ability to implement any individual system. The ability to explain a technical trade-off to a product manager without condescension opens doors that pure technical excellence cannot.

Mistake 9: Anchoring Identity Entirely to a Single Technology

"I am a Java developer." "I am a 1C specialist." Identity anchored to a specific technology is stable only as long as the technology is dominant. Technology cycles are shorter than careers. A developer whose entire professional identity is tied to a platform that is entering decline faces a painful choice: retrain while their current skills still have market value, or wait until the platform has fully declined and retrain from a position of weakness.

The engineers who navigate technology transitions well tend to have a stronger identity around problem-solving patterns — distributed systems, data modeling, user experience, security — than around the specific implementation technologies of a given era. The technologies change; the underlying problems are more stable.

Mistake 10: Treating Career Development as Someone Else's Responsibility

In large organizations particularly, there is a temptation to outsource career development to the company: to wait for the annual review, the promotion cycle, the assigned mentor, the mandatory training. This passive stance is a mistake even in organizations with genuinely good talent development programs, because the company's interests and your interests are not identical.

The company wants you to develop the skills that are useful for your current role and its near-term needs. You should want to develop the skills that will be most valuable across your career, including at other organizations. The training budget exists to serve the company's needs; your career development budget — in time, attention, and money — exists to serve yours. These overlap substantially, but they are not the same, and acting as if they are identical is how capable people find themselves with a decade of specialized experience in a proprietary technology that no one else is hiring for.

The Common Thread

Running through most of these mistakes is a kind of short-termism: optimizing for the near-term at the expense of the long-term, for comfort at the expense of growth, for the transaction at the expense of the relationship. Careers are long. The IT industry is small. Reputation compounds, in both directions, over years. The professionals who navigate this well tend to be the ones who internalized early that what they do now shapes the options available to them five and ten years later — and who make decisions accordingly.