What is computational thinking?

Thinking like a programmer

Computational thinking is not about thinking like a computer. It is about developing a systematic approach to problem solving that works whether you are writing code, designing a system, or debugging a production incident.

It is the skill that separates someone who can write syntax from someone who can solve problems.

"Computational thinking is the thought processes involved in formulating problems and their solutions so that the solutions are represented in a form that can be effectively carried out by an information-processing agent."

Jeannette Wing, 2011, crediting Jan Cuny and Larry Snyder

---

The four pillars

Computational thinking rests on four interconnected skills:

flowchart TB
  subgraph CT["Computational thinking"]
    D["1. Decomposition<br/>break big problems into small ones"]
    P["2. Pattern recognition<br/>spot similarities and recurring structures"]
    A["3. Abstraction<br/>hide details, focus on what matters"]
    AL["4. Algorithmic thinking<br/>design step-by-step solutions"]
  end

Let us preview each one with a real-world example before diving deep in the following lessons.

---

Pillar 1: decomposition

Breaking a complex problem into smaller, manageable parts.

Imagine you are asked to build a user registration system in Rails. Instead of trying to solve it all at once, you decompose:

flowchart TB
  R["Build user registration"] --> A["Create the User model<br/>name, email, password_digest"]
  R --> B["Build the sign-up form<br/>HTML + validations"]
  R --> C["Write the registration service<br/>create user, send welcome email"]
  R --> D["Add password policy<br/>minimum length, complexity"]
  R --> E["Handle errors<br/>duplicate email, invalid input"]
  R --> F["Write tests for each piece"]

Each sub-problem is small enough to solve independently. This is decomposition: and it is the foundation of software engineering.

---

Pillar 2: pattern recognition

Identifying similarities, trends, and recurring structures.

Once you have decomposed a problem, you often notice patterns:

Sign-up form       →  has fields, validations, submit, errors
Sign-in form       →  has fields, validations, submit, errors
Edit profile form  →  has fields, validations, submit, errors

Pattern: All forms share the same structure!

Recognizing this pattern leads to reusable solutions: form builders, shared partials, or service objects with a common interface.

In Ruby, patterns lead to DRY code:

# Pattern: every service returns a Result
module Auth
  class RegisterUserService
    Result = Data.define(:success, :user, :errors)

    def self.call(email:, username:, password:, password_confirmation:, time_zone: nil)
      # ... logic ...
      Result.new(success: true, user: user, errors: [])
    end
  end

  class AuthenticateUserService
    Result = Data.define(:success, :user, :error)

    def self.call(email:, password:)
      # ... logic ...
      Result.new(success: true, user: user, error: nil)
    end
  end
end

---

Pillar 3: abstraction

Focusing on what is important and hiding unnecessary details.

When you drive a car, you do not think about fuel injection or gear ratios: you think about steering, accelerating, and braking. The car abstracts away the complexity.

In programming, abstraction means creating interfaces that hide implementation details:

# High-level abstraction: what (not how)
result = Auth::RegisterUserService.call(email:, username:, password:, password_confirmation:)

# The caller doesn't need to know:
# - How the password is hashed
# - Which database table stores users
# - What validations run
# - How the time zone the browser reported gets checked

Rails itself is a massive abstraction:

# You write this:
Catalog::Course.where(level: :intern).order(:position)

# Rails abstracts away:
# - SQL generation
# - Database connection management
# - Result set mapping to Ruby objects
# - Type casting

---

Pillar 4: algorithmic thinking

Designing step-by-step solutions that can be followed precisely.

An algorithm is a finite sequence of well-defined steps that solves a problem. Algorithmic thinking means designing these steps before writing code:

Algorithm: Authenticate a user

1. Receive email and password
2. Find user by email in the database
3. If user not found → return error "Invalid credentials"
4. Compare password with stored hash
5. If password does not match → return error "Invalid credentials"
6. If password matches → create session, return success

Notice: the same error message for "user not found" and "wrong password": this is a security decision (preventing user enumeration) that algorithmic thinking helps you reason about.

---

How the pillars work together

The four pillars are not sequential steps: they are lenses you apply simultaneously:

flowchart LR
  P["Problem: build a course progress tracking system"]
  P --> D["1. Decomposition<br/>track completed lessons · completion % · award XP · show on dashboard"]
  P --> R["2. Pattern recognition<br/>completions = read receipts · XP = a ledger · progress = completed / total × 100"]
  P --> A["3. Abstraction<br/>LessonCompletion model · UserGamificationQuery · dashboard presenter"]
  P --> G["4. Algorithmic thinking<br/>find enrollment → create completion → award XP<br/>count completions / count lessons × 100"]

---

Computational thinking vs coding

Coding is the implementation. Computational thinking is the strategy.

Computational Thinking	Coding
What problem are we solving?	What language/framework?
How do we break it down?	What classes/methods?
What patterns exist?	What abstractions/gems?
What are the steps?	What is the syntax?
Is this the right approach?	Does this code work?

You can be great at coding but terrible at problem-solving. Computational thinking ensures you solve the right problem in the right way before writing a single line of code.

---

Why this course matters

Every senior developer you admire has strong computational thinking skills: often without knowing the formal name. They:

• Break ambiguous requirements into clear tasks (decomposition)
• Recognize when a problem is similar to one they have solved before (pattern recognition)
• Design clean interfaces that hide complexity (abstraction)
• Plan their approach before coding (algorithmic thinking)

In the next six lessons, we will practice each pillar deeply, building toward a capstone where you apply all four to solve a real problem.

---

Summary

Pillar	Description	Rails Example
Decomposition	Break big problems into small parts	Feature → Models + Service + Controller + View
Pattern Recognition	Spot similarities and recurring structures	All services return Result objects
Abstraction	Hide details, expose clean interfaces	Course.where(level: :intern) hides SQL
Algorithmic Thinking	Design step-by-step solutions	Authentication flow: find → verify → session