Forem: ⛩ Mike Apostolakis

Why mocking in iOS tests may not stop network and DB activity entirely

⛩ Mike Apostolakis — Tue, 13 Aug 2019 07:19:10 +0000

An excellent iOS test suite is fast, reliable, precise, and reproducible. A common problem that makes automated testing in iOS slow and flaky is the presence of unexpected side-effects and artifacts during the execution of unit tests.

For example, unexpected state/artifacts will make:

Some tests fail after running the app
Some tests fail after an unfinished test run
- Even if you clean up state in tearDown, if somehow the test suite does not finish properly (e.g., breakpoint or manually stopped), tearDown may never be executed (so the state is never cleaned)
Some tests fail due to temporal coupling when running:
- in random order
- in isolation
- the whole test suite

The examples above will make your iOS test suite slow, unreliable, inaccurate, and irreproducible. That’s why running real network requests and/or persisting state to disk during unit tests is undesired.

To make your iOS test suite fast, reliable, precise, and reproducible, every test run should start in a clean state and end in a clean state (no side-effects/artifacts left behind).

To solve the problem, iOS developers will rightly replace network clients and databases with some kind of test double. However, that may not solve the problem entirely.

Here’s a common question we receive:

“I’m mocking my HTTP APIClient, but when running my tests, I can still see network requests being fired in the logs. It slows down my tests, and sometimes I get unexpected errors.

For example, if I run my app and login (e.g., manually or on a UI Test), I get a bunch of failures and network requests in my unit test target because the logged-in user state is persisted and we fire a bunch of requests in the AppDelegate to update the logged-in user data.

How can this happen if I’m mocking my HTTP APIClient in the tests?

I can clean the simulator before every run but that also really slows down my test process (a reset takes several seconds or even minutes).

What am I doing wrong, and how can I solve this?”

The reason real network requests will be fired when running the test suite (even though the HTTP APIClient is being mocked) is that there is probably a Host Application attached to the test target.

If your test target has a Host Application, every time you run your tests, the Application will also run with them. For instance, if you watch your simulator while running tests, you’ll see the initial UI getting rendered depending on the state of the app.

So the AppDelegate is being instantiated, and it triggers the API requests through the real APIClient like it would if you just run the Application. Such behavior may be desired on an End-to-End UI test target, but not in an Isolated/Unit test target.

If that’s your case, instead of tweaking Xcode’s parameters to clean the startup state or blaming your app’s architecture, consider the following solutions (in order of our preference):

Configure the tests to run without a Host Application.
Create a new Test Target for Application-independent tests without a Host Application.
Alter the app's entry point by creating a main.swift file without instantiating the Application's delegate.

1. Run your tests without a Host Application

In our experience, the best and cleanest way to decouple your tests from a Host Application is to move your Host-Application-independent code (the majority of code you write!) into frameworks.

Framework targets do not require a Host Application and won’t have one by default. As added benefits, decomposing your Application into frameworks will help you create modular systems that are easier to maintain, extend, test, replace, reuse, and independently develop and deploy.

Alternatively, you can remove the Host Application from any existing test target, as shown below.

In Xcode, in the General tab of a Test Target, you can change the Host Application option to "none." By doing so, the tests will run without a running Application.

Removing the Host Application also makes the tests faster to boot, and there's no need to make any changes to the production target (such as checking for “IS_TESTING” launch arguments).

However, if the components you want to test reside in an Application target, you won’t have access to them in the test target:

If you don’t want to move your code from an Application target into frameworks, you’ll have to add your components into the test target manually. You can do so by ticking the checkbox in the target membership pane:

Note that, if your components or tests depend on a running UIApplication, this solution won't cut it for you. For example, the tests will fail if they're testing any component that references UIApplication.shared directly because the shared UIApplication instance won’t exist without a Host Application.

But that’s a good thing as it helps you to avoid bad practices such as accessing implicit dependencies, mutable global state, and singletons like the UIApplication.shared throughout the Application and use proper Dependency Injection instead.

2. Create a new Test Target without a Host Application

If you're working on a test target with too many entangled dependencies on a running Application, then the cost of making the tests run without a Host Application might be too high. If that’s the case, you can take small steps instead of a significant refactoring.

In Xcode, create a new test target and move all the Application-independent tests to a faster and more reliable Isolated/Unit test target without a Host Application. By doing so, the Application won't load when you run those tests independently.

Gradually, make your way towards the first solution by decoupling as many components as you can from a Host Application and moving them to the new test target.

Make sure to run all test targets as part of your Continuous Integration pipeline before merging code into the master branch.

3. Replace your AppDelegate class when running tests

The third option is a complement of the approaches above. While you can’t fully decouple your test target from a Host Application or if you want to prevent your Application from creating the real AppDelegate, you can replace the AppDelegate class when running tests.

To replace the AppDelegate, you need to create a custom starting point for your Application.

Regardless if you're executing a test suite or running your iOS app, every execution has a starting point.

Historically, in Objective-C, the main entry point for an iOS app was the main function defined in the main.m file, where you would create the UIApplication instance with an AppDelegate class.

However, in Swift, this code is "autogenerated" for you while using the @UIApplicationMain attribute above the AppDelegate class declaration.

The @UIApplicationMain attribute denotes that the AppDelegate is the Application's delegate. When you run your tests with a Host Application, you’re also running your Application with the default AppDelegate, which might execute network requests, analytics events, database side-effects, and a lot of other unnecessary work.

To bypass the default main entry point, you can remove the @UIApplicationMain attribute from your AppDelegate subclass and create a new file called main.swift at the top level of your project.

In the custom main.swift, similar to the old Objective-C main.m, you must explicitly call the UIApplicationMain function passing a delegate class:

The following code snippet below shows what is required to add in the main.swift file to:

Start a UIApplication without a UIApplicationDelegate when testing
Start a UIApplication with a UIApplicationDelegate in production

Notice that the func delegateClassName() function checks if the Swift runtime can find the XCTestCase class. XCTestCase is only available when running tests, so it can't be loaded in production.

The return value of the delegateClassName() is being used as the delegate class name argument in the UIApplicationMain function, which is the main entry point of the app.

If the Swift runtime can't find the XCTestCase class, then the name of your AppDelegate subclass will be returned, otherwise, return nil.

Thus, if you're running the tests, the Application won't instantiate the real AppDelegate as the delegate class name value is nil.

Alternatively, you could create a custom UIApplicationDelegate in your test target and use it instead of returning a nil delegate class name:

Solutions to avoid

There are other popular solutions such as adding launch arguments or compile-time conditions such as #if TESTING clauses but, in our experience, they usually do more harm than help.

We don't recommend launch arguments or compile-time checks as they can quickly spread throughout the production codebase and become unmaintainable, e.g., creating many different execution paths when running your app for tests or production. Ideally, there should be no test execution path in your production code, making it easier and safer to develop and maintain.

Summary

To create a fast, reliable, precise, and reproducible iOS test suite, it’s essential to eliminate unexpected/unnecessary side-effects and artifacts during the execution of unit tests. Running unit tests with a Host Application is a common source of such problems.

In our experience, the best strategy is to develop and maintain a modular codebase composed of frameworks/packages instead of developing your whole project in a single Application target.

One of the advantages of the modular approach is that this problem becomes almost non-existent as frameworks don't require a Host Application.

Finally, note that there are cases where you would want to run an Application while executing tests. For example, a UI Test target needs to run with a real Application. There's nothing wrong with that. However, if you don't need a running Application, it's better to avoid running one.

How burnout endangers your iOS career and well-being

⛩ Mike Apostolakis — Tue, 09 Jul 2019 07:51:20 +0000

Burnout is widespread among professional iOS developers. However, we don’t see enough talks, discussions, and content being created to help devs understand and prevent it.

Many iOS devs experiencing burnout are not even aware of it. Some even start to wrongly believe that “This negative state I’m constantly in is just how things are.”

As a result, they end up jeopardizing their well-being, career, and life plans.

In this article, you’ll learn:

what are the common reasons for burnout among iOS developers
how burnout can negatively affect your career and life plans
actions to prevent burnout and experience a fulfilling career

Common reasons for burnout

Burnout was recently listed as an occupational phenomenon by the World Health Organization (WHO). It is being described as a syndrome resulting from chronic workplace stress that has not been managed successfully. Burnout is being characterized by exhaustion, negative feelings related to one’s job, and low productivity.

Software development is a creative and mentally draining activity, so work overload is a common theme. It’s tough to keep up with the constant challenges, demands, short deadlines, and incoming/changing requirements.

iOS developers have been sharing with us various professional challenges they face daily. We’ve repeatedly been hearing phrases such as “I’m working all the time,” “I wish I had better colleagues,” “I wish I had more time and space to deliver better results,“ “I’m not proud of the work we deliver,” “I don’t feel appreciated,” “I don’t have time to study,” “I don’t have time for anything fun...”

If not handled appropriately, those challenges can lead to burnout and negatively impact their work performance, overall career progression, and life plans. However, what many iOS devs don’t seem to understand are the root causes of their burnout.

Some of the main reasons causing stress and burnout among iOS devs are the following:

an ever-growing backlog of tasks without clear expectations (even though the team produces a lot, they don’t feel like they ever accomplish any goals/milestones; the lack of celebrations is a clear sign)
too much work-in-progress at the same time
the accumulation of missed deadlines
impossible-to-meet deadlines enforced by managers or non-devs
shallow and cloudy requirements that are hard (or impossible) to estimate
very long and stressful iterations; usually releasing new app versions only every 3 to 12 months
spaghetti code and lousy architecture slowing down the team
lack of automation in general (tests, continuous integration, continuous deployment...)
git branches that take days, weeks, or even months to be merged (when devs attempt to merge them, the work is already out of sync causing conflicts in the code and the team)
lack of proper and continuous training and education
feeling intense anxiety when pushing an app to production or releasing to the App Store because of the possibility of bugs, mistakes or simply doing something wrong (e.g., releasing with the wrong dev endpoints configuration)
fear of missing out new developments in the industry or being left behind by new technologies and platforms
inability to see a clear career progression; “things seem fine now, but what about in five years?”
not feeling appreciated
working in companies that don’t offer a career plan
bully bosses/managers/peers and hostile work environment
switching jobs frequently
bad dietary choices
lack of physical exercise

Sadly, such highly stressful situations can deprive iOS developers of enjoying and appreciating their contributions and drastically minimize the rewards of their hard work.

How burnout affects your career

If you can relate to the issues above, or you feel you’re struggling with similar problems, you’re not alone.

For many years we’ve been helping iOS devs achieve enriching and fulfilling careers. And burnout is one of the top factors we see destroying career plans.

In our experience, a career plan is only good if you can follow it in the long-term.

If you set a career plan, burnout and give up after six months, that was a bad—unsustainable—plan.

It may take years to recover from burnout and regain passion for your job. Without proper help, it can actually never go away. So every time devs reach burnout, there’s a huge chance it’ll set them back years in their career and life plans.

Thus, an essential element for long-term gains is a sustainable plan. In other words, you must master skills and practices that generate positive returns in the short- and long-term.

Supercharging your skill set

We have faced the challenges that lead to burnout, and in our experience, they are manageable and mostly preventable. In fact, solving those challenges and helping your fellow devs thrive is one of the most rewarding experiences you can go through as a professional.

For example, it’s common for developers to get stressed, even panic when they face the so-called “spaghetti” code with a massive number of dependencies and no automated tests.

Such fragile systems are quite hard to change with confidence. So ensuring that your contributions work and that no defects were introduced is, of course, extremely stressful. Moreover, short deadlines will just add extra anxiety to the mix.

It’s not easy to solve those challenges, but it’s rewarding (and much better than the alternative of just coping!).

The solution, in this example, is to design components with a low degree of coupling and write a fast, reliable, and comprehensive suite of tests.

Of course, if your peers don't follow or care for good practices as you do, you can’t do it alone. Software development is a social activity, so a healthy and sustainable operation is a team effort.

Another source of conflict and frustration in the workplace is when devs put so much effort into creating good solutions, and their peers completely nullify it with lousy changes.

That’s why excellent education, training, mentoring, high-standards, team building exercises, leadership, and a healthy team culture is so important.

It’s not easy, but it’s simple if you and your team commit to daily disciplines. In turn, it can drastically alleviate you from stress, help others along the way, and clear your path for a long-term career fulfillment.

Maybe you can’t find joy in your current work environment. If you’re working with bullies, it may be time to look for a better place. But if you like your peers, be sure it can be a rewarding experience to start leading them to a healthier, more sustainable, balanced and profitable work-life.

And if you don’t have the skills to do so, it’s time to start building them. You can either request your employer/HR for better training or use your resources to do so. Regardless, it’s essential to invest in yourself to achieve your goals and experience short- and long-term career fulfillment.

Summary

You shouldn’t feel alone if you’re experiencing burnout, stress, or anxiety. It can happen to everyone.

However, you don’t have to accept this negative state as the “norm.” If you feel like your stress and anxiety levels are getting out of control, you should seek professional help.

You can prevent burnout by building up valuable dev and leadership skills and incorporating sustainable practices and healthy habits into your daily routine.

Remember: Delivering work you’re proud of—while helping your fellow iOS devs along the way—is exceptionally rewarding.

Should iOS devs learn Kotlin or other programming languages?

⛩ Mike Apostolakis — Tue, 02 Jul 2019 08:26:04 +0000

Have you ever found yourself wondering if you should learn Kotlin or another programming language?

This is a common question we receive from iOS developers. With so many different languages, frameworks, and platforms in the dev industry, it’s natural for iOS devs to wonder if they are missing out big opportunities out there.

In this article, you’ll learn a simple framework for deciding if a new technology can help you accelerate your success and long-term fulfillment:

choosing between a generalist and specialist approach
setting up clear objectives
building up valuable technology-specific skills
building up essential technology-agnostic skills

Should I be a Generalist or a Specialist?

Of course, the answer is, “it depends!”

Some developers believe that “If I know both iOS and Android development, I should be paid double!” The problem is… Developers are typically paid by the hour (and how much they can produce!), and knowing two platforms don’t make you twice as productive (context-shifting, for example, can actually make you less productive)!

So, if you're an iOS dev, we believe you should strive to become an iOS dev specialist. Thus, Swift should be your specialist language.

It’s counterintuitive but, usually, becoming a specialist (e.g., “I am an iOS/Swift dev specialist”) pays off more than trying to be a generalist (“I am an iOS/Android/Swift/Kotlin/Obj-C/JS/PHP/JAVA/C#/... dev”).

The cost of dabbling with new technology may be small. But mastering many technologies and making them part of your success and long-term fulfillment is a whole different proposition (it can take decades!).

That doesn’t mean you shouldn’t learn other technologies. Quite the contrary. Absolutely, you should learn other languages. We know many highly-paid iOS developer specialists that use Objective-C, Kotlin, JS, Ruby, JAVA, etc., on their day-to-day. But when advertising themselves for a high paying iOS position, they show up as iOS/Swift specialists!

Let's illustrate with a real story. Caio had a serious knee injury practicing jiu-jitsu. Specifically, he had torn his meniscus and needed emergency surgery.

Imagine yourself in his position. Would you choose a "do-it-all surgeon" or a "knee surgeon specialized in torn meniscus sports injury"?

Of course, it doesn't mean the "do-it-all surgeon" can't do a great job. But we believe that most people would pick the specialist as a safer choice.

The same principle applies to your career. There are many outstanding iOS opportunities at the moment for iOS/Swift specialists. Because businesses deem expensive specialists to be a safer choice.

Certainly, there are generalist devs making a good living! However, in our experience, that’s not the norm. Simply because a do-it-all generalist dev often looks “less knowledgeable” to challenging—and rewarding—iOS projects.

If working with multiple languages, frameworks, and platforms is what makes your heart tick, go for it! Otherwise, becoming a specialist may be a better (and more profitable) alternative.

Setting up clear objectives

Learning new languages, frameworks, and platforms indeed open up opportunities to improve as a developer. However, you must clearly define objectives as it may not be the best choice for career progression.

For example, if your objective is to explore how MVC, MVVM, and MVP solutions are implemented in other platforms, learning how to build Android/Kotlin apps can be a great exercise. Or if you want to learn different programming paradigms such as Functional Programming, learning Clojure or Haskell would be fantastic.

In other words, if your goal is to improve your programming skills, you should definitely consider giving another technology a try as it can expand your knowledge and consequently your value as a developer (you can always translate what you learned to iOS/Swift development!).

Moreover, building an open-source side-project for learning a new technology can be extremely fun and rewarding. Ideally, you should document your learning in articles to increase your exposure online (always good to promote yourself!).

On the other hand, if you’re thinking about learning a new technology for professional reasons (e.g., increase your salary), consider your decision carefully. Before diving into learning a new programming language, make sure to research what would take (time, money, and effort!) until you can provide value in the workplace and start collecting rewards. Additionally, be sure of what kind of expected returns you’ll see from your investment and for how long these returns will potentially exist.

As we said previously, instead of learning many languages (generalist), it often makes more economic sense to master one first (specialist).

Building up valuable technology-specific skills

Many factors influence the popularity, adoption, and compensation for a technology-specific skill. Ideally, you should build up highly-paid skills that are currently hot and are expected to have high demand in the long-term as well.

A simple principle is: Scarcity plays a significant role in compensations.

Swift is an example of a new language with current and future expectations for high-demand and high compensation. Since there are not a lot of experienced Swift developers (scarcity), remarkable Swift developers can achieve very high compensations.

However, the demand for a particular skill and the compensation aren’t always aligned.

An interesting example would be technologies that don’t have a mass appeal anymore (low demand) but that have a potential for high returns. Take Objective-C as an example. For decades, Objective-C was the go-to language to develop apps on Apple’s platforms, but it keeps losing its appeal since the announcement of Swift. Sooner or later, professional iOS developers will have to jump on the Swift train, as Apple has expressed clearly that Swift is the future of their platforms. As a result, future iOS developers will most likely never learn Objective-C.

However, that doesn’t mean that there won’t be good Objective-C opportunities in the future. For example, as Objective-C usage fades away, there’ll be fewer Objective-C specialists in the market (low supply), thus there’ll be a massive scarcity for the skill. As long as there are businesses that depend on Objective-C, there’ll be the need to maintain those systems. In this long-term scenario, Objective-C developers can be so scarce that they could potentially land very lucrative roles to maintain or migrate legacy codebases.

With that said, we don’t recommend beginners or even mid-level iOS developers to master Objective-C as it’ll require a lot of effort and it may not pay off in the long-term. Such opportunities are more suitable for senior and veteran Objective-C developers (specialists) that already built the skills along the years.

In our opinion, you should avoid investing time, money and effort on legacy technology-specific skills.

Building up essential technology-agnostic skills

Ok, now you understand the importance of becoming a specialist.

But… “what if I become a specialist in a specific technology and later it becomes obsolete?”

Indeed that’s a legitimate concern. The tech landscape is continually changing, and with it, the technologies we use for developing remarkable products change as well (hopefully for the best!).

Placing all your eggs in one basket probably won't yield the best results for your long-term career fulfillment.

However… Instead of trying to become a “do-it-all generalist,” what if you build up highly-paid skills that combine extreme scarcity with high demand in the job market? And what if those valuable skills could also translate to any other platform, so you wouldn’t have to start from scratch every time there’s a new technology shift in the industry?

The good news is… such valuable skills exist, and you can master them!

The best long-term investment, in our opinion, is to develop essential skills that apply to any platform or language; skills that withstand the test of time. Such timeless skills are vital for generating business value and accelerating your career growth.

For example, the following highly-paid skills are independent of the language or platform you use:

modular design , for adapting to change with high-speed and low-cost.
automated testing , for quickly, reliably, and repeatedly asserting correctness in the codebase.
dependency management , for creating low coupling between reusable components.
effective version-control , for smooth continuous integration and deployment.
short release cycles , for easier and more accurate planning, gathering fast feedback, and delivering value continuously.
codebase health monitoring , for maintaining a sustainable codebase in the short- and long-term.
excellent cross-team communication , for a collaborative and knowledge-sharing culture.

Summary

Building up essential—and timeless—skills will give you a positive outlook and a comfortable attitude towards big shifts in the industry. That means you won’t have to worry about which language or platform you should learn next. Adapting to future challenges and changes will be easy and cost-effective. In fact, every shift will become a rewarding and quite profitable experience!

So… strive to get the best of both worlds: build up a foundational skill set consisting of scarce, highly-paid and timeless technology-agnostic expertise while specializing in technology-specific languages, frameworks, and platforms that are hot in the market.

In retrospect, go ahead and learn anything that is interesting and rewarding to you (it’s important to have fun!). If you are after success, long-term fulfillment, and a remarkable career, make sure also to master the timeless fundamentals of professional software development.

3 Steps to Prepare Your Apps for SwiftUI, Combine, iPadOS, Project Catalyst, and Any Other Leaps in the iOS Industry

⛩ Mike Apostolakis — Fri, 21 Jun 2019 14:32:47 +0000

At this year's WWDC, Apple caught us, developers, by surprise with the announcement of new frameworks and platforms such as SwiftUI, Combine, iPadOS, Project Catalyst, and many other fantastic updates.

Once more, iOS developers are looking at a fantastic opportunity for getting ahead in the game by mastering new technologies and providing outstanding value in the iOS job market.

However, for many iOS developers, the news denotes massive paradigm shifts they have to go through to stay up to date with the new industry trends.

And just like when Swift was introduced, we noticed many developers being afraid of missing out on this fantastic opportunity.

Of course, as part of the Essential Developer community, we don't want you to be left behind. So, in this article, you’ll learn what’s the ultimate strategy to adopt for:

preparing your codebase for the upcoming migration to take advantage of all the new platforms and frameworks, such as SwiftUI
extending your supported platforms by separating your components into platform-agnostic and platform-specific
thriving through tectonic changes in our industry such as language and paradigm shifts

The migration challenges of new frameworks and platforms

Although exploring SwiftUI’s capabilities on pet/test projects with no need for long-term maintenance can be fun and educational, adopting the new changes on iOS codebases backing commercial products bears a lot more effort and risks.

For iOS developers that create and treat the UI and other frameworks (especially 3rd-party) as standalone frameworks that can be plugged into the business logic, the migration to new technologies such as SwiftUI will be simple, fast and remarkably low-cost. That’s because there is a low degree of coupling between the business logic components and the UI code of the application. For example, with decoupled logic, developers will only need to replace the current UIKit module with a new SwiftUI implementation (the business logic stays untouched!).

On the other hand, codebases with high coupling between the business logic and the UI will have to be rewritten (or have parts be rewritten) to adopt the new APIs. The cost for migrating to SwiftUI, in this case, will be much higher.

Migrating business logic from a UI framework to another is a risky and slow process, with chances of breaking existing features and business logic since there’s no clear decoupling between the UI and the core logic. Many teams in that situation might rightly decide not to migrate at all.

Additionally, the iOS team will have to shift its focus to rebuilding existing functionality to the new UI paradigm, instead of directing their efforts on extending the app’s functionality and enriching the product. Moreover, by migrating existing functionality, testing the app’s behavior with the new UI components will most likely have to start from scratch.

A better approach to migrating core logic from a UI framework to another is to start extracting and decoupling the business logic from UIKit or any other UI framework.

SwiftUI is iOS13+, and since most companies support at least two previous iOS versions, that gives you enough time (~2 years) to prepare your codebases for a smooth migration.

The first step for preparing to migrate to SwiftUI and the new frameworks and platforms is to establish low coupling between your application layers (a modular approach).

Platform-agnostic vs platform-specific components

Aim to isolate the UI components from business logic components through iterative refactorings over time. In other words, strive to work in small batches (frequent small commits and merges) guided by a fast and reliable suite of tests.

By isolating the business logic from UI components, you essentially treat the UI like any other framework, a “plug, and play” solution. Then, you can compose all modules in the Main iOS application (Composition Root).

The separation and homogeneity between the modules contribute to your team’s and codebase adaptability towards big paradigm shifts we’ve been experiencing in the past years (the unknown that the future holds!). As a result, the cost for changing even whole layers, such as the UI of your application, becomes substantially smaller.

Adding a watchOS application with a SwiftUI implementation, for example, would be fast and simple as you can reuse the domain logic:

By striving to achieve isolation and uniformity in the codebase modules, you can also witness the following very welcoming side-effects:

faster development and testing times
increased happiness and fulfillment within the iOS team
smoother operations lead to better outcomes and subsequently faster career progression
faster time (and adaptability) to market
less confusion and miscommunication within the iOS team, especially new team additions
more controlled management of state throughout the system
fewer bugs and defects
less exposure to risk for new technologies/requirements/experiments as they become isolated and easily replaceable

Another benefit of organizing your code into isolated homogenous modules is the separation of the platform agnostic business logic components and the platform specific ones. Migrating your iOS app to SwiftUI will be just a matter of composing your application differently:

You can even start delivering better SwiftUI experiences to your customers while supporting old iOS versions by having different compositions of your application depending on the iOS version:

Classifying components as platform-agnostic and platform-specific enable us to reuse a significant portion of the codebase for deployment to multiple platforms.

You can represent business logic with raw Swift types (classes, structs, enums), which makes it platform-agnostic. The same business logic components can be used for different deployment platforms depending on the UI you’d like to plug them. In other words, you can end up with the same “brain” of the app (business logic components) but deploy on the iOS, watchOS, tvOS, iPadOS, macOS, Linux, and even the web.

You can even decouple the UI from the domain module when needed (e.g., to reuse UI elements in separate applications with different domain logic).

Xcode 11 makes it extremely easy to extract code into independent platform-agnostic frameworks and packages that can be shared.

The second step for preparing to migrate to SwiftUI and the new frameworks and platforms is to extract components into decoupled frameworks and packages (modules).

Thriving through tectonic shifts in the iOS industry

Achieving modularity enables you to deal with change much more straightforward, even in rare and unpredictable events where the whole industry must shift and adopt the new standard.

A modular design drives down the cost and time for adapting to change, regardless if it comes from within the company in the form of product requirements, or from external factors such as Apple’s announcements.

The third and final step for preparing to significant shifts in the industry is to maintain low coupling between your frameworks and packages as you implement new features.

As professional iOS developers, we write software to solve problems and improve the lives of our customers. Although it can be appealing to adopt the latest technologies, we need to remember that we have a responsibility to our customers to strive to provide them with the best possible experience first.

A smooth migration (supported by modularity!) goes a long way in helping you to adopt new technologies and features that make your app great with high speed, low cost, and confidence.

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

⛩ Mike Apostolakis — Sat, 15 Jun 2019 11:58:51 +0000

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 _why_s is by learning from experienced mentors (successful/experienced developers) you trust.

And the faster you learn the why_s, 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.

How Deleting Swift Code Can Make You a More Valuable iOS Developer—Clean iOS Codebase Series

⛩ Mike Apostolakis — Wed, 05 Jun 2019 12:07:51 +0000

The ability to develop and maintain a clean iOS codebase is essential to becoming a remarkable iOS Developer.

A simple but extremely valuable action you can take is removing unused code—mercilessly.

At the same time, we meet many developers afraid of deleting code because they might need it in the future.

Today, you’ll learn two ways for retrieving deleted code from a git repository and how good practices for commits facilitate the maintenance of a clean iOS codebase.

Good practices for commits

We teach our students and mentees to break down their changes in tiny/concise commits with explicit and descriptive messages.

Tiny, single-focused, commits with detailed messages:

Make code easier to review, change, and maintain.
Serve as documentation.
Facilitate and reduce the cost of undoing changes.

We recommend you to commit every time the behavior or state of the codebase changes while maintaining a green state (all tests passing), regardless of how small the changes are (the smallest, the better).

As a result, you’ll deal with smaller and less risky changes and become more adaptable as you’ll be free to explore solutions, revert, and restore their changes.

Usually, two is the ideal number of changed files per commit as we’re writing production code and tests at the same time. Refactoring commits change generally only one file but occasionally may affect more when we change a public interface.

Tight coupling between components is often what prevents developers from contributing in small chunks. Thus, the ability to edit only a small number of files per commit can signify a positive loosely-coupled relationship between components of the system!

In other words, a system designed with good abstractions allows you to change specific components without affecting others, making changes in the codebase easier, faster, and less risky. On the contrary, lousy abstractions will force you to edit multiple components, in various files, at the same time, even for minor changes (increasing the risk for mistakes and merge conflicts, slowing down the team).

Reverting a commit

If you follow the commit good practices (concise changes with a descriptive message), reverting changes becomes very simple and cheap—close to zero undo-cost!

For example, in the persistence module of the Essential Developer Academy: iOS Lead Essentials course, we demonstrated how to create supple abstractions enabling seamless replacement of any underlying caching mechanisms.

By using that abstraction, we created two production-ready caching implementations:

A Codable implementation backed by the file system using the FileManager.
A Core Data implementation with a persistent SQLite store.

Although both solutions work and perform well, we need a single persistence implementation. Core Data is a more robust fit for the app we’re creating in the course; thus, we opted to—fearlessly—delete the Codable implementation.

We bundled the file deletions in a concise, single-focus commit, containing only:

the deletion of the Codable store implementation’s production file
the deletion of the Codable store implementation’s test file
any changes made by Xcode in the project structure

Additionally, the commit held the following message describing the changes:

“Delete the CodableFeedStore in favor of the CoreDataFeedStore (we just need one in this project). If needed, of course, we can revert this commit and restore the Codable implementation.”

By including only the minimal necessary changes in a commit, such as the deletion of a file or a variable rename, you can quickly revert specific changes if you ever need to. To do so, all is required is the hash of the commit you want to revert.

To revert a commit, simply run git revert <commit hash>. Git will then create a new commit, reverting the changes introduced by the given commit hash. Git will prompt you to edit the default message for the new commit with the reverted changes. The default message is:

Revert “< given commit message >”

If you are happy to use the default message you can skip the editing by running git revert <commit hash> --no-edit instead. Notice the --no-edit flag telling git that you don’t wish to edit the new commit message.

As you develop iOS apps, you make many decisions like deleting code. You should be able to freely change your mind and restore changes with minimum friction and cost.

In our case, we know we may change our minds and decide to bring back the Codable store. Thus, we could only fearlessly make this change because it’s an easy change to undo (low cost). It’s easy to undo because we’ve created:

A supple abstraction that decouples our production and test code from the concrete backing store.
A concise—single-focus—commit for the code deletion.

A concise git history, with carefully written messages, can help developers understand the history of changes, creating a three-dimensional view of the code, where time becomes an axis we can travel on.

Extracting deleted files from messy commits

A git history with contributions that contain many non-specific changes per single commit, can make reverting a specific change very hard (or impossible!).

For example, you wouldn’t be able to quickly revert only a deleted file if the commit also introduced important business logic changes. If you tried to revert the commit, you would also revert the important business logic changes (which you probably don’t want to do!).

When reverting a specific file deletion in a commit (the easy way) is not an option, you can use an alternative technique by broadening your search scope for the deleted file (the hard way).

In the following process, you’ll learn how to find the deleted files, inspect and restore them. Of course, you can customize this process and optimize your workflow to your needs.

1. Get a list of all the deleted files in the repository:

git log --diff-filter=D --summary | grep delete

The --diff-filter=D argument, tells git to select only files that are deleted and the --summary flag to instructs git to format the output to contain a condensed summary of extended header information including the mode changes, which we can then filter the printed deletions with grep.

This command will yield the full path of all deleted files. There you can find the full path of the file you'd like to restore which is required for the next steps.

2. Get a list of all commits that contained the deleted file:

git log --all --full-history -- <file path>

First, when typing the command, make sure to add a space between the -- and the file path, as the dashes denote a separator and not an argument for this command.

The command above will yield a list of all the commits containing the deleted file.

The --all and --full-history flags tell git to search all the branches containing commits referencing the deleted file, instead of just the current branch. This functionality comes in handy when working in teams and large scale projects that there are multiple branches created in the repository, and you know you're not the only one making changes in the codebase. By not including the --all and --full-history options you could potentially miss significant changes that you weren't aware.

3. Find the version of the file you want, and show its contents:

Now that you have the hash of the deleted commit and the file path of the file you’re looking to restore, you can ask git to show you the file to review its contents. Simply run:

git show <commit hash> -- <file path>

Again, make sure you add a space between the -- and the file path.

This is an optional step, but can be essential to validate you’re restoring the correct file!

4. Restore the deleted file into your working directory:

git checkout <commit hash>^ -- <file path>

By running the above command git will restore and stage the addition of the new file and its contents to your current working directory.

The caret symbol (^) denotes that the parent of the given commit will be used, instead. That's because, in the given commit, the file remains deleted, meaning it doesn't exist; thus, you need to instruct git to look at the commit before it (parent) to fetch the missing file.

“But I don’t use git!”

Regardless of the version-control system you use, you can apply those simple, but essential techniques to maintain a clean iOS codebase.

The goal is to break down your contributions in tiny, concise batches so you can manipulate them easily!

Maintaining a clean iOS codebase

Clean iOS codebases consist of sequences of carefully thought commits.

By being disciplined with your contributions and keeping the codebase clean and well organized, you gain various degrees of freedom as you move forward, such as easily reviewing, maintaining, deleting, and reverting code.

Unfortunately, we see many codebases needlessly carrying unused code. The “dead” code adds a time overhead with every build and test run. Moreover, the unused code can cause significant confusion to new team members as they have to research about its reference or ask other team members about its lack of usage and existence in the codebase.

As a professional iOS developer, you’re also a risk manager. By proactively thinking about your future needs and spending a few seconds to organize your contributions properly, you and your team save hours of pain and wasted hours in the long run!

Why iOS Developers Feel Stuck In Their Careers & What To Do

⛩ Mike Apostolakis — Tue, 28 May 2019 16:05:56 +0000

We have been receiving messages and questions from iOS developers of all levels asking for advice on how to evolve professionally and financially.

The messages usually start with “I feel stuck,” followed by questions like “Should I learn Android/Backend Development?” This pattern indicates that iOS developers are looking to progress in their careers, which is fantastic! But they end up finding suboptimal solutions, such as deciding to become more “generalized” developers (constantly jumping to new technologies & frameworks). When, in fact, we’ve learned that “specialized” developers (mastering specific technologies & foundational concepts) achieve much better outcomes.

In this article, we have gathered some essential findings from our research and discussions we had with iOS developers to help you progress faster in your career and achieve your professional and financial goals. You’ll learn insights on the following key topics:

How unrealistic expectations prevent iOS developers from progressing professionally.
The most common challenges and aspirations of iOS developers we meet.
What iOS developers can do to prevent and/or overcome these challenges and achieve an enriching and fulfilling career.

1. Beware of setting unrealistic expectations

One of the biggest problems we see that many developers face is setting unrealistic expectations regarding the time needed for achieving their goal.

It is imperative to understand the timeframe required to cultivate a particular skill. Also, realize that everyone learns at a different speed.

In many cases, developers expect to learn a skill faster than the actual time required. Since their expectations aren’t met, they end up dropping the learning process and subsequently stop evolving.

As discussed in the video “#1 Reason Why You Don’t Improve As a Software Developer,” the main reason that developers can’t seamlessly progress in their career is that they prematurely stop the learning process. They stop before the “a-ha!” moments. Before the learning occurs.

Why is this happening? One key reason is setting unrealistic expectations.

For example, we’ve talked to many folks that expected to improve their skills by just reading a book, watching some videos or even, in some cases, by being promoted to a more senior role and taking on more responsibility. That’s rarely the case.

Technical excellence comes through continuous learning, practice, and execution.

It’s imperative to understand that improvement takes time and comes in multiple forms. For instance, if your goal is to learn Test-Driven-Development (TDD), you need to recognize that the learning process itself is a crucial element contributing to your improvement.

Improving your learning i.e., enduring longer learning sessions, learning faster, finding better sources, becoming more consistent, deliberate practice, and applying what you’ve learned, are catalysts for achieving your goals. Although such practices may not refer to TDD directly, they all facilitate the underlying path you need to take to reach the goal of getting better at TDD or any other skill. They refer to learning as a process.

In other words, you can learn how to learn better (& faster).

Another reason why iOS developers stop the learning process is the perception of not having enough spare time currently.

If the time allocated for learning—an essential component in increasing your professional value and financial returns—is perceived as spare , it’s natural to become eager to stop. That’s because spare denotes a surplus or a nice to have. However, in this case, developers are actually dealing with a deficit in their expected value or a must have. Learning needs are a must have because they are identified aspects of your professional skill set that can be improved to generate better outcomes (and rewards!).

In the graph above, you can see how we have highlighted the dip of the green line also labeled “Uncomfortable zone.” That’s the stage where students go through materials, ideas, principles, etc. that are unknown to them. That’s also the stage where growth and productivity seems to fall drastically, so many quit before the breakthrough (green line peak).

It’s common and natural to feel stuck when learning something new. It may even be appealing to stop learning because of the unknown return on investment. “What if I’m just wasting time?” “Will this pay off?”

The good news is that you are not alone or on “uncharted territory.” Advanced topics, such as TDD and Modular Architecture, have been mastered by many developers in the industry. So when in doubt about the return on investment when learning such skills, you can study their careers, articles, books, talks, and see if it was worth it. Also, of course, feel free to ask their opinion if you can!

We often see iOS developers who want better skills and being capable of better results (and rewards!); however, they aren’t aware of how to achieve it. iOS Developers really want a remarkable career, so complacency is not the issue. The lack of investment in learning happens because many times, we just aren’t incentivized enough to justify learning as a rational investment. The immediate short-term happiness and utility we get from allocating our resources to more comfortable or familiar options seem like a better investment (with potential huge long-term loss).

“Learning XYZ is hard. Maybe I should be spending my time doing something more entertaining.”

If you experience such thoughts, don’t feel bad. We can assure you that’s natural. Even the most accomplished students face these kinds of thoughts. They just get extremely good at ignoring them. They actually get enormous satisfaction and happiness by shutting those thoughts down as they’re getting closer and closer to achieving their ambitious goals! These students are experiencing a fulfilling and enriching life.

2. Feeling stuck

We have received dozens of emails and comments from developers feeling stuck in their careers. They come from all seniority levels and a lot of different educational backgrounds, including self-taught programmers, CS degree graduates, and boot camp graduates.

The most prevalent challenges include the following issues:

Ineffective cross-team communication with other developers and business/product folks.
Being responsible for unrealistic expectations and being blamed for failed results.
Lack of free time & resources to invest in functional training.
Unrealistic expectations from the business side for dealing with inherited “legacy” codebases.
Lack of proper processes when pushing to production.
Less qualified professionals being compensated more.
Translating iOS specific knowledge to other platforms, e.g., android/backend.

Many developers don’t anticipate to face those issues, nor are they trained to deal with them.

On the other hand, when we asked them to discuss their goals and aspirations, these are the most popular answers we’ve received:

Working with teams of more knowledgeable professionals (mentors) that can teach them how to effectively create and maintain a high-quality codebase (short & long-term).
Working under great leadership.
Working in worthwhile projects with remarkable people.
Working in companies that give them space & resources for professional and personal growth.
Receiving mentorship that leads to professional and personal growth.
Developing skills to become a remarkable developer in the eyes of their peers.
Gaining experience to lead a team of iOS developers effectively.
Increasing compensation/bonuses/perks.
Working under a more flexible schedule and/or remotely.
Master software architecture and be able to create large scale apps effectively.
Improve technical abilities and efficiency in automated testing.
Learn how to work with and improve legacy codebases effectively.
Stress less.

We can deeply understand and relate to these problems and aspirations as we have experienced many of them throughout our careers. Many of these items are not related directly to the discipline of programming; rather, they have to do with communication and economics. Programming is just a single activity of the daily multi-disciplined operations in the life of a professional iOS developer.

The way we understand the underlying challenges iOS developers face in their careers is outlined through the following three-layered realization:

“My goal is to build a profitable career building remarkable apps.” (aspiration)
“Many of my professional challenges have nothing to do with building apps.” (realization)
“I don’t know how to deal with such challenges (feeling stuck), but to progress faster in my career, I do know I have to find the answers.” (action)

The faster you go through those phases, the faster you’ll achieve a prosperous and fulfilling career.

3. Getting unstuck: combining technical excellence with real-life business challenges

The common pattern for many iOS developer careers is an initial struggle to get an opportunity in the iOS market, followed by a fairly quick career (& salary) progression, then stagnation as a mid/senior developer.

Many iOS developers are experiencing frustration in their day-to-day professional life, and they feel stuck. They don't know what to do or where to search to get through these challenges. Most importantly, these are not only technical challenges.

_Software development is a social activity, and it comes with social challenges too. In a job market with increasingly more participants and more significant challenges, developers that can collaborate well and lead with Empathy, Integrity, Economics in mind will thrive. _

We recognized this phenomenon in the professional lives of iOS developers and founded the Essential Developer Academy to provide a solution and accelerate the career growth rate of iOS developers around the world. By continuously studying our most successful students, we have concluded that iOS Developers need two essential elements:

Exceptionally well-thought education integrating technical excellence and leadership to tackle real-life business challenges.
Caring for long-term success equally as the short-term success.

Transforming your challenges into opportunities

The demand for Technical Excellence and Leadership skills in the iOS market is skyrocketing. However, only a few are mastering the skills to tackle those challenges effectively. Ignoring such market needs will lead to stagnation and a massive amount of money left on the table.

When you develop the skills to tackle business challenges and market yourself accordingly efficiently, you become a vital asset to any company striving to adapt and overcome the never-ending opportunities of the business world.

As mentors, educators, and iOS developers, we have been helping many iOS developers break free of salary/market caps and achieve professional and financial independence, with integrity. However, an enriching and fulfilling career doesn’t come easy. It requires dedication, and we’ve learned that, not every iOS developer will do what it takes to achieve their dreams.

To maximize and accelerate your career growth, we recommend you to find mentors that understand what makes successful iOS developers thrive and can help you achieve your best potential. Then, learn, practice, and execute continuously!

How to prepare for an iOS interview

⛩ Mike Apostolakis — Mon, 08 Oct 2018 07:35:23 +0000

A question we are frequently asked, usually by less experienced iOS developers, is how to prepare for an iOS interview. Most candidates look for our advice for preparing on technical details such as what frameworks or libraries to invest their time in, what architectural patterns should they be using, and other technical details. We believe that it is essential to acquire the knowledge and develop a proper understanding of such tools and notions and the ability to use them efficiently. Moreover, we like to introduce developers in thinking somewhat differently when considering changing jobs or even starting a career in software development, emphasizing on the relationship and mutual benefits for both you, the employee, and your future employer.

If your goal as a candidate, is solely to receive an offer, regardless the characteristics of the employer and team, then you should probably focus on two aspects; answering all the questions correctly during the interview and convincing the interviewers that you can deliver what they require. You can approach interviews as a “number’s game” where the more of them you attend, the more offers will get if you’re meeting the criteria, especially when the demand for iOS developers in the job market is high.

However, becoming capable of passing interviews with only short-term goals may very well not work for the best in the long-run. While it can be exciting (and scary) in the beginning to prepare for and jump into the deep waters of commercial software development, we believe you ought to think what kind of career you’d like to have. Because the career is what’s important. That’s how you’ll spend most of your time, opposed to the interview process that overall might take less than ten hours.

Passing an iOS interview as a skill

In all the years being responsible for hiring new developers for our teams, we’ve seen competent candidates performing suboptimally during interviews due to the stress and pressure they experience. It's not uncommon during the interview process (over the phone or in person) for fear to kick in because of many unknown elements candidates might be facing. For example, such elements may consist of the environment like the room or office space or questions that the candidate might not know how to answer immediately. Moreover, the lack of instant feedback from interviewers may lead candidates to a false perception that the interview is going bad, which can influence their performance.

Although it may sound counterintuitive, a way to overcome such fears is by accumulating more experience at interviews. By attending a lot of interviews and testing yourself, regardless if you progress to the next stage or not, you can identify weak spots on your performance and start working on them. Perhaps you may feel that you are strong technically, but lacking good communication skills. Or even the opposite. What's important is to identify what improvements you need to undergo and work on them yourself or expedite the process by asking help from expert coaches.

Building a career as an investment

Joining a new team is a gamble for both the newcomer and for the hiring team, as both have only established assumptions as to how the other party will perform in the future. Of course, this shouldn’t stop you from being thorough and conduct your “due diligence” of potential employers, the market they operate in, the products they produce, the growth and problems that might have faced over the years. Most importantly you should be able to justify how you will be able to contribute to the company’s needs and at the same time how the company will contribute to the increase in your market value. You should be able to ask these questions during the interview process and develop metrics and filters throughout your career. By thinking in terms of reciprocity, you can align your incentives with other developers and businesses and try to create a mutually beneficial relationship.

Because of the dynamics in the capital and job markets, we have reached a point where a significant portion of developers jump between jobs every six to twelve months. We believe that this period doesn’t suffice to create meaningful relationships and exchange maximum value with a company or a team. Moreover, in an ever increasing pool of iOS developers (increase in supply in the job market), competition may start becoming more fierce. Relying only on technical excellence can be a risky proposition when we already know that teams require qualities such as sound leadership, communication, and risk assessment to function optimally .

Finally, most importantly, such a mindset isn’t constrained by seniority levels. Regardless the years of prior commercial experience, your attitude should promote the eagerness for personal and communal continuous improvement through the pursuit of creating more value for others.

Conclusion

In summary, each interview process is different, and the candidate’s incentives will vary from time to time. Being offered roles solely based on your technical skills and/or your seniority level may work well in the short-run. However, if you want to build meaningful collaborations with other developers and companies, you’ll need to fill the needs of non-technical nature. Many companies aren’t looking just for programmers, but for people that can provide solutions to a plethora of internal problems that might be facing. You shouldn’t be afraid to ask the interviewers about what may be valuable to you to know, as it’s probably the first substantial step to start developing a foundation for reciprocity. Even if the interview process doesn’t move forward, it’s advised to maintain a friendly an open attitude towards the business or the interviewers, as your paths may cross again in the future.

We’ve been helping dedicated developers to get from low paying jobs to high tier roles. Sometimes in a matter of weeks! To do so, we continuously run and share free market researches. Learn how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Culture of Integrity Within Successful Software Teams

⛩ Mike Apostolakis — Thu, 13 Sep 2018 13:15:14 +0000

The macOS dictionary defines “integrity” as:

integrity | inˈteɡrədē |

noun

1. the quality of being honest and having strong moral principles; moral uprightness: he is known to be a man of integrity.

2. the state of being whole and undivided: upholding territorial integrity and national sovereignty.

What we can conclude from this definition is that Integrity can be perceived and expressed differently depending on the environment we operate in. For example, the second definition of “being a whole and undivided” may not apply when working alone, thus, if we want to act with integrity, we can rely on the first definition: setting and consistently upholding strong moral principles by ourselves.

When working in a team though, if we want to operate with integrity, the first definition holds true for the individual; however, it is maximized through the state of being whole and undivided as a team. Meaning that we can’t act with integrity as a team unless we act with integrity as individuals first. The effects of the sum of our individual actions will reflect as the behavior traits of the team.

Functional teams operate with shared values and principles that they will never compromise for quick conveniences. Thus, forming team Integrity.

At Essential Developer, we have adopted Integrity as one of our three pillars that form the foundation of our principles, along with Empathy and Economics. We believe that, in the context of a business, to achieve a level of high performance and being unified as a whole with a team full of people holding the same values we must first be able to grasp the possible effects of our actions. Every action we take will influence both our team members and the business. We opt to study and practice Empathy over morality, to understand how we can maximize the probability of our actions to impact our fellow team members positively. And Economics to influence the collective outcome positively.

At the same time, the Team Integrity will affect us as individuals, so we must carefully choose who we work with.

We’ve been helping dedicated developers to get from low paying jobs to high tier roles – sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.

Junior iOS Developers Can Be More Productive Than They Think

⛩ Mike Apostolakis — Fri, 07 Sep 2018 05:46:46 +0000

When we teach beginner and junior iOS developers it’s not uncommon for us to observe a false sense of low productivity and lack of accomplishment by them. We notice that many new and motivated programmers sit for hours, practicing, attending courses, watching videos and searching online for potential solutions to their problems. However, when we periodically ask them to give us a picture of how they feel they often respond negatively or with doubt as they couldn’t move forward on their project at the pace they expected. This is a false perception as we believe Junior iOS Developers can be much more productive than they think they are.

Unfortunately, what a lot of young programmers don’t understand is that they measure their productivity with false metrics, such as lines of code produced per day. For example, assuming that a new developer aspires to be able to build successful products consisting of thousands of lines of code, it’s only natural for them to feel like they are “not getting close to their goal.” Building such complex systems can be an incredibly overwhelming task for a beginner. In reality, they are just setting up almost unachievable goals for their current experience. It takes years of practice to achieve the level of proficiency to carefully craft a clean and sustainable complex system.

At Essential Developer, we teach our students that becoming a proficient software developer is a long and complex process. Not only it requires mastering the technical but also the social aspect of creating a system. Learning to understand how people and businesses operate and how to effectively collaborate is essential. Two skills can help beginners endure, the ability to persist over adversity and always keep learning. Thus, we advise our students that if they end the day more knowledgeable and capable than they started, they are on the right path and should stop worrying.

We’ve been helping dedicated developers to get from low paying jobs to high tier roles – sometimes in a matter of weeks! To do so, we continuously run and share free market researches on how to improve your skills with Empathy, Integrity, and Economics in mind. If you want to step up in your career, access now our latest research for free.

Originally published at www.essentialdeveloper.com.

Let’s connect

If you enjoyed this article, visit us at https://essentialdeveloper.com and get more in-depth tailored content like this.