Coder Legion - Recent posts tagged mentoring

Why I Mentor Junior Developers: Growing the Next Generation of Tech Talent

Sun, 19 Apr 2026 21:20:18 +0000

In 2017, I was a backend developer at Civic MediaLab in Lagos, staring at a production codebase that made no sense to me. The API layer was a tangle of inconsistent patterns. The database schema looked like it had been designed by three different people who never spoke to each other. I was technically employed to write code, but I had no idea where to start.

A senior engineer on the team — a man who had no formal obligation to teach me anything — sat me down one afternoon, opened the codebase on his screen, and walked me through the architecture. Not just the "what," but the "why." Why the services were structured that way. Why certain trade-offs had been made. Why the team had chosen Laravel over alternatives for that particular project. That single afternoon reshaped how I thought about software engineering. It was the first time someone had treated me not as a resource to extract output from, but as a professional worth investing in.

That moment planted a seed. Over nine years of building systems across fintech, health-tech, gaming, logistics, and enterprise SaaS, I have become the engineer who pulls up a chair and walks through the architecture. Mentoring junior developers is not a side activity for me — it is a fundamental part of how I practise engineering, and I believe it is one of the most impactful things a senior engineer can do for the technology sector.

The Mentoring Gap in Tech

The technology industry has a well-documented pipeline problem. We talk endlessly about hiring, about talent shortages, about the difficulty of finding "senior" engineers. What we talk about far less is the systematic failure to develop the talent we already have.

This gap is especially acute in emerging markets. In Lagos, where I began my career, the demand for experienced software engineers far outstrips supply. Boot camps and university programmes produce developers who can write code, but the journey from writing code to building production systems — understanding architecture, debugging complex distributed systems, making sound technical trade-offs under pressure — that journey requires guided experience. It requires mentorship.

The statistics bear this out. According to a 2023 Stack Overflow Developer Survey, over 60% of developers with fewer than five years of experience report that they lack access to meaningful technical mentorship at work. In African tech ecosystems, where the average engineering team is smaller and companies often cannot afford dedicated developer experience roles, the problem is even more pronounced.

I have seen the consequences firsthand. Junior developers who are talented but directionless, writing code that works but does not scale. Mid-level engineers who have plateaued because nobody ever showed them how to think about system design. Brilliant minds leaving the industry entirely because they felt unsupported and overwhelmed.

This is not a talent problem. It is a mentorship problem. And it is one that senior engineers — those of us who have accumulated the scars and the knowledge — have both the ability and the responsibility to solve.

My Approach to Mentoring

Over the years, I have developed a mentoring approach that goes beyond answering questions when asked. It is proactive, structured, and woven into the daily fabric of engineering work. I learned early that the most effective mentoring does not happen in scheduled one-on-ones (though those matter too). It happens in the moments where engineering decisions are being made in real time.

Code Reviews as Teaching Moments

I treat every code review as a teaching opportunity. When I review a junior developer's pull request, I do not simply approve or request changes. I explain the reasoning behind my suggestions. If I ask someone to refactor a database query, I explain what the current query does to performance at scale. If I suggest a different design pattern, I walk through the trade-offs of both approaches.

At Lordwin Group, where I led a team of five backend developers, I established a code review culture where every pull request received at least two reviews, and at least one review had to include an explanatory comment — not just "change this," but "here is why." The impact was immediate. Junior developers began anticipating architectural concerns in their own code before the review stage. The quality of initial submissions improved dramatically within three months.

I remember reviewing a pull request from a junior developer on the team who had written a working but brittle API endpoint for the gaming platform. Instead of rewriting it myself, I scheduled a 30-minute pair programming session. We walked through the request lifecycle together — how the payload was validated, how the database was queried, how the response was structured, and where the failure points were under load. By the end of the session, the developer had refactored the endpoint themselves, and more importantly, they understood the principles behind the refactoring. That developer went on to independently architect a feature module for our investment platform three months later.

Pair Programming as Skill Transfer

Pair programming is the most underutilised mentoring tool in software engineering. I use it deliberately, especially for complex features or unfamiliar domains. When I was at 2am Tech, collaborating with a cross-functional team of eight engineers building Addio — a financial platform serving 500+ organisations — I regularly paired with less experienced team members on critical backend work.

One engineer on the team was strong in frontend development but had limited backend experience. Rather than assigning them only frontend tasks, I paired with them on building a Node.js service that handled vendor payment workflows. Over several pairing sessions, we worked through API design, database transaction management, error handling patterns, and queue-based architecture for processing payments asynchronously. Within two months, that engineer was confidently building backend services independently and had begun contributing to our architecture discussions.

Olamilekan Lamidi does not hoard knowledge. That principle guides everything I do in a team.

Architecture Discussions as Education

I make a point of including junior and mid-level engineers in architecture discussions, even when their immediate role does not require it. At 54gene, where I worked as a full-stack developer building data collection systems for Africa's leading genomics company, we had a cross-functional team of 10+ members. I advocated for — and helped establish — weekly architecture review sessions where engineers at every level could participate.

These sessions were not presentations. They were collaborative discussions where I would propose an architecture, invite challenges, and walk through the reasoning behind decisions. Why we chose a service-oriented approach for certain modules. Why we implemented specific caching strategies for patient data forms. How we balanced data sensitivity with system performance.

The junior engineers on the team may not have been making those architectural decisions, but by witnessing and participating in the discussion, they were building the mental models they would need when they eventually did. Several of those engineers have since moved into senior roles at other companies — and I know those sessions played a part in their growth.

Structuring Mentorship Beyond Technical Skills

Technical mentoring is essential, but it is not sufficient. The engineers I mentor most effectively are the ones where I invest in three dimensions: technical skills, soft skills, and career navigation.

Technical Skills: Building Depth and Breadth

I structure technical mentoring around progressive complexity. A junior developer on my team does not jump straight from CRUD operations to distributed systems. I map out a learning path:

Foundations: Clean code, testing, version control discipline, debugging methodologies
Intermediate: API design, database optimisation, authentication patterns, error handling at scale
Advanced: System architecture, event-driven patterns, performance profiling, infrastructure as code

At Lordwin Group, I created informal "engineering growth plans" for each of the five developers I led. These were not corporate HR documents — they were living technical roadmaps. Each quarter, I sat with every team member and reviewed where they were, what they had learned, and what they needed to tackle next. One developer who started as a PHP-only backend engineer progressed to confidently working across Node.js and React within eight months through this structured approach.

Soft Skills: Communication, Estimation, and Ownership

I have watched technically brilliant engineers stall in their careers because they could not communicate their ideas, estimate their work, or take ownership of outcomes. Mentoring in these areas is harder — it requires trust and candid conversation — but the payoff is enormous.

I coach engineers on how to present technical proposals to non-technical stakeholders. How to write clear, concise pull request descriptions. How to estimate work by breaking down unknowns. How to own a failure, conduct a post-mortem, and extract lessons without blame. These are the skills that separate engineers who write code from engineers who lead teams.

Career Guidance: Navigating the Path

Especially for engineers in Lagos and across Africa, career navigation can be opaque. Which technologies should you invest in? When should you specialise versus generalise? How do you break into remote roles with international companies? How do you negotiate compensation?

I share my own career trajectory openly — from Civic MediaLab in Lagos to working with teams across Ukraine, the United States, and the United Kingdom. I discuss the decisions I made, the mistakes I made, and the skills that unlocked each transition. For engineers who aspire to work on the global stage, having someone who has walked that path is invaluable.

Impact: Developers Who Grew

Mentoring is difficult to quantify. There is no dashboard that shows "junior developer promoted to senior because Olamilekan Lamidi spent 30 minutes explaining event-driven architecture." But the evidence is there in the trajectories of the people I have worked with.

At Lordwin Group, two of the five developers I led as a senior engineer went on to secure senior engineering positions within 18 months of our time working together. One of them now leads a team of his own at a fintech company in Lagos. He told me directly that the code review culture and architecture discussions I established were the most impactful learning experiences of his early career.

At 2am Tech, the engineer I paired with on backend services went from being a frontend-only developer to a full-stack engineer within one product cycle. They credited the pairing sessions with giving them the confidence to tackle unfamiliar domains.

At 54gene, the junior engineers who participated in our architecture reviews went on to contribute meaningfully to system design decisions by the end of their tenure — a progression that typically takes much longer without structured exposure.

These are not isolated cases. They are the predictable outcome of treating mentoring as engineering work — work that deserves time, intention, and rigour.

Community Engagement: Mentoring Beyond the Workplace

My commitment to mentoring extends beyond the teams I work with directly. I have been active in the Lagos tech community, participating in developer meetups and knowledge-sharing sessions that help early-career engineers navigate the industry. I engage on platforms like ADPList, where I offer mentoring sessions focused on backend engineering, career transitions, and breaking into remote international roles.

I also contribute to the broader engineering community through technical writing — articles like this one, published on Medium, DEV.TO, and LinkedIn — that distil hard-earned lessons into accessible guidance. Every article I publish is, in a sense, a mentoring session at scale. When a junior developer in Nairobi or Accra reads about how I optimised database queries at VacancySoft or architected a real-time gaming backend at Lordwin Group, they are gaining access to production-level knowledge that they might not encounter in their current work environment.

This is not altruism. It is ecosystem building. The stronger the engineers around me, the stronger the teams I work with, the products I contribute to, and the industry as a whole.

The Business Case for Mentoring

For engineering leaders reading this, mentoring is not just a moral good — it is a strategic advantage. The data is compelling:

Faster Onboarding. Teams with structured mentoring practices onboard new engineers 40–50% faster. At Lordwin Group, new developers were contributing production code within their second week, compared to the industry average of four to six weeks. This was a direct result of the code review culture and pairing practices I established.

Better Code Quality. When junior developers understand the "why" behind architectural decisions, they write better code from the start. Our pull request rejection rate at Lordwin Group dropped by roughly 35% within four months of implementing teaching-oriented code reviews.

Reduced Turnover. Engineers who feel invested in stay. In an industry where the average tenure is under two years, creating an environment where developers are actively growing is one of the most effective retention strategies available. The Lordwin team remained remarkably stable during my tenure despite competitive market conditions.

Knowledge Distribution. In teams without mentoring culture, knowledge concentrates in one or two senior engineers. This creates catastrophic bus factor risk. By actively distributing knowledge through mentoring, I ensured that no single engineer — including myself — was a single point of failure.

A Call to Action for Senior Engineers

If you are a senior engineer reading this, I want to challenge you directly: when was the last time you deliberately taught someone something?

Not answered a question in Slack. Not pointed someone to the documentation. Actually sat down, understood where someone was struggling, and helped them build the mental model they needed to solve the problem themselves.

Olamilekan Lamidi's career was shaped by a senior engineer who chose to invest 30 minutes in a confused junior developer at Civic MediaLab in 2017. That investment compounded. It made me a better engineer, which made me a better technical lead, which made the teams I led more effective, which made the products we shipped more robust.

Every senior engineer has this power. The question is whether we choose to use it.

The technology sector does not advance through individual brilliance alone. It advances when knowledge flows freely, when experienced practitioners invest in the next generation, and when the barriers to entry are lowered not by reducing standards, but by raising support.

I mentor because I was mentored. I share because someone shared with me. And I will continue doing so because I have seen, over nine years and across six companies and four countries, that this is how you build an industry that lasts.

Building Sustainable Developer Habits in 2026

Sun, 18 Jan 2026 15:23:30 +0000

The pace of software development has never been faster. New frameworks appear overnight, AI tools rewrite code in seconds, and “just ship it” has become a default mindset. In the middle of all this speed, many developers are burning out, working harder, learning more, yet feeling less fulfilled.

In 2026, technical skill alone is no longer enough. What separates developers who thrive from those who struggle is something quieter and far more powerful: sustainable habits.

This article explores how to build developer habits that last, habits that support growth, productivity, and long-term well-being without constant exhaustion.

Why Developer Habits Matter More Than Ever

Modern developers don’t just write code. They:

Manage complex systems
Learn continuously
Debug under pressure
Collaborate across time zones
Adapt to constant change

Without strong habits, even talented engineers eventually hit a wall.

Sustainable habits help you:

Maintain consistent productivity
Learn without overwhelm
Reduce burnout
Improve code quality over time
Enjoy the work, not just survive it

In 2026, sustainability isn’t a luxury. It’s a requirement.

What “Sustainable” Really Means for Developers

Sustainable habits aren’t about doing less, they’re about doing the right things consistently.

A sustainable habit:

Fits into real-life schedules
Scales with workload
Doesn’t rely on constant motivation
Supports both mental and technical growth

The goal isn’t perfection. It’s longevity.

1. Focus on Systems, Not Motivation

Motivation comes and goes. Systems stay.

Developers who last build systems that make good behavior the default:

Scheduled learning time instead of “when I feel like it”
Code review checklists instead of relying on memory
Automated tests instead of manual confidence

In 2026, sustainable growth comes from reducing friction, not increasing willpower.

2. Learn Continuously, But Intentionally

The tech world rewards learning, but unstructured learning leads to burnout.

What sustainable learning looks like:

Picking one primary focus at a time
Going deep instead of chasing trends
Learning through real projects, not endless tutorials

You don’t need to learn everything. You need to learn what compounds.

3. Write Code for Humans First

Fast shipping without clarity creates future pain.

Developers building sustainable careers prioritize:

Readable code
Clear naming
Thoughtful comments
Predictable structure

In 2026, maintainability is a form of self-care. Future-you is part of the team.

4. Automate Repetitive Work Early

Repetition is a silent energy drain.

Sustainable developers:

Automate builds and deployments
Script common tasks
Reduce manual steps wherever possible

Automation doesn’t just save time, it saves mental bandwidth, which is your most limited resource.

5. Protect Your Focus Ruthlessly

Context switching is one of the biggest productivity killers.

Healthy focus habits include:

Dedicated deep-work blocks
Muted notifications during coding sessions
Clear boundaries between work and rest

In a world full of pings, protecting focus is a competitive advantage.

6. Use Tools to Reduce Cognitive Load, Not Increase It

More tools don’t always mean better productivity.

Sustainable tool usage means:

Choosing tools that simplify workflows
Avoiding unnecessary complexity
Mastering fewer tools deeply

In 2026, simplicity scales better than novelty.

7. Build Reflection Into Your Workflow

Sustainable improvement requires feedback.

Simple reflection habits:

Reviewing what went well after projects
Noting recurring pain points
Adjusting processes intentionally

Growth without reflection is just repetition.

8. Take Care of Your Body to Support Your Mind

This isn’t talked about enough in tech.

Your ability to think clearly depends on:

Sleep quality
Movement
Breaks
Posture

Sustainable productivity is biological, not just technical.

9. Embrace Long-Term Thinking Over Short-Term Output

In 2026, the best developers think in years, not sprints.

They:

Invest in fundamentals
Build reusable knowledge
Avoid constant crisis mode

Short-term speed without long-term vision leads to burnout and fragile systems.

10. Redefine What "Success" Looks Like

Sustainable developers redefine success beyond:

Lines of code written
Hours worked
Constant hustle

Real success includes:

Consistent growth
Enjoyable work
Stable health
Strong professional relationships

Careers are marathons, not launch sprints.

How These Habits Compound Over Time

Individually, these habits feel small. Together, they compound into:

Better decision-making
Higher-quality output
Reduced stress
Stronger career resilience

In 2026, compounding habits outperform raw effort every time.

Conclusion: Sustainable Developers Win Long-Term

The future of development belongs to those who can adapt without burning out.

Building sustainable developer habits isn’t about slowing down, it’s about creating a pace you can maintain while still growing. When your habits support you, progress stops feeling like a fight.

If this article resonated with you, share it with another developer who’s trying to build not just better code, but a better career.

Building & Staying Secure as a Solo Developer (Text Seminar)

Sun, 11 Jan 2026 13:44:59 +0000

This post is written in a seminar-style format.

You can read it quietly, pause, reflect, and come back.
No rush. No performance.

Welcome

Hi, I’m Prasoon Jadon, a solo builder working on tools, open-source projects, and security awareness under Vyoma.

This article is part of VSAP — Vyoma Security Awareness Program.

The goal is simple:

Help developers stay secure while building publicly.

Why This Matters

As developers, we:

Push code publicly
Share progress online
Build in open communities

This is powerful — but it also creates attack surfaces we often ignore.

Security is not paranoia.
Security is awareness.

1️⃣ Public Repositories Are Not Safe by Default

One of the most common mistakes I see:

Treating public repositories as harmless.

Never commit:

API keys
Tokens
.env files
Internal URLs

Even if you delete them later, history remains.

Habit to build:
Always assume your code will be read by strangers.

2️⃣ OSINT Works Both Ways

OSINT (Open-Source Intelligence) means:

Collecting information from publicly available sources.

Developers unknowingly leak:

Email addresses
GitHub activity patterns
Tech stack details
Location hints

If you can research companies using OSINT,
someone can research you the same way.

Question to reflect on:
What can someone learn about me in 10 minutes online?

3️⃣ Security Is a Habit, Not a Tool

Many developers ask:

“Which security tool should I use?”

The honest answer:
Tools help, but habits protect.

Core habits:

Unique passwords
Password managers
Regular updates
Minimal permissions
Thinking before sharing

Most breaches happen due to human habits, not missing tools.

4️⃣ Building in Public ≠ Oversharing

Building in public is great.
Oversharing is risky.

You don’t need to share:

Exact infrastructure details
Internal logic
Sensitive architecture diagrams

Rule of thumb:
Share learnings, not weaknesses.

5️⃣ Calm Security > Fear-Based Security

Security content often relies on fear.

VSAP focuses on:

Awareness over panic
Habits over hacks
Calm learning

Security should empower you, not scare you.

Open Reflection

If this were a live text seminar, I’d ask:

What security mistake taught you the most?
What’s one habit you want to improve?
What topic should the next session cover?

You can reflect privately or share in comments.

Closing Thoughts

This article is not about being perfect.
It’s about being a little more aware than yesterday.

I’m experimenting with:

Text-based seminars
Calm developer communities
Community-first growth under Vyoma

If this style resonates, more sessions will follow.

Thanks for reading quietly
— Prasoon Jadon
Founder, Vyoma

Building a Quiet Developer Community (and Why Text-Based Conferences Matter)

Thu, 01 Jan 2026 13:59:28 +0000

Building a Quiet Developer Community (and Why Text-Based Conferences Matter)

Most developer communities today are loud.

Too many notifications.
Too much self-promotion.
Too little signal.

I wanted something different — so I started Vyoma Dev Circle.

What is Vyoma Dev Circle?

It’s a small, focused space for developers to talk about:

Tech ideas
Product building
Real code problems
Learning in public

No spam.
No hustle culture.
No pressure to “perform”.

Just builders helping builders.

Introducing TextConf (Text-Based Conferences)

Not everyone is comfortable with voice calls or live talks — and that’s okay.

TextConf is our experiment:

30–45 minute text-only sessions
One focused topic
Calm, thoughtful discussion
Questions > noise

No mic. No stage fear.
Ideas come first.

Who is this for?

Student developers
Indie builders
Beginners who want to ask real questions
Anyone tired of chaotic servers

If you like building quietly and consistently, you’ll fit right in.

Why small communities matter

Growth can wait.
Quality can’t.

Strong communities aren’t built by numbers — they’re built by regular, meaningful conversations.

That’s what we’re trying to do here.

Join the circle

If this resonates with you:

DM “DEV” on Instagram → @vyomanews
Tell us what you’re learning or building

Built under Vyoma
by @developer_prasoon