DEV Community: Emeka Ugbanu - Software Developer

The Psychology Behind Great Software

Emeka Ugbanu - Software Developer — Mon, 13 Jul 2026 14:00:00 +0000

The tech industry has evolved far beyond simply writing code.

Programming is still incredibly valuable, but building successful software today requires much more than algorithms and clean architecture.

It requires understanding human behavior, emotions, habits, motivations, and decision-making.

That's where psychology comes in.

The best products don't just solve technical problems. They understand the people using them.

Understanding the Human Element

Building great software isn't just about making something work.

It's about understanding the people you're building it for.

What frustrates them?

How do they think?

What motivates them?

What makes them hesitate?

The more you understand your users, the easier it becomes to build software that feels natural instead of confusing.

Great products don't force people to adapt.

They adapt to people.

Psychology Principles Used in Great Software

Hick’s Law (Fewer Choices = Faster Decisions): Hick's Law mathematically proves that human brains take logarithmically longer to make a choice for every option you throw at them. It’s why huge restaurant menus make people nervous, but streamlined ones feel premium. Take the Google Search Homepage for example, Google indexes billions of web pages (the ultimate backend complexity), but the UI gives you exactly one choice: type what you want. It is the perfect visual representation of hiding options

2.Jakob’s Law (Users Expect Familiar Interfaces): Jakob's Law states that since your users spend 99% of their time on other apps, they expect your app to work exactly like those ones do. If you try to innovate by changing standard navigation layouts, you don’t look creative you just confuse people. The Bottom Navigation Bar in Instagram, Twitter/X, or Threads is an example Almost every major consumer social app puts the home icon on the far left and the profile on the far right. Because they don't break the "Mental Model," a user opening your app for the first time instantly knows how to move around without a tutorial

3.Progressive Disclosure : Our brain's working memory can only handle a limited amount of information at once before it bugs out. Progressive disclosure is the art of sequencing information over time so you never choke the user with too much data. An example is the Duolingo Onboarding or Uber/Bolt Checkout Flow. Imagine if Uber put the destination input, maps, 8 vehicle types, driver details, and credit card forms all on one single screen. It would look like a chaotic airplane dashboard. By breaking it into steps, they reduce mental friction.

4.The Peak-End Rule : Humans don’t remember the average of an experience. We only remember two things: the absolute most intense emotional point (the Peak) and the very final moment (the End). If your app is slightly slow but ends with a burst of pure satisfaction, users will remember it as a great app. An example is Asana (The Celebration Unicorn) or Duolingo (Lesson Completed Streak). Project management is boring, repetitive work. But by engineering a sudden, delightful "Peak" animation right when you finish a task, Asana turns a mundane moment into a dopamine hit that makes the software memorable.

5.Aesthetic-Usability Effect : This principle describes a tendency for users to perceive attractive products as being more usable. A visually pleasing interface builds trust and credibility, making users more tolerant of minor usability issues. While aesthetics cannot replace fundamental usability, a polished design can significantly enhance the overall user experience.

Psychology Isn't Only for Users

The best companies understand that psychology doesn't stop with the customer it also affects the people building the product. Healthy engineering teams communicate better, Good product discussions reduce stress and Clear design systems reduce decision fatigue. Understanding human behavior makes better software and healthier teams.

The Dark Side of Psychology in Software

while discussing the good and great side of applying Psychological principles to improve life and quality of both our users and software let's not forget that there's also a dark side. Software companies realized that the more time you spend in their app, the more ad revenue they make or the more data they collect. They stopped using psychology to make life simpler and started using it to make life addictive.

Dark Psychology Patterns in Software

The Variable Reward / Slot Machine Effect :In psychology, a "variable reward schedule" is the most addictive reinforcement model. If an action gives you a reward sometimes but not always, your brain goes crazy wanting to repeat it. It’s the exact science behind casino slot machines. An example is the The Infinite Scroll & Pull-to-Refresh. here is no "end" button. Pulling down to refresh feels exactly like pulling the lever on a slot machine—you don't know if the next piece of content will be boring or a massive hit of dopamine. This keeps users scrolling for hours, destroying their focus.
Artificial Urgency & Fomo : Humans are naturally terrified of losing out on something more than they are excited to gain something (Loss Aversion). An example is Booking sites or E-commerce apps saying "Only 1 room left at this price!" or "37 people are looking at this right now!". Often, these numbers are entirely fabricated or exaggerated by code. The software uses psychological panic to force you into making a fast financial decision before you can rationally think it through.

Conclusion

As developers, designers, and founders, we have a choice.We can use psychology to hook users, drain their time, and spike their anxiety for profit. Or, we can use psychology for good—to respect human attention, lower cognitive load, and make software feel effortless so users can get back to living their lives

This is exactly why I'm building StepMello. Many walking and fitness apps rely heavily on streaks, constant notifications, and fear of breaking progress. With StepMello, my goal is different. I want a distraction-free experience that encourages people to slow down, reflect, and turn an ordinary walk into a meaningful memory not another digital obligation

That's all for now.
you can follow me here on dev.to for more and on twitter @EmekaUgbanu.

Good Software Feels Simple But Isn’t

Emeka Ugbanu - Software Developer — Sat, 11 Jul 2026 13:00:00 +0000

We've all been there, especially as developers or first-time founders.

We keep adding one more feature, one more screen, one more setting, or one more animation because we believe more equals better.

It feels productive.

It feels like progress.

But most of the time, we're only making our software more complicated.

The best software rarely feels impressive because of how much it can do.

It feels impressive because of how much it understands the users and lets them accomplish what they came to do with as little effort as possible.

What Do I Mean by "Simple"?

When we say software is Simple it doesn't mean easy to build.
It means software that is natural and make the users feel like the product understands them.

That's what makes software feel effortless.

Ironically, creating that experience usually requires more engineering, not less.

Making a single-button interface feel effortless often requires complex logic behind the scenes to handle edge cases, recover from errors, synchronize data, and keep the experience reliable

Simplicity Starts Before You Write Code

We think simplicity comes from clean code.

I think it starts much earlier.

It starts with understanding your users.

How do they think?

What are they trying to accomplish?

What frustrates them today?

The more you understand those answers, the fewer features you'll need because you'll be solving the right problem instead of every possible problem.

Architecture, user flows, and even the technologies you choose become much easier once you truly understand who you're building for.

Avoiding Feature Creep

One of the biggest mistakes I see is feature creep.

We assume our competitors have more features, so we need more features too.

Or we think users will love having more options.

In reality, every new feature comes with a cost.

It adds more decisions.

More maintenance.

More testing.

Great Software Removes Decisions

One thing I've learned while building products is that users rarely want more choices.

They want fewer decisions.

Every unnecessary button, modal, animation, or setting increases the effort required to use your product.

Good software doesn't make users think.

It helps them stop thinking about the interface so they can focus on what they came to accomplish.

Conclusion

It's easy to blame slow growth on missing features because features are visible.

But before adding another one, ask yourself:

Do I truly understand my users?
Am I solving a real problem?
Does this make the product simpler or more complicated?

Sometimes the best feature you'll ever build is the one you decide not to build.

💭 This is just my perspective after building products and making plenty of mistakes along the way.

That's all for now.
you can follow me here on dev.to for more and on twitter @emekaugbanu

I’m building StepMello, a reflective walking app that helps you slow down, capture moments, and turn everyday walks into meaningful memories. If that sounds interesting, I’d love your feedback

Writing Code Was Never the Hard Part

Emeka Ugbanu - Software Developer — Fri, 10 Jul 2026 14:00:00 +0000

it’s no secret that AI models are getting better at writing code. Since the release of ChatGPT, the progress has been incredible, and every few months they seem to become even more capable.

A lot of developers have tied their identity to writing code, and I understand why. It’s the most visible part of what we do.

But I want to offer a different perspective.

In my experience, writing code was never the hardest part of software engineering.

What Do I Mean by That?

Before AI, the hardest part of my job wasn’t typing code into an editor.

It was spending hours researching a problem, reading documentation, comparing Stack Overflow answers, testing different approaches, and figuring out why one solution was better than another.

Once I understood the solution and had proven it in a small test project, writing the actual code was usually the tiring part.

The next challenge was making sure that solution would scale. Could another developer understand it six months later? Was it easy to change? Was there a simpler approach? Was I solving the right problem in the first place?

Those questions have always been more difficult than writing the implementation.

If anything, writing code was often the repetitive part that many developers wished could be automated.

Should We Be Worried About LLMs and Job Security?

Personally, I don’t think we should panic.

Instead, we should appreciate that AI can remove some of the repetitive work and give us more time to focus on what really matters: understanding users, designing better systems, and building better products.

Being a software engineer has never been just about writing code quickly.

It’s about making good technical decisions, communicating with teammates, understanding trade-offs, debugging complex problems, thinking about maintainability, and taking responsibility for what you build.

Those responsibilities don’t disappear because an AI can generate code.

How I Think We Should Use LLMs

AI writing your code doesn’t mean you should skip the engineering process.

The process is still the valuable part.

Today, I think the ideal workflow is AI-assisted development, not blind vibe coding.

Think through your architecture first.

Choose technologies that actually fit your goals.

Have coding standards and patterns that you want your project to follow.

Then let AI generate an implementation.

After that, review it, refactor it, improve it, and repeat the process.

Think → Generate → Review → Refactor → Repeat.

You don’t always need the most powerful model either. Even smaller modern open-source models can be incredibly capable when you give them clear context and precise instructions.

Large frontier models certainly have advantages, but good engineering still matters more than model size.

Vibe coding often relies on vague prompts and hopes the AI gets everything right.

As developers, we shouldn’t aim to simply make something work.

We should aim to understand the solution, own the architecture, and make the code easy to change in the future.

Man vs. Machine?

It sounds like the plot of a movie: Man vs. Machine.

I don’t think that’s the right way to look at it.

The best use of AI isn’t replacing humans.

It’s enhancing humans.

AI should automate repetitive work so that people can spend more time thinking, designing, creating, and solving problems.

Think about the Mona Lisa.

Even if a robot could produce a visually identical painting, most people wouldn’t value it the same way as Leonardo da Vinci’s original.

Not because the robot lacked technical ability, but because the human work represents creativity, intention, emotion, countless decisions, and the story behind its creation.

Humans are valuable for much more than the output they produce.

Conclusion

Rather than fighting AI or letting it think for us, I think we should focus on integrating it into our workflow in a thoughtful way.

Let AI handle the repetitive parts.

Use the extra time to think more deeply, design better systems, understand users, and create better solutions.

That’s where real value has always come from.

The tools have changed.

The responsibility of building great software hasn’t.

💭 This is just my perspective.
Or maybe I've simply reached the final stage of grief: acceptance.

That's all for now.
you can follow me here on dev.to for more and on twitter @EmekaUgbanu

I’m building StepMello, a reflective walking app that helps you slow down, capture moments, and turn everyday walks into meaningful memories.
If that sounds interesting, I’d love your feedback.

👉 StepMello: https://stepmello.com

How to store form data to Google Sheets Using ReactJS,GatsbyJS or NextJS

Emeka Ugbanu - Software Developer — Wed, 02 Mar 2022 11:11:30 +0000

I wrote about this because I was having an issue with storing users’ form data on Google Sheets in Gatsby. I saw it being done from the backend but I wanted to implement it on the frontend with little stress but it was giving me a headache so here is the ultimate solution that saved the day.

How the solution works

The main idea of the solution was to make ReactJS, NextJS, or in this case, GatsbyJS POST form data to Google Sheets like REST APIs.

First, Initialize Your Workspace

here is documentation on how to set up your projects in ReactJS, GatsbyJS, and NextJS

ReactJS - https://reactjs.org/docs/create-a-new-react-app.html

GatsbyJS - https://www.gatsbyjs.com/docs/tutorial/part-1/

NextJS - https://nextjs.org/docs/getting-started

But in this case, I would use GatsbyJS, If you had set up the project correctly in GatsbyJS, you would see the screen below

Create Your Form

Well, now it’s time to create your form. I would use Material-UI for creating the form and Formik and Yup for handling and validating the form.

You can read more on the technology stack mentioned above:

Material-UI - https://mui.com

Formik - https://formik.org/docs/overview

Yup - https://formik.org/docs/guides/validation

But you can create it with any technology stack of your choice.

How to Post the data to Google Sheets

TO post our form data to Google Sheets will be using Stein. Stein is an open-source program to help you turn any Google Sheet into a database. And let you POST data to Google Sheets.

we also need to install the stein-js-client. Its a JavaScript client library to interact with the Stein API.

Go over to Google Sheets and open a new Spreadsheet by clicking File, then New, and then Spreadsheet.

Name the sheet to name of your choice and save.

Click the share button on the top right of your screen, and edit the permission to public.

Copy the link and go to https://steinhq.com and create your free account.

Click on Create API. You'll be redirected to your details page. Here, you can see you sheet url and API url. Click on copy on API URL. This URL will be used as the endpoint for sending Requests.

Now, let's install stein-js-client. Type npm install stein-js-client in your terminal to install the package.

After it has been installed, import it at the top of your file. We will make the POST Request in the submitHandler function.

import React from "react";
import SteinStore from "stein-js-client";
 const store = new SteinStore("url");

submitHandler = () => {
   store
  .append("Sheet1", [
    {
      title: "Awesome article",
      author: "Me!",
      content: "A brief summary",
      link: "blog.me.com/awesome-article"
    }
  ])
  .then(res => {
    console.log(res);
  });
    })
  }

Replace the submitHandler function with the code above. Here, we are using stein-js-client to post the data to the URL and get back the response in the console using the .then keyword.

Paste the copied API URL endpoint from stein and replace it with the URL in new SteinStore("url").

import React from "react";
import SteinStore from "stein-js-client";
 const store = new SteinStore("https://api.steinhq.com/v1/storages/61eea0ad8d29ba237915e07d");

submitHandler = () => {
   store
  .append("Sheet1", [
    {
      title: "Awesome article",
      author: "Me!",
      content: "A brief summary",
      link: "blog.me.com/awesome-article"
    }
  ])
  .then(res => {
    console.log(res);
  });
    })
  }

Now, open up Google Sheets and fill up the first columns, that is name, age, salary, and hobby. Please fill them out carefully, or else it will not work. It should be case sensitive.

Now, run your React app and fill in the input fields. You'll see that the data is getting populated into your Google Sheets.

Now instead of the default values used here pass the values gotten from the form

submitHandler = () => {
   store
  .append("Sheet1", [
    {
      title: values.title,
      author: values.author,
      content: values.content,
      link: values.link,
    }
  ])
  .then(res => {
    console.log(res);
  });
    })
  }

Now You get this

You can read more on stein
features:https://docs.steinhq.com/introduction

That's all for now. Now you know how How to store form data to Google Sheets Using ReactJS,GatsbyJS or NextJS application.

you can follow me here on dev.to for more and on twitter @EmekaUgbanu_ and also thanks to @PaulieScanlon for offering me help in using Gatsby Serverless Functions with Google Sheets. You can know about that here.