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 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.
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.
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.
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 software 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:
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.
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:
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.
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.
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.
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.
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:
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.
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.
Geoffrey is an experienced software developer and open source evangelist. When not coding he writes and talks about current technology trends, small business tips and developer productivity hacks. He is no coffee addict.
9 Skills That Will Get You a Junior Penetration Tester Job
7 Tips for Landing Your First Client as a Freelance Developer
How to Jumpstart Your Software Engineering Career Today with Udemy Courses
Top Courses on Udemy to Sharpen Your Software Testing Skills in 2017
How to Install Sublime Text 3 in Windows
How to Create a PHP Abstract Class