Failure may lead to success, but unthinking complacency is a certain dev career killer
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, senior software engineer 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.
Hilary Craft, IT branch manager, Addison Group
“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,
“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.”
Mistake No. 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 can 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,” says MediaMath’s Donohue. “Soft skills and conversations with customers can 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 overengineering.”
Talent Inc.’s Henderson says your work with other people is a crucial part of developing a successful dev career.
“All human activities are social, and development is no exception,” Henderson says. “I once witnessed an exchange on the Angular mailing list where a novice developer posted some code with questions. Within an hour -- and through the help of five people -- he had rock-solid idiomatic Angular code, a richer understanding of Angular nuance and pitfalls, and several new contacts. Although the trolls can sometimes cause us to lose faith, the world is full of amazing people who want to help one another.”
Automic’s Wilson says a lack of soft skills is a career killer. Then when less proficient programmers move ahead developers who don’t have people skills -- or simply aren’t exercising them -- are left wondering why. Yet everyone loves bosses, he says, “who demonstrate 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,” Wilson says. “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, says management consultant Puri. “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.”
Mistake No. 7: Failing to develop a career road map
Developing goals and returning to them over time -- or conversely developing an agilelike, go-with-the-flow approach -- both have their proponents.
“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.” --Michael Henderson, CTO, Talent Inc.
“I engineer less for goals and more for systems that allow me to improve rapidly and seize opportunities as they arise,” says Henderson. “That said, 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 maybe equally as important -- where you don’t want to go.
“Early in my career, I hadn’t learned to say no yet,” says Edge, of JAMF Software. “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.”
Automic’s Wilson gives a pep talk straight out of the playbook of University of Alabama’s head football coach Nick Saban, who preaches having faith in your process: “The focus is in following a process of success and using that process as a benchmark to hold yourself accountable. To develop your process, you need to find mentors who have obtained what you wish to obtain. Learn what they did and why they did it, then personalize, tweak, and follow.”
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, senior software engineer 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.
Hilary Craft, IT branch manager, Addison Group
“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,
“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.”
Mistake No. 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 can 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,” says MediaMath’s Donohue. “Soft skills and conversations with customers can 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 overengineering.”
Talent Inc.’s Henderson says your work with other people is a crucial part of developing a successful dev career.
“All human activities are social, and development is no exception,” Henderson says. “I once witnessed an exchange on the Angular mailing list where a novice developer posted some code with questions. Within an hour -- and through the help of five people -- he had rock-solid idiomatic Angular code, a richer understanding of Angular nuance and pitfalls, and several new contacts. Although the trolls can sometimes cause us to lose faith, the world is full of amazing people who want to help one another.”
Automic’s Wilson says a lack of soft skills is a career killer. Then when less proficient programmers move ahead developers who don’t have people skills -- or simply aren’t exercising them -- are left wondering why. Yet everyone loves bosses, he says, “who demonstrate 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,” Wilson says. “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, says management consultant Puri. “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.”
Mistake No. 7: Failing to develop a career road map
Developing goals and returning to them over time -- or conversely developing an agilelike, go-with-the-flow approach -- both have their proponents.
“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.” --Michael Henderson, CTO, Talent Inc.
“I engineer less for goals and more for systems that allow me to improve rapidly and seize opportunities as they arise,” says Henderson. “That said, 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 maybe equally as important -- where you don’t want to go.
“Early in my career, I hadn’t learned to say no yet,” says Edge, of JAMF Software. “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.”
Automic’s Wilson gives a pep talk straight out of the playbook of University of Alabama’s head football coach Nick Saban, who preaches having faith in your process: “The focus is in following a process of success and using that process as a benchmark to hold yourself accountable. To develop your process, you need to find mentors who have obtained what you wish to obtain. Learn what they did and why they did it, then personalize, tweak, and follow.”
No comments:
Post a Comment