What 1,500 minutes of Mentoring This Year taught me about the future of engineering

The Moment That Changed Everything

In 2019, it was about 9:30 p.m. in a Lagos office. I was still at my desk, debugging a product. The room felt heavy, the way it does after hours of staring at a screen. I was focused on fixing another issue, trying to keep the product stable. The founder paced behind me, making comments, until he said something that shook me more than any bug ever had:

I didn't respond or argue. I didn't even process it at the time. But that sentence stayed with me. I wasn't sure why it bothered me so much, but this year, after nearly 1,500 minutes of mentoring engineers, I finally understand its weight. It's not about being true or false, but about a mindset many people have about engineering, often without realizing it.

This year, mentoring showed me that engineers have talent, fear, potential, and blind spots. Many act like “tools” not by choice, but because no one has taught them to think differently.

The Interview That Reshaped My Thinking

One of the memories that resurfaced the most this year came from one of my earliest interviews, with Joseph Taiwo Orilogbon, a man who unknowingly reshaped my entire approach to engineering. He asked me what seemed like the simplest question imaginable: "Can you check if a number is even or odd… in one line?" I had been writing code for years by then, so confidently, almost with a sense of pride, I wrote the exact same structure I had written countless times:

if number % 2 == 0 {
    print("Even")
} else {
    print("Odd")
}

I pushed my solution forward, expecting approval. Joseph looked at it, smiled kindly, and said, "No. Write that in a single line." In that moment, I froze. There was no reason for me to hesitate. I knew modulus and I understood conditions, but I hadn't trained myself to think beyond my usual habits. I was coding on autopilot. The answer he wanted was actually very simple:

print(number % 2 == 0 ? "Even" : "Odd")

The two-line version wasn't wrong or less readable. The real problem was that I had stopped being curious and pushing myself. I was coding out of habit, not with intention. This year, as I mentored engineers from all over, I saw that same gap between knowing and thinking happen again and again.

Patterns from 1,500 Minutes of Mentoring

After hundreds of mentoring sessions, I noticed some clear patterns. The engineers who struggled most didn't lack technical skills—they lacked clarity. Many people asked questions not about code, but about direction: "What exactly is being asked here?", "What is the real problem?", "Why am I stuck?", "What am I missing?", "Why does this feel confusing?" Engineers often think the next framework or tutorial will help, but what they really need is the ability to see the problem clearly. I saw how powerful clarity is and how quickly it can turn frustration into progress. I also saw how rare it is. The people who grew the most this year weren't the ones who knew the most tools, but the ones who learned to think clearly.

The Power of Clarity

Along with clarity, another important skill stood out: communication. It's not about talking more or explaining everything, but about sharing your thoughts, organizing ideas, asking the right questions, and guiding discussions without overwhelming others. Communication isn't just a "soft" skill—it's an engineering skill. A system is only as strong as its creators' clarity. This year, I saw engineers get promoted not for writing more code, but for expressing their thinking with precision and confidence. Communication became the bridge between talent and impact.

Communication as an Engineering Skill

Then there was orchestration, a quiet skill that separates engineers who just do their tasks from those who create momentum. Orchestration isn't about management or authority. It's about influencing direction, guiding conversations, anticipating obstacles, bringing calm during confusion, and helping a group reach a clear outcome. Some of the most effective engineers I mentored didn't speak often, but when they did, everyone listened. They didn't force direction; they created it. They didn't lead loudly; they led with clarity. Orchestration is invisible leadership, and this year I saw how much this skill defines true senior engineers.

The Crisis of Ownership

But nothing stood out more in all 1,500 minutes than the crisis of ownership, even among senior engineers—true, end-to-end ownership. This is where engineers struggle most, and where growth happens fastest once the mindset changes. Too many engineers have spent years limiting themselves to only "what the ticket says." I heard countless versions of:

These aren't signs of incompetence; they are signs of limited thinking. Engineers who work this way see themselves as just parts of a pipeline, only responsible for what's in front of them. But the best engineers (the ones who grow quickly and reliably) think differently. They see the whole system. They understand the flow from when a feature is first imagined to when a user interacts with it. They follow their work beyond the code. They open the app, test the flow, break it, and rebuild it. They ask deeper questions. They look at neighboring files. They read previous pull requests. They don't wait for permission to care about the bigger picture

This year, I saw many engineers who had been stuck for years suddenly move forward as soon as they embraced ownership. They became more confident, creative, impactful, and valuable. They became the people others relied on. They became the ones with answers when things got chaotic. They became the memory of their teams, the knowledge banks who understood not just what was built, but why. They became pillars, engineers no company could easily replac

The Emotional Journey

The emotional journey was just as powerful. Many mentorship conversations started with technical issues but ended with something deeper. People shared fears, insecurity, exhaustion, imposter syndrome, comparison anxiety, and the quiet worry that they weren't improving fast enough. I learned that behind every engineer is a person dealing with doubts, pressure, and expectations. No amount of syntax mastery can protect you from the emotional ups and downs of growth. But once engineers understood that thinking, not typing, is the core of the job, something changed. The panic faded. The fear eased. The path forward became clearer.

The engineers who grew the most this year weren't the ones chasing frameworks. They were the ones seeking understanding. They treated engineering as a craft, not a checklist. They stayed curious, asked deep questions, explored fundamentals, and challenged assumptions. They thought more than they typed. They took ownership of what they built, communicated clearly, guided direction, and cared. Because of that, they rose.

The Deepest Truth

After nearly 1,500 minutes of mentoring this year, I found the deepest truth is simple: engineering has never been about code. It has always been about thinking. Keyboards, languages, tools, and frameworks are secondary. The real work is in how you reason, communicate, understand, anticipate, and connect the dots that others miss.

The engineers who rise are those who think clearly, act with intention, communicate thoughtfully, and take deep responsibility. They see the product, not just the ticket; the user, not just the code; and the consequences, not just the requirements.

Mentoring has become one of the most meaningful parts of my journey. Through late-night calls, honest conversations, breakthroughs, and moments of reflection, I realized how fulfilling it is to help engineers find clarity, rebuild confidence, and reconnect to the craft of thinking. If you're on your engineering journey, whether building fundamentals, seeking clarity, aiming for senior roles, or just learning to think more deeply, I'm always open to help when I can. Growth is rarely a solo journey; our industry gets stronger when we learn, question, and rise together.