I met with a technical director last week, talking about software engineering in general. He has been one of the smartest people that I know, and an inspiring leader to me. It was great to catch up with him after some time, and I decided to write down his sharing with me.
Everyone has imposter syndrome. Literally everyone, including the seniors.
I was sharing with him how sometimes I feel like an imposter where all the engineers around me look smarter than me, etc. He shared with me his previous experience of failing a coding interview and being panicked. Having a little bit of imposter syndrome and being anxious is fine, that’s the motivation to drive you further and work harder. I have also shared with him how I always compare myself with others who have been in the company for more than years. He told me that we should not be thinking about starting to show the work while just joining for a few months. People hired you and might not expect you to perform on the very first day as the processes in companies are different. Just be like a sponge and absorb as much as possible. Sit in, learn and ask people who have been in the company for a longer time.
One of the differences between a senior and a junior engineer is that the senior engineer could digest a piece of code more precisely than the junior by just looking at it.
Both senior and junior engineers have to search on Google when writing code, even like “How to implement a hash map in JavaScript”. However, the difference is obvious when both of them were introduced to a block of code, or an issue, the senior is able to spot the crucial piece regarding the root cause fast. The seniors are also able to identify the anti-patterns and being able to guide juniors on how/why they should be changed. This has to be built with experience in the process of reading and writing in the different code bases.
It is not just about technical skills to be promoted to a senior engineer, but soft skill matters as well.
Senior engineers have to communicate well with all the team members, especially since they serve as an important layer between the juniors and the managers/leads. They can help to do high-level analysis, and pass on knowledge to the juniors.
Engineering managers should not just care about engineers’ job performance, but also about their personal well-being.
He shared with me that one of the roles of an engineering manager is to help the engineers under him/her to unblock things that could hinder them to progress. He tends to make the one-on-one talk with the engineers to be much more casual, checking if they are burned out or having any issues in life. This could make the engineers feel a sense of belonging and encourage the culture of being transparent.
Do things that make an impact at your company.
The most important part of working in a company is to make sure that the work you do has an impact. A good manager would guide the team into doing higher-impact work. Lower-impact but easy-to-do things are sometimes inevitable. However, we should try our best to avoid works that are low impact and hard to be done. It might be just wasting your time.
Your manager gets promoted when you are promoted. The same goes for you and the people under you.
When you are climbing the corporate ladder, you might feel that there’s no room for you to move up as your manager is still in his/her position. However, in most cases, the manager will get promoted higher when his/her people are promoted higher. For example, if you are now a manager, and you are able to grow people under you to be a manager, you would eventually grow into the director’s (manager of managers) position. Therefore, the managers will try their best to help people to grow, and be as independent as they go.
Focus on learning best practices on code structure, and writing tests.
I have also asked for his advice on what should I focus on at this stage of my career. He advised me to learn how to write code in the right and proper way, instead of more languages, or more frameworks. The former could be applied to any programming language that you learn in the future. It is also precious as something that might not be taught in school or in tutorials out there. Besides, always cover your code with unit testing. Start practicing this on every single piece of code that you write.
Don’t be chased away by “NO WORK LIFE BALANCE”. It is relative.
When we see someone working from 9 to 8, we might think: “Oh, that’s terrible. Doesn’t the company know what is a work-life balance?” However if engineers from the typical “996” working culture join the company, they might feel they are having the best “work-life balance” ever. More importantly, we should always focus on, what can I learn more from this company. How can I make an impact on work, or influence others? If work-life balance is the only thing that you look at in your 20s, you might be chilling with Netflix in the peak growing period of your life. Under the premise of being healthy, grind hard in your 20s and 30s so that you leave no regrets.
He also brought this message to me:
Software engineering is no different from other types of engineering… things are inherently complicated as time goes by — but the concepts remain similar. If we can look at a vehicle’s engine for example… good engineering makes it maintainable. In order to make it maintainable you need to define a clear structure, boundaries, and processes. The things that change the most often (like engine oil filter), must be easily accessible, and making a change to it should not affect the things that change less often (like the pistons in an engine). It may sound like common sense when you think of a car engine, but the same also applies to software.
The reality is that engineering is more thinking, testing, trying than writing/doing.
Lastly, he also shared a framework of career growth as the software engineering manager from this website: A framework for Engineering Managers.
Do follow me for future articles on programming, developer productivity, and more topics! Cheers.