DEV Community: Precious Afolabi

Week 13: Learning PostgreSQL and SQL Fundamentals

Precious Afolabi — Mon, 30 Mar 2026 18:45:58 +0000

PostgreSQL Fundamentals
Week 13 covered PostgreSQL from setup to aggregate functions. Lots of SQL practice.

Getting Started
Installed PostgreSQL and learned the basics. Creating databases, connecting with psql, and understanding basic commands. The interface uses backslash commands for meta operations and SQL for data operations.
Small thing that surprised me: semicolons matter. They end commands. Forget one, and your query hangs, waiting for you to finish. Similar to forgetting the return in JavaScript, where the function keeps running.
SQL Queries

SELECT and Filtering
Retrieving data with SELECT. All columns or specific ones. Filtering with WHERE using various conditions.
Pattern matching with LIKE. Finding values with IN. Range checking with BETWEEN. Handling nulls with IS NULL.
Sorting results with ORDER BY. Ascending or descending. Multiple columns. Limiting results with LIMIT for pagination.

Data Manipulation
INSERT adds new records. Single rows or multiple at once. The RETURNING clause shows what was inserted without a separate query.
UPDATE modifies existing records. Single column or multiple. Conditional updates with WHERE. RETURNING shows what changed.
DELETE removes records. Always test with SELECT first. Use transactions for safety. TRUNCATE for clearing entire tables.

Aggregate Functions and GROUP BY
This was the challenging part. Aggregates calculate values across rows. COUNT for counting, SUM for totals, AVG for averages, MIN and MAX for extremes.
GROUP BY organizes data into groups before aggregating. Instead of one result, you get one result per group.

WHERE vs HAVING
The key difference was that it took practice to understand.
WHERE filters individual rows before grouping. It runs first, deciding which rows to include in the aggregation.
HAVING filter groups after aggregation. It runs after GROUP BY, deciding which grouped results to show.

Example: finding cities with more than 2 users where those users are over 25.
WHERE age > 25 filters the rows first. Then GROUP BY city groups them. Then HAVING COUNT(*) > 2 filters the groups. WHERE operates on rows, HAVING operates on groups.

Practice Exercises
Worked through many queries. Sales data analysis, grouping by categories and regions, calculating totals and averages, and finding top performers.
Counting distinct values, calculating percentages, combining multiple aggregates, and ordering grouped results. The repetition made the patterns clear.
GROUP BY with multiple columns, HAVING with multiple conditions, and combining WHERE and HAVING in one query. Each exercise reinforced when to use which clause.

Key Lessons
Semicolons end commands. Forget them, and queries hang.
WHERE filters before grouping, HAVING filters after. Different purposes, different timing.
Aggregate functions need GROUP BY when you want per-group results instead of one overall result.
Always test DELETE with SELECT first. Transactions provide safety.
Practice is how SQL concepts stick. Reading about GROUP BY is different from writing 20 queries using it.

Moving Forward
Continuing with SQL. Database design and relationships next. Connecting PostgreSQL to Node.js using the pg library. Starting MongoDB to understand NoSQL alongside relational databases.

Question: What SQL concept took you longest to understand?

Week 12: Express.js and Refactoring Error Handling

Precious Afolabi — Mon, 23 Mar 2026 12:12:45 +0000

Express.js and Better Error Handling
Week 12 covered Express.js fundamentals and refactoring my blog platform with proper error handling patterns.

Express.js Fundamentals

Middleware
Middleware is how Express processes requests. Functions that run before your route handlers. Each middleware can modify the request, send a response, or pass control to the next middleware.

Built-in middleware parses JSON bodies and URL-encoded data. Custom middleware handles logging, authentication, and timing. The order matters. Middleware runs in the order you define it.

Understanding middleware flow changed how I structure applications. Instead of handling everything in route handlers, break concerns into separate middleware functions.

Routing and Controllers
Express routing maps URLs to handlers. Instead of one massive file, separate routes into logical groups. User routes, post routes, comment routes.
Controllers handle the business logic. Route files define endpoints, and controllers implement what happens when those endpoints are hit—clean separation of concerns.

Validation
Input validation with express-validator. Define validation rules, check for errors, and return appropriate responses. Users send all kinds of invalid data. Validation catches it before it reaches your database.

Centralized Error Handling
This was the game changer. Instead of repeating try/catch blocks in every async function, use two utilities.

AppError Class
Custom error class that includes status code and message. Throw this instead of generic errors.
When something goes wrong, throw an AppError with the appropriate status code. The centralized error handler catches it and sends the right response.

catchAsync Wrapper
Wraps async route handlers. Automatically catches errors and forwards them to the error-handling middleware. No more try/catch in every function.
Before catchAsync, every async controller had repetitive error handling. After catchAsync, the code is clean, and errors are handled consistently.

Global Error Handler
One middleware at the end catches all errors. Whether you threw an AppError or something unexpected happened, it handles the response.
Errors get logged, appropriate status codes get sent, and users get meaningful error messages instead of crashes.

Refactoring My Blog Platform
Applied these patterns to my existing blog platform project.

What Changed
Added AppError and catchAsync throughout all controllers. Removed repetitive try/catch blocks. Errors now flow to one central handler instead of being handled inconsistently everywhere.

Implemented a comments API. Users can create comments on blog posts and delete their own comments. Full CRUD operations with proper error handling, validation, and authentication middleware.

The Challenge
Understanding how error handling actually works was tricky. How errors propagate in async functions, when to throw versus when to pass to next, how the global error handler receives them.
The pattern clicked after refactoring existing code. Seeing all the repetition disappear made the value clear.

The Result
Cleaner controllers. Consistent error responses. One place to modify error handling instead of updating dozens of try/catch blocks. Adding new features is faster because the error handling is already solved.

Key Lessons
Middleware order matters. Authentication before validation before handlers.
Centralized error handling removes boilerplate and ensures consistency.
AppError and catchAsync are simple patterns that make code significantly cleaner.
Validation prevents bad data from reaching your database.
Error handling isn't optional. Things break in production.

Moving Forward
Starting databases. Learning MongoDB and PostgreSQL fundamentals. Understanding both NoSQL and relational databases.

Project Links
GitHub: https://github.com/Precixphantom/blog-platform
Live Demo: https://blog-platform-6wv2.onrender.com

Question: How do you handle errors in your backend applications?

Week 11: Node.js Fundamentals and Understanding Core Modules

Precious Afolabi — Mon, 16 Mar 2026 10:34:40 +0000

Node.js Fundamentals
Week 11 covered Node.js core modules and finished the weather CLI from last week.

Core Modules

File System Module
The fs module handles all file operations. Reading files, writing data, checking existence, creating directories, and getting file stats.
Using fs/promises makes everything work with async/await. Clean async code without callbacks.

Error handling is critical. File operations fail often. Files don't exist, permissions are incorrect, and the disk is full. Every operation needs try/catch.

Path Module
The path module handles file paths correctly across operating systems. Windows uses backslashes, Unix uses forward slashes. Path handles this automatically.
Join builds paths correctly. Resolve gets absolute paths. Dirname, basename, and extname extract path components.

Events Module
EventEmitter is how Node.js handles events internally. You create events, listen for them, and emit them when things happen.
This pattern appears everywhere in Node.js. Streams use events, servers use events, and core modules are built on EventEmitter.
Understanding events changed how I see Node.js architecture. It's event-driven at the core.

CommonJS vs ES6 Modules

The difference between module systems was interesting, especially **with __filename and __dirname.
In CommonJS, __filename and __dirname are available as globals. They give you the current file path and directory.
In ES6 modules, these don't exist. You need to use import.meta.url and path functions to get the same information. Different approach for the same result.
This matters when migrating old Node.js code to ES6 modules. Code that uses __dirname directly will break.

Weather CLI Project
Finished the weather CLI from Week 10.
The tool fetches weather data from OpenWeather API and displays it in the terminal. Pass a city name, get the current weather.
Features: fetch by city, handle invalid cities with errors, display temperature, show conditions and humidity, and format output readably.
Used fetch for API requests, process.argv for command line arguments, and fs for configuration.

HTTP Basics
Started learning HTTP fundamentals and building servers with the http module.
Understanding request and response. Clients send requests with method, URL, and headers. Servers send responses with a status code, headers, and body.
Status codes matter. 200 for success, 404 for not found, 500 for errors, 201 for created.
Handling different HTTP methods. GET for retrieving, POST for creating, PUT for updating, and DELETE for removing.
Built a basic server handling different routes and methods. Routing based on URL and method. Parsing request bodies. Setting correct status codes and content types.
Understanding HTTP before frameworks makes everything clearer.

Key Lessons
File operations need error handling. Things fail in production.
The Path module prevents cross-platform bugs. Never build paths manually.
Events are fundamental to Node.js. EventEmitter is everywhere.
ES6 modules handle __filename and _ _ dirname differently from CommonJS.
HTTP is simpler than it seems. Request in, response out.

Moving Forward
Starting Express.js and building APIs. Moving from the raw HTTP module to proper frameworks.

Question: What Node.js concept was hardest for you to understand?Share**

Week 10: Working with APIs and Starting to Build

Precious Afolabi — Mon, 09 Mar 2026 19:33:14 +0000

Working with APIs

Week 10 was about working with APIs using the Fetch API. Also started building a weather CLI project, though exam week meant I didn't finish it.

Learning Fetch API

Learned how to make different types of API requests. GET requests to fetch data, POST requests to send data, handling JSON responses, and structuring API calls properly.
Practiced with public APIs like JSONPlaceholder to understand how real API interactions work. Fetching users, posts, creating new posts, updating existing ones.

Error Handling with Fetch

Understanding how fetch handles errors changed how I approach async operations.

Fetch doesn't throw errors for failed HTTP requests. A 404 or 500 status is still a resolved promise. The fetch succeeded in making the request and getting a response, even if that response says "not found" or "server error".

You have to check response.ok or response.status manually. Response.ok is true for status codes 200-299. Anything else means something went wrong.
But that's just HTTP errors.

There's also network failures when the request can't be made at all. Invalid JSON when the response isn't valid JSON. Missing data when the response structure isn't what you expect.

Each type of error needs different handling. Network failures get caught by try/catch. HTTP errors need manual checking. Invalid JSON throws when you call response.json(). Missing data needs validation after parsing.

Building a Weather CLI

Started building a weather CLI that fetches current weather data from OpenWeather API.
Got the basic structure working and started implementing the main functions. Making the API request with city parameters, checking if the response is valid, parsing the weather data, displaying temperature and conditions.
Exam week meant I couldn't finish everything planned, but the core functionality is there.

What This Week Taught Me

There's a difference between learning concepts and applying them. Understanding async/await from last week was one thing. Using it to fetch real data from APIs, handle errors properly, and build something functional is different.

APIs are how backend systems communicate. Everything connects through HTTP requests and JSON responses. This is what backend development actually is.

Moving Forward

Going into Node.js fundamentals. Learning how to build actual backend servers, handle routes, work with the file system, and create real applications.

Question: What tripped you up when you first worked with APIs?

Week 9: Understanding Asynchronous JavaScript

Precious Afolabi — Mon, 02 Mar 2026 16:15:12 +0000

Asynchronous JavaScript

Week 9 was about understanding how JavaScript handles asynchronous operations. Callbacks, promises, async/await, and the event loop.

Callbacks and the Event Loop
The breakthrough. Understanding how JavaScript's call stack works with the event loop. JavaScript is single-threaded, but the event loop makes it feel concurrent.

Learned why setTimeout doesn't guarantee exact timing, how asynchronous operations don't block execution, and how the call stack, web APIs, and callback queue work together.
Callback hell showed why we need better solutions. Nested callbacks three levels deep become unreadable pyramids of doom.

Promises
Promises flatten callback hell into readable chains. Creating promises with resolve and reject, chaining with then and catch, handling errors properly.
Promise.all runs multiple operations in parallel and waits for all to complete. Promise.race returns whichever finishes first.

Async/Await
Async/await changed everything. Same asynchronous code, written like synchronous code. No more then chains. Just await the result.
Error handling uses try/catch. Cleaner syntax, easier to reason about.

Sequential vs Parallel
Sequential awaits happen one after another. Three operations take three seconds total.
Promise.all runs them in parallel. Three operations take one second total if they can run simultaneously.
Error handling was tricky. Understanding when to use try/catch, when errors propagate, and how to handle failures properly.

Key Lesson
Understanding the event loop is critical for backend. It explains how JavaScript handles concurrency despite being single-threaded.

Moving Forward
Building projects with APIs, applying async JavaScript in real scenarios, and starting Node.js fundamentals.

Question: What took you longest to understand when learning JavaScript?

Weeks 6-8: Advanced Arrays, Problem-Solving Patterns, and Building a Data CLI

Precious Afolabi — Mon, 02 Mar 2026 15:44:57 +0000

Three Weeks of Backend Fundamentals: Arrays, Patterns, and Building a Real Tool

Weeks 6 through 8 were a turning point. Not because the content was the hardest so far, but because it was the first time everything started connecting. Arrays, performance, patterns, Node.js. Here's what those three weeks looked like.

Week 6: Advanced Array Methods + Big O
This week was about using array methods on realistic data, not just [1, 2, 3] examples.
Working with product data meant chaining methods together to answer real questions — total value of in-stock items, most expensive item per category, filtering by rating and price simultaneously.
The one that clicked hardest was reduce for grouping:

const grouped = products.reduce((acc, p) => {
if (!acc[p.category]) acc[p.category] = [];
acc[p.category].push(p);
return acc;
}, {});

Once you understand this pattern, you see it everywhere.
Big O in Plain Terms
The Big O section was kept practical, not academic. The number that stuck:

Processing 1,000 items with O(n) = 1,000 operations. With O(n²) = 1,000,000 operations.

That's not a footnote — that's the difference between a backend that handles load and one that falls over. Nested loops feel harmless on small data. At scale, they're a problem waiting to happen.

Week 7: Problem-Solving Patterns
This was the most valuable week. Two patterns that genuinely show up everywhere:

Frequency Counter Instead of comparing every item against every other item (O(n²)), you count occurrences in an object first, then check against it. Two separate loops instead of nested ones. javascriptfunction isAnagram(str1, str2) { if (str1.length !== str2.length) return false;

const freq = {};
for (let char of str1) freq[char] = (freq[char] || 0) + 1;
for (let char of str2) {
if (!freq[char]) return false;
freq[char]--;
}
return true;
}

O(n) time. You trade a little space to avoid expensive nested loops. Worth it almost every time.

Two Pointers Works on sorted data. One pointer at the start, one at the end, moving inward based on what you find:

function pairSum(arr, target) {
let left = 0;
let right = arr.length - 1;

while (left < right) {
const sum = arr[left] + arr[right];
if (sum === target) return [left, right];
if (sum < target) left++;
else right--;
}
return null;
}

O(n) time, O(1) space. No extra memory. You're using the structure of the sorted array itself to guide the search — which feels almost like a cheat code once it clicks.
What both patterns have in common: there's almost always a smarter approach than brute force. Big O gives you the lens to recognize when you've found it.

Week 8: Building a Data Processing CLI
Week 8 was about applying everything — not more exercises, but an actual working tool.
The project: a command-line sales data analyzer that processes JSON files.
bashnode analyzer.js data.json --sum price
node analyzer.js data.json --filter "region=Lagos"
node analyzer.js data.json --group region
node analyzer.js data.json --stats price

Each command maps to a function. groupBy uses the reduce pattern from Week 6. filterData splits the condition string and applies it. getStats maps, reduces, and spreads all in one go:

async function getStats(data, field) {
const values = data.map(item => item[field]);
return {
min: Math.min(...values),
max: Math.max(...values),
avg: values.reduce((sum, val) => sum + val, 0) / values.length,
total: values.reduce((sum, val) => sum + val, 0)
};
}

The whole thing comes together in a main() function that reads process.argv, loads the file with fs/promises, and routes to the right handler.
Why It Matters Beyond the Exercise
The CLI is simple. But the patterns inside it are exactly what runs in:

REST APIs processing incoming request data
Database query results being transformed before returning
Batch jobs running against thousands of records
Data pipelines aggregating in real time

Load data → filter → transform → aggregate → return. That loop is backend work. The interface changes, the logic doesn't.

The Shift That Happened
Before these weeks, arrays, Big O, and patterns felt like three separate topics in a curriculum.
After building the CLI, they feel like one thing.
Array methods implement the patterns. Big O tells you which pattern to reach for. The patterns combine to solve real problems. Reading about reduce is fine. Using it to group sales by region and generate stats is when you actually understand it.

What's Next
Asynchronous JavaScript — promises, async/await, and finally connecting to external APIs. The backend foundation is there. Time to make it talk to the outside world.

What's the hardest part of learning for you — grasping new concepts, or applying them to build something? Drop it in the comments.

Weeks 4 & 5: Recursion and Arrays in JavaScript

Precious Afolabi — Mon, 02 Feb 2026 12:59:39 +0000

Two Weeks of Core JavaScript Concepts

Weeks 4 and 5 covered two fundamental topics: recursion and arrays. Here's what I learned and built.

Week 4: Recursion and Completing the Calculator
Started Week 4 by finishing my CLI calculator from Week 3. University tests pushed it back, so I adjusted my timeline. The calculator includes basic operations, advanced operations like power and square root, memory functions, calculation history, and chain operations using a prev keyword.
javascriptCalculator Ready

add 5 3
Result: 8
multiply prev 2
Result: 16
store
Stored: 16

Then moved into recursion. Reading about it was confusing, and watching videos was still abstract. Building simple examples made it click. Understanding how each function call builds on the previous one, then returns values back up.
Recursion Examples
Factorial:
javascriptfunction factorial(n) {
if (n === 1) return 1;
return n * factorial(n - 1);
}
Fibonacci:
javascriptfunction fibonacci(n) {
if (n <= 1) return n;
return fibonacci(n - 1) + fibonacci(n - 2);
}
String Reversal:
javascriptfunction reverseString(str) {
if (str === "") return "";
return reverseString(str.substring(1)) + str.charAt(0);
}
Palindrome Checker:
javascriptfunction isPalindrome(str) {
if (str.length <= 1) return true;
if (str[0] !== str[str.length - 1]) return false;
return isPalindrome(str.substring(1, str.length - 1));
}

Built recursive solutions for factorials, Fibonacci sequences, string reversal, and palindrome checking. Each one reinforced the pattern: base case to stop recursion, recursive case that calls itself with a simpler input.
Week 5: Arrays and Method Chaining
Week 5 was about arrays, from basic operations to chaining methods that changed how I approach data manipulation.
Array Fundamentals
Started with creating arrays, accessing elements, and basic manipulation with push, pop, shift, and unshift.
The critical lesson: arrays are reference types.
javascriptlet arr1 = [1, 2, 3];
let arr2 = arr1; // Reference copy
let arr3 = [...arr1]; // Shallow copy

arr2.push(4);
console.log(arr1); // [1, 2, 3, 4]
console.log(arr3); // [1, 2, 3]
When you assign arr2 = arr1, both variables point to the same array. The spread operator creates a new array.

Iteration Methods
Explored different ways to loop through arrays: traditional for loops, for...of loops, and forEach. Ran performance tests on arrays with a million elements. Traditional for loops won on speed, forEach wins on readability.
Transform Methods
map() transforms every element:
javascriptconst numbers = [1, 2, 3, 4, 5];
const doubled = numbers.map(n => n * 2);
// [2, 4, 6, 8, 10]
filter() selects elements that pass a test:
javascriptconst numbers = [1, 2, 3, 4, 5, 6];
const evens = numbers.filter(num => num % 2 === 0);
// [2, 4, 6]
reduce() accumulates to a single value:
javascriptconst numbers = [1, 2, 3, 4, 5];
const sum = numbers.reduce((acc, num) => acc + num, 0);
// 15

Search and Test Methods
find() and findIndex() locate elements:
javascriptconst users = [{id: 1, name: "Alice"}, {id: 2, name: "Bob"}];
const user = users.find(u => u.id === 2);
some() and every() test conditions:
javascriptconst numbers = [1, 2, 3, 4, 5];
numbers.some(n => n > 3); // true
numbers.every(n => n > 0); // true

Method Chaining
This is where things clicked. Instead of nested loops, chain operations:
javascriptconst numbers = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10];

// Sum of squares of even numbers
const result = numbers
.filter(n => n % 2 === 0)
.map(n => n * n)
.reduce((sum, n) => sum + n, 0);
// 220
Each step is clear: filter for even numbers, square them, sum the results.

Key Lessons

Recursion: Every recursive function needs a base case and a recursive case. The base case stops the recursion, the recursive case solves a simpler version of the problem.
Arrays as references: Be conscious of how you copy arrays. Assignment creates a reference, spread operator creates a shallow copy.

Array methods: Map for transforming, filter for selecting, reduce for accumulating. These cover most data transformations.
Method chaining: Chain operations to create readable data pipelines instead of nested loops.

Moving Forward
From here, I'm going into advanced array manipulation and data structures.

Question: What concept took you multiple attempts to understand?

Weeks 2 & 3 - Loops, Strings, Functions & Why "Understanding" is Different from "Making it Work."

Precious Afolabi — Sat, 17 Jan 2026 23:06:15 +0000

Two weeks down. Loops, strings, functions, scope, and closures. If you asked me before this, I would've said I understood loops. Turns out there's a huge difference between making code work and actually understanding why it works.

Week 2: The Nested Loop Revelation

I spent hours staring at for(let j = 0; j <= i; j++) trying to figure out what that j <= i was actually doing.
Then it clicked. The inner loop depends on the outer loop's counter. When i = 0, j runs once. When i = 1, j runs twice. That relationship is what makes half the patterns in programming work, and I've been using it without understanding it.

String methods showed me something else: you can chain them because each one returns a string. text.toLowerCase().trim().split(' ') works because toLowerCase() gives back a string, trim() takes that string and gives back another one, then split() works on that result. Small thing, but it changed how I think about methods.

The Project: Built a text analyzer. Takes in text, finds the most common word, checks for palindromes, counts everything. No libraries, just loops and string methods. The "find the most common word" part made me actually think instead of just Googling for a solution.

Week 3: The Documentation Trap
Functions, scope, and closures. This week was harder. Not because of time - the concepts themselves demanded more.
I'd read documentation, watch endless tutorial videos, and still not understand what they were saying. Then I'd build something small and it would click. Reading gives you the map. Building shows you the terrain.

Finally understanding closures and how functions can return other functions felt like unlocking something. It's one thing to read about it, another to see why it actually matters.

The Reality: Uni tests meant I didn't finish the project I planned for this week. That's how it goes sometimes. You adapt.

What I'm Learning About Learning
Progress isn't smooth. Some days you code for hours. Other days, the power cuts out between classes and you're just trying to keep up. But the pattern is clear now: confusion is part of the process. Read, watch, stay confused, then build something small. That's when it clicks.

Next week: recursion and arrays.

Question for you: What's one thing in code you thought you understood but later realized you had no idea how it actually worked?

Connect:

GitHub: https://github.com/Precixphantom
LinkedIn: https://www.linkedin.com/in/precious-afolabi-34194138b/

Week 1 - JavaScript Fundamentals & My First Mini Project

Precious Afolabi — Sun, 04 Jan 2026 21:07:22 +0000

Week 1 is wrapped. I spent the past week working through JavaScript fundamentals - variables, data types, operators, and conditionals. The goal was to build a solid foundation before moving to more complex concepts.

What I Built
Created a simple quiz program in Node.js. It asks 5 JavaScript questions, takes user input, calculates the score, and displays a grade.
Simple concept, but actually building it revealed gaps I didn't know I had.
The trickiest part? Getting user input to work in Node.js. I had to figure out the readline module, which handles things asynchronously.
Coming from basic JavaScript exercises to dealing with async patterns was a bigger jump than expected. Took some googling and trial-and-error, but I got it working.

What I Figured Out
The most useful thing I learned wasn't syntax or methods - it was how to actually start building.
I sat there looking at a blank file thinking "where do I even begin?" The quiz needed questions, input handling, scoring, grade calculation - it felt like too much at once.

Then I just made one question work. That's it. Once that worked, I added another question. Then I figured out scoring. Then the grade display.
Turns out you don't need to see the whole path before you start. Just get one small thing working, then build from there. Sounds obvious when I say it now, but actually doing it was different.

The technical stuff - learning readline, dealing with async code - that was challenging too. But learning to just start with one small piece instead of trying to solve everything at once? That's what made the difference.

The Real Challenge
Consistency. I didn't code every single day like I planned. Some days I went hard for 2-3 hours. Other days, nothing. Life happened, motivation wavered, and I didn't stick to the schedule.

But here's what I'm taking away: when I did show up and code, I made real progress. I built something that works. I understand the concepts. That counts.
Next week I'm setting a specific time slot instead of just "whenever I feel like it." Structure helps.

Resources That Helped

javascript.info - Clear explanations with practical examples

freeCodeCamp - Interactive exercises that reinforced concepts

Good old Google, when I got stuck

Next Week
Focusing on loops and strings. Going to build something that combines both concepts.

If you're learning too, drop a comment. What are you working on? What's challenging you right now?

Connect with me:

GitHub: https://github.com/Precixphantom
LinkedIn: https://www.linkedin.com/in/precious-afolabi-34194138b/

Making an Unconventional Move 5 Months Into Backend Development

Precious Afolabi — Mon, 29 Dec 2025 14:35:54 +0000

The Unconventional Decision
I'm making a move that might seem counterintuitive for someone 5 months into backend development: I'm going back to strengthen my fundamentals instead of just pushing forward.
Here's the context. Over the past 5 months, I've been building with Node.js and have some projects to show:

Chronos API: Study tracker with JWT authentication, automated email reminders using node-cron, background jobs, and production deployment on Render
Blog Platform: Full CRUD operations, user authentication, and session management with EJS

Both work. Both are deployed. Most people would keep building at this point. But I realized something important: I can build features by following patterns and documentation, but when it comes to understanding what's actually happening under the hood or making informed architectural decisions, I want more confidence.
Why This Makes Sense
Right now, I can make things work. But I want to understand, not just implement. I want to be able to explain my code and make decisions based on understanding, not just what worked in the last tutorial.
As a CS student actively looking for internships, I know employers care about how you think and solve problems, not just what you've built. This is about developing that deeper understanding.
What I'm Focusing On
Instead of rushing to learn new frameworks and tools, I'm going back to strengthen:

JavaScript fundamentals (closures, async patterns, prototypes)
How Node.js actually works
HTTP and web protocols
API design principles
Database design and optimization
Testing and code quality

The Approach
How I'm doing it:

Learning systematically through a structured roadmap
Building progressive projects that increase in complexity
Documenting everything publicly with weekly updates
Sharing code, challenges, and what I'm learning

Why publicly?
Two reasons. First, accountability - posting updates keeps me consistent. Second, I want to show how I approach learning and problem-solving, not just finished projects.
What To Expect
Every week I'll share:

What I'm learning and why it matters
Projects I'm building with code walkthroughs
Challenges I'm facing and how I'm solving them
Resources that are actually helping
Honest updates on progress

No fluff. Just real learning and real progress.
Let's Connect
If you're learning backend development, working on similar goals, or just starting out, I'd love to connect. Drop a comment with what you're working on or reach out.
Find me:

GitHub: https://github.com/Precixphantom
LinkedIn: https://www.linkedin.com/in/precious-afolabi-34194138b/

Week 1 update coming soon.

BackendDevelopment #NodeJS #LearningInPublic #WebDevelopment