How to Think Like a Programmer#

The biggest problem people face with programming is that they watch too many tutorials. Don’t get me wrong — tutorials aren’t bad. But what happens is you copy and paste code, and at the end of the day you’ve learned nothing about how to structure or write something on your own.

I struggled with this myself. I learned GDScript from tutorials. I even learned how to make games in Godot. But when it was time to write code alone, I froze. I couldn’t structure anything. I didn’t understand why I needed multiple functions instead of one big block. I could write small fragments, but I didn’t truly understand what was behind all of it.

If you struggle like I did — let me show you how I figured it out.

It turns out there are really only two pillars to programming mastery:

Thinking in Code — translating concepts into executable logic
Writing Clean Code — structuring code for clarity and maintainability

Learn these two things and you can build anything. So let’s get into it.

Pillar 1: Thinking in Code#

The Translation Problem#

You understand “player damages enemy” as a concept. But how does that become code?

The trick is realizing that every programming language has more or less the same structure. The differences are mostly syntax. If you move from something like Python to C++, you get more features — but you can structure your code the same way with a few adjustments.

IMPORTANT
First of all, you always — and I mean always — need to break code down to simple pseudocode. What does an if-statement actually do? What about a function? A for-loop? Here’s how I think about them:

1
if (something is true) → then do this; else do that

1
function (input/settings)
2
{
3
    code that does something with your input
4
    and produces an output or changes some state
5
}

1
for (repeat until this condition is met)
2
{
3
    code that runs a fixed number of times
4
}

1
while (this statement is true)
2
{
3
    code that runs endlessly until the condition becomes false
4
}

CAUTION
Please do NOT make a while(true) loop unless you know what you’re doing — it can easily crash your computer.

Logical Operators#

and, or, and not are essential. Let me demonstrate:

if this AND that → both must be true for the whole condition to be true
if this OR that → only one needs to be true
if NOT this → reverses the statement. If it’s false, it becomes true. Think of it as a flipper.

For example, if FireRateLimited is a boolean that’s true when you can’t shoot, you want to shoot when it’s not limited:

1
while(!FireRateLimited)
2
{
3
    shoot()
4
}

You can stack conditions:

1
while(!FireRateLimited and !MagazineEmpty)
2
{
3
    shoot()
4
}

1
while(!FireRateLimited and !MagazineEmpty and Input.is_action_just_pressed("Shoot"))
2
{
3
    shoot()
4
}

And so on. Once you internalize this, you have enough to build almost anything.

The Mental Model#

Thinking in code means breaking down real-world concepts into five elements:

Entities (nouns) — What objects exist? → Player, Enemy
Properties (adjectives) — What describes them? → health, damage_value, is_alive
Actions (verbs) — What can happen? → attack(), take_damage(), die()
State Changes — How does the system evolve? → Enemy.health -= damage
Conditions — When do things happen? → if enemy.health <= 0

For any concept you want to code, ask yourself:

What are the nouns? → Classes/Objects
What are the verbs? → Methods/Functions
What are the relationships? → How objects interact
What is the state? → What changes over time
What is the flow? → Order of operations

Example: “Player Damages Enemy”#

Let’s break it down:

Who are the actors? → Player, Enemy
What’s the action? → Dealing damage
What changes? → Enemy’s health
What follows? → Check if enemy dies

We need two files — one for the Hero, one for the Enemy.

Hero logic:

1
if (hero detects an enemy in range AND hero presses attack)
2
    then call Enemy.Damaged(10)

Enemy logic:

1
int Health = 100
2

3
function Damaged(int damage)
4
{
5
    Health -= damage
6
}

That’s it. Now you just need to research how to apply this in your specific engine or language.

Here’s how it looks in Godot:

1
Main Scene
2
├── Player
3
│   ├── Sprite2D
4
│   └── RayCast2D
5
└── Enemy
6
    ├── Sprite2D
7
    └── Collision2D

Player.gd

1
@onready var ray_cast_2d: RayCast2D = $RayCast2D
2

3
func _process(delta: float) -> void:
4
    if ray_cast_2d.is_colliding():
5
        var hit = ray_cast_2d.get_collider()
6
        hit.on_hit_by_raycast(10)

Enemy.gd

1
var health := 100
2

3
func on_hit_by_raycast(damage: int) -> void:
4
    health -= damage

Concept → pseudocode → real code. Every time.

More Examples#

”Car Accelerates on a Highway”#

Nouns: Car, Highway. Verbs: accelerate. Properties: speed, max_speed, position. Condition: can’t exceed max_speed.

1
class Car:
2
    def __init__(self):
3
        self.speed = 0
4
        self.max_speed = 120
5

6
    def accelerate(self, amount):
7
        self.speed = min(self.speed + amount, self.max_speed)

”Trading Bot Buys When Price Drops Below Threshold”#

Nouns: TradingBot, Order, Price. Verbs: monitor, execute. Condition: price < threshold AND not already in a position.

1
class TradingBot:
2
    def __init__(self, threshold):
3
        self.threshold = threshold
4
        self.in_position = False
5

6
    def on_price_update(self, current_price):
7
        if current_price < self.threshold and not self.in_position:
8
            self.execute_buy(current_price)
9

10
    def execute_buy(self, price):
11
        # execute order logic
12
        self.in_position = True

”Inventory Removes Item When Player Uses It”#

Nouns: Inventory, Item, Player. Verbs: use, remove, apply_effect. Flow: use item → apply effect → remove from inventory.

1
class Inventory:
2
    def __init__(self):
3
        self.items = {}
4

5
    def use_item(self, item_name, player):
6
        if self.items.get(item_name, 0) <= 0:
7
            return False
8
        item = get_item_definition(item_name)
9
        item.apply_effect(player)
10
        self.items[item_name] -= 1
11
        if self.items[item_name] <= 0:
12
            del self.items[item_name]
13
        return True

Same pattern every time. Nouns, verbs, state, conditions, flow.

Pillar 2: Writing Clean Code#

Thinking in code gets you working software. Writing clean code makes it maintainable software. Here’s the core principle:

IMPORTANT
Every function should do ONE thing, and its name should accurately describe that one thing.

The Problem: Hidden Responsibilities#

1
# BAD — this function does TWO things
2
def check_password(password):
3
    if password == stored_password:
4
        initialize_session()  # surprise side effect!
5
        return True
6
    return False

The name says “check” but it also initializes a session. You can’t reuse the check without triggering the session. You can’t test them independently.

1
# GOOD — each function does ONE thing
2
def check_password(password):
3
    return password == stored_password
4

5
def initialize_session():
6
    # session logic here
7
    pass
8

9
# Usage
10
if check_password(user_input):
11
    initialize_session()

The 10 Principles of Clean Code#

0. Naming Reveals Intent#

Function names are verbs: calculate_damage(), validate_input(), spawn_enemy(). Variable names are descriptive: enemy_health not eh, player_position not pp. If a name requires a comment to explain, the name is wrong.

1
# BAD
2
def calc(a, b):
3
    return a * b * 0.75
4

5
# GOOD
6
def calculate_discounted_price(original_price, quantity):
7
    DISCOUNT_RATE = 0.75
8
    return original_price * quantity * DISCOUNT_RATE

1. Small Functions#

If you can’t see the entire function on your screen, it’s probably too long. Aim for 10–20 lines max.

1
# BAD — god function doing everything
2
def process_game_turn():
3
    # 80 lines of player input, enemy AI, physics, rendering, scoring...
4

5
# GOOD — orchestrate focused functions
6
def process_game_turn():
7
    handle_player_input()
8
    update_enemy_ai()
9
    check_collisions()
10
    render_frame()
11
    update_score()

2. Functions Do One Thing#

If you need the word “and” to describe what a function does, it does too much. “Check password and initialize session” → split it.

3. Consistent Levels of Abstraction#

High-level functions call mid-level functions. Mid-level calls low-level. Don’t mix raw database queries with business logic in the same function.

1
# BAD — mixed abstraction
2
def process_payment(order):
3
    total = order.total
4
    if order.user.credit_card[0:4] == "4532":
5
        charge_visa(total)
6
    db.execute("UPDATE orders SET status='paid' WHERE id=?", order.id)
7

8
# GOOD — each level reads clearly
9
def process_payment(order):
10
    validate_payment_method(order)
11
    charge_customer(order)
12
    mark_order_as_paid(order)

4. Avoid Repeated Switch Statements#

If you’re writing the same if/elif chain in multiple places, use polymorphism or data structures instead.

1
# BAD — duplicated logic
2
def calculate_damage(weapon_type, base_damage):
3
    if weapon_type == "sword": return base_damage * 1.2
4
    elif weapon_type == "bow": return base_damage * 0.8
5

6
def get_attack_speed(weapon_type):
7
    if weapon_type == "sword": return 1.0
8
    elif weapon_type == "bow": return 1.5
9

10
# GOOD — centralized
11
WEAPON_STATS = {
12
    "sword": {"damage_mult": 1.2, "speed": 1.0},
13
    "bow": {"damage_mult": 0.8, "speed": 1.5},
14
}

5. Minimize Function Arguments#

Zero to two arguments is ideal. Three or more? You probably need an object.

1
# BAD
2
def create_character(name, health, mana, strength, dex, int, level, x, y, team):
3
    pass
4

5
# GOOD
6
def create_character(name, stats, position, team, level=1):
7
    pass

6. No Hidden Side Effects#

A function called get_something() should never secretly modify state. If it changes things, make that obvious in the name.

1
# BAD — "check" but also modifies
2
def check_password(password):
3
    if password == stored_password:
4
        self.session = initialize_session()  # hidden!
5
        self.login_count += 1               # hidden!
6
        return True
7
    return False
8

9
# GOOD — explicit
10
def is_password_valid(password, stored_password):
11
    return password == stored_password

7. Command-Query Separation#

Functions should either do something (command) or answer something (query). Not both.

1
# BAD — does both
2
def get_next_enemy():
3
    enemy = self.enemies.pop()  # changes state
4
    return enemy                # returns data
5

6
# GOOD
7
def has_next_enemy():       # query
8
    return len(self.enemies) > 0
9

10
def remove_next_enemy():    # command
11
    return self.enemies.pop()

8. Handle Errors Properly#

Don’t mix error handling with business logic. Use exceptions instead of error codes.

1
# GOOD
2
def process_player_move(direction):
3
    validate_direction(direction)
4
    new_pos = calculate_new_position(direction)
5
    check_collision(new_pos)
6
    player.position = new_pos
7

8
try:
9
    process_player_move(user_input)
10
except InvalidDirectionError:
11
    show_message("Invalid direction")
12
except CollisionError as e:
13
    handle_collision(e)

9. DRY — Don’t Repeat Yourself#

If you’re copy-pasting code, extract it into a function.

1
# BAD — duplicated
2
def damage_player(amount):
3
    player.health -= amount
4
    if player.health <= 0:
5
        player.is_alive = False
6

7
def damage_enemy(enemy, amount):
8
    enemy.health -= amount
9
    if enemy.health <= 0:
10
        enemy.is_alive = False
11

12
# GOOD — shared logic
13
def apply_damage(entity, amount):
14
    entity.health -= amount
15
    if entity.health <= 0:
16
        entity.is_alive = False

Writing clean code is rewriting. First draft: make it work. Second pass: make it right. Third pass: make it fast — only if needed.

1
# First draft — just works
2
def do_stuff(x, y):
3
    result = []
4
    for i in x:
5
        if i > 5:
6
            result.append(i * y)
7
    return result
8

9
# Refined — clear and intentional
10
def multiply_values_above_threshold(values, multiplier, threshold=5):
11
    return [v * multiplier for v in values if v > threshold]

Real-World Example: Game Enemy AI#

Let’s apply both pillars to a real scenario — an enemy AI system.

1
# BAD — god function that does everything
2
def update_enemy(enemy, player, delta_time):
3
    # movement, attack, animation, health regen
4
    # all crammed into 40+ lines...

1
# GOOD — each system separated
2

3
def get_movement_direction(enemy, player):
4
    if calculate_distance(enemy.position, player.position) < enemy.chase_range:
5
        return normalize(player.position - enemy.position)
6
    return enemy.patrol_direction
7

8
def move_enemy(enemy, direction, delta_time):
9
    enemy.position += direction * enemy.speed * delta_time
10

11
def can_attack(enemy, player):
12
    distance = calculate_distance(enemy.position, player.position)
13
    return distance < enemy.attack_range and enemy.attack_cooldown <= 0
14

15
def execute_attack(enemy, player):
16
    damage = calculate_damage(enemy.base_damage)
17
    apply_damage(player, damage)
18
    enemy.attack_cooldown = enemy.attack_delay
19

20
def update_animation(enemy):
21
    enemy.animation = "walk" if enemy.velocity.length() > 0 else "idle"
22

23
def regenerate_health(enemy, delta_time):
24
    if enemy.health < enemy.max_health:
25
        enemy.health = min(enemy.health + enemy.regen_rate * delta_time, enemy.max_health)
26

27
# Orchestrate — reads like a plan
28
def update_enemy(enemy, player, delta_time):
29
    direction = get_movement_direction(enemy, player)
30
    move_enemy(enemy, direction, delta_time)
31

32
    if can_attack(enemy, player):
33
        execute_attack(enemy, player)
34

35
    update_animation(enemy)
36
    regenerate_health(enemy, delta_time)

Each function is testable on its own. You can modify movement without touching combat. You can reuse apply_damage() for any entity. The orchestrating function reads like English.

Advanced Thinking Patterns#

Once the fundamentals click, these patterns will level you up.

State Machine Thinking#

When something has distinct modes — idle, walking, jumping, attacking — think in states and transitions. Each state knows its own behavior and when to hand off to the next.

1
class Player:
2
    def __init__(self):
3
        self.state = "idle"
4

5
    def handle_input(self, input):
6
        if self.state == "idle":
7
            if input.jump: self.transition_to("jumping")
8
            elif input.move: self.transition_to("walking")
9
            elif input.attack: self.transition_to("attacking")

Event-Driven Thinking#

When one event should trigger many reactions — “enemy killed” updates score, plays sound, spawns loot — use an event bus. The publisher doesn’t know or care who’s listening.

1
events.subscribe("enemy_killed", score_system.add_points)
2
events.subscribe("enemy_killed", audio_system.play_death_sound)
3
events.subscribe("enemy_killed", loot_system.spawn_drops)
4

5
def kill_enemy(enemy):
6
    enemy.alive = False
7
    events.publish("enemy_killed", {"enemy": enemy, "position": enemy.position})

Pipeline Thinking#

When data flows through transformations — parse, validate, convert, filter, calculate — each stage is independent and composable.

1
def process_trading_data(raw_data):
2
    parsed = parse_csv(raw_data)
3
    cleaned = clean_trade_data(parsed)
4
    enriched = add_technical_indicators(cleaned)
5
    save_trades(enriched)
6
    return enriched

Want to process without saving? Just drop the last step. Want to add a new indicator? Insert one function. The pipeline doesn’t care.

Code Smells Cheat Sheet#

Watch out for these red flags:

Function name uses “and” → validate_and_save() — split it
Generic names → do_stuff(), handle(), manager() — rename or rethink
Long functions → 30+ lines usually means multiple responsibilities
A “get” function that also modifies state → separate query from command
Boolean flag arguments → save(data, compress=True) — probably two functions
Copy-pasted blocks → extract into a shared function
Global variables in calculations → pass them as arguments instead
Can’t test without a database/API/filesystem → extract dependencies

The Mastery Loop#

1
1. Encounter a concept
2
       ↓
3
2. Think in code (break it down)
4
       ↓
5
3. Write working code
6
       ↓
7
4. Refactor for cleanliness
8
       ↓
9
5. Review: Does it read well? Does each piece do one thing?
10
       ↓
11
6. Learn from the pattern
12
       ↓
13
   (Return to 1 with better instincts)

Quick Reference#

Thinking in Code — 5 Questions:

What are the nouns? → Objects/data
What are the verbs? → Actions/functions
What is the state? → What changes
What are the conditions? → When things happen
What is the flow? → Order of operations

Clean Code — 5 Rules:

One function = one job
Name reveals intent
No hidden side effects
No “and” in function descriptions
If you can’t see it all on screen, it’s too long

The Refactoring Workflow:

Does it work? → Make it work first
What does it do? → Name it clearly
Does it do one thing? → Split if not
Can I test it? → Extract dependencies
Is it readable? → Simplify

IMPORTANT
When you’re stuck or your code feels messy, ask yourself two questions:

Can I explain this concept without code? (Thinking)

Does each piece do ONE clear thing? (Cleanliness)

These two questions will guide you back to clarity every time.

“First, make it work. Then, make it right. Then, make it fast.” — Kent Beck

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.” — Martin Fowler

How to Think Like a Programmer#

Pillar 1: Thinking in Code#

The Translation Problem#

Logical Operators#

The Mental Model#

Example: “Player Damages Enemy”#

More Examples#

”Car Accelerates on a Highway”#

”Trading Bot Buys When Price Drops Below Threshold”#

”Inventory Removes Item When Player Uses It”#

Pillar 2: Writing Clean Code#

The Problem: Hidden Responsibilities#

The 10 Principles of Clean Code#

0. Naming Reveals Intent#

1. Small Functions#

2. Functions Do One Thing#

3. Consistent Levels of Abstraction#

4. Avoid Repeated Switch Statements#

5. Minimize Function Arguments#

6. No Hidden Side Effects#

7. Command-Query Separation#

8. Handle Errors Properly#

9. DRY — Don’t Repeat Yourself#

10. The Refinement Loop#

Real-World Example: Game Enemy AI#

Advanced Thinking Patterns#

State Machine Thinking#

Event-Driven Thinking#

Pipeline Thinking#

Code Smells Cheat Sheet#

The Mastery Loop#

Quick Reference#