Seniority

People use different words to classify Engineer skill, some companies give you more senior role just based on a number of years you have been working there, but what does it mean to be Senior?

In this article, I composed a complete and final list of API's that you need to know to classify yourself as Senior Engineer.

Here’s a list of all the APIs you must know:

•

API's don't matter

If you thought that what makes people Senior is memorizing API's, then this article is most definitely for you.

Sure, experience matters and helps you be a better developer, but knowing any particular API is not of great importance, anyone can learn a new API given enough time.

How each company gives title is very arbitrary, sometimes it's based on years of experience, other times, unfortunately, its a matter of how friendly you are with management.

What matter is not the title you hold, but what you represent.

Technical skills will usually come to you naturally with years. I want to focus on something many people miss: soft skills.

Let's split this into Personal Principles and Working with Others.

Personal Principles

Reliable

You need to be reliable, never promise you do something and then drop the ball.

Others people work often depends on being able to gauge when your piece of the puzzles are ready, for that reason it is better to be on the safe side with estimates and over-deliver than to promise too much and fail to deliver.

There are always tasks you can pick up if you finish your sprint sooner, seniors are proactive and do not sit on their hands until they are assigned new tasks.

Accountable

The only person that does not make mistakes is the person that does nothing.

Making mistakes, or hitting roadblocks is normal. More experienced people know that when that happens they let other people know, and they are not afraid to ask for help.

Don't be afraid to admit your mistakes, it is only human, and it will build more trust when working with others.

Flexible

Don't get attached to particular framework or language.

Only one thing is sure: you will change them many times in your career. Some languages that I used early in my career are obsolete now.

I would go further and suggest that you should embrace change, force yourself to challenge your assumptions, it makes you less ignorant of other opinions/ways. There is more than one way to skin a cat.

I usually have some side-project going, and I have a rule that every six months I try using a different approach to things.

It allows me to distinguish the best solutions from those I am used to. Endowment bias states that we value things we own/know more than they are worth.

One thing to remember is that change is hard and requires time. Trying something for a couple of days just won't cut it.

Pragmatic

Many programmers would like to just focus on the engineering side of things, always do the cleanest code they can and ignore the business side of things.

That is not how our jobs work. People hire you because they need to solve some specific problems for their core business, be it a new app or anything else, not to write code for the sake of code. Delivering things matters.

You need to invest time into understanding the business requirements, only knowing them you can make well-informed decisions and focus your work on things that matter.

Working with others

A single person rarely creates software products on their own.
You have to work with other people.

Invest time into learning how to be a team player.
This will make a huge difference in how your career progresses.

Lead by example

People will look up to you and how you behave will heavily influence team culture.

If you are:

Proactively grabbing new tasks from the backlog when you are free
Looking for ways to improve the architecture and tooling
Teaching and volunteering to pair program or help with issues
Giving everyone space to state their opinion and discuss with arguments
Treat everyone as an equal conversation partner

Other people will adopt those behaviors, and your team will prosper.

Listen and learn from others

In engineering, there are many different ways to achieve the same end results. It's way too easy to get set in our ways, we have to exercise our flexibility.

Be open to other opinions, do not dismiss other people ideas because they are different to your default thought.

Spend some time discussing others' opinions to better understand what they mean and how their ideas would work, all the pros and cons, etc. Only then you can evaluate whose approach makes more sense.

It does not matter whether the idea comes from people that are more experienced than you or less. I have learned plenty useful things from Junior developers in my teams, they often have fresh ideas and challenge our assumptions.
Which bring me to another important point: Do not leverage your 'power' or 'seniority'.

Never treat people as inferior and never use arguments like 'Let's do X because I've higher position than you / I've been programming for N years.'

When an Engineer uses that kind of argumentation, it makes him look like a child from kindergarten, not a professional. Don't be that person.

Use factual arguments. If you cannot find reasons behind your way of doing things, maybe it is not that good?
Avoid being reactive, discussions can get heated, but a professional understands that a critique of an idea is not the same as a critique of a person.
Pause and think before replying, and don't interrupt other people. Let them finish and focus on understanding their message before discussing it.

Learning how to manage your impulses and emotions is crucial in living with others. Learning time management will allow you to maintain sanity.

Take a look at [some recommended reading.] (http://merowing.info/2016/02/8-books-that-everyone-should-read/)

Become a mentor to other devs

Mentoring other developers is incredibly rewarding, and it also helps foster the right team culture.

I want everyone in the team to feel comfortable asking me any questions. Be it to learn how to do something or questioning my decisions.

I have seen few teams that people were afraid to ask questions because managers were awful and used that to evaluate people performance based on that.

Encourage your teammates to ask for help, or advice how to do something.

If you want to be the mythical 10x engineer, help other engineers in your team grow.

Remember: There are no stupid questions, and if people are asking about your code it usually means it can be simplified or improved in some way.

Actively looking for ways to improve the process

No process is ideal. You should always be on the lookout for improvements.

If you criticize something, always propose alternatives. You can have excuses or results, but not both.

If you see pain points when working on your code, or when observing your teammates, think about how they how they could be resolved.

You do not immediately jump on writing another library or tool if something happens twice. However, when a pattern keeps repeating itself many times for different people, it means it is time to look at ways of improving it.

iOS community is one of the best communities I had the privilege to be a part of. I would encourage you to open source those tools and libraries and share your experienced with others.

Writing about things often makes you realize how much you still have to learn.

Subscribe to newsletters like iOS Dev Weekly or Swift News for ideas.

Courage to fight for healthy team culture

I cannot stress this point enough, I have seen many people complain about their team culture over the years, my question is always 'What are you doing about it?'

You need to fight for a healthy team culture, if you see that someone is misbehaving do not be afraid to speak up. Propose things like team contract or code of conduct.

The way I think about this is simple:

If I see something I do not like, then I question it in the team environment. Otherwise, the team might become toxic, and if that happens, I quit.

If you are going to quit otherwise, why are you afraid of fighting for your team?

Many people might be afraid to speak up, especially minorities and introverts. Often they will reach out to you in private to say thanks.

Things to look for:

Everyone is equal, make sure everyone can express his or her opinion, even those people that are shy.
When people are interrupted by someone, make sure to make it easy for them to speak their mind e.g. "Hey X, you were saying?"

Conclusion

Being a good developer and team member is about so much more than programming. With years you can gain much technical experience, but if you do not invest time and energy into improving your soft skills, you can create a bottleneck for your career, one that you might not even see.

Seniority

API's don't matter