How to Impress as a (Remote) Software Engineer

Codelitt is a remote-first digital product firm that specializes in UX design, development and strategy. During my time here, I’ve learned a lot about human nature and taken note of how my remote peers impressed me. Hopefully these insights are helpful to you!

Alright, let’s get started!

Communicate

Ever wondered how to rally your colleagues around your idea so that it gets implemented? Here are a few tips on how to write a nice message that will speak to your peers from around the world.

Don’t assume people’s knowledge

Essentially, don’t think they know this or that just because you do.

• Don’t: “Hey, I noticed we could use a HOTP, returned by the tuple of the create endpoint...”
• Do: “Hey, I noticed we could use a HMAC-based One-time Password (HOTP), returned by the object (tuple) of the create endpoint...”
  

Write a clear context

The idea is to understand how you came to think about it.

Example: "Hey guys, I noticed POTATO is not really matching our needs because of X and Y, what if we try APPLE instead? [explanation continued]"

Describe your idea in the clearest and concise way possible

Opt for short sentences. Don't use a ton of punctuation. Avoid too much emphasis. You'll lose your audience's understanding. You can use http://www.hemingwayapp.com/ to help you catch difficult sentences before you send them. Use images when possible.

• Don’t: At the moment, the spaceship is broken and lost around Centaurus XII, which could cause some trouble in our communication system, consequently, this is potentially and irreversibly making us lose the faith of our people, which, as you might recall, is already damn low and will (undoubtedly), be reflected badly in the next election turn if we don’t act now.
• Do:  At the moment, the spaceship is broken and lost around Centaurus XII. This is damaging our communication system. Because of this situation, our people are losing faith in us. This will be reflected badly in the next election turn if we don’t act now.
  

Write the goals

Explain what you hope to achieve by the proposed idea.

Example: By doing this, the main goal is to improve our response time by at least 30%.

Example: So by doing this refactoring this would save everyone ~10 minutes (the time I measured when doing this) because the task will now be automated.

Write the expectations

What do you expect from your peers after reading your message?

• Do you want them to acknowledge they have read it?
• Do you want them to take action?
• Do you want them to discuss it for future implementation?

If you don’t let them know, your message might fall into the forgotten realm and will never be discussed

Example: Please acknowledge this message once you have read it with a ✅
Example: Please let’s discuss if this idea would be possible in the thread. I expect we could also plan it if that looks like a good idea.
Example: Please, let’s discuss this as soon as you have time, as the situation is quite urgent.

Use paragraph and different format to separate points of concern

Use bold, italics, - bullet points, [code block]
Use any tool your message editor provides to make your message more readable

Example:
In order to X and Y, we need to follow these steps:

1. Do X
2. Do Y and this if you are on Windows
3. Add [code block] in your config file
   

♥️ Use emojis when you have to convey feelings ♥️

I really love programming with Visual Basic. <- Is this true? Is this ironic? Let your team know! If you don’t let colleagues know your intentions in a more serious situation, then you might unintentionally hurt some feelings if they don't know you (and your amazing sense of humor) well.

I really do love programming with Visual Basic 🤪😂

Read your finished message as if you were one of your peers

Adjust it accordingly, do it as many time as you want for better results.

Example Context: I am proposing an idea to the frontend (FE) team, but they don’t really know how the backend (BE) works. Let’s put ourselves in my FE peers' shoes and imagine which of these two messages they'd rather receive.

1. "Hey dear FE team 😘! We saw that you could benefit from the CI/CD system we've built for our BE. Let us know if you are interested!"

2. "Hey guys! We recently built this amazing CI/CD system, it uses X and Y (to know more, here is the link to our documentation). By following those simple steps, you can easily use the system which might improve your CI/CD speed:

• Do X
• Do Y
• And docker this
• And container that
• And Makefile blah blah
• And [input trendy word here 😬]

Please let us know if you are interested. We're available to answer any questions. -  - Your devoted BE team 😘"

The second message is much more clear and helpful. It is direct and addresses questions the FE team might have. This allows them to iterate upon it without confusion, leaving a strong impact within their hearts. They will remember how eloquent you are!

Ask questions!

You have doubts? Ask. You don’t know? Ask. Most of the time you will realize that your team doesn’t know either!

Continuing in a direction where you have doubts and misunderstanding will make your colleagues grumpy and your results won’t be up to the expectations. In this situation, nobody wins - not you, not the person expecting you to finish your work.

Be simple

Ever read a book with an exaggerated style? You suddenly realize you’ve been reading descriptions for 2 pages and yet you're still not able to figure out what the scene is actually about? That’s exactly what’s happening when your code is not relevant to the context of the project’s scope.

Simplicity is hard. Simplicity is having a clear idea of the requirements with a straightforward implementation and avoiding tons of useless overthinking. It's keeping the code flexible enough to be easily understandable, rewritten or extended. All of this while keeping the cognitive overhead 'light', is hard.

Achieving simplicity demonstrates the ability to see clearly through a complex problem while keeping in my mind the whole picture of the project.

In all, presenting an over-engineered solution, or “a rocket that kills ants” as my colleague Diogo elegantly says, only flatters your ego. It doesn’t demonstrate a clear understanding of the application, the problem it solves, or its requirements. In the end, you will make your peers' days worse, as they will have to deal with this solution or spend a lot of time reviewing your PRs. Nobody wins.

On the other hand, presenting a very simple but elegant solution that everybody understands will not only make your own life easier, but also make your goal achievable.

Be humble

Humility is taking feedback, appreciating what your peers do better than you, and helping them when they need it. It's essential for your own improvement as a colleague and as a software engineer.

Your company doesn't make money from your ego! You’ll be more valuable if you take feedback as challenges to overcome, rather than personal attacks. Once those challenges are no more, you are already more valuable :)

Your company, your peers, your projects, and you yourself evolve. Everything is changing constantly. Staying humble makes you more aware of those changes. Be more conscious and intentional about how you communicate with and perceive others. This helps you be more precise and in tune with your personal goals as well as the team's at any moment in time. It's the key to staying more open-minded and being able to see things differently.

Own your mistakes

The art of taking ownership of your mistakes is amazing. If I’ve made a mistake, I make my team aware of it. Everybody knows what’s going on then and they might even want to help. If you own your mistake, the consequences are never as severe as if you'd tried to hide it. Everybody can have a bad day, and that’s okay. The more you hide your faults, the more severely you'll be judged as time passes and things get worse! If everybody in the team shares the mistakes they've made, it creates an environment of support and solutions that is productive, safe and positive for you and your team.

To conclude

As time passes you will hopefully learn those soft skills by yourself. So learn as much as you can. The more you learn, the more you will see that the things you know are connected. This will improve your creativity in solving problems, finding elegant solutions, understanding others and communicating!

If there are three things to keep from this article they are:

• Be open-minded
• Learn
• Be empathetic

You will impress in ways you don’t expect.