DEV Community

Cover image for Career Advice Given by a Technical Director
Dylan Oh
Dylan Oh

Posted on • Updated on

Career Advice Given by a Technical Director

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.

Follow me on Medium

Top comments (8)

wadecodez profile image
Wade Zimmerman

In my opinion programming is one of the most cognitively demanding jobs. As a result, negative mental health effects are a serious risk for developers, and long working hours directly impact mental health.

If you work directly with clients, these mental health effects can be managed by balancing your social time and programming time. However, many programmers work with clients indirectly where they could be in a back room programming for weeks on end. Always take the opportunity to communicate with people outside of your field.

Burnout is extremely common among developers, and in my opinion, devs should allocate time towards being social or enjoying nature. Taking time away from the screen reduces stupid mistakes and time spent dwelling on low priority bugs and tasks.

Grinding certainly helps get experience under your belt, but it leads to all sorts of problems.

ohdylan profile image
Dylan Oh

Absolutely agree with that, Wade. I have personally burned out quite a few times, not because of works but the stress that I have been putting on my shoulders. That's why 'grinding under the prem of being healthy' is the goal for me :) There are also lots of people that I know are just being too chilled and far from burned out.

adamdsherman profile image
AdamDSherman • Edited

Agreed. To be honest the amount of "smart drugs" (eg amphetamines, nootropics) that I know some programmers use just to get on top of work is concerning.

ohdylan profile image
Dylan Oh

Wow... I didn't know that. This is kinda scary by just imagining what happens when the effect fades away. We have to find the sustainable way to support throughout the career path.

pierrewahlberg profile image
Pierre Vahlberg

Also, one additional advice or tangent is to locate the ones that succeeds around you, or are smarter. Watch them, imitate, learn from them and excel.

It is very common to find "safe ground" with a colleague who is much like you, but you should strive for CHANGE to develop. Its really clear if you think of it that way. Do what you do and remain. Change and you will develop.

ohdylan profile image
Dylan Oh

That's a very useful and practical advice, Pierre! Appreciate that.

tylim88 profile image
Acid Coder • Edited

I suspect there is no "technical director" here, everything is your own opinion

"technical director" is just a click bait

There are a lot of article like this on medium, they do this for the sake of the clicks

ohdylan profile image
Dylan Oh

Thanks for your comment Acid Coder! I did really meet up with the technical director and this is a real conversation :)
But I do agree with you on click baits are everywhere now though