From JavaScript Syntax to Solving Real Problems
Learn why becoming a backend developer starts with understanding problems—not memorizing frameworks—and how beginner JavaScript knowledge can already be used to design meaningful software.

From JavaScript Syntax to Solving Real Problems
Backend Development Series
This article is Update 1 of our step-by-step Backend Development series.
← View the Backend Development Series · Continue to Update 2 →
When many people begin learning JavaScript, they naturally focus on syntax.
They learn things such as:
- Variables
- Functions
- Arrays
- Objects
- Loops
- Conditions
All of these concepts are important.
But knowing JavaScript syntax alone does not automatically mean you know how to build useful software.
There is another skill that matters just as much:
Learning how to identify a real problem, break it down, and use technology to solve it.
That is where software development really begins.
Programming Is a Tool, Not the Final Goal
A programming language is simply one of the tools available to a developer.
JavaScript is a tool.
Node.js is a tool.
Express is a tool.
PostgreSQL is a tool.
Prisma is a tool.
The real question is not:
"Which technology should I learn?"
The better question is:
"What problem am I trying to solve, and which tools can help me solve it?"
That small change in thinking can completely change how you approach programming.
Instead of learning technologies without context, every technology begins to have a reason for existing.
The Real-World Problem
For our Backend Development journey at GREE Software Academy, we started with a simple community problem.
Imagine a local community that relies mainly on:
- WhatsApp groups
- Social media posts
- Community group chats
- Word of mouth
- Personal messages
to distribute important information.
That information may include:
- Community announcements
- Educational information
- Scholarship opportunities
- Job opportunities
- Events
- Articles
At first, this method appears convenient.
Most people already have WhatsApp.
Most people already use social media.
Sharing a message only takes a few seconds.
But over time, problems begin to appear.
Problem 1 — Important Information Gets Buried
Imagine that someone posts an important scholarship opportunity inside a WhatsApp group.
Within the next few hours, people begin sending:
- Greetings
- Stickers
- Memes
- Questions
- unrelated discussions
- Voice notes
The scholarship announcement gradually moves higher and higher in the conversation.
A few days later, someone asks:
"Where was that scholarship information posted?"
Now they may have to scroll through hundreds of messages.
That is not an efficient information system.
Problem 2 — People Can Easily Miss Updates
Suppose someone was offline when an important announcement was posted.
By the time they return, dozens of other messages may have appeared.
The announcement may never even be noticed.
This means the availability of important information depends too much on:
textWas the person online?
Did they open the group?
Did they scroll far enough?
Did they notice the message?A more reliable system should allow people to find important information whenever they need it.
Problem 3 — Information Becomes Scattered
Imagine the community uses:
textWhatsApp Group A
WhatsApp Group B
Facebook Page
Instagram
Telegram
Personal Messages
Word of MouthDifferent information begins appearing in different places.
Someone looking for an old announcement may not even remember where it was originally posted.
This creates another problem:
There is no single reliable place where important community information can be found.
Asking the Right Question
At this point, we could immediately begin asking technical questions such as:
- Should we use Node.js?
- Should we use Express?
- Should we use PostgreSQL?
- Should we use Prisma?
- Should we use React?
- Should we use Next.js?
But those questions come later.
The first question should be:
How can technology improve the way this community shares and retrieves important information?
That question leads us toward the actual solution.
The Proposed Solution
We can create a central digital information platform.
Instead of depending completely on social media and messaging applications, the community can have a website where important information is permanently organized.
Community members could visit one place to find:
- Announcements
- Articles
- Opportunities
- Events
- Educational content
- Important notices
The information would no longer disappear underneath unrelated conversations.
It would remain available until it was intentionally archived or removed.
But Now We Have More Questions
Once we propose a central platform, we immediately discover more questions.
For example:
- Who is allowed to publish information?
- Can everyone create a Post?
- Who can edit Posts?
- Who can remove Posts?
- Should deleted Posts disappear permanently?
- Can Posts contain images?
These are software design questions.
And this is where backend development begins to become interesting.
Defining the Users
We decided that not everyone should have the same permissions.
Our initial system contains three types of Users.
Community Admin
The Community Admin has the highest level of control.
They may be allowed to:
- Create Posts
- Edit Posts
- Publish Posts
- Archive Posts
- Manage important information
Verified Journalist
A Verified Journalist may be trusted to contribute information.
They may be allowed to:
- Create Posts
- Edit their Posts
- Submit useful information
But they may not have all administrative permissions.
Community Member
A normal Community Member mainly consumes information.
They may be allowed to:
- Browse Posts
- Read articles
- View announcements
- Access opportunities
- Read important community information
Why Roles Matter
Imagine if every person visiting the website could publish anything they wanted.
The platform would eventually become another noisy information source.
We would have solved one problem only to create another.
That gives us our first important software rule:
Different types of Users may need different permissions.
We will later implement this idea properly using:
textAuthentication
+
Authorization
+
Role-Based AccessBut we do not need to implement everything today.
First, we understand why the requirement exists.
What Makes Something a Post?
The next question is:
What information should a Post actually contain?
Our initial Post may contain:
- Title
- Short description
- Main content
- Author
- Featured image
- Image description
This gives us a rough picture of the information our backend will eventually need to manage.
What Makes Someone a User?
A User may contain:
- First name
- Last name
- Username
- Email
- Phone number
- Password
Later, we will improve some of these decisions.
For example, instead of storing:
textpassworddirectly, our database will eventually store something like:
textpasswordHashbecause real applications should not store plain-text passwords.
Notice What We Have Done
We have not written any backend code yet.
But we already know a surprising amount about the application.
We know:
textThe Problem
↓
Scattered community informationWe know:
textThe Solution
↓
A central information platformWe know:
textMain Resources
↓
Users
PostsWe know:
textUser Types
↓
Community Admin
Verified Journalist
Community MemberWe know:
textMain Actions
↓
Create
Read
Edit
Publish
ArchiveThis is already software design.
Why This Matters for Beginners
One common mistake when learning programming is believing that development begins with code.
It does not.
Development often begins with questions.
A good developer asks:
- What is happening currently?
- What is wrong with the current process?
- Who is affected?
- What information is involved?
- What should the new system improve?
- Who should be allowed to perform certain actions?
Once these questions are answered, the code becomes easier to reason about.
You Do Not Need to Know Everything Before Starting
You may currently know only:
textVariables
Functions
Arrays
Objects
Conditions
LoopsThat is okay.
Those concepts can already be combined into useful applications.
For example, you may know how to create an object:
jsconst user = {
name: "Ama",
role: "COMMUNITY_ADMIN",
};You may know conditions:
jsif (user.role === "COMMUNITY_ADMIN") {
console.log("User has administrative access");
}Later, the same basic ideas can become part of a real authorization system.
The individual concepts remain understandable.
The real skill is learning how to combine them to solve larger problems.
Our Development Principle
Throughout this Backend Development series, we will follow one important rule:
textEncounter a Problem
↓
Understand the Problem
↓
Introduce a Solution
↓
Understand the Solution
↓
We will not create ten folders simply because professional projects have ten folders.
We will create each folder when we understand the problem it solves.
We will not install a database simply because backend tutorials use databases.
We will first experience the limitation of temporary data.
Then the database will make sense.
What We Are Going to Build
Our learning project will gradually grow into a backend capable of handling concepts such as:
- Users
- Posts
- HTTP requests
- REST APIs
- CRUD operations
- Routes
But we will introduce them gradually.
One problem at a time.
Main Lesson
The most important lesson from this first stage is simple:
Programming is a means, not the end.
Knowing JavaScript is valuable.
But knowing how to identify and solve problems is what turns JavaScript knowledge into software development ability.
The journey should look like this:
textReal Problem
↓
Understand It
↓
Break It Down
↓
Design a Solution
↓
That is the mindset we will carry throughout this entire backend series.
What's Next?
Now that we understand the problem we are solving, the next step is to create the actual backend project.
In Backend Development Update #2, we will start from an empty folder and learn how to create a modern Node.js backend project using JavaScript.
We will understand:
- What
package.jsonis - Why we need a
srcfolder - Why we use
.gitignore - Why
We are starting small.
But every step will have a reason.
GREE Software Academy
At GREE Software Academy, our goal is not simply to teach learners how to copy code.
We want learners to understand:
Why does this code exist?
What problem does it solve?
Why was this technology introduced?
Because when you understand the reasoning behind the code, you can build far beyond the tutorial you started with.
Understand the problem.
Learn the concept.
Build the solution.
Then improve it.
Continue Learning
You have completed Update 1 — From JavaScript Syntax to Solving Real Problems.
Next
Update 2 — Setting Up Your First Modern Node.js Backend Project →
Learn how to create the Node.js project itself and understand package.json, src/, .gitignore, ES Modules and the foundation of our backend structure.
← Back to the Series Overview
Browse All GREE Software Company Updates

