You'll find no shortage of career motivational phrases surrounding failure: Fail fast, failure builds character, the key to success is failure, mistakes make you grow, never be afraid to fail. But the idea of mistaking your way to the top of the software industry is probably unsound. Every developer will have their share of missteps in a career but why not learn from others’ experience -- and avoid the costliest errors?
That’s what we did: We talked with a number of tech pros who helped us identify areas where mistakes are easily avoided. Not surprising, the key to a solid dev career involves symmetry: 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 -- a minefield you can easily avoid while you navigate a tech market that’s constantly changing.
Mistake No. 1: Staying too long
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 or “rightsizing,” depending on the buzzword favored at the time.
“The longer you stay in one position, the more your skills and pay stagnate, and you will get bored and restless.” -- Praveen Puri, management consultant
Opinions vary on how long you should stay in one place. Praveen Puri, a management consultant who spent 25 years as a developer and project manager before starting his own firm, isn't afraid to throw out some numbers.
“The longer you stay in one position, the more your skills and pay stagnate, and you will get bored and restless,” Puri says. “On the other hand, if you switch multiple jobs after less than two years, it sends a red flag. In my own experience, I stayed too long on one job where I worked for 14 years -- I should have left after six. I left other positions after an average of four years, which is probably about right.”
Michael Henderson, CTO of Talent Inc., sees two major drawbacks of staying in one place too long. “First, you run the risk of limiting your exposure to new approaches and techniques,” he says, “and secondly, your professional network won’t be as deep or as varied as someone who changes teams or companies.”
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,” says Mehul Amin, director of engineering at Advanced Systems Concepts. “But this can limit your growth and knowledge in other areas. Obviously staying a few months at each job isn’t a great look for your résumé, 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.”
Mistake No. 2: Job jumping
Let’s look at the flip side: Are you moving around too much? If that’s a concern, you might ask whether you’re really getting what you need from your time at a firm.
“Constant job hopping can be seen as a red flag.” -- Hilary Craft, IT branch manager, Addison Group
Charles Edge, director of professional services at Apple device management company JAMF Software, says hiring managers may balk if they’re looking to place someone for a long time: “Conversely, if an organization burns through developers annually, bringing on an employee who has been at one company for 10 years might represent a challenging cultural fit. I spend a lot of time developing my staff, so I want them with me for a long time. Switching jobs can provide exposure to a lot of different techniques and technologies, though.”
Those who move on too quickly may not get to see the entire lifecycle of the project, warns Ben Donohue, VP of engineering at MediaMath.
“The danger is 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,” Donohue says. “No matter how talented and knowledgeable you are as a technologist, you still need the ability to see things from the perspective of a user, and it takes time in a position to get to know user needs that your software addresses and how they are using your product.”
Hilary Craft, IT branch manager at Addison Group, makes herself plain: “Constant job hopping can be seen as a red flag. 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.”
Mistake No. 3: Passing on a promotion
There’s a point in every developer’s life where you wonder: Is this it? 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,” says Talent Inc.’s Henderson. “Management is a career change -- not the logical progression of the technical track -- and requires a different set of skills. Also, I’ve seen many companies push good technical talent into management because the company thinks it’s a reward for the employee, but it turns out to be a mistake for both the manager and the company.”
“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.” -- Scott Wilson, product marketing director, Automic
Get to know your own work environment, says management consultant Puri, adding that there’s no one-size-fits-all answer to this one.
“I’ve worked at some places where unhappy managers had no real power, were overloaded with paperwork and meetings, and had to play politics,” Puri says. “In those environments, it would be better to stay in development. Long term, I would recommend that everyone gets into management, because development careers stall out after 20 years, and you will not receive much more compensation.”
Another way of looking at this might be self-preservation. Scott Wilson, product marketing director at Automic, asks the question: “Who will they put in your place? If not you, they may promote the most incompetent or obnoxious employee simply because losing their productivity from the trenches will not be as consequential as losing more qualified employees. Sometimes accepting a promotion can put you -- and your colleagues/friends -- in control of your workday happiness. 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.”
Mistake No. 4: 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.
“I’ve found that mentoring junior developers has made me better at my job because you learn any subject deeper by teaching it than you do by any other method,” says Automic’s Wilson. “Also, as developers often struggle with interpersonal skills, mentoring provides great opportunities to brush up on those people skills.”
If experience is the best teacher, teaching others will only deepen your knowledge, says JAMF Software’s Edge. That said, he doesn’t hold it against a busy developer if it hasn’t yet happened.
“When senior developers don’t have the time to mentor younger developers, I fully understand. Just don’t say it’s because ‘I’m not good with people.’” -- Charles Edge, director of professional services, JAMF Software
“Let’s face it -- no development team ever had enough resources to deliver what product management wants them to,” Edge says. “When senior developers don’t have the time to mentor younger developers, I fully understand. Just don’t say it’s because ‘I’m not good with people.’”
Mistake No. 5: Sticking to your stack
Your expertise in one stack may make you invaluable to your current workplace -- but is it helping your career? Can it hurt to be too focused on only one stack?
MediaMath’s Donohue doesn’t pull any punches on this one: “Of course it is -- there’s no modern software engineering 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. Some would argue that isn’t a good thing -- if 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 can hurt your trajectory to be too focused on one stack, says Talent Inc.’s Henderson, but maybe for different reasons than you think.
“Every stack will have a different culture and perspective, which ultimately will broaden and expedite your career growth,” Henderson says. “For instance, I find that many C# developers are only aware of the Microsoft ecosystem, when there is a far larger world out there. Java has, arguably, the best ecosystem, and I often find that Java developers make the best C# developers because they have a wider perspective.”
Automic’s Wilson says proficiency -- but not mastery -- with one stack should be the benchmark before moving onto another.
“It’s time to move on when you are good at the skill, but not necessarily great,” says Wilson. “I’m not advocating mediocrity, just 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 that skill before you consider moving on.”
Finally, Talent Inc.’s Henderson offers this warning: “Avoid the expectation trap that each new 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 pain.”