Being more efficient as a mobile engineer

I was reading this week about “10x engineer” and what it means in the tech industry. If the title can be questionable, I wanted to reflect on its definition and what it can mean in mobile engineering.

Definition

If you search about “10x engineer”, it’s defined as “engineers that are ten times better than their peers, in terms of productivity or quality of work”.

Putting the title aside, the definition lacks to reflect a person’s productivity isn’t constant. It can depend on your team, your manager, or the project you’re currently working on.

Maybe you can be productive in Swift on an iOS project, would you be as productive in Python on a data project? Maybe not. So there are some variants around it. You get the idea.

The second part that struck me is how to know if you are one. Since the definition point toward “better than their peers”, the only would be to compare yourself to others. That doesn’t feel right.

Then I read Max Howell’s definition:

Being a 10x engineer (IME) is:
• being efficient
• architecting for scaling your code productivity
• picking the right tools and knowing them well
• building your own tools
• knowing when to quit a failing approach
• knowing what to build first to get the most value

— Max Howell (@mxcl) June 20, 2022

This is already much clearer and the first point resonates with me: being efficient.

So what does it mean for mobile engineers? How can we get more efficient? That’s the part I will focus on today.

I will cover three main parts around efficiency:

• Planning
• Execution
• Tools and Automation

Planning

The best way to do more in a day is to plan our day better.

The best way to do more in a day is to plan our day better.
For a simple thing, prioritizing tasks to make sure urgent things get executed the right way.

As part of my daily routine, I make a list in the morning of what tasks I need to complete on the day. The list has to be realistic, too many/big items would just demotivate me if I cannot complete it by the end of the day.

The second part is about time management, keeping control of my day and my calendar.

If I work on an important project with some unknown areas, I will timebox it, research, and document as much as possible, for a specific amount of time.

If I don’t timebox it, I might lose track of time and miss completing other tasks, hence blocking other teammates or projects.

Finally, planning applies also to the tasks themselves.

Working on a new feature? How much do you know about the scope? Does it need to support internationalization or accessibility?
What iOS version do we support? What kind of device? Do we need to persist any data? How about the security of personal data? Is there any API service dependency? Are they already deployed in an environment? How are we going to roll out the feature safely?

It’s okay to not have all answers. But then, who can help me answer them? The more questions I raise, the more defined the feature is, and the better I can code and design the project to fit the requirements.

From prioritization, time management, and planning, I am ready to code and execute the plan.

Execution

Nowadays, our laptops and computers are getting faster and faster. We can build fast and often, so we have fast feedback.

However, I try to not launch apps from Xcode too often. With my notes aside (from before), I should know exactly what is needed or not, so I can just focus on the code.

From Xcode, the auto-completion and error highlighting are usually fast enough to suggest changes while I’m editing, so compiling isn’t even necessary yet. It’s just about coding.

Once a big piece of code is ready, it’s time to compile and launch the app. I take notes of all the bugs and missing parts (i.e. misalignment of UI, data not storing, etc) for the next code iteration.

Sometimes, the feature or screen I work on is hard to access. For instance, I need to add a new journey for a specific screen: I need to be logged in, then go to a listing screen, then a detail screen, then make an action to enter a new journey.

In these cases, I would create a dedicated deep link URL, like deeplink://test... to directly open the destination. From a terminal, I can access it much faster and save lots of time in the debug process.

xcrun simctl openurl booted "deeplink://test..."

This custom journey allows me also to quickly mock different entry point and make sure each state are covered quickly (i.e network error, non-logged-in user).

Once I have the feature stable, it’s time to refactor and clean the code if needed. It’s about making the code testable, abstracting the parts that aren’t yet, injecting dependency that wasn’t, adding encryption if needed, documenting the hardest part, etc.

If there aren’t any tests yes, it’s time to add some. I need to make sure the code behaves as expected. It helps maintain the code in the future, flag broken features but also build confidence in the code.

When it comes to API requests, mocking network is very beneficial to developer mobile features in parallel with back-end effort. Once the API contract and error handling is shared across the team members, then using a network proxy tool, I can iterate further into code behavior and sometimes be ready before the first back-end deployment.

This is probably my favorite part.

So far, all of what I do is pretty manual, from planning to execution. When it comes to tools and automation, it’s about improving further any manual task to save a bit more time for my next use.

The most important part is to have quick feedback when something breaks. Continuous Integration is key in these aspects. There are many continuous integration tools out there, so feel free to pick any, the important is to have one that fits your purpose and works for your team.

For tooling to make your life easier, fastlane is the most common scripting tool for Xcode projects, but Xcode CLI with some shell script can be a great start too.

What other small tasks can we improve? Actually, there are plenty.

A simple example: opening a pull request requires me to open a web browser, go to the repository, open a pull request, and compare it against the right branch.

If you open more multiple pull requests a day, it’s some time that you won’t get back. Having a simple alias in your favorite Terminal can help a lot for this.

alias open-pull-request="git symbolic-ref --short -q HEAD | xargs printf -- 'https://github.com/username/repository/compare/main...%s?expand=1' | xargs -0 open"

If you’re not limited on the tools, Github CLI goes even further to attach a title, a description, and more. All directly from your terminal.

On the other hand, Xcode is where I probably spend the most time during my day, so I looked for improvements there too. I have created many code snippets on Xcode to help me create new classes or Unit Tests, saving precious time for any new features.

Here is an example to give you an idea.

There are many more tools that can help you out, like linting and style extension during build phases, UI automation for App Store screenshots, and many more.

It’s about finding good solutions to help you daily.

Team efficiency

Most of those tips and tweaks are for individual efficiency. But how about your team?

I believe improvements can come through the same levels. For instance, better communication and planning as a team allow a better collaboration, especially if you work on a big project with many people involved.

How does your feature fit in the whole user journey? Who will handle the previous screen or the next one? How will you sync the code base? How to decide who’s working on what?

During execution, it’s also about following the same standards and best practices your team has. It’s much simpler to understand each other when everybody speaks the same language, right? It applies similarly to the code base: freestyle-ing for a new architecture that doesn’t integrate well with the rest of the app might slow down testing, maintenance, and peer review.

Finally, tools and automation systems are meant to help you and your team be more efficient. It can be about notification when a pull request is assigned to you to review, or auto-merge once reviewed, so your teammates aren’t blocked.

It can also be about knowledge sharing, so not only one person can handle a piece of the structure. This comes through documentation, tech sharing sessions, or a tailored onboarding process.

Creating dashboard and monitoring reports can also help make your team more efficient: if the number of crashes is only accessible to a few, how can we create awareness and make the project better? How does it help to avoid issues in the future? Sharing and exposing others allow them to share responsibility and ownership, which eventually help the team and the quality of the shipping release.

As your team and organization grow, keeping your team as efficient can become a full-time job, that’s where the Mobile Platform team came in, to support and help other contributors to focus on adding value and stay efficient by providing tools and resources to keep your build stable and feedback loop short.

Being efficient is looking at your work and wondering if there is a better way to do it. It’s about how to be better on daily basis, but don’t stop at the first solution. Keep digging, and keep reaching for more creative ways.

To get better, you don’t need a fancy title “10x engineer” or compare yourself to others. It’s about finding smart ways and keeping learning.

And without noticing, you’ll already be there 🚀.

Photo credits Hannah Wei