Forem: Frank

Hey, This is Why Your Vibe-Coded App Will Fail

Frank — Fri, 22 Aug 2025 10:25:17 +0000

I built a $1M App in 5 hours

I just shipped [cool app]! That was built in 3 hours with AI

I make $250k/month from 20 apps.

You must have come across videos or tweets like this these days. Your 14-year-old neighbor’s son is probably shipping one as we speak.

When building gets this easy, you stop asking if you should build something. You just build it.

I’ve been there. Three years into my software development journey, and I’ve fallen into this trap more times than I’d like to admit. I’m the guy who always comes up with ideas. I’m visual, so anytime something pops into my head, I open up Lovable or Bolt, write in some prompts, and boom—three hours later my idea is a working app.

These apps aren’t bad apps. Some actually solve real problems. The issue is deeper than that.

Let me tell you why your vibe-coded app will fail, and it’s not for the reason you think.

The Real Problem: You Don’t Control Your Own Code

Everyone talks about vibe-coded apps failing because they solve the wrong problems. That’s part of it. But the real killer is that you don’t control your codebase. The AI does.

I had an idea that I was convinced would solve a real problem. And it would have—the concept was solid. So I vibe-coded my way through it using AI. The app looked great and worked perfectly, and I was feeling good about myself.

I started getting a lot of users. And that’s when everything went south.

The app started breaking constantly due to security vulnerabilities I didn’t even know existed. The tech stack the AI chose wasn’t something I was familiar with then, so when there were critical issues, I was always stuck. I was just sitting there watching my app fall apart, waiting for the AI to understand my problem and fix it.

Sometimes it couldn’t.

I realized I had built something I couldn’t maintain.

The Four Ways AI Will Kill Your App

1. You’re Stuck With Whatever the AI Thinks

When something breaks in your app in a frustrating way, you’re stuck waiting for the AI to understand your problem through natural language. Good luck explaining complex technical issues in plain English.

2. Customization are Limited

Your customization options are limited to what the AI is capable of. Do you want to add a specific feature that requires deep technical knowledge? I hope you can explain advanced algorithms in simple terms.

There are developers out there spending hours trying to get AI to implement something that would take 30 minutes if they just wrote it themselves.

3. Hidden Security Vulnerabilities Kill Your App Silently

AI generates code that works, not code that’s secure. You wouldn’t know of any vulnerabilities until someone exploits them. And when that happens, you run back to the AI, hoping the AI understands cybersecurity principles.

4. Technical Debt Piles up Behind the Scenes

When it comes to functional codes, AI does that perfectly these days. But is it maintainable? I don’t think so. Your app might handle 100 users effectively, but when it gets to 1000+ users, it starts breaking.

Why This is Especially Dangerous for Beginner Developers

If you’re just starting your web development journey, vibe coding with AI is like learning to drive in a self-driving car. You might get to your destination, but you have no idea how you got there.

When technical issues occur that need actual technical solutions, not natural language prompts, you’ll end up frustrated and stuck.

AI should be a tool for tasks you CAN do but would take too long. If you’re a beginner using AI to build apps, you better be familiar with the tech stack the AI chooses. How else will you debug issues the AI can’t fix?

My advice to junior developers: if you’re using VS Code, disable GitHub Copilot for now. You honestly don’t need code completions at the moment. Learn programming the right way first. Copilot should guide you when you know what you’re doing but can’t remember the syntax—not think for you when you don’t know what to think.

The Problem With User Feedback

If you’ve built a prototype or an app already, and you’re seeking validation from a target audience, be careful. Most of the time you hear advice like “just listen to your users.”

Yes, users can tell you what’s broken, but they can’t tell you what to build next.

Some developers build exactly what users request, then wonder why their app has a lot of features nobody really wants.

Users asked for faster horses, not cars. They asked for better candles, not light bulbs.

I’ve come to notice a pattern about successful builders, which is that they listen to the problems users describe, not the solutions they suggest. They identify patterns across complaints. They always have a vision and say no to most feature requests.

Steve Jobs didn’t build Apple by asking users what they wanted. He built it by understanding what they needed, even when they couldn’t articulate it.

The Money-Making Fantasy

Most vibe coders think they’re building profitable businesses fast. But what happens after you make some profit and start having issues that require technical knowledge? Or when security vulnerabilities arise?

They kill the app and move on to the next shiny idea, or hire developers to fix the issues, which costs a lot.

That’s not a business model. That’s just jumping from project to project.

The Right Way to Use AI (It’s Not Your Destination)

Don’t get me wrong, AI has come to stay, and we should embrace it. But AI shouldn’t be your destination. It should be a bus stop.

Validate → Prototype → Customize

If you have an idea that’s been validated by your target audience and you’re sure it’s a solution to a problem, not a solution looking for a problem, then absolutely use AI to prototype quickly. Don’t waste time wireframing when you could have a working version.

But then you customize. You take control.

You should always be able to add features that require technical knowledge.
You should be able to handle security vulnerabilities like SQL injections.
Your app might handle 100 users perfectly, but what about 1,000+ users when it starts breaking? Don’t you think you should be in control of that?

What Programmers Should Actually Do

AI makes you more powerful as a developer.

Use AI to handle the boring stuff like boilerplate code, basic CRUD operations, and UI components that you might have built before. Save your brain for the interesting problems like architecture decisions, performance optimization, and complex business logic. These are what AIs struggle with.

Focus your human brain on what humans do best. Things like thinking strategically, understanding context, and so much more.

The Hard Truth

Building the first version was never the hard part. Any decent AI can build together a working prototype in hours. The hard part is what comes after:

Scaling under real load
Handling edge cases users find
Maintaining code quality as features multiply
Debugging complex production issues
Making architectural decisions that support growth These problems require understanding, not just code generation.

What You Should Actually Do

If you’re going to vibe code (and honestly, you probably should for rapid prototyping), do it right:

Validate and use AI to prototype quickly: — this is where it shines
Learn the tech stack your AI uses: — you should be able to speak its language when things break
Transition to manual control before scaling: — rewrite critical parts in code you understand
Focus on problems, not solutions:— listen to user pain points, not feature requests
Plan for maintenance from day one :— your prototype needs to become a product

Quick prototyping is valuable. But mistaking a prototype for a product is where things go wrong.

So validate your idea. Vibe code your prototype. Then take control of your codebase before you scale.

Because the moment you can’t fix your own app is the moment it stops being your app.

Keep learning, keep building, keep asking questions. That’s how you turn curiosity into mastery.

What’s your worst coding mistake? Share it below, trust me, you’re not alone.

The 2 Best Coding Tips I Ever Learnt

Frank — Thu, 14 Aug 2025 17:22:24 +0000

You shouldn’t be scared of writing “bad code.” When you plan every variable name, overthink every function, and have to know/research the “perfect” way to solve problems before even writing a single line. You get frustrated and end up wasting time with barely any progress.

In my three years and counting in my software engineering journey, I’ve consumed lots of information and read books from experts in the software development world. Two tips changed how I approach every programming challenge and also changed my programming journey.

# TIP 1: FIRST MAKE IT WORK, THEN REFACTOR.

Phase 1: Make It Work

Here your only goal is functionality. Don’t worry about elegant solutions, perfect naming conventions, or optimization. Write code that solves the task, even if it’s messy, repetitive, or inefficient.

The benefits are immediate:

Build Momentum: You see progress quickly, which keeps you motivated.
Provides Feedback: Working code tells you if your approach is viable.
Creates a foundation:- You will have something tangible to build upon.
Reduces Anxiety: The pressure to be perfect is removed.

Phase 2: Refactor and Improve:

Once you have working code, now you can make it better. This is where you:

Clean up the structure and improve readability.
Optimize performance where needed.
Add proper error handling.
Improve naming conventions. The beauty of this approach is that you can experiment with improvements knowing you can always fall back to the version that works.

Let’s look as an example
Let’s say you’re building a simple calculator. In phase 1, you might write:

It works. Now in Phase 2, you might refactor to

Phase 2 has the same functionality as Phase 1, but it has a cleaner implementation and better error handling.

# TIP 2: READ CODE MORE THAN YOU WRITE

As a developer, you’ll spend more time reading code than writing it. Whether you’re debugging, adding features to existing projects, or trying to understand a new codebase, reading comprehension should be your most valuable skill.

The benefit of reading code is writing better code. It’s like learning a new language. You don’t become fluent by only practicing speaking—you need to read books, listen to native speakers, and immerse yourself in well-crafted examples of the language in action.

How To Read Code Effectively

Study Open Source Projects: Pick popular projects in your preferred language or framework. Start with smaller and well-maintained repositories. And please don’t try to understand everything at once; focus on files or functions that solve problems similar to what you’re looking for.
Analyze Code You Admire: Find developers whose work you respect and study their code.
Read Your Own Old Code: It might be stressful, I know, but it’s incredibly valuable. Compare code you wrote six months ago to what you’d write today. You’ll be amazed at how much you’ve improved.
Participate in Code Reviews:- Whether giving or receiving feedback, code reviews are goldmines for learning. You’ll see different approaches to solving the same problems and learn from your teammates’ expertise.

WHAT TO LOOK FOR

When reading code, pay attention to:

How experienced developers structure their files and organize their logic.
Common patterns and naming conventions in your field.
How they handle errors and edge cases.
How they break complex problems into smaller, manageable pieces.

These two tips create a powerful feedback loop.

The cycle works like this:

Write working code → Read quality code → Improve your code → Repeat

Each iteration makes you better, and the process becomes increasingly natural and enjoyable.

If you enjoyed this, like it, comment on it, and share it with a friend.

You Shouldn't Be A Developer If ...

Frank — Wed, 06 Aug 2025 08:09:37 +0000

I’m about to tell you something most coding bootcamps and YouTube tutorials won’t: programming isn’t for everyone, and that’s perfectly okay.

I know this sounds harsh, especially when the internet is flooded with “anyone can code” messages and success stories of people landing six-figure jobs after three months of learning (yeah, 3 months). Too many people waste months or even years chasing a career that was never right for them.

This isn’t about crushing dreams. It’s about helping you make an honest assessment before you invest your time, money, and emotional energy into something that might not be the right fit.

Imagine it like a reality check from someone who genuinely wants to see you succeed, whether that’s in programming or somewhere else entirely.

1. You’re Only Chasing the Money

Let’s address the BIG GUY in the room first, MONEY. Yes, developers can earn good money. But if dollar signs are your primary motivation, you’re setting yourself up for disappointment.

This is what the “learn to code and get rich quick” crowd won’t tell you: those six-figure salaries everyone talks about? They’re not handed out to beginners.

As I write this in late 2025, Entry-level job postings in the U.S. overall dwindled by about 35% since January 2023, they are increasingly competitive because of AI. It is coming for entry-level jobs, even Bill Gates said “Gen Z may not be safe no matter how well they learn to use it”

And many markets are saturated with junior developers who learned the basics of programming but lack the depth to solve real problems.

More importantly, if you’re only motivated by money, you’ll quit the moment things get difficult — and trust me, they will get very difficult. Programming requires patience and independence, you constantly need to push through frustrating bugs, spend hours debugging issues that seem impossible, you should also be patient and research without asking people for help, and constantly learn new technologies just to stay relevant.

I’ve seen it happen countless times: someone starts learning JavaScript because they heard about a friend who got a $100k job, then gives up after a few weeks when they realize how much effort it actually takes. Meanwhile, people who genuinely enjoy the problem-solving aspect of coding push through those same challenges because they find the process rewarding.

If your main goal is financial security with less intellectual demand, consider sales, skilled trades, or other careers with clearer paths to good income. There’s absolutely no shame in choosing a more straightforward route to financial stability.

2. You Hate Puzzles and Problem-Solving

Here’s something that might surprise you: most of programming isn’t actually writing new code. It’s debugging existing code, figuring out why something isn’t working, and breaking down complex problems into manageable pieces.

If you’re the type of person who gets frustrated with puzzles, avoids escape rooms, or gives up quickly when technology doesn’t work as expected, programming might feel like torture. Every single day as a developer involves systematic problem-solving, logical thinking, and working through issues step by step.

Before you commit to learning programming, try this simple test:

Pick up a logic puzzle book or try some basic coding challenges online.
Pay attention to your emotional response.
Do you feel excited when you solve a tricky problem, or do you feel relieved that it’s over?

That difference matters more than you think.

Programming attracts people who find satisfaction in the process of figuring things out, not just in having figured something out. If you’re naturally curious about how things work and enjoy the work of finding solutions, you might have the right mindset. If problem-solving feels like a necessary evil, you might want to reconsider.

3. You Need Everything to Make Sense Immediately

Programming has a learning curve unlike most other skills. You’ll often need to use concepts before you fully understand them, work with tools that seem overly complicated, and accept that confusion is part of the process.

I’ve noticed that people who struggle most with programming are those who need to understand everything completely before moving forward. They get stuck on the “why” behind every syntax rule or spend weeks trying to fully grasp a concept before writing any code.

Successful programmers are comfortable with ambiguity. They’re okay with using a library they don’t completely understand, following tutorials that skip over some details, and gradually building understanding through practice rather than perfect understanding.

If you’re someone who needs clear, linear explanations for everything and gets frustrated when things don’t make immediate sense, the messy, iterative nature of learning programming might drive you crazy. Some people learn better through structured, predictable processes — and that’s totally valid. It just might mean programming isn’t the best fit.

4. You’re Looking for Stability and Routine

One of the most challenging aspects of a programming career is that the learning never stops. The JavaScript framework you spend months mastering this year might be considered outdated in two years. The database technology your company uses today might be replaced by something completely different next year.

This constant change excites some people and exhausts others. If you’re someone who wants to learn a skill once and use it for decades without major updates, programming will feel overwhelming. The technology landscape moves incredibly fast, and staying relevant requires continuous learning throughout your entire career.

There are developers who’ve been coding for 20+ years, and they’re still learning new technologies, adapting to new methodologies, and occasionally feeling like beginners again. That’s a feature of the industry.

I need you to ask yourself honestly:

Does the idea of constantly learning new things energize you or stress you out?
Are you excited by change, or do you prefer mastering one thing deeply and sticking with it?

Neither answer is wrong, but they point toward very different career paths.

5. You Avoid Details and Precision

When it comes to details, programming is unforgiving. A single misplaced character can break an entire application. A small logic error can cause hours of debugging. Inconsistent formatting can make code impossible for others to understand.

If you’re naturally detail-oriented. I mean, the type of person who notices typos in emails, gets bothered by inconsistent formatting, or naturally organizes things systematically — you already have a significant advantage in programming.

But if you’re more of a big-picture person who prefers to leave the details to others, programming might feel frustrating. You can’t delegate precision in code. The computer does exactly what you tell it to do, not what you meant to tell it to do.

This doesn’t mean you need to be obsessive about every tiny detail in your personal life, but you do need to be able to shift into a detail-focused mindset when working with code. Some people find this shift natural and even relaxing. Others find it mentally exhausting.

6. You Prefer Working Alone Always

There’s a persistent saying that programming is a one-man activity — just you, your computer, and endless lines of code. The reality is quite different. Modern software development is highly collaborative.

You’ll spend significant time in meetings discussing project requirements, reviewing other people’s code, explaining your solutions to teammates, and working together to solve complex problems. You’ll need to write documentation that others can understand, communicate with designers and product managers, and sometimes even present your work to clients or stakeholders.

This doesn’t mean you need to be an extrovert or love constant social interaction. Many successful developers are introverts who recharge through solo work. But you do need to be comfortable collaborating, receiving feedback on your code, and explaining your technical decisions to others.

If the idea of having your code reviewed by colleagues makes you anxious, or if you strongly prefer working independently without input from others, the collaborative nature of most development teams might be challenging.

7. You Can’t Handle Constant Failure

An uncomfortable truth about programming, and that’s: your code will break constantly, and most of the time it will be your fault. You’ll introduce bugs while fixing other bugs. You’ll spend entire days debugging issues that turn out to be caused by a single typo. You’ll build features that get scrapped before anyone uses them.

Failure isn’t occasional in programming — it’s a daily part of programming. The difference between successful and unsuccessful developers isn’t that successful ones fail less; it’s that they’ve learned to fail productively and are comfortable with it.

This means bouncing back quickly from setbacks, learning from mistakes without taking them personally, and maintaining motivation even when progress feels slow.

If you’re someone who gets discouraged easily by failure or takes mistakes as personal criticism, the constant problem-solving nature of programming might be emotionally draining.

Programming requires a specific type of resilience: the ability to stay curious and motivated even when things aren’t working. Some people find this challenge motivating. Others find it exhausting.

On the other hand: You Might Love Programming If…

Before you think I’m trying to scare everyone away from programming, let me share some positive signs that development might be perfect for you:

You actually enjoy troubleshooting problems, whether it’s figuring out why your WiFi isn’t working or solving a complex puzzle.
You’re naturally curious about how things work and don’t mind diving deep into details when something interests you.
You find satisfaction in building things that other people can use and appreciate.
You’re comfortable being wrong and learning from mistakes.
You don’t mind starting over when your first approach doesn’t work.
You enjoy learning new things and see change as an opportunity rather than a threat.

If any of these resonate with you, programming might be an excellent fit, regardless of your educational background or previous experience.

Here’s how to honestly assess whether programming is right for you:

1. Try coding for 30 days straight. Not just watching tutorials, but actually writing code and solving problems.

Pay attention to your emotional responses to.
Do you feel energized by solving coding challenges, or do you feel relieved when you’re done?
Do you find yourself thinking about coding problems outside of study time, or do you forget about it the moment you close your laptop?

2. Work on a complete project from start to finish. Build something simple but functional — maybe a basic calculator or a simple website. Experience the full cycle of planning, coding, debugging, and completing a project. This will give you a taste of what actual development work feels like.

3. Be brutally honest about your reactions. If you find yourself procrastinating on coding tasks, feeling overwhelmed by the learning curve, or losing interest after the initial excitement wears off, those are important signals to consider.

4. It’s Okay to Choose a Different Path
If you’ve read this far and realized that programming might not be the right fit for you, that’s not a failure — it’s valuable self-awareness. If you don’t have the attributes stated above, you’re not going to make it.

Instead of wasting your time on programming, do something you’re really passionate about. Chase your dreams. Do what you’re really passionate about. Don’t do something because others are doing.

The tech industry offers many opportunities beyond programming:

UX/UI design for visual creativity,
Product management for strategic thinking,
Technical writing for communication skills, or
Project management for organizational abilities.

There’s no shame in discovering that programming isn’t your calling. In fact, it’s much better to realize this early than to spend months or years struggling with something that doesn’t align with your natural strengths and interests.

Be honest with yourself about your motivations, strengths, and preferences.

The most important thing is making an informed decision based on your realistic expectations rather than social media success stories or salary headlines. Your future self will thank you for taking the time to really consider whether this path is right for you.

Would you rather be a world-class fashion designer or an average programmer?

Whatever you decide, choose it deliberately and with full awareness of what you’re getting into. That’s the first step toward building any successful career.

Happy decision making!

If you enjoyed this, like it, comment on it, and share it with a friend.

Are You a Nigerian Looking for a Profitable Side Business — Yes?

Important Programming Concept Every Self-Taught Developer Must Know

Frank — Wed, 30 Jul 2025 18:24:04 +0000

Let’s be honest, you don’t need to memorize every Python library or JavaScript framework out there. Those CSS styles and animation tricks can easily be googled in seconds and used. What you can’t afford to skip are the core programming concepts that form the backbone of every language you’ll ever touch, irrespective of the language. Knowing most of them will really help you in your programming journey as a self-taught developer, but most importantly, it will help you pick up new programming languages faster than you ever thought possible.

I get asked questions like, “So Frank, what should I learn as a self-taught developer?” constantly. Well, if you’re teaching yourself to code, you’re not alone, and you’re definitely not at a disadvantage. But there are some foundational concepts that can make or break your journey in tech.

I’ll be breaking down the important concepts you need to master, split into two clear paths based on where you are in your journey.

If you’re a Beginner: Building Your Foundation

1. Version Control

Git and GitHub aren’t optional—they’re essential. Think of version control as your coding safety room. You’ll use it for managing your code changes, collaborating with other developers, and yes, impressing potential employers who check your GitHub profile.

Start with the basics: commits, branches, and merges. Trust me, your future self will thank you when you need to go back to that “quick fix” that broke everything.

2. Master One Language, Understand Others

Here’s my advice: pick one language and get really good at it first. Whether it’s JavaScript, Python, or Java, go deep before you go wide. But once you’re comfortable, peek at other languages. Understanding the basic syntax and concepts of multiple languages will make you a more well-rounded developer and help you choose the right tool for each job.

3. Data Structures and Algorithms

I know, everyone talks about these all the time, and they can seem intimidating. But here’s why they matter: they’re your problem-solving toolkit.

Start with Big O notation to understand performance, then tackle the essential data structures: arrays, linked lists, stacks, queues, hash tables, trees, and graphs. Add in searching and sorting algorithms, and you’ll have the foundation for writing efficient, scalable code.

4. Programming Paradigms—Different Ways of Thinking

Code isn’t just about syntax—it’s about thinking. Learn the differences between procedural, object-oriented (OOP), and functional programming (FP). Each paradigm offers different approaches to solving problems. OOP is great for modeling real-world entities, functional programming excels at data transformations, and procedural programming keeps things straightforward for simple tasks.

5. Debugging and Testing

There’s no way of escaping bugs—they’re inevitable, but staying stuck on them isn’t. Learn to use debugging tools in your IDE and browser. More importantly, write tests from the beginning. Unit tests and integration tests—they’re not just for “big companies.” They’re your insurance policy against breaking your own code.

6. Command Line

Get comfortable navigating directories, managing files, and running commands. You’ll use it for version control, package management, and countless development tasks. It might feel intimidating at first, but it’s incredibly powerful once you understand it.

7. Code Refactoring

Writing code is one thing; writing clean, maintainable code is another. Learn to refactor your code, improving its structure without changing its functionality. Clean code isn’t just prettier; it’s easier to debug, extend, and collaborate on.

For More Advanced Learners

8. Database Management—Where Your Data Lives

Every application needs to store data somewhere. Learn SQL for relational databases — it’s been around for decades and isn’t going anywhere. Also get familiar with NoSQL basics for when you need more flexibility or scale.

9. Gang of Four Design Patterns

The GoF design patterns are time-tested solutions to common software design problems. Singleton, Factory, Observer, and Strategy—these patterns will help you write more maintainable and scalable applications.

10. Software Design Principles

Master DRY (Don’t Repeat Yourself), KISS (Keep It Simple, Stupid), and the SOLID principles. They’re not just academic concepts—they’re practical guidelines that separate good code from great code.

11. Security Best Practices—Protecting Your Users

Security isn’t someone else’s job—it’s everyone’s responsibility. Learn the fundamentals: input validation, authentication vs. authorization, and basic encryption concepts. Understanding common vulnerabilities like SQL injection and XSS will make you a more valuable developer.

12. Continuous Integration/Continuous Deployment (CI/CD)

Understand Continuous Integration and Continuous Deployment. Learn how automated testing and deployment pipelines make software delivery more efficient and reliable. Your future team will appreciate that you understand these concepts.

Your Learning Path Forward

Remember, you don’t need to master everything at once. Pick the concepts that align with your current projects and career goals. Build small projects that incorporate these concepts. The key is consistent practice and gradual improvement.

The beauty of being self-taught is that you get to customize your learning journey. Use this roadmap as your guide, but don’t feel pressured to check every box immediately. Focus on building a strong foundation first, then expand your skills as you grow.

Keep coding, keep learning, and remember—some of the best developers I know are self-taught. You’ve got this.

Happy coding!

If you enjoyed this, like it, comment on it, and share with a developer friend.

The Challenges of Self-Learning Programming (and How to Overcome Them)

Frank — Fri, 25 Jul 2025 08:50:41 +0000

Most of my friends knew what they wanted to be in high school. I didn’t.

Well, I thought I did. I wanted to become a petrochemical engineer because they were earning a lot of money, or so I thought. The problem was, I didn’t like chemistry. Failed it twice. I still thought this was my path because, you know, the money.

That was my plan for a while, until a tutor came to the tutorial center where I was preparing for college one day and said, “Most students study courses they don’t like. They do it for money, or because their parents want them to, or because companies pay well. Go home and think about what you actually love doing.”

I went home and thought hard. Chemistry was out—obviously not happening. But I’d always loved web applications—in fact, tech as a whole. After school, I’d hang out in the I.C.T. lab with my friends. I wanted to know how websites worked. How did people build apps? What happened behind the scenes?

Tech is huge. I needed to pick a niche. So I chose software development and decided to teach myself programming before going to college.

What Self-Learning Actually Looks Like

Learning to code by yourself sounds great.

You go at your own pace.
You pick what to learn.

It’s also really tough.

I made countless mistakes. Got stuck more times than I can count. Almost gave up more than once. But I figured out what works and what doesn’t.

If you’re thinking about learning programming on your own, here’s what I wish someone had told me.

1. Don’t Try to Use Every Resources Out There

When I started, I thought more resources meant faster learning. I was wrong.

I had YouTube tutorials, Udemy courses, books, blogs, documentation, and forums all open at once. One night I counted 47 browser tabs.

Instead of learning faster, I learned nothing.

Then I discovered roadmap.sh. It gives you a clear path to follow. No more guessing what to learn next.

I made a rule: one main resource, two backup ones. That’s it.
Pick a course or book as your main guide. Then use two other sources only when you’re confused. This will stop the endless switching and actually let you focus.

2. Stop Collecting Courses and Start Building

You know what’s worse than too many resources? Collecting them without using them.

Here’s what nobody warns you about: you can watch tutorials forever and still not know how to code.

I’d finish a 10-hour JavaScript course, feel smart, and then immediately start a React course. I never built anything with JavaScript. I just kept consuming.

I stopped watching and started building.

Every time I learned something new, I had to build something with it. Even something tiny.

When I learned about functions, I built a calculator.
I learned about arrays and built a to-do list.

The projects were small, but they were mine. That made all the difference.

3. You Need People, Not Just Tutorials

The first weeks were amazing. I was coding, and I was learning.

There was no professors breathing down my neck. I didn’t have classmates to compete with. No grades to chase. No deadlines that mattered.

I’d set goals and miss them, nothing happened. I’d skip days, then weeks. Procrastination became my biggest enemy. Some days I wondered if I was meant for this.

I found my community online. The web developer community, Build In Public, and Software Engineering community on twitter, became my classroom. Twitter gave me coding mates.

The idea was coding every single day. Even if just for 30 minutes. Small daily progress beats coding 5 hours, two days in a week.

4. Get Feedback Early and Often

I could write code that worked, but i had no idea if it was good code.

I built my first web app, my gosh i felt proud. Later I discovered it was terrible, from security holes everywhere to spaghetti code. The code was really messy.

I had nobody to tell me “Hey, maybe don’t do it that way.”

I started asking friends of mine who were experienced dev, if there was better ways i could write a particular code. I seldomly post my code on my socials for feedback (I’m working on it doing better though). The feedbacks might be harsh but will be incredibly helpful.

You can find mentors on social media just by asking. Most people will be happy to help.

5. Embrace Not Knowing Things

To be honest, confidence is dangerous when you’re self-taught dev. You think you know something, then you hit a wall and realized you don’t actually know much.

This is where imposter syndrome comes in. You feel like a fraud who’s about to get exxposed.

I stopped being ashamed of not knowing things. Instead, I got curious. I usually keep a “things I don’t understand” list. it helps me spot patterns and plan what to tackle next.

I started comparing myself to my past self, not to other people online. That simple shift helped my confidence more than anything else.

6. The Real Education Happens in The Struggle

These challenges weren’t just obstacles I needed to overcome, it taught me things no classroom could.

Yes, I learned to code. But I also learned how to learn anything, self-discipline, research skills, and problem solving under pressure.

Now when I see new technologies, I don’t panic, I know I can figure them out. That’s true confidence if you ask me. You can’t get it from a traditional classroom.

My Self-Learning Hack

Use roadmap.sh for a clear learning path.
Set small goals and deadlines you can actually hit.
Join Learning Communities on Twitter, Reddit, and Stack Overflow.
Share your code and ask for feedback.
Find mentors online/offline who can help you.
Build real projects with everything you learn.
Code every day even if it’s just 30 minutes.

Self-learning programming is hard. But you can do it.

What’s your biggest challenge right now? Share it in the comments, we’d love to help you.

Go build something amazing.

If you enjoyed reading this, like it, comment on it, and share it with a friend.

This is Why Good Enough Software is Better Than Perfect

Frank — Mon, 21 Jul 2025 15:46:47 +0000

I used to lie awake at night thinking about my code.

Was that function elegant enough?
Could I refactor that module one more time?
Should I rebuild the entire architecture with the latest framework?

For a long time, I was trapped in perfectionism, something that so many developers today struggle with. We’ve been conditioned to believe that our code needs to be flawless, with zero bugs, clean architecture, and the newest technology stack. It’s a dangerous belief that can weaken progress and kill innovation.

The truth hit me during a particularly intense code review session. A senior architect, someone whose work I deeply respected, made a confession that changed everything. He said, “I’ve never written perfect code. Neither has anyone else in this room. That’s exactly why we’re successful.”

Beautiful code exists only on blog posts. ~Mosh Hamedani

I realized that perfectionism isn’t a virtue in software development—it’s a trap that keeps you from delivering real value to real people.

What Real Software Actually Looks Like

Software development is messier than the polished blog posts and conference talks would have you believe. That elegant code you admire in tutorials? It doesn’t exist in production. Real software is built by humans, under pressure, with changing requirements, evolving technologies, and tight deadlines.

Legacy code accumulates in some big IT firms codebases. Technical debt builds up faster. Different engineers, with different styles and skill levels, leave their fingerprints all over the codebase. This often results in software that works, that serves millions of users, that generates billions in revenue—but looks nothing like those examples you’ll probably see in your computer science textbooks.

This isn’t a failure of the industry. It’s just how software works in the real world. Once you accept this reality, you can start focusing on what actually matters.

What Exactly Is A “Good Enough” Software?

Many developers misunderstand what I mean by “good enough” software. I’m not talking about poorly written code or you trying to cut corners. I’m talking about strategic excellence — you knowing where to invest your perfectionist energy and where to embrace pragmatic solutions.

Good enough software is:

Functional: It solves the problem it was designed to solve
Maintainable: Future developers (including yourself) can understand and modify it
Reliable: It performs consistently under normal conditions
Valuable: It delivers real benefits to users

Good enough software is NOT:

Sloppy: Rushed code with no thought to consequences
Untested: Software without proper validation
Undocumented: Code that only its creator understands
Unmaintainable: Solutions that create more problems than they solve

Why Timing Beats Perfection

In the real world, software is a race against time, competition, and changing user needs.

While you’re fine-tuning the perfect solution, someone else is already shipping something that works. While you’re debating the “right” architecture, they’re learning from actual users. While you’re writing tests for edge cases that may never happen, they’re iterating in real time.

Take a look back at the smartphone wars. BlackBerry had better features on paper, superior email, physical keyboards, and more control. But while they were focused on perfecting what already worked, Apple shipped the iPhone with big limitations: no copy-paste, no third-party apps, and no 3G. And still, it changed everything. Why? Because it solved a problem users didn’t even know they had, and it kept evolving.

The Rise and Fall (and Rise Again?) of BlackBerry - Digital Innovation and Transformation

d3.harvard.edu

The magic of shipping early and iterating fast isn’t just in speed; it’s in learning. Each version brings insights. Each mistake teaches. That learning stacks up fast. And that compounding knowledge beats perfect-but-late every single time.

What Really Matters to People

Users don’t care about your code. They care about their problems being solved. They care about getting their job done, connecting with friends, or being entertained. Your nice and clean algorithm and architecture are invisible to them—and that’s exactly how it should be.

Real users are tolerant of imperfections when the core functionality works. They’ll forgive slow loading times if the app helps them accomplish their goals. They’ll overlook UI quirks if the software saves them time. They’ll even report bugs with patience if they believe in the product’s value.

But they won’t forgive delayed launches, missing features, or solutions that never ship because they’re “not ready yet.”

Learning from Winners

The most successful software products in history were all imperfect when they launched. Windows, iPhone, Facebook, etc.

These products succeeded not because of their imperfections, but because their creators knew that getting real software into real hands beats polishing something no one can use. They learned, adapted, and improved after launch.

The Continuous Improvement Mindset

You don’t need to get it right the first time. You just need to get it working, then make it better.

Instead of stressing over every edge case, you focus on what most users actually do.
Instead of guessing at performance, you let real-world data guide your optimizations.
Instead of chasing perfection, you design with room to grow.

Every version you ship brings you closer to what your users really need. Every bug, every tweak, every bit of feedback—it’s all part of the process. Progress, not perfection. That’s how great software gets built.

To break free from perfectionism. Start with these practical strategies:

Identify Your Core Value: Figure out the one thing your software has to get right, no compromises. That’s where your perfectionist energy should go. Everything else is secondary.
Set “Good Enough.” Criteria: Know what done looks like, what users actually need, and what can wait. Not everything needs to be polished to shine.
Time-box Your Perfectionism: Give yourself a fixed amount of time to polish and optimize. When the timer runs out, ship what you have.
Embrace Technical Debt: Not all debt is bad. It’s okay to take shortcuts when you need to move fast, as long as you’re honest about it and plan to clean things up later.
Create Feedback Loops: Build simple ways to get feedback early and often, whether it’s a quick user test or real-world usage. The sooner you hear what’s working (or not), the better you can adjust.

Try not to add features unless they’re requested by users.

The software industry needs more developers who understand that perfect is the enemy of good. We need builders who can ship functional solutions, gather feedback, learn from it, improve, and iterate rapidly. We need developers who understand that “good enough” isn’t laziness—it’s momentum.

Start today. Look at your current project: What part of it is already good enough to help someone? What is that tiny obsession that is slowing you down? Let it go. Ship the thing. Learn fast. Iterate smarter.

Your users are waiting.

If you enjoyed reading this, like it, comment on it, and share it with a friend.

How To Think Like a Programmer

Frank — Mon, 21 Jul 2025 15:18:56 +0000

Yeah, that’s right. I said that.

You’re probably wondering why I’d make such a bold statement, especially when every programming tutorial tells you the opposite. Stay with me, and you’ll see exactly why this mindset shift changes everything.

The biggest mistake I see new programmers make is focusing on learning syntax instead of learning how to solve problems.
— V. Anton Spraul

Why This Matters

We all have problems. Big and small. Financial struggles, relationship issues, career decisions, that weird noise your car makes, or figuring out why your code crashes every time you run it.

How we deal with these problems is often random. Most of us tackle these challenges using what I call the “spray and pray” method:

Try something, anything
When it fails, you try something else.
You keep throwing solutions at the problem until it works.

This approach is really common. I’ve been there. When I started coding, I’d randomly try different syntax combinations, hoping something would magically work. Sometimes I would get lucky, but it was a big waste of time and very frustrating.

The truth is, Problem-solving is the foundational skill. It’s the skill that makes all other skills more effective. Maybe you’re debugging code, planning a budget, or trying to fix a relationship; the same fundamental principles apply.

What It Means to Think Like a Problem-Solver

A problem-solver doesn’t just come up with random solutions and hope that one of them works. They have a systematic approach, a way of tackling problems no matter what the problem is

When you think like a problem-solver, you:

Break down complex problems into smaller problems.
Approach challenges with curiosity instead of feeling annoyed
Build solutions step by step
Learn from every attempt, whether it works out or not

This is why the best programmers aren’t necessarily the ones who know the most syntax — they’re the ones who can systematically work through any problem they encounter.

The Problem-Solver’s Step

Step 1: Understand the Problem

“If you can’t explain something in simple terms, you don’t understand it.”
— Richard Feynman

Most hard problems are hard because we don’t truly understand them. This is why understanding comes first, before any solution attempts.

How to know when you understand a problem: When you can explain it in plain English to someone else (or even to yourself out loud).

I can’t count how many times I’ve been stuck on a coding problem, started explaining it to a friend, and halfway through my explanation, the solution became obvious. This phenomenon is so common that programmers have a term for it: rubber duck debugging — explaining your problem to an inanimate object

Let’s say you’re trying to build a login system. Instead of immediately jumping into code, first understand what you’re really building:

Users need to provide their email and password.
I need to check if those credentials match what’s in my database.
If they match, I need to let them access the protected content.
If they don’t match, I need to show an error message.

See how breaking it down in simple terms makes it easier and clearer?

Next time you face any problem (not just coding), try explaining it out loud. Talk through what you’re trying to achieve, what obstacles you’re facing, and what a successful outcome would look like.

Step 2: Plan Your Approach

You shouldn’t jump right into solving without a plan. I know it’s tempting; when you’re excited about a solution, you want to jump in immediately. But planning saves time in the long run.

Let’s continue with our login system example:

Create a form with email and password fields
When user submits, capture the form data
Send that data to the server
On the server, search the database for a user with that email
If found, compare the submitted password with the stored password
If passwords match, create a session and redirect to the dashboard.
If not, send back an error message

This might seem straightforward, but writing it down forces you to think through each step. You’ll often discover edge cases or missing pieces during this planning phase.

Pro tip: In programming, use comments to outline your plan before writing code. In life, use a notebook or document to outline your approach before taking action.

Step 3: Break Problems Down (The Reduction Technique)

Pay attention; this is the most important step of all.

Do not try to solve one big problem. You will get overwhelmed, frustrated, and likely give up.

Instead, break it into smaller problems. These smaller problems are much easier to solve. Then solve each smaller problem one by one, starting with the simplest.

What makes a smaller problem “simplest”?

You know the solution (or are closer to knowing it)
Solving it doesn’t depend on other smaller problems being solved first

“If I could teach every beginning programmer one problem-solving skill, it would be the ‘reduce the problem technique.’ For example, suppose you’re asked to write a program that reads ten numbers and figures out which number is the third highest. For a brand-new programmer, that can be tough. If you’re stuck, reduce the problem to something simpler. Instead of the third-highest number, what about finding the highest overall? Still too tough? What about finding the largest of just three numbers? Or the larger of two? Reduce the problem to the point where you know how to solve it and write the solution. Then expand the problem slightly and rewrite the solution to match, and keep going until you are back where you started.” — V. Anton Spraul

Step 4: When You’re Stuck—The Three-Step Recovery

When you hit a wall (and you will), you have three powerful strategies:

1. Debug
Go step by step through your solution, trying to find where things went wrong. In programming, this means using a debugger or adding print statements to see what’s happening at each step.

In life, this means retracing your actions. Imagine you’re following a recipe and your cake didn’t turn out right. Debug by going through each step:

Did you measure ingredients correctly?
Was your oven at the right temperature?
Did you mix for the right amount of time?

2. Reassess
Sometimes we get so lost in the details that we miss a simpler approach. Take a step back and ask, “Is there a completely different way to approach this?”

Pro tip: Sometimes the best reassessment is starting over completely. Delete everything and begin again with fresh eyes. This might sound extreme, but it’s often the fastest way to a better solution.

3. Research:
No matter what problem you’re facing, someone has probably encountered something similar. Find that person or solution.

You shouldn’t be looking for a solution to your entire big problem. Only look for solutions to sub-problems. Because unless you struggle (even a little bit), you won’t learn anything. If you don’t learn anything, you’ve wasted your time.

For our login system example, you might research:

How to validate email addresses
How to securely hash passwords
How to implement sessions

But don’t just copy someone else’s complete login system—you’ll miss the learning opportunity.

Step 5: Learn and Practice

Don’t expect to become a great problem-solver overnight. Like any skill, it requires deliberate practice.

All problems share similar patterns. The more problems you solve, the more patterns you’ll recognize, and the faster you’ll become at solving new problems.

How to practice:

For programming: Try coding challenges on platforms like Coderbyte, LeetCode, or HackerRank
For general problem-solving: Chess puzzles, Sudoku, escape rooms, strategy games
For real-world skills: Take on small projects outside your comfort zone

I solve at least one coding challenge every day, not because I enjoy the challenge itself, but because it trains my problem-solving muscles. Each problem teaches me a new pattern or reinforces an existing one.

The goal isn’t to memorize solutions; it’s to make the problem-solving process a part of you.

Step 6: Get Help (After You’ve Exhausted Other Options)

Try the other five steps first. There’s immense value in struggling through a problem yourself, even if you don’t solve it completely.

When you do ask for help:

Explain what you’ve tried so far
Show your current approach
Ask specific questions rather than “How do I solve this?”

For example, instead of
“How do I build a login system?”

Try:

“I’m building a login system and I’ve got the form working, but I’m stuck on how to securely compare passwords. I’ve tried using === but I read that’s not secure. What approach should I research? ”

This shows you’ve done the work and helps others give you more targeted assistance.

After all the explanation in this article, I think you already know why I said earlier why you shouldn’t think like a programmer; instead, think like a problem solver. If you still don’t know, and it’s okay, just know this:

Not every programmer is a problem solver, but every problem solver can become a great programmer.
Problem-solving skills transfer to every area of life; programming syntax only works in code.

The programming languages you learn will become outdated. The frameworks you master will be replaced. But the ability to break down problems, think systematically, and persist through challenges is forever.

I hope you encounter many problems. That’s right.

At least now you know how to solve them. Plus, you’ll discover that with every solution, you improve.

Your Next Steps

Start small: Pick a minor problem you’re facing today and apply this framework
Practice daily: Solve one small problem every day using these steps
Teach others: Explain your problem-solving process to someone else
Document your patterns: Keep notes on the types of problems you encounter and how you solve them
Stay curious: When you encounter bugs, errors, or obstacles, approach them with curiosity rather than frustration

Programming is just one application of problem-solving skills. Learn and practice the art of systematic problem-solving, and you’ll not only become a better programmer—you’ll become better at life.

I'm a programmer, I have no life

Frank — Mon, 21 Jul 2025 14:42:14 +0000

Working programmers, after work they start on their personal side project and don’t quit until it’s time to go to bed.

Self-employed programmers are constantly juggling client work, business development, and staying competitive — basically working around the clock. These guys probably have it even harder in some ways — no guaranteed income but still need to work those crazy hours.

The ones who don’t have a job yet mostly spend their time learning new technologies or frameworks intensively. Some might also juggle it with some personal side projects or building a startup/SaaS.

And then you have the college programmers — we face multiple pressures that can completely consume our existence. We deal with demanding pressures simultaneously, like academic grind, skill race, job market anxiety, and social sacrifice, among others.

The brutal part is that unlike working programmers who at least get paid for their long hours, we’re paying tuition for the privilege of being overwhelmed. We often survive on caffeine/energy drinks, minimal sleep, and whatever food we can grab while watching our friends have what looks like a normal college experience.

There are similarities between these programmers. Most of us spend extremely long hours coding, working weekends, or being so mentally absorbed in solving technical problems that we neglect everything else, like:

Skipping meals or eating poorly while glued to their computer
Zero social life or dating.
No hobbies, exercise, or relaxation
Losing touch with family
Sleep schedule completely destroyed by coding marathons
Thinking about code problems 24/7

“I have no life” has become our badge of honor in programmer culture —it’s a mix of dark humor and genuine complaint about how intense this gets.

Let me walk you through my life as a college programmer schooling in Nigeria.

It’s 2:37 AM, and I’m sitting in engineering’s faculty building with my laptop, two empty Fearless bottles next to me, and my Digital Assessment Platform still giving me headaches. This is my life now.

If you know anything about Nigerian federal universities, you’ll know we programmers aren’t welcome in the campus library. You want to code? You either do it in your room when NEPA (they are responsible for the electricity generation and transmission in Nigeria) decides to bless you with light or pay for some workspace with stable power and WiFi — which some might not afford. So what do we do? After lectures, by 10pm we’re sneaking into faculty buildings hunting for any socket that works, coding till 4AM.

This is my reality as an undergraduate programmer in Nigeria. The phrase “I’m a programmer, I have no life” isn’t just some joke anymore — it’s literally what my existence looks like right now.

How I Even Got Into This Mess

I Didn’t Start Early Like Everyone Else

Let me be honest — I wasn’t one of those kids who started coding at 8 years old. I didn’t even know what programming was when I was young. But I was always curious about tech stuff. Like, how do websites actually work? How can I make my own app? Could I create another Subway Surfers like the one I used to play on my mom’s phone?

That curiosity led me to join tech communities online, and they all kept saying the same thing: “It’s not about your credentials but your potential.” Build a portfolio. Do personal projects. Contribute to open source. Build what matters.

So that’s what I did.

My Typical Day (Or Should I Say Night?)

Here’s what my life actually looks like:

6:00 AM: Wake up, go jogging, hit the gym (gotta stay healthy somehow)
8:00 AM: First lecture — Software Engineering, Data Structures, Operating Systems, whatever
10:00 AM—2:00 PM: More lectures I actually have to attend
3:00 PM—6:00 PM: If there’s coursework due, I’ll do it. If not, I rest up for the all-nighter ahead
7:00 PM—10:00 PM: Try to work on personal projects (if there’s light in my room; else i head to school )
10:00 PM—3:00 AM: Still coding with/without my energy drinks

Why I Don’t Like School

Let me be straight with you — I hate school. Not learning, but school specifically. Our curriculum is stuck in the past. Most of what they’re teaching me, I already learned from ALX SE way back. It’s frustrating sitting in classes hearing outdated stuff when I could be building something that actually matters.

That’s why I only attend lectures where attendance is compulsory. The rest of the time? I’m working on my Digital Assessment Platform — a project I started because I saw how messed up our test-taking and assessment systems are. I knew I could fix it with code.

The Real Struggle

You guys in other countries probably can’t imagine this, but here’s our daily reality: power outages aren’t occasional —they’re guaranteed. Internet isn’t a given — it’s a luxury. When you’re trying to debug some code and NEPA takes the light for 12 hours straight, you’ll understand why we get creative.

I’ve mastered the art of downloading documentation when there’s internet, keeping everything offline-ready, and somehow predicting when power will go off so I can plan around it.

During the day, I’m submitting assignments using whatever outdated programming languages my lecturers want, just to get grades. At night, I’m building real stuff with modern tech stacks that actually matter in the industry.

My Digital Assessment Platform isn’t some school project — it’s my solution to a problem I see every semester. Bad testing systems, inefficient assessments. I decided to do something about it instead of just complaining.

How I Survive This

I’ve figured out which lectures I can skip and which ones I can’t. It’s not about being lazy — it’s about recognizing that some classes won’t teach me anything I don’t already know, and I’d rather use that time building my portfolio.

Those late-night coding sessions in faculty buildings have become my routine. It’s quiet, no distractions, and somehow I get my best work done between midnight and 4AM. Fearless and Predator energy drinks have become my best friends.

Community Support

We Nigerian student programmers stick together. We share intel about which buildings have the most reliable power, which online resources work offline, and what skills are actually getting people jobs. We help each other survive this system.

The Truth About This Life

Look, I’m not going to sugarcoat it — this life is hard. “I’m a programmer, I have no life” sounds dramatic, but it’s pretty accurate for where I am right now.

But here’s the thing —I’m not sacrificing my life for nothing. I’m building toward something bigger. Every late night in those faculty buildings, every energy drink, every skipped social event — it’s all investment in being able to solve real problems with code.

My Digital Assessment Platform might not impress my lecturers, but it’s solving actual problems I see around me. And that matters more to me than any grade.

The 2:37 AM coding sessions will continue. The energy drinks will probably keep piling up. But I’m not just surviving this —I’m building something that matters, whether the system recognizes it or not.

That’s what being a Nigerian undergraduate programmer really looks like.

If you enjoyed reading this, like it, comment on it, and share it with a friend

JavaScript ES6+ Features Every Developer Should Know

Frank — Mon, 21 Jul 2025 14:17:23 +0000

JavaScript has evolved massively since ES6 dropped in 2015. Are you still writing JavaScript like it’s 2010? You’re making your life harder than it needs to be. These features actually solve the annoying problems you deal with every day.

React, Vue, Angular — they all lean heavily on ES6+ features. You can’t really avoid learning them anymore. Plus, they help you write less code, introduce fewer bugs, and actually maintain your projects without frustration kicking in.

1. Variable Declarations and Scoping

let and const Replace var

let and const are new ways to declare variables that were introduced in ES6 to replace var. They provide better scoping rules and help prevent common JavaScript. The old var keyword creates confusing behavior. Variables declared with var are function-scoped and get “hoisted,” which leads to unexpected results.

Here’s how you fix it:

Simple rule: Use const by default, let when you need to reassign, and avoid var completely.

2. Template Literals

Concatenating strings with + is painful to read and write. Template literals use backticks and let you embed expressions directly in strings.

3. Destructuring

Instead of writing object.property five times in a row, destructuring lets you extract multiple values at once.

4. Arrow Functions

Arrow functions use => syntax and are perfect for short functions and callbacks.

Arrow functions also handle “this” differently, which solves common JavaScript problems:

5. Default Parameters

Default parameters allow you to set default values for function parameters that will be used if no argument is provided or if undefined is passed.

Rest and Spread Operators The … operator works in two ways depending on context.

Rest — collecting multiple elements into an array:

Spread — expanding arrays or objects:

7. Classes

Classes provide a much cleaner syntax than the old prototype approach. They are template for creating objects with shared properties and methods.

The old prototype way was confusing

Classes are so much clearer

8. Enhanced Object Literals

When your property name matches your variable name, you can skip the repetition.

9. Asynchronous Programming

Promises: Handle Async Operations Better

Promises give you a way to handle asynchronous operations without repetitive callbacks.

Async/Await: Write Async That Looks Synchronous

This is possible with these keywords called async and await. They make working with promises easier by allowing you to write asynchronous code that behaves like asynchronous code.

async before a function means it returns a Promise
await pauses the function until the Promise resolves
You can use try/catch for error handling

10. Maps and Sets: Better Data Collections

Maps are like objects but can use any type as keys, not just strings.

Sets store unique values and automatically prevent duplicates.

11. ES6 Modules: Organize Your Code

Split your code into separate files and share functionality between them using import and export statements.

Creating and exporting from a module (math.js):

Importing and using the module (main.js):

12. Optional Chaining: Safe Property Access

The ?. operator lets you safely access nested properties without worrying about null or undefined values.

13. Nullish Coalescing: Better Default Values

The nullish operator works similarly like theOR operator (||). The ?? operator provides a default value only when the left hand side is null or undefined (not for other falsy values like 0, ‘’, or false)

14. BigInt: Handle Very Large Numbers

JavaScript’s regular numbers break down beyond Number.MAX_SAFE_INTEGER. BigInt handles arbitrarily large integers.

Don’t try to learn everything at once. Pick a couple of these features and start using them:

Replace all your var declarations with const and let
Use template literals instead of string concatenation
Try destructuring in your function parameters
Convert some callbacks to arrow functions
Use async/await for your Promise-based code
These features will make your JavaScript more readable and maintainable.

Start with the basics and gradually work your way up to the more advanced features.

If you enjoyed reading this, like it, comment on it, and share it with your developer friend.

DATATYPES IN C (double, long double, void, bool)

Frank — Mon, 28 Oct 2024 11:59:11 +0000

In the previous story, we talked about some datatypes like int, char, and float. We are going to see more datatypes in this article.

double —

Size:
The doubledata type typically requires 8 bytes of memory on most systems, providing more precision compared to the float data type.
Declaration:

double double_variable;

Example

double pi = 3.14159265359;

Initialization: You can initialize a doublevariable when declaring it.

double temperature = 98.6;

Operations: doublesupports standard arithmetic operations, like addition, subtraction, multiplication, and division:

double x = 5.0;
double y = 2.5;
double result = x / y;  // result is now 2.0

Output Formatting: When printing or displaying the value of a double, weuse the %lf format specifier in functions like printf:

printf("The value of pi is %lf\n", pi);

Scientific Notation: Numbers can be expressed in scientific notation, using the e or E character to represent the exponent.

double scientific_number = 1.23e-4;  // Equivalent to 0.000123

Precision:
doubleprovides double-precision floating-point numbers, offering a larger range and higher precision than the float data type.
It is suitable for applications where higher precision is required, such as scientific and engineering computations.
Limits:
The <float.h> header file provides constants that represent the limits of various floating-point data types. For double, you can use DBL_MIN and DBL_MAX to get the minimum and maximum representable values.

#include <float.h>

printf("Minimum value of double: %e\n", DBL_MIN);
printf("Maximum value of double: %e\n", DBL_MAX);

long double —

The long double data type represents extended-precision floating-point numbers.

It offers extended-precision floating-point numbers, depending on the platform.

Size:
The size of a long double variable is platform-dependent and is typically larger than that of double. It can vary, but it’s often 8 bytes or more.
Declaration:
To declare a long double variable, you use the following syntax:

long double long_double_variable;

Example

long double pi = 3.14159265358979323846;

Initialization: Similar to double, you can initialize long double at the time of declaration:

long double large_number = 12345678901234567890.1234567890;

Operations: long double variables support standard arithmetic operations.

long double x = 5.0;
long double y = 2.5;
long double result = x / y;  // result is now 2.0

Output Formatting: When printing or displaying the value of a long double, we use the %Lf format specifier in functions like printf:

printf("The value of pi is %Lf\n", pi);

Scientific Notation: As with double, long double supports scientific notation:

long double scientific_number = 1.23e-4;  // Equivalent to 0.000123

Precision:
long double provides the highest precision among floating-point data types in C. It is commonly used in applications that demand extremely high accuracy, such as scientific research and complex simulations.
Limits:
The <float.h> header file provides constants that represent the limits of various floating-point data types. For long double, you can use LDBL_MIN and LDBL_MAX to get the minimum and maximum representable values.

#include <float.h>

printf("Minimum value of long double: %Le\n", LDBL_MIN);
printf("Maximum value of long double: %Le\n", LDBL_MAX);

void —

void data type is a special data type that is used to indicate the absence of a specific type.

No Value: Use void for functions that don’t return a value.

void myFunction() {
    // Function does not return any value
}

No Arguments: When used as a function parameter, voidindicates that the function does not expect any arguments.

void printMessage(void) {
    printf("Hello, World!\n");
}

Pointer to void (Generic Pointer): A pointer of type void* (generic pointer) can point to objects of any data type. It is often used in functions that need to handle various data types.

void printValue(void *ptr, char type) {
    // Function to print values of different types using a generic pointer
}

Incomplete Type: voidcan be used as an incomplete type when declaring pointers.

void *ptr;

Return Type in Functions: In function declarations, void indicates that the function does not return a value.

void myFunction(void);

Dynamic Memory: void* is commonly used for allocating memory dynamically (with malloc, calloc, etc.) because it can be cast to any pointer type.

void *ptr = malloc(sizeof(int));

Generic Programming: In some programming paradigms, void is used in generic programming where functions or data structures can work with multiple data types.

bool —

The bool type was introduced in C99. Before that, C did not have a native boolean type. However, starting with the C99 standard, a header was introduced that includes a boolean type and boolean constants.

Header Inclusion: To use boolin C, include the <stdbool.h> header.

#include <stdbool.h>

Boolean Type: The bool type can take values trueor false.

bool isReady = true;
bool isValid = false;

Boolean Constants: The header defines two constants: true and false.

#include <stdbool.h>

bool isReady = true;
bool isValid = false;

Operations: The booltype is often used in conditions and logical expressions.

#include <stdbool.h>

bool isReady = true;

if (isReady) {
    // Code executed if isReady is true
}

Functions Returning bool:

#include <stdbool.h>

bool isEven(int number) {
    return (number % 2 == 0);
}

Compatibility:
While C99 and later standards have native support for bool, some older compilers or projects might not fully support it. In such cases, you - boolean variables represented using int, where 0 is equivalent to falseand non-zero to true.
Conditional Expressions:
boolis commonly used in conditional expressions to improve code readability.

#include <stdbool.h>

bool isPositive(int number) {
    return (number > 0);
}

Understanding the different data types in C, like double, long double, void, and bool, is crucial for writing efficient and accurate code. Each datatype has its unique properties and is suited for specific tasks—whether it's handling precise calculations with double and long double, defining functions with no return type using void, or managing logic with bool. Mastering these concepts will allow you to build more robust and flexible programs, especially as you tackle more complex problems in scientific computing, system programming, or everyday application development.

Further Resources

To continue your journey in mastering C and its data types, here are some valuable resources:

Books:
The C Programming Language by Brian W. Kernighan and Dennis M. Ritchie (also known as K&R) — A classic text that introduces C with clarity and depth.

Online Tutorials:
Learn-C.org — An interactive platform to practice C programming.
Video Resources:

YouTube Channel: freeCodeCamp — Provides free tutorials on C programming, among many other languages.

By diving into these resources, you’ll deepen your understanding of C and strengthen your programming skills. Keep experimenting and coding!

DATATYPES IN C

Frank — Fri, 11 Oct 2024 13:05:06 +0000

In C, data types form the structural backbone of any program. Understanding them is critical because they dictate how the compiler allocates memory, interprets data, and determines what operations are valid. In a way, selecting the right data type in C can be compared to choosing the right building material for a structure—it influences efficiency, reliability, and robustness.
Data types define the types of data that a variable can hold. They specify the amount of memory space required and the operations that can be performed on the data. C provides a rich set of built-in data types to handle different types of data.

Types Of Datatypes In C
int
- How To Know How Many Bits Your Machine Can Store
char
float

Types Of Datatypes In C

Data types specify the type of data that can be stored in a variable. They help in defining the variable's memory requirements and the operations that can be performed on the data.

Primary Datatypes

int
char
float
double
void
bool

Derived Datatypes

Array
Structure
Union
Pointer

User-defined Datatypes

typedef
Enum

int-

The int (integer) data type is used to represent whole numbers. It is one of the fundamental and most commonly used data types in C.

This can also be categorized as

NB: This are size modifiers

NB: This are sign modifiers

“int” stands for INTEGER, in this datatype you can store integer values. Examples 1, 123, 10, etc.

Here are the key characteristics and considerations regarding the int data type:

Size and Range

The size of an int variable is platform-dependent, meaning it can vary based on the system architecture. Commonly, an int is 4 bytes on most modern systems.
The range of values that an int can represent is determined by the number of bits allocated to it. It is from -32768 to 32767 For a 32-bit int, the range is typically from -2,147,483,648 to 2,147,483,647. This range is for signed int, by default int means signed integer, because it permits +ve and -ve signs. But for unsigned int you have to specify it in your program.

Unsigned int permits only +ve sign . So the range is from 0 to 65535.

The memory taken by an int datatype is

2 bytes on a 16 bit machine.
4 bytes on a 32 bit machine.
4 bytes on a 64 bit machine. If you want to find out what machine you are working on you can write this code snippet printf(“%lu”, sizeof(int))

NB: %lu is a format specifier for long integer

Short int —

Suppose you want to store a number like 1, 2, 3, 8, 7, 63 etc. the space allocated will be smaller than that of long int. The space allocated in memory for a short int value is 1 byte.

Long int —

In this case the space allocated will be more than that of short int, because with values like 53782, 1234567, 88107, etc. we will need enough space to store the values in memory. The space allocated in memory for long int is 2 bytes.

How To Know How Many Bits Your Machine Can Store

Suppose your machine is a 2gb RAM machine. To know how many bits your machine can store you can do this:

2 * 1024MB
2 * 1024 * 1024KB
2 * 1024 * 1024 * 1024bytes
2 * 1024 * 1024 * 1024 * 8bits

 On a 2gb RAM machine you can only store 17,179,869,184 bits

Declaration

To declare an int variable, you use the following syntax:

int variable_name;

Initialization

You can initialize an int variable at the time of declaration by using the assignment operator ( = ):

int count = 10;

Operations

int variables support standard arithmetic operations like addition, subtraction, multiplication, and division.

int x = 5;
int y = 3;
int sum = x + y;  // sum is now 8

Formatting for Output

When printing or displaying the value of an int, you can use the %d format specifier in functions like printf:

printf("The value of x is %d\n", x);

Limits

The header file provides constants that represent the limits of various data types. For int, you can use INT_MIN and INT_MAX to get the minimum and maximum values an int can hold.

#include <limits.h>

printf("Minimum value of int: %d\n", INT_MIN);
printf("Maximum value of int: %d\n", INT_MAX);

Modulus Operator

The modulus operator % can be used with int to find the remainder of a division operation:

int remainder = 10 % 3;  // remainder is 1

char-

The char data type is used to represent individual characters. It is one of the fundamental data types and is commonly employed for storing and manipulating characters, such as letters, digits, and special symbols.

Here are the key characteristics and considerations regarding the char data type:

Size

The size of a char variable is always 1 byte / 8bits be it signed char or unsigned char .

By default char is still the same as signed char. This range of signed char is from -128 to 127. The range of unsigned char is from 0 to 255.
The char data type is designed to store a single character from the ASCII character set.

Declaration

To declare a char variable, you use the following syntax:

char character_name;

For Example

char grade;

Initialization

You can initialize a char variable at the time of declaration:

char first_initial = 'A';

Note that character literals are enclosed in single quotes.

ASCII Representation

Each char variable holds a numeric ASCII (American Standard Code for Information Interchange) value that corresponds to a specific character.

For example, the ASCII value for ‘A’ is 65.

Operations

char variables can be used in various operations, including assignment, comparison, and arithmetic operations.

char first_char = 'A';

char second_char = first_char + 1;  // second_char now holds the ASCII value of 'B'

Formatting for Output

When printing or displaying the value of a char, you can use the %c format specifier in functions like printf:

printf("The first initial is %c\n", first_initial);

Character Arrays (Strings)

A sequence of char variables can be used to represent strings (arrays of characters).

char greeting[] = "Hello";

Strings are terminated with a null character (‘\0’), and functions like printf and scanf interpret them accordingly.

Escape Sequences

Special characters, called escape sequences, can be represented using the backslash (). For example, \n represents a newline character.

char newline = '\n';

float-

float data type is used to represent floating-point numbers. Floating-point numbers are numbers that have a decimal point or are expressed in exponential (scientific) notation.

Here are the key characteristics and considerations regarding the float data type:

Size

The size of a float variable is typically 4 bytes on most systems. It may vary depending on the compiler and platform.

The range of a floating number is -3.4e38 to 3.4e38.

Declaration

To declare a float variable, you use the following syntax:

float floating_point_variable;

For Example

float pi;

Initialization

You can initialize a float variable at the time of declaration:

float pi = 3.14159;

Operations

float variables support standard arithmetic operations, including addition, subtraction, multiplication, and division.

float x = 5.0;
float y = 2.5;
float result = x / y;  // result is now 2.0

Formatting for Output

When printing or displaying the value of a float, you can use the %f format specifier in functions like printf:

printf("The value of pi is %f\n", pi);

Precision

float provides single-precision floating-point numbers. Datatype float takes six digits of precisions. It is suitable for a wide range of applications but may have limited precision, especially for very large or very small numbers.
If higher precision is needed, the double data type can be used, which typically provides double-precision floating-point numbers.

float is categorized into

double → 8 bytes
long double → 10 bytes

Scientific Notation

float numbers can be expressed in scientific notation, using the e or E character to represent the exponent.

float scientific_number = 1.23e-4;  // Equivalent to 0.000123

Limits

The header file provides constants that represent the limits of various floating-point data types. For float, you can use FLT_MIN and FLT_MAX to get the minimum and maximum representable values.

#include <float.h>

printf("Minimum value of float: %e\n", FLT_MIN);
printf("Maximum value of float: %e\n", FLT_MAX);

When you code in C, every choice of a data type affects the performance, portability, and correctness of your program. As a software engineer, one of the most powerful tools in your arsenal is a deep understanding of these types and how they interact with the hardware underneath.

If you enjoyed this journey and would like to show your support, here’s how you can:

Buy me a coffee
Follow me on Medium for more insightful content.
Connect with me on X, LinkedIn, and GitHub, where I consistently share valuable programming resources for free.

What’s a Progressive Web App (PWA), Anyway?

Frank — Sat, 28 Sep 2024 03:01:26 +0000

Imagine you love using apps on your phone because they’re fast, easy to access, and work even if you lose internet for a while. But then there are websites that sometimes feel slow, clunky, and don’t work without a connection. What if you could have the best of both worlds? That’s where Progressive Web Apps (PWAs) come in.

A PWA is basically a website that behaves like a mobile app. It's still a website, but it feels faster, can work offline, and even lets you install it on your phone like an app. No need to go through an app store—just open the website, and if it's a PWA, you can save it to your home screen.

Why Should You Care?
Let’s say you’re using a restaurant's website to place an order. Normally, you’d need a good internet connection, and you’d have to wait for pages to load. But with a PWA, the site could load instantly because it’s been cached on your phone. Even if your connection is slow or drops for a bit, you can still browse and use the site!

Alright, let's dive into building a basic Progressive Web App (PWA) from the ground up.

Building Blocks of PWAs: Essential Tools and Technologies
Creating Your Installable Web App
Ensuring Your PWA Works, Even When Offline
How to analyze web performance, accessibility, SEO, etc.
Tips for Boosting App Performance and User Experience

Most of us might have come across PWAs without knowing it . Common examples of some PWAs are Pinterest and Google Map

Websites that displays a computer icon with a downward arrow indicates the site is a PWA, allowing installation for offline access and native app functionality.

Building Blocks of PWAs: Essential Tools and Technologies

To get started with a PWA, you don’t need a fancy toolkit or complex setup—just a few things:

HTML: The structure of your website.
CSS: To make your website look good.
JavaScript: To add interactivity and offline features.
Service Worker: A script that runs in the background, helping with offline functionality.
Manifest File: This is what makes your web app installable.

Creating Your Installable Web App

A PWA lets users install your website on their home screen, so it feels just like an app. The trick? We need to add something called a Web App Manifest.

Step-by-Step Example:

Start with a Basic HTML Page:
This is our website's structure: (index.html):

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <meta name="theme-color" content="#f5a623">
    <title>Burger Hut</title>
    <link rel="stylesheet" href="style.css">
    <link rel="manifest" href="manifest.json"/>
    <link rel="apple-touch-icon" href="images/iconlogo192.png">


</head>
<body>
    <header>
        <div class="logo">
            <img src="images/iconlogo.png" alt="">
        </div>
        <nav>
            <ul class="nav-links">
                <li><a href="#home">Home</a></li>
                <li><a href="#menu">Menu</a></li>
                <li><a href="#order">Order</a></li>
                <li><a href="#locations">Locations</a></li>
                <li><a href="#about">About Us</a></li>
                <li><a href="#contact">Contact</a></li>
            </ul>
        </nav>
        <a href="#order" class="cta-button">Order Online</a>
    </header>


    <!-- Hero Section -->
    <section class="hero">
      <div class="hero-content">
          <h1>The Juiciest Burgers in Town!</h1>
          <p>Crafted with fresh ingredients, served with love.</p>
          <div class="hero-buttons">
              <a href="#order" class="btn-primary">Order Now</a>
              <a href="#menu" class="btn-secondary">See Menu</a>
          </div>
      </div>
  </section>
  <script src="script.js"></script>
</body>
</html>

Create a Manifest File (manifest.json): This file gives your PWA its metadata like name, icon, and more:


{
  "name" : "Burger Hut App",
  "short_name" : "Burger Hut",
  "start_url" : "./",
  "background_color" : "black",
  "theme_color" : "#f5a623",
  "display" : "standalone",
  "icons" : [
      {
        "src" : "images/iconlogo192.png",
        "sizes" : "192x192",
        "type" : "image/png"
      },

      {
        "src" : "images/iconlogo512.png",
        "sizes" : "512x512",
        "type" : "image/png"
      }
  ]
}

CSS Styles (styles.css): Now let’s add some simple CSS to give our app a clean and professional look.

* {
  margin: 0;
  padding: 0;
  box-sizing: border-box;
}

/* Global styles */
body {
  font-family: 'Arial', sans-serif;
  background-color: #0a0a0a;
  color: #f4f4f4;
  margin: 0;
}

header {
  display: flex;
  justify-content: space-between;
  align-items: center;
  padding: 20px;
  background-color: #0a0a0a;
  box-shadow: 0 2px 10px rgba(0, 0, 0, 0.5);
}

.logo img {
  height: 80px;
}

nav {
  flex-grow: 1;
  margin-left: 50px;
}

.nav-links {
  display: flex;
  list-style: none;
  justify-content: space-evenly;
}

.nav-links li {
  margin-left: 20px;
}

.nav-links a {
  text-decoration: none;
  color: #f4f4f4;
  font-size: 18px;
  transition: color 0.3s ease;
}

.nav-links a:hover {
  color: #f5a623;
}

.cta-button {
  padding: 10px 20px;
  background-color: #f5a623;
  color: #181818;
  text-decoration: none;
  border-radius: 25px;
  font-weight: bold;
  transition: background-color 0.3s ease;
}

.cta-button:hover {
  background-color: #ffbf47;
}


/* Hero Section */
.hero {
    height: 100vh;
    background: url('images/hero-background1.jpg') no-repeat center center/cover;
    position: relative;
    display: flex;
    justify-content: space-between;
    align-items: center;
    padding-left: 45px;
    /*text-align: center;*/
}

.hero::before {
    content: "";
    position: absolute;
    top: 0;
    left: 0;
    right: 0;
    bottom: 0;
    background-color: rgba(0, 0, 0, 0.6); /* Dark overlay */
}

.hero-content {
  max-width: 650px;
    position: relative;
    z-index: 1;
    color: #f4f4f4;
}

.hero h1 {
    font-size: 50px;
    font-weight: bold;
    color: #f5a623;
    text-transform: uppercase;
    letter-spacing: 2px;
}

.hero p {
    font-size: 20px;
    margin: 20px 0;
    color: #f4f4f4;
}

.hero-buttons {
    margin-top: 30px;
}

.hero-buttons a {
    padding: 15px 30px;
    margin: 0 10px;
    border-radius: 30px;
    text-decoration: none;
    font-weight: bold;
    text-transform: uppercase;
    transition: background-color 0.3s ease;
}

/* Primary button */
.btn-primary {
    background-color: #f5a623;
    color: #181818;
}

.btn-primary:hover {
    background-color: #ffbf47;
}

/* Secondary button */
.btn-secondary {
    background-color: transparent;
    border: 2px solid #f5a623;
    color: #f5a623;
}

.btn-secondary:hover {
    background-color: #f5a623;
    color: #181818;
}

Ensuring Your PWA Works, Even When Offline

How to Implement Offline Functionality in PWAs**

Now, let’s make sure our app works even if the user is offline. We’ll add a Service Worker. It’s a little JavaScript file that tells the browser to cache assets (HTML, CSS, JS, etc.), so when there’s no internet, the site still loads.

Service Worker:

JavaScript for Registering the Service Worker (`script.js`):

if ("serviceWorker" in navigator)  {
  navigator.serviceWorker.register("sw.js").then(registration => {
      console.log("SW Registered!")
      console.log(registration);
  }).catch(error => {
    console.log("SW Registration Failed!");
    console.log(error);
  })
}

Service Worker Script (`sw.js`):

This script caches files and serves them when the user is offline:

self.addEventListener("install", e => {
  e.waitUntil(
    caches.open("static").then(cache => {
      return cache.addAll(["./", "style.css", "images/iconlogo192.png"]);
    })
  );
});

self.addEventListener("fetch", e => {
  e.respondWith(
    caches.match(e.request).then(response => {
      return response || fetch(e.request)
    })
  )
});

Incredible 👏, you did it, you've turned your website to a progressive web app.
Go ahead and click the install icon and then install. You should see something like this this:

Now our web app is installed on our computer and can be accessed offline, you can also pin it to the taskbar if you want.

The service worker handles file caching and offline functionality you can check this on the web browser using the inspect tool.

How to analyze web performance, accessibility, SEO, etc.

Once your app is running, it’s important to check if it’s fast, accessible, and SEO-friendly. The easiest way to do this is by using Lighthouse, a tool built into Chrome.

How to Run Lighthouse:

Open your site in Chrome.
Right-click, choose Inspect, and go to the Lighthouse tab.
Click “Generate Report.” It’ll give you insights on performance, accessibility, SEO, and more.

Tips for Boosting App Performance And User Experience

To make sure your PWA is fast and feels like a native app, follow these tips:

Minify your CSS and JavaScript: Use tools like UglifyJS for JavaScript and CSSNano for CSS to remove unnecessary code and reduce file sizes.
Optimize Images: Compress images using tools like TinyPNG. This reduces load time, especially on mobile networks.
Lazy Loading: Only load images or content when they’re visible on the screen. This speeds up the initial load.
Cache Important Assets: Use the service worker to cache JavaScript, CSS, and images so that the app loads quickly.
Responsive Design: Make sure your app looks good on all screen sizes using media queries in CSS.

You’ve made it to the end and gotten smarter by learning about PWAs. Now, try practicing what you’ve learned. Good luck!

If you enjoyed this journey and would like to show your support, here’s how you can:

Buy me a coffee
Follow me on Medium for more insightful content.
Connect with me on X, LinkedIn, and GitHub, where I consistently share valuable programming resources for free.