7 Silly Mistakes Developers Make That Will Ruin Your Career

The idea of mistaking your way to the top of the software industry is definitely dumbfounded.

Every developer will have their share of missteps in a career but you could learn a great deal from others people’s experiences and save yourself the hassle. Thereby avoiding some of the most costly errors.

Often than not, the key to a solid software developer career always involves  striking a balance: Not staying with one stack or job too long, for example, but then again not switching languages and employers so often that you raise red flags.

Here are some of the most notable career traps for engineers that can potentially ruin your career and that you need to avoid while you navigate a tech market that’s constantly changing.

1. Staying too long at one job

These days it’s rare to have a decades-long run as a developer at one firm.

In many ways, it’s a badge of honor, showing your importance to the business or at least your ability to survive and thrive. But those who have built a career at only one company may suddenly find themselves on the wrong end of downsizing.

The longer you stay in one position, the more your skills and pay stagnate, and you will get bored and restless.

There is no iron rule on how long you should take at a job. In my recent interview with Rob Percival, he declines to give a particular figure to go by.

Related: Top 15 Best Coursera Courses & Specializations To Take in 2018

Opinions vary on how long you should stay in one job. In my opinion I think leaving a position after an average of 2 -3 years is probably about right.

If you stay at a job for too long, you run the risk of limiting your exposure to new approaches and techniques.

Besides, your professional network won’t be as deep or as varied as someone who changes teams or companies.

This however can limit your growth and knowledge in other areas.

Obviously, staying a few months at each job isn’t a great look on your resume, but employee turnover is pretty high these days and employers expect younger workers like recent college graduates to move around a bit before staying long-term at a company.

2. Job hoping too often

Consider the other side of the coin. Are you moving around too often? If that’s a concern, you might want to ask yourself whether you’re really getting what you need from your time at a firm.

Constant job hopping can be seen as a red flag.

Besides, those who move on too quickly may not get to see the entire life-cycle of the project which is really great and essential for your learning and experience.

You risk becoming a mercenary, a hired gun, and you miss out on the opportunity to get a sense of ownership over a product and build lasting relationships with people.

No matter how talented and knowledgeable you are as a web developer, you still need the ability to see things from the perspective of a user. 

It takes a great deal of time in a position to get to know end user needs that your software addresses and how they are using and interacting with your product.

Employers hire based on:

  • technical skill,
  • dependability, and more often than not,
  • culture fit.

Stability and project completion often complement these hiring needs.

For contractors, it’s a good rule to complete each project before moving to the next role. Some professionals tend to ‘rate shop’ to earn the highest hourly rate possible, but in turn burn bridges, which won’t pay off in the long run.

3. You are passing on a promotion

There’s a point in every developer’s life where you wonder: Is this all? If you enjoy coding more than running the show, you might wonder if staying put could stall your career.

Moving into management should be a cautious, thoughtful decision.

Management is a career change, not the logical progression of the technical track, and requires a different set of skills.

There are many companies who push good technical talent into management because the company thinks it’s a reward for the employee.

Everyone should be in management at least once in their career if for nothing else than to gain insight into why and how management and companies operate.

This goes a long way to help you get to know your own work environment because there’s no one-size-fits-all answer when it comes to this.

However, I have experienced some cases where unhappy managers:

  • had no real power,
  • were overloaded with paperwork and meetings, and
  • had to play politics to get along.

In those environments, it would be better to stay in development.

For the long term goal though, I would recommend that everyone gets into management, because development careers stall out after 20 years, and you will not receive any much more compensation beyond that time.

Sometimes accepting a promotion can put you, and your colleagues/friends, in control of your workday happiness.

4. You are not paying it forward

A less obvious mistake might be staying too focused on your own career track without consideration of the junior developers in your office.

Those who pair with young programmers are frequently tapped when a team needs leadership.

Mentoring junior developers has made me better at my job. I learn any subject deeper by teaching it than I do by any other method.

Again, as developers often struggle with interpersonal skills, mentoring provides me a great opportunity to brush up on these people skills.

If experience is the best teacher, then be rest assured that teaching others will only deepen your knowledge.

Never make the statement ‘I’m not good with people’, it just comes out as lazy and careless.

5. Sticking to your one favorite stack

Your expertise in one stack may make you invaluable to your current workplace, but is it really helping your software development career? Can it hurt to be too focused on only one stack?

Focusing too much on one stack used by your current employer obviously is great for the firm but maybe not for you.

It’s a benefit to other employers looking for a very specialized skill set, and every business is different.

There’s no modern software development role in which you will use only one technology for the length of your career.

If you take a Java developer that has been working in Java for 10 years, and all of a sudden they start working on a JavaScript application, they’ll write it differently than someone with similar years of experience as a Python developer.

Each technology that you learn influences your decisions. If say you take a Java object-oriented approach to a loosely typed language like JavaScript, you’ll try to make it do things that it isn’t supposed to do.

It will hurt your trajectory to be too focused on one stack.

Every stack has a different culture and perspective, which ultimately will broaden and expedite your career growth. For example, many C# developers are only aware of the Microsoft ecosystem, when there is a far larger world out there. If you have used Bitbucket for version control for a long time, you might consider trying out Github.

Proficiency, but not mastery, with one stack should be the benchmark before moving on to another shinny stuff.

You’ll know it’s time to move on when you are good at the skill, but not necessarily great.

This is not to say I’m advocating for mediocrity, in fact it’s exactly the opposite. I am saying that before you head off to learn a new skill make sure you are good, competent, or above average at your current skill before you consider moving on.

You must avoid the expectation trap that each new programming language is simply the old one with a different syntax.

Developers of C# and Java who try to force JavaScript into a classical object-oriented approach have caused much unnecessary pain to themselves and their team members.

6. Neglecting soft skills

Programmers are typically less outgoing than, say, salespeople. No secret there.

But soft skills can be picked up over time, and some of the nuances of developing a successful career, like learning from mentors and developing relationships, can be missing from your career until it’s too late.

Soft skills and conversations with customers will also give a great sense of compassion that will improve how you build. You begin to think about what the customers really need instead of over-engineering.

It makes for better software when people talk. 

Let me stress the point that your work with other people is a crucial part of developing a successful developer career.

All human activities are social, and development is no exception.

A lack of soft skills is a career killer.

Haven’t you seen when less proficient programmers move ahead, then developers who don’t have people skills or simply aren’t exercising them are left wondering why?

Don’t you agree that everyone loves a boss who demonstrates tact and proficient communication?

To improve your soft skills, the:

  • Internet,
  • e-courses,
  • friends, and
  • mentors

are invaluable resources if you are humble and remain coachable.

Besides, we will all reach a point in our career when we will need to lean on relationships for help.

If no one is willing to stand in your corner, then you, not they, have a problem, and you need to address it.

In my career, I have valued coachable people over uncoachable when I have had to make tough personnel decisions.

Programming is only one aspect of development.

The big part is being able to communicate and understand business objectives and ideas, between groups of people with varying levels of technical skills. I’ve seen too many IT people who try to communicate too much technical detail when talking with management.

7. You fail to develop a career road map

Developing goals and returning to them over time, or conversely developing an agile-like, go-with-the-flow approach both have their proponents.

Make a list of experiences and skills that you’d like to acquire and use it as a map, updating it at least annually.

I engineer less for goals and more for systems that allow me to improve rapidly and seize opportunities as they arise.

Having said that, I recommend making a list of experiences and skills that you’d like to acquire and use it as a map, updating it at least annually.

Knowing where you’ve been is as useful as knowing where you want to go. And of course equally as important, where you don’t want to go.

Early in my career, I hadn’t learned to say NO yet.

So I agreed to a project plan that there was no way could be successfully delivered. And I knew it couldn’t.

If I had been more assertive, I could have influenced the plan that a bunch of nontechnical people made and saved my then-employer time and money, my co-workers a substantial amount of pain, and ultimately the relationship we had with the customer.

What are your some of the mistakes you’ve made as a developer that hampered the successful progress of your career?

Please share your thoughts in the comments below.

14 thoughts on “7 Silly Mistakes Developers Make That Will Ruin Your Career”

  1. Nice tips.

    I think there’s one more thing that would ruin a developer career, which is “lazy” attitude.

    If a developer keeps giving himself excuse not to do a difficult task or use an alternative way (which is worse than the original one), the developer will never get improved. In my opinion, I think nothing is impossible to do in technology, the more difficult task will just take more time to finish, but everything is just about project management and timeline, but it’s not an excuse for a developer saying that “I can’t do it”, which I have heard many times from my previous colleagues.

    • You are right. When a developer just says ‘No, I can’t do it’ without even giving much thought to it, it comes out as lazy.

      I also agree that it boils down to time management. When there is a bigger problem you break it down into smaller pieces that you can solve one bit at a time. Finally what appeared too hard and impossible finally got solved.

      Thanks for stopping by Ken.

  2. Really great tips. I couldn’t agree more.

    By the way your follow on Twitter button isn’t working from iPhone 7plus chrome browser (not sure about other browsers). I tried following you and it doesn’t do anything. I would like to follow you on Twitter though. Hit me back with your Twitter handle.


Leave a Comment