Why switching iOS dev jobs is not the best way to increase your salary

Many iOS developers believe that switching jobs frequently is the best (and easiest) way to increase their compensation and progress in their career.

Although it can yield improvements, we believe that switching jobs frequently generates only micro-improvements while bearing huge risks.

For example, we often see iOS developers (both permanent and contractors) switching jobs for a tiny salary bump ($2-5K) which end up tying them to this amount for another year or more.

There are faster strategies that can yield much better results—with integrity!

As part of our teaching and consulting jobs, we work closely with developers and businesses. Although most of the iOS professionals we talk to claim to be "satisfied" at their current work, they're confident they can find new (better) opportunities and switch jobs reasonably easily if they decide to.

For iOS developers, the ability to switch jobs on demand can be empowering. It provides a sense of financial security and also lets candidates seek or negotiate better salaries, work environment/culture, interesting work, health benefits, work/life balance, and appreciation for their work.

What they don't know is how much better those opportunities can be when they build valuable (scarce) skills.

Following a strategy to get tiny salary bumps after long periods makes developers miss huge opportunities (to double or even triple their compensation!).

For example, the demand for professional iOS developers, especially those demonstrating technical excellence and stellar leadership skills, has been skyrocketing. However, only a few are developing the skills to tackle those challenges (high demand & low supply!).

Switching jobs is a good strategy when you build valuable (scarce) skills that will help you get fantastic job offers. Otherwise, you'll be only getting micro-improvements.

The hidden risks of switching jobs frequently

"I make more money now, but I hate working here" is a recurrent theme among developers changing jobs frequently. Often, they wish they could go back to a previous job (being paid less) to enjoy work again. What we learn from this is that, of course, money is not everything.

From our recent research, most developers that switch jobs frequently are in one of these two categories:

• Happy with their compensation, unhappy with work
• Happy with work, unhappy with their compensation

This may lead developers to jump to the wrong conclusions. "I can either be paid more or work in a place I enjoy."

But… they couldn't be more wrong!

You can—and should aim for—a compensation you're happy with while working on a job you enjoy!

The problem is that switching jobs frequently is like gambling. You don't know where you'll land. You just hope to land in a good place.

The legacy problem

One of the most common challenges developers face when starting a new job is dealing with the newly inherited codebase.

New developers report having difficulties navigating and understanding the existing (messy/buggy) code. Additionally, they might be unable to get clarifications from the authors of the code as they might have already left the company!

Lousy codebases lacking proper structure, high cohesion (and low coupling), and reliable automated testing strategies are a threat to any iOS developer career plan. It can slow your career progression by a huge factor, as the odds to improve it are low, and you wouldn't be proud to add buggy/low-rated apps to your CV!

Such codebases are often deemed by developers as "legacy" because of their unmanageable and cumbersome nature.

Legacy codebases are not just the fault of developers, but the whole operation (from business people to product owners, managers, etc.). Usually, the pressures coming from above make developers rush and make lousy decisions.

Thus, inheriting a legacy codebase may not be the worst of your problems. A legacy codebase can be improved, but only if the company/team/management allows it (e.g., by giving the time and space for developers to make it better).

The truth is… When you inherit a legacy codebase, you inherit a legacy development process (and management)!

And… changing processes and company/team culture (which is usually what's necessary) is much harder than improving a messy codebase.

When a codebase reaches the legacy status, the incentive is for iOS developers to move on to a new greenfield or more manageable/high-profile project, for a chance to increase their compensation and boost their CV.

Who can blame them? That's probably the right thing to do.

Working in a legacy codebase is super stressful and rarely rewarding (unmaintainable or "legacy" codebases drastically increase burnout and drop developer happiness).

Changing jobs can indeed give you a (small) salary bump. However, you probably don't want to be the one to inherit an unmaintainable legacy codebase developed under a "legacy" management.

As a result, greenfield projects are the go-to option for iOS developers looking for a new job.

The problem is… If most iOS devs want to work on greenfield projects, the competition for those job positions is pretty high (high demand, but high supply)! In turn, it may decrease the compensation offers for everyone.

The best opportunities out there have low supply (scarcity). As far as possible from the competition!

To take advantage of rare opportunities, you need to develop scarce skills.

The (missed) learning opportunity problem

Many valuable lessons come from developing and maintaining a codebase for an extended period.

Developers that switch jobs frequently don't acquire the experience (valuable lessons) of maintaining a project in the long-term (one of the most valuable skills a developer can master!).

For example, when a change in the codebase makes the code less resilient to change (e.g., tight coupling or lack of testing), it might be weeks or even months in the future until production might start to slow down because of those changes. And it's tough to trace back the origin of the problem.

The decaying effect in code quality appears with a delay. It's asynchronous.

The asynchrony between the state of the health of the codebase and the team's productivity (and happiness!) is basically "invisible," until one day it catches up and people start leaving.

Many don't even see the down effects of bad dev decisions, as they move on to new jobs before the codebase becomes "legacy." (In fact, it's rare to see developers call their codebases "legacy." It's usually the new developers that dread it!).

Of course, developers are not to blame (universities and traditional education systems are often to blame—as they don't teach us essential lessons about dealing with the long-term). However, if you want to progress faster and achieve a fulfilling career, you owe it to yourself to learn how to create sustainable and profitable dev operations!

Since we don't learn it from traditional ways, learning at work (real-world knowledge) is vital. But you don't have to stay in a negative environment to learn such lessons. If you're working with toxic people and you have the opportunity to leave, take it (even for less money)!

Your well being is much more important than delivering great software or making more money.

At the same time, we understand that many don't have a choice. Many don't have the means to quit or the opportunity to work on great projects with remarkable people. So they feel trapped. Trapped because they know their work environment is limiting their growth. And that limitation prevents them from getting the skills to find a better job.

It's like a vicious circle.

But there's a solution... find mentors and invest in yourself!

Investing in yourself

Let us say that again: Invest in yourself!

In other words, invest in your (non-traditional) education.

For example, developers may not value certain dev principles and practices that can boost their career progression until they know why those principles are valuable in the workplace. Again, this knowledge usually comes from experiencing the asynchronous down effects of lousy dev decisions (and it takes time and a lot of effort to learn on your own!).

The fastest and simplest way to learn the whys is by learning from experienced mentors (successful/experienced developers) you trust.

And the faster you learn the whys, the quicker you progress. (We call those the "a-ha!" moments.)

We noticed that when our iOS dev students and mentees understand "the why" behind counterintuitive principles, many things start to click immediately. In turn, principles stop being an "annoying overhead," and instead, they become powerful tools in their dev arsenal (valuable skills!).

Another insight from our students is the realization that there are no silver bullets in software development. Although many start their education by asking, "which is the best architecture" or "what design patterns should I learn," they quickly realize that everything depends on the needs of the business, the product, and the team.

There is no "best architecture" or "best design pattern" to follow to solve all of their problems. By focusing on the needs of their systems, developers can cultivate the confidence to build custom solutions after carefully assessing challenges such as:

• complex domains
• technical debt
• time to market (short deadlines)
• limited team capacity
• cloudy requirements
• inadequate training
• low resources (time/money)

leading to fantastic job offers, as excellent dev skills are in high demand and low supply!

The effects of seriously investing in your (non-typical) education result in a fulfilling professional and personal life.

Self-fulfillment, freedom of choice, financial rewards, and continuous learning are indicators of success.

At the end of the day, there's no way to separate your professional and personal life fully, so experiencing a fulfilling career is essential for you to live a fulfilled life.