I have been working full-time in a professional environment as a software engineer for more than a year now, and I have learnt a lot. I took notes of what I had learnt and thought it would be beneficial to share.

Do not adopt these as a rule. Adapt them.

Avoid saying no

When the product owner gives you a feature idea, first try to think about how you can implement it, avoid saying no or ‘it is hard’ in the first place — this is a good chance to challenge yourself!

But wait. By no means I am saying that you should make a promise on something so uncertain that you cannot guarantee — try to analyse thoroughly, find the possibility and the effort needed. At the end of the day it is OK to say no if you are not willing to take it.

Be kind

We are all human beings. We make mistakes. We have bad days. We can be fragile. Yet we are sometimes successful. Cheer up and praise your teammates whenever possible — even if it is something so small — they will appreciate it, just like you would.

“In a world where you can be anything, be kind,” as said by someone.

Be open

Listen. Always be open to suggestions.

Communication is important

Clear communication is important when working on the same product as a team. Do not expect your teammates to use the same ‘common sense’ as you. It is better to ask to get the clearest picture of what you are going to do than to do it wrongly and have to spend time fixing it later.

Write requirements clearly. Do not make up your own requirements or software constraints without asking it from the real stakeholders, the product owner, the business analyst. When in doubt, discuss with your teammates. When you cannot keep up with the plan, report it to your supervisor so they can adjust their plan. It is very important to be transparent about what you do.

Don’t be afraid to ask for help

You are not working alone — your teammates are there to help. It is no one’s sole responsibility to work alone. When you are stuck, it is totally OK to ask for help. Take care of your mental health!

Also, while it is good to ask, sometimes it might be better to try finding the answer on your own first. If you want to find a file, try searching with some keywords in the knowledge base. If you want to find an API response format, try looking into the source code.

I would sum it up like this: if it is a question on requirements, ask thoroughly and make it clear; if it is a general question or a technical question that you can try to infer from available resources, try on your own first.

Even the slightest change can break your program

Always run unit tests locally so you do not feel shy when the CI pipeline fails.

That you don’t understand doesn’t mean you won’t

I had a hard time when I started working on the microservices written in GoLang. I did not have experience on Go as much as I had on JavaScript but I still wanted to get on the boat and take a ride onto something new. Learning with such big code bases was a pain. Unit tests were… meh: here and there I would run into Nil pointer exception–kind of things, and I was sad. But I kept on telling myself it was not because I was not good; it was because I did not know.

Maybe you have stumbled upon a mind-boggling bug or maybe your code just spits out a never-before-seen error. First you try to investigate it, debug it part by part, and of course — StackOverflow. If somehow you still cannot figure it out, try to ask your colleagues or seniors for they might have had that same experience before. Chances are they have.

Eventually if something does not seem to work today, take a good night’s sleep and continue tomorrow. Resting really helps.

You will learn something new every day

A code review from your teammate can guide you to an unknown land. A bug might lead you to an interesting concept. An email newsletter can teach you something new. Read others code to see how they match a design pattern with a use case. Research database optimisation to see variations in database design.

Be prepared to learn and always keep on learning.