DEV Community: Victor Osunrinde

Do You Need to Memorize Syntax to Be a Real Developer? I Had the Same Question.

Victor Osunrinde — Wed, 10 Jun 2026 17:55:44 +0000

I'm Victor. Self-taught JavaScript developer, currently working through The Odin Project. Four years into this and there are still days I open my editor and have to Google syntax I've used a hundred times before.

For a long time that felt like a problem. Like everyone else had this memorized and I was the only one quietly opening MDN in a second tab hoping nobody noticed.

That feeling has a name. Imposter syndrome. And it's lying to you.

The Question Every Beginner Has But Won't Ask

When you're starting out, you encounter so much syntax so fast. Arrow functions, array methods, promises, async await. Every tutorial introduces something new.

Somewhere in the middle of all that, a quiet anxiety builds.

Should I be memorizing this? Am I falling behind if I have to look it up?

Most beginners feel this. Almost none of them say it out loud.

So let me say it clearly: No. You do not need to memorize syntax to be a real developer. That belief is one of the most damaging ideas a beginner can carry.

Memorization and Understanding Are Not the Same Thing

Memorizing means you can recall something without any help. Understanding means you know what it does, why it exists, and when to use it.

Only one of those actually matters for building software.

Here is a personal example.

I know what forEach does. I understand it loops over every item in an array and runs a function on each one. I know when to use it over map or filter. But if you asked me to write the exact syntax from memory right now without autocomplete, I might pause for a second.

Does that mean I don't know forEach? No. It means I understand it and I know where to find the syntax when I need it. That combination is what makes you effective.

Another example: async/await. I understand that it handles asynchronous code and makes it read like synchronous code. I know why it exists. I still occasionally check the exact syntax for error handling with try/catch when I haven't used it in a while. That is completely normal.

Memorization without understanding is useless. Understanding without perfect memorization is completely fine.

What Actually Happens in the Real World

Senior developers Google things constantly. Every single day. Developers with ten, fifteen years of experience open documentation regularly, use IDE autocomplete, and ask AI tools like Claude or ChatGPT to remind them of syntax they've used a hundred times.

This is not a secret. It just doesn't fit the image of the mythical developer who has everything in their head.

The job is not to be a human syntax dictionary. The job is to understand the problem, identify the right approach, and know how to find what you need.

Google is a tool. Documentation is a tool. AI assistants are a tool. Using tools is the job.

The developer who looks up syntax and understands what they are doing with it will always outperform the developer who has syntax memorized but doesn't understand the logic underneath it.

What Companies Actually Expect From You

Companies are not hiring developers to recite syntax. Here is what they actually care about.

Problem solving skills
Can you break a problem into smaller pieces and work through it? This is about how you think, not what you have memorized.

Code quality
Do you write code other developers can read? Do you handle errors? Do you think about edge cases? These are judgment calls, not memory exercises.

Debugging skills
When something breaks, can you read the error, trace where it is coming from, and test a fix? Debugging is built entirely on understanding.

No company worth working for cares whether you can write a reduce function from memory. They care whether you can solve real problems.

What Repetition Actually Does

When you start learning JavaScript you will look up forEach every time you use it. After the fifteenth time you will start to remember it. After the fiftieth time it comes out automatically.

That is how syntax gets into your head when you build consistently. Not through drilling. Through repeated use in real projects.

The syntax you use most becomes automatic over time. The syntax you rarely use stays something you look up. Both are completely fine.

Keep building. Repetition takes care of the rest.

Fundamentals Are What Actually Matter

Focus on building mental models, not memorizing syntax.

Understand what a function is and why it exists. Understand how the browser communicates with a server. Understand what asynchronous code means. Once you have those mental models, any syntax becomes something you can look up and immediately understand because you already know what it is supposed to do.

Fundamentals transfer. Memorized syntax does not.

The Answer

Do you need to memorize syntax to be a real developer?

No.

You need to understand what you are building. You need to read documentation. You need to use the tools available to you, search engines, your IDE, AI assistants. You need to keep building things that break and force you to figure out why.

That process is what turns a beginner into a developer.

Imposter syndrome told me I wasn't a real developer because I had to look up syntax. What actually makes you a real developer is knowing what to build, why to build it, and how to find what you need to build it.

Open the editor. Write the code. Look up what you need to look up.

That is exactly what every developer you admire is doing right now.

Resources

The Odin Project - theodinproject.com
Free, project-based, full stack curriculum. Teaches you how to think like a developer. This is where I am building my foundation.

MDN Web Docs - developer.mozilla.org
The most reliable JavaScript reference on the internet. No shame in living here.

JavaScript.info - javascript.info
The clearest explanation of JavaScript fundamentals available for free.

Victor Osunrinde is a self-taught developer based in Nigeria building in public at @VEND321

MySeniorDev

Victor Osunrinde — Sat, 23 May 2026 22:16:40 +0000

This is a submission for the Gemma 4 Challenge:
Build with Gemma 4

What I Built

MySeniorDev is a local-first AI code reviewer powered
by Gemma 4 E2B. You paste any file from your project
and get an honest, specific code review — the kind a
senior developer gives in a real pull request.

Three review modes:

Security — finds hardcoded secrets, missing validation, exposed API keys, auth holes
Architecture — flags god files, mixed concerns, patterns that won't scale
General — full review across security, structure, and code quality

After the review you can ask follow-up questions.
Gemma 4 holds your full file in context for the
entire conversation.

Built for self-taught developers who have never had
a mentor or senior developer to learn from. In Nigeria,
India, Indonesia — anywhere bootcamps are expensive
and code reviews are not accessible.

Demo

Code

GitHub — VEND321/MySeniorDev

The core of the project lives in two places:

The system prompt — backend/services/prompt.js
This is where the real intelligence is. Gemma 4 is
instructed to behave like a senior developer doing
a real pull request review — direct, specific, always
referencing the actual code, never giving generic advice.

The Ollama integration — backend/services/ollama.js
Sends code to Gemma 4 E2B running locally via Ollama
at http://localhost:11434. Falls back to Google AI
Studio automatically if Ollama is unavailable.

How I Used Gemma 4

Model chosen: Gemma 4 E2B via Ollama

I chose E2B for one reason: it runs on hardware most
developers in the world actually own. 8GB RAM. No GPU.
Consumer laptop. That is the target user's machine and
the model had to match.

Gemma 4 is doing real work at three layers:

1. Code Understanding
The model reads entire files pasted by the user and
reasons about them structurally — not just syntax,
but design patterns, security implications, and
architectural concerns. This requires the kind of
contextual reasoning Gemma 4 handles well.

2. Plain Language Translation
The system prompt instructs Gemma 4 to explain every
technical term it uses in the same sentence. A beginner
reading "SQL injection vulnerability" immediately gets
"that means an attacker can type code into your form
and your database will execute it." That translation
layer is entirely prompt-driven — Gemma 4 does it
consistently without being explicitly told each time.

3. Conversational Memory
Gemma 4's context window holds the full file across
the follow-up conversation. When a user asks "how do
I fix the auth issue you flagged?" the model still
knows their exact code. It answers specifically,
not generically.

Why local matters for this use case:
Every other AI code review tool sends your code to
a server. For a beginner pasting real production files
with real API keys and real secrets, that is a genuine
security risk most beginners don't know exists.
MySeniorDev runs Gemma 4 entirely on the user's machine.
Code goes from their editor to their RAM and back.
Nothing else.

That's not just a technical choice. That's the reason
this tool should exist.

Built by @VEND321

YouTube: darkshard

Location: Nigeria

Hardware: 8GB RAM, no GPU, consumer laptop

Model: Gemma 4 E2B via Ollama

I Ran Gemma 4 on an 8GB Laptop — Here’s What the Experience Was Actually Like

Victor Osunrinde — Fri, 22 May 2026 19:47:13 +0000

I took a screenshot of code with a SQL injection vulnerability, compressed it twice through WhatsApp, and fed it to Gemma 4 running entirely on my 8GB RAM laptop.

One minute and forty-seven seconds later, it pointed out the exact dangerous line, explained why it was vulnerable, and showed the correct way to fix it.

I'm a 19-year-old self-taught developer in Nigeria. I don't have a high-end machine or a GPU. Just a consumer laptop, an internet connection, and four years of figuring things out alone.

When Google released Gemma 4, I skipped most of the benchmark discussions and tested it myself to see what it could actually do on limited hardware.

This is that report.

TL;DR for the skimmers:

Gemma 4 E2B runs on 8GB RAM without a GPU
It analyzed a WhatsApp-compressed screenshot and caught a real SQL injection vulnerability
It handled Hausa naturally, while Yoruba and Igbo showed some limitations with diacritics
Available RAM matters more than you think
It’s free, private, offline, and surprisingly capable

What Gemma 4 Actually Is:

Before I get into what I found, here's the context you need.

Gemma 4 is Google DeepMind's latest family of open models. Open means you can download the weights and run them locally — no API costs, no data leaving your machine. For reference: E2B downloads at 7.2GB best for 8gb RAM device, E4B at 9.6GB best for 16gb RAM.

The family comes in three variants:

E2B and E4B — The Edge Models
Built for ultra-low resource deployment. Think mobile devices, Raspberry Pi, laptops without GPUs. E2B has around 2 billion effective parameters. E4B has around 4 billion. These are the models that run on hardware most developers in the world actually own. This is what I tested.

31B Dense — The Bridge Model

31 billion parameters in a dense architecture. Sits between consumer hardware and full server deployment. Bridges the gap between what you can run locally on a powerful machine and what requires a data center.

26B MoE — The Efficient Reasoner
26 billion parameters in a Mixture-of-Experts architecture. Not all parameters activate for every token; only the relevant experts fire. This makes it highly efficient for reasoning tasks at scale without burning through compute proportionally.

I tested E2B. Here's why that matters for developers like me.

Test 1 — Vision: Low quality Image Test

This was not a clean lab test. This was real world conditions.

I had a screenshot of an Express.js route with a SQL injection vulnerability — the classic mistake where user input goes directly into a database query without sanitization. Instead of taking a clean screenshot and uploading it properly, I sent it through WhatsApp. Then I downloaded it and sent it through WhatsApp again. Anyone who has done this knows what happens; WhatsApp compresses images aggressively. By the time I fed it to Gemma 4, the image quality had degraded significantly.

I opened Google AI Studio, loaded Gemma 4, uploaded the image, and asked it to review the code for security issues.

What happened:

One minute and forty-seven seconds later; on a fresh boot with nothing else running Gemma 4 returned a structured response that:

Identified the exact vulnerable line in the image
Named the vulnerability correctly as SQL injection
Explained how an attacker could exploit it
Provided the corrected code snippet
Gave step-by-step prevention advice

The output was specific. It referenced the actual code in the image, not generic advice. It did not say "make sure you validate your inputs." It said here is the line, here is why it is dangerous, here is the fix.

Why this matters:

Most developers do not have perfect screenshots. They have photos of monitors taken in bad lighting, screenshots forwarded through three different messaging apps, images captured on a low-end phone. The documentation never tests for this. I did.

Gemma 4 processed a degraded, double-compressed image and returned accurate, actionable output. For a model running on consumer hardware, that is not nothing. That is the difference between a model that works in a lab and a model that works in the real world.

Test 2 — The Finding Nobody Else Will Write About

I asked Gemma 4 to explain JWT authentication JSON Web Tokens, a common auth mechanism in three Nigerian languages: Yoruba, Hausa, and Igbo.

This took approximately two minutes and fifty seconds. By this point I had more files open and my RAM was no longer as fresh as the first test. The model was noticeably slower.

But here is what it returned.

Hausa:
The response was accurate and natural. The model understood the request, switched languages correctly, and explained the concept in a way that read like genuine Hausa rather than a mechanical translation. For a locally running model with no internet access during inference, this was genuinely surprising.

Yoruba:
The response came through but with drift. Yoruba has tonal markers — accent marks that change the meaning of words entirely. Without those diacritics in my prompt, the output was approximate rather than precise. Writers targeting Yoruba-speaking audiences would need to verify carefully before publishing anything.

Igbo:
Similar story. Igbo has its own special characters and tonal markers. The model approximated and the nearest recognizable output came through; but it was not fully accurate Igbo. Close enough to understand, not close enough to trust without review.

What this means practically:

There are over 500 million people in West Africa. There are writers, developers right now building and writing for users who speak Hausa, Yoruba, Igbo, Twi, Amharic, Swahili. Those writers need to know exactly what these models can and cannot do in local languages before they ship something.

Here is my honest assessment:

Gemma 4 E2B handles Hausa better than I expected. Yoruba and Igbo have limitations tied directly to diacritics if your prompt does not include them, the output won't either. For a model running entirely offline, the multilingual capability is remarkable. For production use in tonal African languages, test before you ship.

Test 3 — The 128K Context Window on 8GB RAM

The spec sheet says Gemma 4 supports a 128K context window. That number means nothing without knowing what it costs to use it on consumer hardware.

I fed it an entire README file — a long, detailed project documentation file — and asked for a structured summary.

It took five minutes to complete.

The output was accurate. It understood the document. It structured the summary well. It did not hallucinate content that was not there. It captured the main purpose, the architecture, the setup steps, and the key features correctly.

Five minutes is slow by cloud standards. By the standard of a free, private, offline model running on 8GB RAM with no GPU, five minutes to accurately process and summarize a long document is a different conversation entirely.

The 128K context window is not just a spec sheet number. It held an entire document in memory and reasoned about it correctly. For developers building tools that need to process long files — entire codebases, full documentation, lengthy configuration files — E2B can do this on hardware you already own. Just plan for the time it takes.

The RAM Reality Nobody Documents

Here is practical information that is not in the official documentation anywhere.

I noticed a clear performance pattern across my tests:

Test	RAM State	Time to Complete
Vision + code review	Fresh boot, nothing open	1 min 47 sec
Multilingual explanation	Multiple files open	2 min 50 sec
Long context summary	Heavy use, many tabs	~5 minutes

The pattern is obvious once you see it. As RAM fills with other processes, Gemma 4 E2B slows down significantly. This is not a flaw. The model needs memory to run and it competes with everything else on your machine.

Practical advice for 8GB RAM users:

Close everything before running a local inference task
Restart your machine for faster result — you want fresh RAM
E2B is the realistic choice at 8GB, E4B will be tight
Do your most demanding tasks first, before RAM fragments
If you are building an app on top of Ollama, test your performance after extended use not just on first boot

I learned all while trying to build with it

Which Model Should You Actually Use

Stop reading benchmarks and use this decision guide instead.

You have an 8GB RAM laptop with no GPU → Gemma 4 E2B via Ollama. Nothing else is realistic.

Your project handles sensitive data and privacy is critical → Any Gemma 4 variant running locally via Ollama. Your data stays on your machine. Full stop.

You are building for multilingual users in Africa or South Asia → E2B has meaningful multilingual capability. Test your specific languages before shipping. Hausa works well. Tonal languages with special characters need careful prompting.

You need high performance for a server deployment → 31B Dense is your target.

You need efficient reasoning at high throughput → 26B MoE is built for this.

You are building for mobile or edge devices → E2B or E4B. These models were designed for exactly this hardware profile.

Your budget is zero and you need full capability → E2B via Ollama. Free to download, free to run, free forever. No API key. No subscription. No data leaving your machine.

What Running AI Locally Actually Means

Every conversation about AI accessibility focuses on API costs and internet connectivity. Those are real barriers. But there is a third barrier that nobody talks about: trust.

When a developer in Lagos pastes their production code into ChatGPT or any cloud AI tool, that code leaves their machine. If there are API keys in that code, database connection strings, auth secrets — they just went to a server somewhere. Most developers do not think about this. Most beginners definitely do not.

Running Gemma 4 locally via Ollama removes that problem entirely. Your code goes from your editor to your RAM and back to your screen. Nothing else happens. No network request. No logging. No third party.

For a self-taught developer building their first real project, that matters. For a developer in a region where cloud AI costs are prohibitive relative to local income, that matters. For anyone building tools that touch sensitive user data, that matters.

Gemma 4 E2B is not the most powerful model available. It is not trying to be. What it is — a capable, multimodal, multilingual model that runs on hardware most developers in the world actually own, for free, privately, offline — is something different from anything that existed before it.

There is a difference between a model that exists and a model that runs on hardware people actually own.

That difference is the whole thing.

How To Get Started Right Now

If you have not pulled Gemma 4 yet, here is everything you need.

Step 1 — Install Ollama

Go to ollama.com and download it for your operating system. Install it like any normal application.

Step 2 — Pull Gemma 4 E2B

ollama pull gemma4:e2b

This downloads the model to your machine. Approximately 2-3GB. You only do this once.

Step 3 — Start Ollama

ollama serve

This runs Ollama in the background on localhost port 11434. Leave this terminal open.

Step 4 — Test it immediately

ollama run gemma4:e2b "explain what a SQL injection attack is to a complete beginner"

If you get a response, everything is working. You are now running a capable multimodal AI model locally on your own machine at zero cost.

Step 5 — Try the vision capability

Head to aistudio.google.com, select Gemma 4, upload a screenshot of any code, and ask it to review for security issues. No setup required. See what it catches.

Final Thought

I started these tests expecting to be disappointed. Consumer hardware running open models has usually meant compromises — slow inference, shallow responses, limited context.

What I found instead was a model that analyzed a WhatsApp-compressed screenshot and caught a real security vulnerability. That explained JWT authentication in Hausa. That summarized long documents on 8GB RAM. All privately, offline, and free.

The compromises are still real. The speed is nowhere near cloud models. The tonal language limitations matter. The RAM constraints are physics.

But benchmark scores are measured in controlled environments on optimized hardware by people who are not your users.

I am the user.
8GB RAM. Nigeria. WhatsApp screenshots. Nigerian languages. Midnight deadlines.

And if Gemma 4 works in those conditions, then it works in the real world.

That is the benchmark that matters to me..

Pull it. Test it. Build with it.

ollama pull gemma4:e2b

Everything else is waiting on the other side of that command.

Tested on: 8GB RAM laptop, Windows, Ollama + Google AI Studio, May 2026
Models tested: Gemma 4 E2B
Location: Nigeria