Personal

Emmanuel Asika’s Advice for 20-Year-Old Coders

Oct 6, 2025
8 min read
E.A
Emmanuel Asika

Stop over-optimizing. Start shipping. From WordPress hustles to Cloud engineering, here is the raw, technical advice I wish I had at 20.

The Code Doesn't Matter (Until It Does)

I turn 20, blink, and suddenly I'm deep in a Masters program in Ireland, pivoting from a reliable WordPress hustle to the complex world of Cloud Engineering and Indie Hacking. When I look back at the code I wrote at 20, I cringe. Not because the syntax was wrong, but because the thinking was wrong.

At 20, you have energy. You have time. But you usually lack context. You treat programming like a competitive sport of memorizing syntax or arguing about frameworks on X (formerly Twitter).

If I could sit down with my 20-year-old self, or any 20-year-old writing code today, I wouldn't tell them to just "learn Python." That's lazy advice. I'd tell them how to survive the next decade of tech without burning out or becoming obsolete. Here is the blueprint.

1. Stop Being a "Framework Fanboy" and Learn Patterns

I spent years in the WordPress ecosystem. It paid the bills. It bought me freedom. But for a long time, I confused "knowing WordPress functions" with "knowing software engineering."

When I decided to pivot to modern SaaS stacks-Next.js, Supabase, Tailwind-I felt like a junior again. Why? Because I had memorized a specific tool instead of the underlying patterns.

Don't attach your identity to a framework. React might die. Next.js might get bloated (some argue it already is). But the patterns remain.

The MVC Pattern is Eternal

Whether you are building a plugin in PHP or a route handler in Next.js, you are essentially moving data from a database to a view.

When you learn Next.js, don't just memorize how to use useClient. Understand why client-side rendering exists versus server-side rendering. Understand the hydration gap.

Here is a practical example. A 20-year-old dev learns to fetch data in a React component like this:

// The Junior Way: Fetching inside useEffect without understanding the cost import { useState, useEffect } from 'react'; export default function BadDashboard() { const [data, setData] = useState(null); useEffect(() => { fetch('/api/user') .then(res => res.json()) .then(data => setData(data)); }, []); if (!data) return <div>Loading...</div>; return <div>{data.name}</div>; }

It works. But it cascades. It creates layout shifts. It's bad UX.

Now that I'm building scalable systems, I look at Server Actions or server-side data fetching. I look at keeping the heavy lifting off the client's phone.

// The Senior/Modern Way: Leveraging Server Components import { createClient } from '@/utils/supabase/server'; export default async function GoodDashboard() { const supabase = createClient(); const { data: user } = await supabase.auth.getUser(); return <div>{user?.email}</div>; }

The syntax changes. The concept of "Get data securely, render HTML" does not. Focus on the concept.

2. Infrastructure is Not "Someone Else's Job"

This is the biggest gap I see. You write the code, push to GitHub, and Vercel magically deploys it. That is great for velocity, but it is terrible for your education.

I am currently studying Cloud Computing. I am diving into AWS and Azure. Do you know what happens when Vercel's pricing tier hits you in the face? You need to know how to deploy a Docker container. You need to know what a VPC is.

At 20, you should spin up a raw Linux VPS (Virtual Private Server) on DigitalOcean or AWS EC2. SSH into it. Try to deploy your Node app manually with Nginx as a reverse proxy. You will fail. You will get permission errors. You will break the firewall.

Good.

That pain teaches you more about software than 100 LeetCode problems.

Understanding infrastructure-how memory works, how latency affects databases, how cold starts kill Lambda functions-makes you a better application developer.

Here is a simple Dockerfile. If you can't read this and explain what every line does, stop learning new React hooks and learn this:

# Use a lightweight node image FROM node:18-alpine # Set working directory WORKDIR /app # Copy package files first (better caching) COPY package*.json ./ # Install dependencies RUN npm install --production # Copy the rest of the code COPY . . # Expose the port EXPOSE 3000 # Start the app CMD ["npm", "start"]

When you understand that your code lives in a box like this, you start writing code that is "stateless." You stop writing files to the local disk because you know that container might disappear in 5 minutes. That is Cloud Engineering thinking.

3. Speed Wins (The Indie Hacker Mindset)

I value freedom. That is why I pivoted to Indie Hacking.

Corporate development is slow. They have meetings about meetings. When you are 20, your superpower is speed. You can out-build a team of 10 seniors because you don't have to ask for permission.

But you can only move fast if you pick a boring stack and stick to it.

My stack is:

  • Next.js (Frontend & Backend)
  • Tailwind CSS (Styling)
  • Shadcn/UI (Components)
  • Supabase (Database & Auth)

I do not waste time configuring Webpack. I do not waste time building a custom dropdown menu. Shadcn gives me the component, I copy-paste it, and I move on to the business logic.

Do not invent problems. If you are building a SaaS, your users do not care if you used Redux, Zustand, or Context API. They care if the button works.

Use Tailwind. People hate on it because it looks ugly in the HTML. But it allows you to style at the speed of thought. You stop fighting the cascade and start building interfaces.

4. Databases Are Where the Truth Lives

Frontend is flashy. Backend is logic. But the Database is the truth.

In my WordPress days, the database was a mess of wp_options and serialized arrays. It was a nightmare to query efficiently.

Now, working with Supabase (PostgreSQL), I realize that 90% of performance issues are just bad schema design.

At 20, you probably just want to use a NoSQL database like MongoDB or Firebase because it's "easy." You just dump JSON objects and forget about it.

Don't.

Learn SQL. Learn Relational Data Modeling. Learn what normalization is (and when to break it).

If you design your database wrong, no amount of clean React code will save you. If you design it right, the code almost writes itself.

Learn about Row Level Security (RLS). In Supabase, you don't write backend logic to check if a user owns a document. You write a policy in the database itself. This is powerful.

-- A simple RLS policy in PostgreSQL -- Only allow users to select their own data create policy "Users can view own data" on profiles for select to authenticated using ( auth.uid() = id );

This single chunk of SQL replaces dozens of lines of middleware code. It is safer and faster. Learn the database deeply.

5. You Must Learn to Sell (or at least communicate)

I used to think my job was just to write the best code. I was wrong.

As a freelancer, I learned quickly that the client doesn't pay for code. They pay for a solution to a painful problem.

If you are an engineer who can only speak to machines, you will hit a ceiling. You will be the person in the basement implementing tickets written by someone who makes twice your salary.

Start writing. Start documenting what you build.

When I post about my journey from WordPress to Cloud, or explain a technical concept in Next.js, I am creating luck. I am building authority.

Indie Hacking is 20% coding and 80% marketing. You might hate hearing that. I hated hearing it. But it is the truth.

If you build the most scalable, clean-code SaaS on Azure using the perfect microservices architecture, and nobody uses it, you have failed.

If you build a messy monolithic script that solves a real problem for 100 people paying $10 a month, you have succeeded.

6. AI is Your Junior Developer, Not Your Replacement

There is a lot of doom and gloom right now. "Devin will replace us." "ChatGPT writes better code."

Relax.

I use AI every single day. I use Cursor. I use Copilot. It has made me 10x faster. But it hasn't replaced my brain.

AI is excellent at boilerplate. It is terrible at architecture. It is terrible at understanding context.

Use AI to generate the regex you always forget. Use it to scaffold a Shadcn form. Use it to write unit tests.

But do not blindly copy-paste. I have seen AI suggest SQL queries that would bring a production server to its knees because it missed an index.

If you don't understand the code the AI wrote, you are technical debt waiting to happen.

The developers who will get replaced are the ones who just output syntax. The developers who will thrive are the ones who act as "System Architects," orchestrating AI tools to build complex solutions faster.

7. Embrace the "Rough" Edges

Perfectionism is procrastination in a tuxedo.

When you are 20, you want your GitHub graph to be green and your code to be lint-free.

But in the real world-whether you are freelancing or building a startup-rough edges are fine. Shipping a feature with a known bug (that isn't critical) is often better than delaying launch by two weeks to fix it.

My transition to Cloud Engineering taught me this too. AWS is messy. The console is ugly. Documentation is scattered. You have to get comfortable with being uncomfortable.

You have to get used to reading error logs that make no sense. You have to get used to digging through Stack Overflow threads from 2014.

That grit is what makes you a senior engineer. Not the number of years you've been working, but the number of fires you've put out.

Summary: The Path Forward

If I was restarting my career at 20 today:

  1. Pick a stack and go deep. Next.js, TS, SQL is a safe bet.
  2. Learn the Cloud. Not just Vercel. Learn Docker, AWS, CI/CD.
  3. Build Products. Don't just do tutorials. Build a tiny SaaS. Try to get $1 from a stranger.
  4. Write. Share what you learn. It attracts opportunities.

You have the time. You have the resources. Just stop over-thinking and ship.

#emmanuel#IndieHacker

Read Next