Becoming a Senior Engineer: the Checklist, part 2

The points I’ve stated in part one were just the tip of the iceberg. Now we dive deeper to see what other mysteries the ocean of seniority holds!

What’s new? 

Two Desperados devs are always up to something! A couple of things that are going on right now:

• A prototype team has been assembled, with a mission of creating new games, features and mechanics!
• We are refactoring our processes with the goal of boosting discipline, decision making, autonomy, ownership and communication. All within the bigger picture of bringing top quality content to our gamers.
• A special team is creating a top secret system that will be announced soon, so stay tuned for the news!

What are we diving into now?

We dwell into the depths of some of the most important dos and don’ts of engineering and leadership, discovering how to approach system design, how to think about your team’s future and structure, and how to level up while helping others do the same. We will see creatures like the “Over-engineering monster” and “The hiring beast”, while going through the vast spaces of mentorship and one-on-ones!

A senior designs and develops systems appropriate to scale, extensibility, and scope of the problem. They have learnt how to avoid over-engineering.

We will now see the “Over-engineering monster” in its two most common forms. It is best to stay away from these creatures, and if the encounter is imminent, ensure that it doesn’t happen again.

Form 1: I’ll do more than you need, and it will take months.

I see this behavior way too often. You get a problem or even a technical specification. Then you imagine the solution to that problem and every other possible need that might come up (and it possibly won’t).

• What if in two years from now stakeholders want something else here? I’ll design the system so it fits every possible need!
• Cool, how much time do you think you will need for the implementation?
• I will need around four weeks.
• Four weeks!?! They just wanted to change a couple of parameters!

Always think carefully about what is asked of you. Ask for the context and the timeframe. Think about how you could do it more efficiently, rather than making the task bigger than it is. Always have the impact / effort in mind.

Form 2: SOLID IProblem Factory

While I was working on a project where the request was to create a playing card system with an UI for deck creation, an engineer who I worked with came across the “Over-engineering monster” in its second form: 

• The engineer wrote around twenty classes for a simple card system, and around the same amount for the UI.

• Everything was abstract, classes inherited multiple interfaces, which were actually used once or not even once, but were there in case it is needed in the future. Some of the interfaces had only one usage, and only one or two functions. 
• The UI buttons, tabs and lists had their own abstractions and interfaces, even though Unity engine has that covered already. 
• Clicks on the cards were also done through a custom made system (and clicking is a basic Unity UI functionality). 

If you asked him – the code was perfect, and it was SOLID. If you asked his colleagues – they had no idea how to navigate a system of this complexity made for a simple task, and when bugs started appearing, it was a terror chasing them down.

People have their own interpretations of what “clean code” is, and that’s ok. Your job as a senior is disambiguating ambiguous problems, and making complex things as simple as possible. Decouple the systems, make them as abstract as necessary, but always keep in mind that a good system is easily understandable.

Get involved in hiring for your team and company, and maintain a high bar for hiring quality candidates.

A senior engineer doesn’t only write code. They mentor others and they are known as technology experts throughout the company. They are fire starters of new initiatives and they get involved in different processes and projects, one of which is hiring. Senior engineers should be able to actively help and think about the team’s and company’s resource needs.

“Why do we need to think about hiring, we are not HR?!”

You have a project you are working on, which has its goals and its strategy. In order to complete the project, you may need more hands on it. Those hands, who will sometimes be new hires, are coming to your team. You will be working with them every day, brainstorming, doing merge requests, writing code, etc. You will depend on them and trust them to do the job right. Wouldn’t you want to be involved in picking the right person to be your co-pilot, sort of say?

How can you help?

• Filter out the applications for the engineering positions
• Help in setting hiring standards and requirements deriving from team and company needs
• Conduct engineering interviews and keep a high bar for hiring
• Find potential candidates, or point the recruiters in the right direction

Have strong mentors to help you navigate and grow in the company.

This is a point of great importance. Having a strong mentor, who is able to teach and to coach you is one of the most important things you can have in your career. If you don’t have one in the company, and there is no one suitable, reach outside and find someone from the industry. You can even learn a lot from a bad example, but a good mentor takes you a long way.

Mentorship could be a well organized ritual, on a daily, weekly, monthly, or any other dynamic that suits you. It can be paid, or even free, depending on the mentor, and your needs and goals.

I found some great people on LinkedIn, for example, who were open to giving me advice without charging a fee – just helping out a fellow engineer. Whenever I have a problem that I need to overcome, I contact one or a couple of them who have the relevant experience, go out for a beer and get the information I need. Big thanks to them, btw!

If you are going in a professional, paid mentorship or coaching relationship, make sure you define monthly goals, and specific points you need help with, and work towards solving them.

Drive your one-on-ones. Maintain a list of topics for the next one-on-one discussion.

Ah, the one-on-one. It happens sometimes that I come with defined topics, but the other party has nothing. That’s also ok. We could sometimes just chat about the weather and personal things, but not every time. Come prepared. Think about how your manager can help you and don’t hesitate to ask any questions, or express any of your needs. 

I love it when people come to our 1:1 and say “Where to start, I have a lot of topics”.

Some tips:

• Scale your direct report team size. Too many people – too many meets, not enough time to commit to each one of them. Read about Amazon’s “two pizza” rule. If you can’t share two pizzas with your team so no one is hungry at the end – you have too many direct reports.
• I like to have more frequent 1:1s, which take less time. Weekly or bi-weekly half hour 1:1 meets is what I prefer. It can go up to 45 mins if there is a lot to talk about, but not that often, and not more than that. It’s hard in the beginning, but you should manage to keep up that tempo if you are doing everything right.
• 10 minutes for the direct report, 10 minutes for the manager, 10 minutes to talk about the future. Don’t stick to this agenda too rigidly, but try to structure it that way. If someone has a lot to talk about, take some time off the next topic, and be flexible. Anything over the limit can go to the next meet.
• Come prepared, share your topics with the one you are having the 1:1 prior to the meet. Prioritize the topics and structure the conversation.
• These meets are private. What gets told there – stays there. Do not share it with others after the meeting, unless you agree it’s the right thing to do. You can do it at the office or in the park, a “walk and talk” will also do. You just need to make sure no sensitive information leaks outside unintentionally.
• Follow-up. Take notes of every meet (wherever you prefer). I prefer a simple doc, for each individual, with date and time and important information written down. Plan action points and review what’s done at the next meeting.
• These are not status reports. You have daily stand ups or other meetings for that. This is the time to bond more with the people and talk about goals and performance. This is the time for mentoring and coaching. I always take interest in personal things going on in the lives of our devs, and I advise you to do the same. We are all people, and there is more than just work that affects us.

Slobodan Nikolić, Head of Development