Why do software developers give up the 1-year mark?

Updated on : December 8, 2021 by Mayson Wilkins



Why do software developers give up the 1-year mark?

Money and regain strength.

If you look at the two or three year mark, we often start to see organizational or management changes, the departure of some other really great engineers, etc., but right at the one year mark or often of? 13 to 14 months? That is sometimes the case still, but less often.

Retention bonus and first stock distribution!

So every company is a little different here, but I can tell you that in a couple of places I've been, there's a signing bonus, then a 12-month retention bonus, which can be substantial (think $ 10k +).

Also, with stock options or even RSU, what can happen is that you '

Keep reading

Money and regain strength.

If you look at the two or three year mark, we often start to see organizational or management changes, the departure of some other really great engineers, etc., but right at the one year mark or often of? 13 to 14 months? That is sometimes the case still, but less often.

Retention bonus and first stock distribution!

So every company is a little different here, but I can tell you that in a couple of places I've been, there's a signing bonus, then a 12-month retention bonus, which can be substantial (think $ 10k +).

Also, with stock options or even RSUs, what can happen is that you sign a 4-year distribution where 25% comes in a lump sum after 12 months, and then the distributions take place every month after that. . So while leaving that $ 3,500 / month stock bonus hurts, leaving more than $ 40,000 on the table (plus the retention bonus) is comparatively very difficult.

Resume forces.

I have a role on my resume that was less than a year old. Lead Software Developer at CenturyLink for 6-7 months. Essentially, CenturyLink acquired a startup and while I loved them and the team was amazing, I joined just as the team was disbanding and their "golden handcuffs" were falling off.

When I started I was developer 11 or something like that, and when I left I was one of 3 developers without a director.

All recruiters and development managers have asked me about that job.

Each and everyone since then, no exceptions. Why the hell did I leave after such a short time? What the hell is wrong with me? Am I going to leave your company after 6 months and cost you a fortune? Am I difficult to work with? What the hell is going on!?

Now, putting that together with 4.5 years at SAP beforehand and almost 3 years at Smartsheet after, has meant that I still get the call, but what if I had 2 or 3 of those? No possibility.

But a year? It is not a big problem.

As long as I have my partner of places with 2 to 5 years, I am golden if I take another concert for a year and I leave or whatever. Hell, even taking time off to start my own company, get a master's degree, etc., people won't really mind. You can see that historically, if I am presented with a good team / company, I am dedicated.

But in my experience, the jobs that people leave in a year are usually jobs that they wanted to leave after 2 months, but basically get stuck due to current industry paradigms. They have to keep up appearances and no one wants to leave 50-100 of the greats on the ground behind them.

There are many reasons, money, technology, recognition. It's hard to find a good balance to keep people going.

Ultimately, while trying to keep them is futile as they all have their reasons or even no reason at all ... developers can do things for no reason at all, so don't try to predict them. What you want to do is create positions that anyone can get off the street and into with just a few days or weeks of training. Otherwise you cannot scale.

If that means sitting down throwing away everything you have and building from scratch, so be it. Sit your developers around a table and ask them how

Keep reading

There are many reasons, money, technology, recognition. It's hard to find a good balance to keep people going.

Ultimately, while trying to keep them is futile as they all have their reasons or even no reason at all ... developers can do things for no reason at all, so don't try to predict them. What you want to do is create positions that anyone can get off the street and into with just a few days or weeks of training. Otherwise you cannot scale.

If that means sitting down throwing away everything you have and building from scratch, so be it. Sit your developers around a table and ask how they would build the current application from scratch. You will be amazed at the responses you get. Sometimes you can go from 1 million to 10k lines or less of code.

Actually, this could be the number one reason that developers, especially early in their careers, go off at the one-year mark ... they see the stack, they see that only a few people in the entire organization know how. stand up or even hold the pile (so called job security) then they leave because they perceive the pile as outdated or outdated or not good for their careers or whatever comes to mind. It is much easier to find a new job, with new expectations and a new beginning (and a new accountant) than to stay in an organization somehow drawing the knowledge of all the necessary people and learning in depth how a system works. Expectations generally increase year after year.

Generally, “junior” type developers without much work experience or fresh out of school can expect a massive salary increase after a year (this gives you a few more years), followed by salary increases of 10-15% on each change of work. Of course you can and should always negotiate much more.

The current "happiness" threshold for jobs is around 120,000, the research says ... it used to be 70,000, but new research says that happiness through money actually peaks much higher. Of course, this depends on the person, but what it means is that, on average, someone looking for a "living wage" and doing something technically painful will continue to move until they get a six-figure salary. I'll tell you a secret, yes, developers love it, but for most (almost everyone) it's just a job and they are trying to support their families.

Most developers want a six-figure salary.

If you desperately want to keep someone, but don't want them to become complacent, a good way is to massively increase it after the first year to about six figures (but not quite), this will scare off the mercenaries but keep the ones who are trying to build a life. It could be a bonus of 90k more to overcome them.

Otherwise, build your business (and technology) assuming people will leave because you can't control it.

Good luck.

I can only tell you why I quit jobs, and I quit many of them over the years. Some at the 1 year mark; one after some more than that.

Only once did I quit a job that was challenging and where I felt I could do a good job; in that case someone came along and gave me a huge raise in salary and liability, and I couldn't turn it down (I should have, in hindsight).

So that's it, really: I'm leaving because the job isn't challenging * and * I've felt like I couldn't do a good job, both at the same time. I have also not left a job after a short period of discomfort. I am the

Keep reading

I can only tell you why I quit jobs, and I quit many of them over the years. Some at the 1 year mark; one after some more than that.

Only once did I quit a job that was challenging and where I felt I could do a good job; in that case someone came along and gave me a huge raise in salary and liability, and I couldn't turn it down (I should have, in hindsight).

So that's it, really: I'm leaving because the job isn't challenging * and * I've felt like I couldn't do a good job, both at the same time. I have also not left a job after a short period of discomfort. I'm the type of person who takes pleasure in explaining to my boss what problem (s) I have with the current situation, offering options, listening to and working with him or her, and trying to make things work. In all cases, I have left after at least a year of boredom and inability to affect the direction of my team. Life is short and my skills are interchangeable; I believe that a year without any changes and with no way to make changes is enough. If they offer me options that could be later, I would stay, while progressing, but if I do not see anything, Why would I stay? There is always someone else who will provide a challenging environment with real responsibility, enough authority to do a good job, and an adequate salary.

And honestly, when have you seen a good developer leave a company if they had the authority to do a good job? I bet it comes down to that for more than half of the developers leaving.

  1. Mental health is very important and is worth more than money. Just a little warning though, years ago my friend moved from a high paying managerial position and moved across the country and took a big step down in his career, both in responsibilities and salary, because he was unhappy and stressed. . Unfortunately, his stress and unhappiness did not improve, the problems were very much in him and did not come from his situation. It took him a while to realize that stress was worth addressing to be sure where it came from before making drastic changes.
  2. Frequent relocation: another friend has dec
Keep reading
  1. Mental health is very important and is worth more than money. Just a little warning though, years ago my friend moved from a high paying managerial position and moved across the country and took a big step down in his career, both in responsibilities and salary, because he was unhappy and stressed. . Unfortunately, his stress and unhappiness did not improve, the problems were very much in him and did not come from his situation. It took him a while to realize that stress was worth addressing to be sure where it came from before making drastic changes.
  2. Frequent Relocation - Another friend has decided to quit his high paying job for various reasons. While the compensation, benefits, and perks of the business are incredible, relocation is required every 2-5 years. The requirement was to move to New York, then to Los Angeles and other interesting places. Your locations are state capitals in the US, most of which are boring and uninteresting (some are great though). You've been living in a somewhat unsatisfying state capital for three years and you've decided that the location really matters to you. So don't think you want to maintain the lifestyle that this company requires. He's also moving to close the distance with his long-distance girlfriend because he got a job in his city.
  3. Backstabbing - A lot of stress, backstabbing, mischief, and a cacophony of people talking and not saying anything, taking up all of your mental bandwidth. Great compensation, incredible benefits, etc. People would kill for it. Despite all that, you will be depressed about everything and you will not be able to relax even on a Sunday. not to mention working like a dog. Never a day where you wake up happy to go to work and feel like at the end of the day you accomplished something great for people.
  4. Stress: Product engineers are high-stress jobs in a technology-related field. He doesn't get home until 8:00 p.m. M. Most nights, constant anxiety about work, crying, I can't forget it. I don't know what to say, but I can say that this job is probably having an adverse effect on relationships. It's about what you personally value. People would come out. Work doesn't have to make you happy, but it shouldn't make you miserable.
  5. Trying to get richer and richer - So much ambition to get all kinds of high-class materialistic stuff.
  6. Solid passion for art: working on something that is more interesting / fun than what you are currently working on
  7. Family situation: if your family wants you to have their 'home', this is more emotional and there is no compensation for this

Apologies for the anon, I don't want to be judged.

Ok, first, yes, many engineers quit every 2 years, and yes, as stated before, many of them do so because they are experts who stand out from others and seek more exciting jobs. Some of them are experts like no other and find good jobs in well-paying companies (Google, Amazon, etc.)

But there are also engineers who, although they are good, do not really stand out much. Still, they are great and will gain more experience over time with hard work and study. And there is work in many places. The most common in the case of the c

Keep reading

Apologies for the anon, I don't want to be judged.

Ok, first, yes, many engineers quit every 2 years, and yes, as stated before, many of them do so because they are experts who stand out from others and seek more exciting jobs. Some of them are experts like no other and find good jobs in well-paying companies (Google, Amazon, etc.)

But there are also engineers who, although they are good, do not really stand out much. Still, they are great and will gain more experience over time with hard work and study. And there is work in many places. The most common in the case of the city in which I live? Consulting companies.

When I started, I was in one. He paid me little but it was fine because I was just starting out. I worked hard and sometimes the deadlines were crazy, but it was okay. I got my first raise in a year, and I won over two years, and then ... my contract was terminated, so I had to resign. I was disheartened at the time thinking that I had done something wrong, but then I met a lot of my co-workers as well, right at the same time that it happened. So what happened? The customers changed. You see, when an IT consulting company loses a big client, people lose jobs like me. That was one of my first lessons in this career. Then I went to my next job, which was almost like the last one, except I was getting paid more and the work was still hard. I did a full year and was planning to stay. People told me they were happy with me. But when the year ended, I left. Why? Now that was more off the mark. You see, at this company I met a software architect and learned a lot from him. We even became great friends. Okay, I am aware that my skill was not very good and yet I improved and worked hard, and my bosses were happy with me, so they rated me average and I stayed. My friend, the architect, was even cooler. One month he stayed overnight to finish project work and slept 3 hours a day. For every mistake or mismanagement, bosses yelled at him. One time he got so hot that my boss was practically insulting him. His tenure with the company was more than three years. At the beginning of the project, the boss promised him a big raise if they finished on schedule, but after he finished, he gave nothing. A 3% increase like me, who made much less, and rated it average. I was furious. At lunch I told him that I was wasting my time in that place and I realized that I was too. Luckily, he took my advice and got a much better job. I also found another one next year. The key here was that the timeline was too ambitious and it was done by someone who was not only not part of the project, but did not know the tools and methodology we use (if there were any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) rather, he did not know the tools and the methodology we use (if there were any to begin with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) rather, he did not know the tools and the methodology we use (if there were any to begin with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis) and performed by someone who not only was not part of the project, but did not know the tools and the methodology we used (if there was any to start with). So, second lesson. You only grow in a consulting company if you work on a project with a reasonable schedule or one that is at least achievable (in times of crisis)

In my third job, I worked for a telecommunications company. That was one of the best experiences of my life. I learned new code platforms, met great people, and made even more money. I could even do more things in my spare time. That was the best. Every year he improved in salary and experience. And then ... I found another ugly side to this career. Telcom decided to outsource all the work for more profit next year. So they outsourced to… you know who? Yes. Another consulting company. However, this one was bigger. I signed with them when Telcom was closing its office in my country and I started working with them. And well, salary wise, nothing changed, and my workload is fine, but, well, most of the people I knew left. The experience I am getting is basically not enriching (maintenance work?) And they have not established a proper system for paying overtime or raises. So yeah ... I want to quit again.

My point is that some engineers change jobs to keep increasing not only their experience but also their salary. I hope that there are cases that show that I am wrong, but in the more than 7 years of work that I have been working in this career and especially for consulting companies, I have not found a consulting company that really bets on the growth of its employees seriously . And if they do, I have only seen in 3 cases:

You are a person related to business (manager, etc.)

You have worked for the company for a long time and know key people who can vouch for you (meet people)

You are an exceptional expert and are fortunate to have a word on estimating the deadline or having achievable deadlines for the project (and by feasible, I mean at least with crisis time included)

If not, well ... study, improve, be faster, be a good team player, and get jobs that recognize your greatest ability. I read that it has its limits, but if you are not a sociable person like me, and not too greedy then you can become a very good coach with a lot of effort and discipline. If, on the other hand, you are greedy, well ... learn skills with people. Because business is about people and many other things. Anyway, I just wanted to throw that perspective there. Hope it helps a bit.

People are different.

Some people may consider the crappy codebase to be just "part of the job". It is perfectly reasonable when you do your job for the sole purpose of making money. You sell your time and you don't care much what happens between 9 and 5. Anyway, it is not your problem to solve it.

But things are very different if you do your job with passion. If you are one of those people, you just can't ignore it. It is personal and disguised. You feel like you've fallen into a sewer full of horrible, stinky things. It is absolutely below your personal standards and expectations and

Keep reading

People are different.

Some people may consider the crappy codebase to be just "part of the job". It is perfectly reasonable when you do your job for the sole purpose of making money. You sell your time and you don't care much what happens between 9 and 5. Anyway, it is not your problem to solve it.

But things are very different if you do your job with passion. If you are one of those people, you just can't ignore it. It is personal and disguised. You feel like you've fallen into a sewer full of horrible, stinky things. It's absolutely below your personal standards and expectations and it's just something you can't deal with, because that would mean compromising your core values ​​and identity.

In my observation, 90-95% of people fall into the first category. It happens that I am in the second.

Speaking for myself, I probably wouldn't abandon a project solely because of a horrible code base, at least as long as the people and culture are nice. Those things are much more important in the long run. However, bad code base and bad culture are often closely related, and for very good reasons. So when it comes down to it, it usually comes in a "complete package."

Due to the shortage of developers, people have no problem finding work. This could also be a factor. Ultimately, the decision to quit a company depends on a complex combination of expectations, values, relationships, and salary. Human behavior is irrational and chaotic and we don't always do what is logical or what is best for us.

I was once tested on my nerves because my choice of naming variables was not compatible with what the team expected. After more than 35 years of experience, I have a whole philosophy dedicated to naming variables, and my eyes hurt when I have to look at theirs. It was a brainless experience, absolutely insignificant but brutally painful. I suffered several bouts of depression and really was about to leave the project. Fortunately I survived, but next time I prefer to choose a team that better matches my values ​​and allows me to be creative and independent.

I had a burnout this year. A couple of years ago, I went from being an in-house developer to a commercial developer. I found that the management relied on information that would have made things easier for the developers if we had known, the sales staff exaggerated the capabilities of the software too much, forcing the development team to add the features they lied about, and that there was a lot of infighting between the developers. One of those incidents was the last straw for me.

He had created a module that handled requests for information and documentation. He was fantastic in his role and he looked smart. The code was

Keep reading

I had a burnout this year. A couple of years ago, I went from being an in-house developer to a commercial developer. I found that the management relied on information that would have made things easier for the developers if we had known, the sales staff exaggerated the capabilities of the software too much, forcing the development team to add the features they lied about, and that there was a lot of infighting between the developers. One of those incidents was the last straw for me.

He had created a module that handled requests for information and documentation. He was fantastic in his role and he looked smart. The code was up to standards and I was relieved that it was complete. I submitted it for code review and let two of my colleagues see what I had missed.

I usually have a handful of minor bugs that are not bugs, but maybe not by standards or I missed an else statement that could cause the software to crash under extreme circumstances. This one returned with 97 serious defects.

While reviewing the comments that had been left, it was clear that the two developers who had reviewed my code had no idea about the techniques that I had used or the controls that were built into the forms. I managed to reduce 97 to 32 just by answering and saying that this was how the control / technique was supposed to be used.

However, the one that really pushed me over the edge was the spelling error. When making a change, we are supposed to put a comment line above and below our changes, comment on the original and replace it with the new one. The standards manual states that this is so so that any change can be reversed if it causes more problems. I misspelled a word in a message box (popup). I corrected it without adding code comments because it was to remove an extra character in a word that is simply displayed on the screen and does not affect the operation of the software. IT WAS MARKED AS A DEFECT. Worse still, the manager confirmed the defect.

Now I work for the same salary designing and building kitchens. It is a much less hectic role.

Yes. He worked for a major telecommunications company. I was assigned to a project that was behind schedule. They felt that assigning more developers to the project would make progress faster. Once I was assigned to the project, there were no things I could work on because everything that could be assigned was assigned to other developers. But they needed me to help with the unit tests, which didn't seem to reflect the results of the project.

I started reviewing the unit tests. 90% of Unit Tests did not do any type of code coverage. In fact, most unit tests

Keep reading

Yes. He worked for a major telecommunications company. I was assigned to a project that was behind schedule. They felt that assigning more developers to the project would make progress faster. Once I was assigned to the project, there were no things I could work on because everything that could be assigned was assigned to other developers. But they needed me to help with the unit tests, which didn't seem to reflect the results of the project.

I started reviewing the unit tests. 90% of Unit Tests did not do any type of code coverage. In fact, most unit tests only had one entry point and one successful test result.

At a product meeting, I pointed this out. They told me to write the unit tests for those who didn't have the proper unit tests. I started doing it, but to do any kind of Code Coverate, I had to go through the code I was testing. In reviewing most of the code, I found there was NO WAY for the code to work.

I pointed this out in a meeting and they told me I should fix the code. I said it was not my responsibility to fix the code…. That the original developers should correct their code and then write the appropriate unit tests. It was explained to me that the developers were already working on new code and that they couldn't help but go back and fix their code.

So, I started to go back and correct the code…. Try to find the specifications in which the code was written. Sometimes the specs were so obscure that there was NO WAY that code could be written to meet the specs. So, I had to dig to find the person who had written the specs…. And they were on vacation.

I wrote this down ... and they quickly shut me down. I tried to find out what was going on ... and was finally told in a meeting that I should "type faster".

That was the last straw. I discussed this with the project manager. He explained that ESA was the reason the project was so late and suggested that he read Edward Yourdan's book "The Death March" because that project was one. They told me I was a denier and a pessimist. I explained that I had been in Software Development since the 70's and had managed over 250 people at a time and that I was no longer going to be associated with this project and would leave it.

In fact, I quit development and retired. And my stress level dropped to ZERO.

It really depends, but in my experience, it's more often companies that make developers leave than developers that want to find a new job. So the reasons are diverse, to name just a few that I have come across:

  • companies closing
  • companies that move to different cities
  • companies paralyzing projects
  • companies that reduce profits due to cost reduction
  • companies that assign developers to "simple" and endless maintenance jobs once the project is complete (I know they have to be done, but you should probably assign your rockstar developer to those tasks because he will get bored)

Most software developers

Keep reading

It really depends, but in my experience, it's more often companies that make developers leave than developers that want to find a new job. So the reasons are diverse, to name just a few that I have come across:

  • companies closing
  • companies that move to different cities
  • companies paralyzing projects
  • companies that reduce profits due to cost reduction
  • companies that assign developers to "simple" and endless maintenance jobs once the project is complete (I know they have to be done, but you should probably assign your rockstar developer to those tasks because he will get bored)

Most software developers I know are pretty lazy when it comes to proactively looking for a new job, but if they are dissatisfied and a headhunter approaches them with the right job, they may take it. But I've only seen very few developers leave companies when they had a challenging job and the company was growing or stable. Software developers also rarely leave projects unfinished, but once a project is finished, you will see a slight spike in people changing jobs.

When I have seen developers who have a lot of short stays (1-3 years), I usually wonder about the projects they have, if they were launched or not, how was the start-up, if there was a lot of maintenance. and support once the project was alive. If you could answer all of those questions, chances are these guys will remain committed to your project and seldom leave a job unfinished. You would hire such a person without hesitation, but if you get the impression that people have never completed a project, you should dig a little deeper into the interview and think twice if you want to hire this person.

I didn't have any bad experiences like some of the posts here. But the main reason I stopped being a software developer and went into administration was because the software development environment changed. When I started, forty years ago, software developers were often given a machine with maybe an assembler and a very basic operating system. If you wanted a compiler, you had to build one. If you wanted a word processor, you had to write one. You were asked to create a filesystem ... be fancy and implement one with searchable indexes. Do you want a database? Build one. Etcetera etcetera.

These days a file system is not implemented; you him

Keep reading

I didn't have any bad experiences like some of the posts here. But the main reason I stopped being a software developer and went into administration was because the software development environment changed. When I started, forty years ago, software developers were often given a machine with maybe an assembler and a very basic operating system. If you wanted a compiler, you had to build one. If you wanted a word processor, you had to write one. You were asked to create a filesystem ... be fancy and implement one with searchable indexes. Do you want a database? Build one. Etcetera etcetera.

These days a file system is not implemented; You will learn all the details of the use of the one that comes with Linux or Windows. You don't implement a database, you learn all the intricacies of Oracle or MySql or Hadoop. The modern developer needs to know how to take advantage of all the work that has been done before. I'm not advocating a return to the good old days ... the new way is certainly the smart way. Functionality that would have taken months to develop can now be delivered in just hours or even minutes. But for me, learning all the intricacies of what other people have developed and how to harness that just doesn't interest me.

One more thing that perhaps bothers me more than it should is the way the physical office has changed. When I was an intern at university, I had my own office with a door, a desk, a chair for a guest, and a whiteboard. In my first job after college, I had a bigger office with a window. It was a small company, and the founders believed that software developers needed to focus without interruption to be productive. But as everyone knows, this has certainly changed with developers sitting face to face in giant open bulls in the name of communication. (I will say that CEOs seem to lead by example; Zuckerberg and Bloomberg have desks with people around them and no privacy.)

Every answer so far takes the premise of the question at face value. The truth is that it is a myth.

The US Bureau of Labor Statistics has tracked median seniority across all occupations and industries since 1983. Its latest report, from 2018, is available online 1.

In "Computer and mathematics occupations", we find an average seniority of 4.3 years. That's roughly the same as the median age of the entire survey population of 4.2 years.

In fact, median tenure has remained remarkably constant across the board since 1983. Computer and math occupations fell slightly to 3.2 years.

Keep reading

Footnotes

1 https://www.bls.gov/news.release/pdf/tenure.pdf

Every answer so far takes the premise of the question at face value. The truth is that it is a myth.

The US Bureau of Labor Statistics has tracked median seniority across all occupations and industries since 1983. Its latest report, from 2018, is available online 1.

In "Computer and mathematics occupations", we find an average seniority of 4.3 years. That's roughly the same as the median age of the entire survey population of 4.2 years.

In fact, the median tenure has remained remarkably constant across the board since 1983. Computer and math occupations dropped slightly to 3.2 years after the dot-com crash in 2002, but has remained between 4 and 4 years since then. 5 years.

Whenever you see articles like this 2 that claim to have an average tenure in tech companies of 2 years, question those numbers. It is often the case that those statistics forget to take into account people who have not yet quit smoking. They ignore the concept of censorship 3.

Software developers usually don't leave a company after 2 years. They tend to stay twice as long. I think it's clear that the reason we accept this myth is due to confirmation bias.

Footnotes

1 https://www.bls.gov/news.release/pdf/tenure.pdf2 Silicon Valley techies get free food and dazzling offices, but they're not very loyal: this is how long the average employee in the largest technology companies 3 Censorship (statistics) - Wikipedia

Those who still love to do it don't and can be highly employable, but the census bureau says the attrition rate is about twice that of other engineering fields and only about 30% remain in the field after 20 years.

I've been doing it professionally for 17 years and I don't see myself doing anything different ever. However, the problem with scheduling is the pace of change. If you were programming 15 years ago, it was probably for native Windows applications. Remember visual fox pro / Visual Basic / COBOL / outdated language? Many of those who quit probably struggled a lot to feel comfortable

Keep reading

Those who still love to do it don't and can be highly employable, but the census bureau says the attrition rate is about twice that of other engineering fields and only about 30% remain in the field after 20 years.

I've been doing it professionally for 17 years and I don't see myself doing anything different ever. However, the problem with scheduling is the pace of change. If you were programming 15 years ago, it was probably for native Windows applications. Remember visual fox pro / Visual Basic / COBOL / outdated language? Many of those who quit have probably struggled a lot to get comfortable with those languages ​​only to find that a good deal of their knowledge is now worthless and they have to start over. That's enough to scare anyone who was scheduling more like a race than a wish. Good programmers adapt and continually strive to learn new things, often outside of their day-to-day work.

In my experience, good programmers are highly employable no matter how old they are if they have the relevant skill set and maintain their overall core expertise. That's not easy to do, especially if you have a job that uses legacy technology and for many I think it becomes easier just to go into administration.

Other Guides:


GET SPECIAL OFFER FROM OUR PARTNER.