Top 10+ rules every successful engineer should follow
Table of contents
Do you recall that guy from a movie called "Zombieland", who used to have survival rules? Well, it is somewhat similar to the world of engineering. The demand for good engineers is (still) high, but the competition is even higher.
So here is a list of insights I've managed to gather so far. Should you feel stuck with your career, or looking for new opportunities, perhaps this article can help you get off the ground.
This is the ground rule. If you refuse to do it, you may as well just close this article. The comfort zone is what stands between you and your growth, promotion, and, eventually, higher income and career ladder climb.
Always remember Kratos and what he said to his son Atreus during the final scene:
Here are some tips for you:
- Start blogging. Write articles and share them across different social media platforms. You can also start your own Youtube channel if you feel like it.
- Everything you do - you share immediately (unless it is proprietary) and seek for feedback. "I can't show you until it's done." - this attitude sucks. Drilling till perfection drains energy. Sharing resupplies it.
- Organise things. Run workshops, facilitate meetups, host meetings. Conduct scrum ceremonies. Share updates and conduct demo sessions.
- Help organising and participate in hackathons. This is important, because it helps you develop the following skills: finding right people for the job, focusing on what really matters, delivering imperfect yet working solutions on time. Also, it helps growing your network, so if you start a company one day, you would already know people of different skills.
- Know your superiors. Report to your superiors. Have coffee with your superiors.
- Seize every opportunity to do public speaking. The more you do it, the better you become.
- Ask questions, communicate. Don't be afraid of potentially silly questions, as the most stupid question is the one that was not asked.
- Try to not having your lunch meal alone. I know it is hard for introverts (like myself).
- On every meeting speak at least once. This is a must. You can ask a question, or communicate your opinion on something. By doing so you remind the others (the managers, most importantly), that you are here and that you have ambitions.
- Attend all key meetings, such as All hands, Technical updates and Knowledge sharing sessions. Make sure you keep your hand on pulse of the organization, grow awarness and also look for opportunities to participate in inspiring and promising initiatives and projects.
Pair this rule with the previous one, and a man can say with pretty good confidence: there is no such thing as luck. Luck means staying visible and vocal.
You must always remember: an absence of visibility is one of the key reasons why you usually don't receive promotion in big companies, even if you are ready for it mentally and professionally. Your engineering manager knows you, and puts your case for promotion, but then the superior lead asks "Who is this guy? I haven't seen him. This case is not strong enough to be promoted. Come back next cycle."
Make sure your name is on hearing of your superiors.
As I am a honored bearer of eastern culture, it was quite difficult for me to adapt when I moved to Europe. I've walked a long path, and I am still on it, but there are a few things I've managed to realise so far, leaving my previous, not always pleasant experience behind.
- Always respect your teammates. Don't be toxic, don't judge and don't foster the culture of blaming. Try to solve the problem instead, like a true manager would have done.
- Value any contribution. Always keep in mind, that any PR is a result of your colleague's effort. Do not discard it and try to re-use it to the best degree possible.
- Don't try to be the smartest guy in the room. Always be humble, but know how to hold your ground should you see it is necessary.
- Share the responsibility. You don't have to, and you should not be a single point of failure. Write RFCs, participate in technical discussions, seek for an advice/feedback.
- Be transparent. Don't keep your team in the dark in case if you have problems, like when your kid is sick and you can't complete what you promised in time. Awareness of the problem is always better than false expectations and false planning.
- Receive and share knowledge. Don't be hesitant to ask for a knowledge sharing meeting if something is not clear. It is always faster, easier and eventually cheaper to ask for help, rather than spending hours trying to heroically figure things out on your own.
- Don't be shy cancelling meetings. This is kinda obvious, but I always have this sense of guilt when cancelling a meeting I won't be able to attend. That's why I always push this unpleasant moment till the very end. But nothing compares to the level of guilt when I don't show up for a meeting I forgot to cancel in good time, and let people waiting for nothing.
This rule is kind of sneaky, but it can earn you a few score points. You always respect you team, remember? But also, nothing stops you from competing with them:)
So, this includes, among other things, sharing your own ideas as soon as you have them popped up in the mind. Of course, owning an idea is nearly not the same as brining it to life. However, should you hold it back while your team member brings it up openly, evokes a tiny bit of pity. You can always say "I had the same in mind", but it will never be as strong as "Hey, people, I have an idea I wanted to share with you!"
So, don't hold back, believe in yourself, and you will be rewarded.
- Use any chance to read other people's code, so volunteer for code reviews. Trust me, you will learn a lot.
- Reserve time for passing courses, one hour a day.
- If a teammate wants to show you something, accept this. Don't say you have no time, you never know how this knowledge may serve you in the future.
- Join or create and lead a guild for your topic. Make it mandatory for yourself to attend.
- Keep your knowledge up to date. A lot of engineers stale. But the world is a subject of rapid change. Attend conferences. As my field is mostly React, Node and Go, I chose to track the following events:
- If you see your colleague doing something interesting, ask if you could shadow them, so next time you know the subject better.
This is a whole skill in itself, and it was tricky for me to develop it (and I am not even half there yet).
It's easy to take a ticket created by someone, and just implement it. But it's a whole new level when I need to design something from scratch. It is though. I always second guess my judgment, for I don't see the whole picture at that moment, only fragments of it. And the worst thing is - when it comes to designing, there is nobody who knows more than I do.
But I can state with the highest confidence here, that this kind of work is one of the most rewarding, mental-, financial- and personal-wise.
Just a few tips to get started with the thing:
- Seek for the most difficult, vague yet the most impactful tasks, and commit. This will pay you back ten times, but also be ready for failure. It's fine. It happens.
- Develop ownership over your product/feature. Know it back and forth. It will render you as a pillar of competence in the field.
- Remember, that you are not alone in this. You have the whole team of experts by your side. Trust in them.
Trust in the Force - Gather requirements and pre-requisites.
- Write RFCs, iterate, gather meetings and discuss.
- Do not be afraid of sharing your vision of the solution to the problem.
- Be open-minded, but also know how to hold your ground.
Aim to grow career-wise. You loose money if you don't climb up the career ladder. Here is why.
- First of all, for the same position the hiring budget changes over the course of years due to market inflation. An engineer hired two years ago always has lower salary than the one of the same level who was hired yesterday. This is sad to realise, but one of the ways to beat it is to grow.
- Secondly, even though companies usually do annual salary raise, again, sometimes it just does not beat the inflation.
The action items here would be:
- Talk to your engineering manager. Define goals and make a plan on how to get there. I know, it sounds somewhat generic, but every case is unique. Do what suits your needs better.
- Track the progress of your colleagues to stay fit and focused. Jealousy is a powerful thing that can give you strengths, don't write it off like it's a bad thing.
- Start doing things that don't typically fit into a circle of your regular responsibilities. Want to become a manager - offer your manager help. Aiming for a principal - help another principal with something. The way the promotions work is: first you show what you are capable of, and then you have your promotion, not the other way around.
- Look for new connection points. When you work only for your team's project, sometimes it's hard to find topics where you can showcase your skills on the company level, because you simply miss the connection points. One option could be to always attend technical talks, and if a topic clicks, you can always reach out to a speaker and offer collaboration. You will grow your network inside of the company and have a good case for promotion.
- Promptly write your achievements down. Having the list of your quarter achievement bu the hand, you can always use it as a argument for promotion, put it into your self-evaluation report and simply discuss it with the superiors.
It's impossible to use the same amount of words on a day-to-day basis. It sounds not only poorly educated, but also gives you frustration that you can't express yourself in a proper, satisfying way.
Here is what you can do:
- Out every meeting, movie or youtube video try to carry one or two new words or phrases. Shortly after, use these in your speech or writing at least a couple of times, in order to strengthen the knowledge. Should you stay exposed to that influx of new language material, you will soon notice drastic improvement of your language skills.
- Subscribe to a podcast/youtube channel/etc of a native speaker and find time to listen to it. It does not matter who this person is and what their topic is. You can catch a lot of new vocabulary from an ASMR gal or a guy talking about travelling. As long as it speaks to you, do it :)
- When texting something or composing a speech, in case if you feel the phrase does not sound, hold on a second and ask yourself: "What can I do to make it better?"
- Use thesaurus to seek for synonyms.
Verbal credits is a form of reward, and you should not reject it. This is something you deserved, so there is no point for staying humble and diminish the efforts. There is really nothing more to it, but many people suffer from an imposter syndrome. Usually the syndrome vanishes into thin air the very first moment you see how impactful the results of your work truly are.
It may seem trivial, but a lot of engineers actually don't read. It could take decades to foster practical knowledge, should you be lucky enough to work on a certain project (or several) that will give you a boost towards right direction. Or, you can just take any trusted knowledge that literary rests in front of your eyes and fill up any sort of gap you may have.
I have a list of must-read books. Among them, there books such as:
and many others to come :)
You can't stop the progress. Over the course of the last 6 months I've heard many opinions, varying from recklessly optimistic "They will never catch me, I am that good." to radically pessimistic "We are all doomed." Nobody knows how the table will eventually turn, and the society is rightfully concerned about the future. However, here is my opinion, if you like. Take it or leave, up to you ✌️
The golden era of every second person turning into an engineer is certainly coming to an end. We, engineers, have to evolve. We need to become more efficient by entering some sort of symbiosis between a human brain and the AI.
The community will likely crack into two parts: people who just use ML to create things, and engineers who never stop learning, who delegate daily routine to a machine.
Study a new programming language to make a project X? Easy, as with Chat-GPT it takes a week. Scaffold an application tailored for a specific needs, deploy and enable observability? Sure, give me 15 minutes. The difference between engineers and data scientists will become more indistinct. Develop a neural network that becomes a tiny gear in your project and have other 5 tickets in the current spring to complete - that is just the new reality to come.
Suddenly the value of soft skills grows in value. Being a good person, being able to coach and mentor turns to be way, way more valuable than knowing 10 programming languages.
Now, there you have it :)
This rule stands out a bit, because it's a behavioural rule. Nevertheless, for an engineer who realizes the responsibility for delivering high quality features, it is of utmost importance to follow the at least one unit test rule. What does it mean? In every feature PR include minimum one test, to make sure the feature works. Sometimes smoke testing is not enough, it's easy to overlook a problem. Don't be shy if a PR is huge, add one unit test, it won't make a difference size-wise, but can make a huge impact catching the problem earlier, than it goes to prod.
That's certainly not the final list. As I keep growing professionally, I will expand it. So, there is always more to come.
Sergei Gannochenko
Golang, React, TypeScript, Docker, AWS, Jamstack.
19+ years in dev.