Here I will share some of the best advices and things I discovered while I worked at different companies, startups, some unicorns, and some corporates.

First of all, I am not the kind of engineer who is a LeetCode expert, nor a high-IQ genius. When I was in programming classes, I really struggled with programming tasks, and that’s why I moved to DS. But in the end, I had to learn programming anyway.

What I refer to as a “high-leverage engineer.” My metric is simple:

  • Past bosses call you back for consulting.
  • People pull you into ambiguous, high-impact decisions because you consistently de-risk outcomes.
  • Being part of architectural decisions for impactful projects.
  • Great engineers working at big companies call you to give you referrals.
  • Managers and engineers respect you a lot, and you can move things if you propose them. Working on best and ambitious projects. Those are some of the indicators I discovered.

Let’s start:

• Outcome-obsessed, not code-obsessed. I heard years ago: “Wow, look at me, I’m writing 100 lines of code per minute while I listen to hard techno to increase my heart rate to 159 so I can type faster.” Throughout my career, I’ve discovered that great engineers are really outcome-obsessed; they see code as a medium, not the end. I discovered this when I started to learn new programming languages: all are very similar, with loops, vars, patterns. In the end, programming is mechanics; creating and expressing our vision is what matters.

This is important because we can focus on improving the systems and their usage, and not get stuck on very technical details like which language or pattern sounds better. As an example: I learned mobile because I wanted to create an app to organize the tons of photos on my phone of boards. The idea was that I just put my schedule on the app, and when I opened the camera on the app, took a photo of the board, and would have a folder with the task hours’ photos. This hunger of building things to solve daily tasks helps you learn a lot and start working on projects from zero and dealing with the uncertain. Usually, at school or work you have guidelines already defined and work done by other engineers, so you jump in for new contributions, but there is a lot of value in starting projects from zero, especially if they are things you really want to build. My first app was FotoApuntes, an app for taking photos of boards at school and organizing them. For sure, a lot of programmers work for companies, but the most outstanding see programming as a tool. One of the best engineers I worked with created an AI program for detecting beauty on Tinder and automated swiping for his preferences.

• Act despite uncertainty, with risk controls. Since I worked at Rappi and Clara, I had a lot of responsibility. It was like: you’re going to build a platform for the whole company, thousands of engineers. Yes, there were a lot of things I didn’t know, but I was hungry to learn while creating. Most people just want to learn new things but stay in their comfort zone for years until they get fired.

• Speed without depth creates hidden risk; depth creates reliability. They build reliability because they read the documentation everyone else skimmed. I discovered things that people who understand quickly don’t take into account. A great example is any documentation for a library: we think we just need to read the main page of the function or feature, but there are a lot of hyperlinks that contain hidden key information that will help us understand.

• Asking a lot. I always ask when I don’t understand. Sometimes I use ChatGPT, but for internal things I do everything I can to get an answer: email, chat, Slack, GitHub blame—anything. It’s better to ask for full context from people with experience. I know people are busy at work, so at first I try to send direct messages with all the context to make them easily understandable.

• Take initiative. No one wants to take initiative. I talked with an engineer who told me he wanted to learn and take tasks related to AI projects, but when the manager asked who would take a task, no one raised their hand. After that, he told me: “If you get that project, I will follow you.” I was like… ??

• Internal side projects. There is nothing better than fresh eyes to look at current systems. Sometimes something particular happens and you discover new or different ways of solving problems. You can propose those as side projects or as ADRs. We sometimes think, “Yep, I’ll solve this later,” but taking action and creating stories or ADRs to give visibility ensures those proposals get implemented.

• Share your work. Some of my best managers told me: it doesn’t count if you don’t do a tech talk. Yes!! When you create something good, prepare a call for your team or the engineering team and show what you accomplished. Document your project and be as explicit as possible. There is nothing better than well-written documentation.

• Really create. Whatever you think, there are a lot of things to create. Really. I even created a page to declare my love to my girlfriend: https://vercel.com/os-projects-6c155535/ari-love This is just one of my side projects. Learn new things.

• Prioritize impactful work and be transparent. Know your business. Talk with your manager and stakeholders and understand priorities. If you have an estimated time, say it. If the PO wants a feature in 3 days but you know it will take longer, say so and negotiate more time or alternatives.

• Moving fast vs scalability and good practices. This was more common in the past, when we didn’t have Cursor or LLMs to code like beasts. But I can assure you it’s still possible to create bad-practice code with AI if you ignore context engineering.

• Talk with people. Programming may seem lonely, and sometimes it is, but real knowledge comes from talking with others. I usually talk with DevOps, DS, or product managers. I prefer emails or DMs and respect people’s time—I’m a big fan of “this could be an email”—but sometimes calls are necessary. Some technical skills I haven’t seen in junior engineers: They don’t ask, or they ask the wrong person. Use Git blame, documentation, and commits to see who worked on features. They don’t use a debugger (this saves a lot of time). They use AI coding assistants very naively—just asking and approving changes. No documentation.

They don’t take responsibility; they just wait for new stories to be assigned. Those are some points if you’re hungry for knowledge and really want to be a top engineer. I didn’t expect to become a good engineer—I just wanted to learn new things, improve my methods, solve daily system issues, and express my love. In the end, I learned all of this without expecting it.