Home
Builders
@abdulfatai

Builder Passport

Abdulfatai

@abdulfatai

Software engineer

51 posts 88 comments 7 followers 7 following Ilorin

Developer Open Open to full-time Open to contract +2 more

My name is Sakariyau Abdulfatai I’m a Full-Stack Software Developer skilled in JavaScript, TypeScript, React, Next.js, Node.js, Express.js, MongoDB, PostgreSQL, GitHub, and modern web application development.

View Portfolio

Professional Passport

Professional Builder

Free courses and real projects strengthen your Passport.

Your journey

01 Learn

Browse free Academy courses
02 Prove Done

20 Certificate(s) of Completion

20
03 Showcase Done

3 public project(s) · 8 challenge(s)

3
04 Discover Done

Recruiter-facing Passport completeness · 100%

100/100

Activity score

A living view of what they’ve been doing — posts, comments, projects, and learning.

455

Active builder

Trusted Builder · 100%

Projects

Shipped

Endorsements

Collabs

Challenges

Followers

Project Publisher 4-Challenge Streak Challenge Winner

Posts

Build update 14 hours ago

The First Solution Is Not Always the Best

The First Solution Is Not Always the Best One thing I’ve learned while coding is that getting something to work is only the first step. For example, imagine you need to filter users by their role. You could quickly write the same filtering logic in several components: ```js users.filter(user => user.role === "admin") ``` It works. But if you find yourself repeating that logic across the application, it may be worth moving it into a reusable function: ```js const getAdmins = users => users.filter(user => user.role === "admin"); ``` Now the code is easier to reuse, test, and maintain. Sometimes the first solution solves the problem, but taking a moment to step back can help you find a cleaner one. **“Does it work?”** is important. But **“Can I make this simpler and easier to maintain?”** is another question worth asking. What’s a coding solution you’ve improved after getting it to work the first time?

Open thread →

Build update 14 hours ago

Why Good Developers Read Error Messages First

Why Good Developers Read Error Messages First One habit that has saved me a lot of time while coding is simply reading the error message before changing anything. It’s easy to see an error and immediately start guessing, searching Google, or changing random lines of code. But the error often tells you where the problem is and sometimes even what caused it. For example, if an API returns a `401 Unauthorized`, I don’t immediately start changing the frontend. I first check whether the token is missing, expired, or being sent incorrectly. The error is not always the solution, but it’s usually a clue. Before you start fixing the problem, **read what the problem is actually telling you.** What’s one error message that has taught you something the hard way?

Open thread →

Build update 14 hours ago

You Don’t Have to Know Everything

You Don’t Have to Know Everything One thing I’m learning in tech is that you’ll never know everything. There will always be another framework, tool, language, or concept you haven’t touched yet. And sometimes seeing what other developers know can make you feel like you’re behind. But maybe the goal isn’t to know everything. For example, when I first started working with APIs, I could follow tutorials and make requests work. But building a small project from scratch forced me to understand things like authentication, error handling, and how the frontend and backend actually communicate. That kind of learning sticks differently. Maybe the real goal is to understand your fundamentals, get better at solving problems, and stay willing to learn. The ability to learn might be one of the most important skills we can build in tech. What’s something you learned recently by actually building it?

Open thread →

Build update 14 hours ago

Are You Learning or Just Consuming?

**Are You Learning or Just Consuming?** Sometimes we spend hours watching tutorials, reading posts, and saving resources, and it feels like we’re making progress. But there’s a big difference between consuming information and actually learning. For me, the real learning starts when I try to build something without following a tutorial step by step. That’s when the questions, mistakes, debugging, and deeper understanding begin. Tutorials can show you the way, but practice is what makes the knowledge stick. So if you’ve been learning something lately, try building a small project with it. You might be surprised by how much you actually know — and what you still need to learn. How do you make sure you’re actually learning and not just consuming content?

Open thread →

Build update 5 days ago

Why Don’t Websites Store Your Password Directly?

Why Don’t Websites Store Your Password Directly? When you create an account, you might think your password is simply stored in the database. It shouldn’t be. Imagine a website stores: password: mypassword123 If the database gets exposed, attackers can immediately see users’ passwords. Instead, applications usually hash passwords before storing them. For example: mypassword123 → a8f91c... The application stores the hash, not the original password. When you log in, your password is hashed again and compared with the stored hash. If they match: Login successful ✅ If they don’t: Invalid password ❌ The important part is that good password hashing is designed to be one-way. You don’t simply “decrypt” the hash to get the original password. This is why backend developers use password-hashing algorithms such as bcrypt or Argon2. So remember: Don’t store passwords. Hash them. One small backend decision can make a huge difference to your application’s security.

Open thread →

Build update 5 days ago

Your first coding project could definitely be ugly.

Your first coding project could definitely be ugly. I’m not saying you expect your first project to look clean, professional, and sharp — like Google and Apple just collaborated on it. 😂 But your first project can still look like a website that **escaped an accident.** This was my first React project, by the way. link: https://chi-chi-exquiste-kitchen.vercel.app **Please don't laugh at me. 😂** Looking at it now, I can see so many things I would do differently. The UI wasn't great. The code wasn't as clean as I wanted. Some things were probably more complicated than they needed to be. But honestly? I'm glad I built it. Because that ugly first project taught me things that watching tutorials couldn't. I learned how to actually structure a project, make mistakes, debug them, and figure things out when the solution wasn't one Google search away. And that's the thing about your first project: **It's not supposed to prove that you're already a great developer.** It's supposed to prove that you started. Your first project might be ugly. Build it anyway. Your second one will probably be better. Then the third. Then you look back at the first one and wonder: **“Who allowed me to write this code?” 😂** Anyway, this is mine. **How did your first project look?**

Open thread →

Build update 5 days ago

Imagine you want to transfer ₦100,000 to your friend.

Imagine you want to transfer ₦100,000 to your friend. The bank removes ₦100,000 from your account. But before they add it to your friend's account, the network fails. Some of us have experienced this before, right? Your account balance has reduced. Your friend hasn't received the money. Now you're thinking: **“Where did my money go?”** And you're already preparing to go to the bank and start asking questions. 😂 But let's look at this from a software engineering perspective. This is one of the problems **database transactions** are designed to solve. A bank transfer involves multiple operations: 1. Remove ₦100,000 from Account A. 2. Add ₦100,000 to Account B. These operations are related. We don't want this to happen: **Account A → Money removed ✅** **Account B → Money not received ❌** Instead, we want the operations to behave as one unit. If everything succeeds: **COMMIT ✅** The changes are saved. If something goes wrong: **ROLLBACK ❌** The changes are undone. So if the money was removed from Account A but something failed before it could be added to Account B, the transaction can roll back the changes. Account A gets the money back. This is called **atomicity**. The simple idea is: > **Either everything happens, or nothing happens.** And database transactions aren't only useful for bank transfers. They can also help when: - Creating an order and reducing product stock - Processing payments - Moving money between accounts - Updating multiple related records - Performing several database operations that must stay consistent This is one backend concept that becomes much easier when you connect it to real-life situations. there are many things to learn 😂 **Have you ever had a transaction fail after your account was already debited?**

Open thread →

Build update 5 days ago

For Week 5 of the Africoders Launch Campaign, I tested the Community, Learn, and Messaging features. Here’s my feedback:

For Week 5 of the Africoders Launch Campaign, I tested the Community, Learn, and Messaging features. Here’s my feedback: 1. Community The Community makes it easy to share ideas, ask questions, showcase projects, and connect with other builders. What worked: Creating posts, sharing projects, asking questions, and interacting with users worked well. What I liked: It brings builders together and provides a space to share work and learn from others. What should improve: Users should be able to upload more pictures in one post. I noticed I couldn't add up to eight images. This would be useful when showcasing projects with screenshots of different features. 2. Learn The Learn section provides practical tutorials that users can pause, replay, and follow at their own pace. What worked: Video tutorials, step-by-step explanations, and the ability to rewatch lessons worked well. What was confusing: Some videos move quickly or assume prior knowledge. What I liked: Being able to learn at my own pace and revisit previous lessons. What should improve: Content could be better organized and regularly updated to make relevant lessons easier to find. 3. Messaging I tested Messaging by reaching out to other users. What worked: Sending messages worked well. The Star and Archive options were also useful. What was confusing: The All types filter was unclear. Options like Opportunity, Collaboration, Invites, Staff, and Reports are not clear and not working. What I liked: The interface feels organized and keeps important information visible. What should improve: A call feature would improve communication. Users should also be able to share pictures, videos, and files in conversations. Overall, my experience was good. The core features work well, and improvements to media sharing, messaging, and content organization could make Africoders even more useful for builders.

Open thread →

Wall

Leave a note for Abdulfatai. The builder and Africoders staff can moderate this wall.

Open full wall →

No wall posts yet

Be the first to write on this builder’s wall.

Comments

Replies across Africoders — open any thread to read the full conversation.

20 shown

journal in One thing I’ve learned about using ChatGPT: 3 hours ago

One thing I’ve learned is that AI works better when you give it context instead of just asking a question. For example, instead of saying “Fix this code,” I’ll provide the error, the relevant code, what I expected, and what actually happened.

Abdulfatai

Professional Builder

Activity score

Posts

Wall

No wall posts yet

Comments

Challenges

Proof of work

Elegant-Store

Elegant-Store

Activity

Skills & stack

Need help with Builder Passport?