💡 Pain Is About Avoiding Pain in the Future - Reflections on The Pragmatic Programmer

Gustavo Oliveira — Tue, 22 Jul 2025 10:41:20 +0000

💡 Pain Is About Avoiding Pain in the Future

Reflections on The Pragmatic Programmer

“Programming is about trying to make the future less painful.

It’s about making things easier for our teammate.

It’s about getting things wrong and being able to bounce back.

It is about good habits.

It’s about understanding your toolset.”

— The Pragmatic Programmer, 20th Anniversary Edition

🧭 Introduction

When I first read this paragraph from The Pragmatic Programmer, it really hit me. For most of my career, I was focused on learning technologies and applying them at work. I thought that was enough.

But I was wrong.

I used to obsess over writing "clean code" mostly because I didn't want anyone to read my code and think poorly of me. But this reflection made me realize it goes way deeper than that.

Writing good code isn’t just about elegance or syntax. It’s about reducing future pain — for the next engineer who needs to maintain it, for the company that needs to scale, and for the users who expect stability. It's about making decisions today that reduce friction tomorrow.

Ultimately, it’s about empathy.

🧠 Good Habits Go Beyond Personal Life

I’ve always cared about good habits — sleep, discipline, learning consistently — but I never realized how directly they impact how I code and how I contribute to the company.

When I don’t sleep well, I’m more likely to take shortcuts. I may skip testing or delay proper planning. That might not hurt today, but the pain always comes later — for me or someone else.

Improving just 1% every day — in communication, in focus, in mastery of tools — compounds. And the quality of my work reflects it.

💬 Reflections on Each Line

✅ "Programming is about trying to make the future less painful."

This made me reflect on times I built projects that scaled to thousands of users — and how much pain I caused by not thinking ahead.

I once built a system without asking basic architectural questions like:

How many data events per minute will we receive?
What are the limits of our DB connection pool?
What happens if a user sends a large payload?

I was thinking in code, not in architecture. And we paid the price later. Painful scaling, fragile systems, rushed fixes. I now know that a few small questions early on could have saved us hours (or days) of rework.

🤝 "It’s about making things easier for our teammate."

This one struck me emotionally.

Imagine your teammate is your neighbor. They knock on your door asking for help. Would you ignore them? No — you’d offer a hand.

Why not do the same in code?

Clear names, good docs, helpful comments — they’re small acts of professional kindness. They turn frustration into flow for the next person.

🔁 "It’s about getting things wrong and being able to bounce back."

We will get things wrong. And that’s okay — as long as we learn.

In the past, I missed planning details. But instead of blaming tools or teammates, I started asking better questions before coding:

Who is the user?
What’s the real problem?
What edge cases are likely?

Bouncing back isn’t about perfection. It’s about responsibility.

🔧 "It is about good habits."

I now see that my daily routine shapes my engineering. When I take care of my health, stay focused, and practice intention — I write better code.

Even simple habits like reviewing my commits, naming functions clearly, or taking time to test edge cases — they matter.

🧰 "It’s about understanding your toolset."

A good developer doesn’t just write code — they wield tools with intention.

I’ve spent time improving how I use:

My editor (shortcuts, snippets)
Testing tools (naming, coverage, mocks)
Git (atomic commits, rebases)
The terminal (scripts, automation)

Mastery isn't about showing off. It’s about flow. When you know your tools, they disappear — and your attention stays on the problem.

🛠️ How I Practice This Today

Here are a few things I now do that reflect this mindset:

Before coding, I ask: What value will this bring to the team, user, and company?
I embrace mistakes as part of the process — they’re feedback loops.
I plan with care, like a craftsman: writing tests before features, considering edge cases, and naming things with clarity.
I write to the future — for the engineer who reads my code months from now (who might be me).

🧾 Final Thought

Your code changes the future.

It may save hours of frustration. Or it may cost them.

You decide — every time you open your editor.

What about you? Have you ever changed your coding philosophy after reading a single paragraph? Reach out on Twitter — I’d love to hear your story.

Mastering Concurrent Programming in Elixir

Gustavo Oliveira — Wed, 17 Jul 2024 10:32:26 +0000

Introduction

Concurrent programming can significantly improve an application's performance, responsiveness, and resource utilization. In this article, we'll explore how Elixir leverages the Erlang Virtual Machine to simplify concurrent operations. Whether you're new to Elixir or seasoned, you'll gain valuable insights and practical tips to elevate your programming skills.

Benefits of Concurrent Programming in Elixir

Concurrency in programming is key to handling multiple operations simultaneously, leading to improved performance and user experience.

Improved Performance: Efficient utilization of system resources.
Responsiveness: Ensures that applications handle multiple tasks at once seamlessly.
Resource Utilization: Optimizes the capacity and throughput of the system.

Elixir’s Process Model

In Elixir, lightweight processes manage concurrency, inspired by the actor model.

Spawning Processes

Creating new processes is simple with the spawn function:


spawn(fn -> IO.puts("Hello from a new process!") end)

Messaging Between Processes

Message passing allows processes to interact while remaining isolated.

send self(), :hello

receive do
  :hello -> IO.puts("Received a hello message")
  _ -> IO.puts("Unknown message")
end

Linking and Monitoring Processes

Processes can be linked and monitored for fault tolerance.

pid = spawn(fn -> raise "oops" end)
Process.link(pid)

Leveraging the OTP Framework

Elixir's Open Telecom Platform (OTP) provides a set of libraries and design principles for building robust applications:

Using Supervisors

Supervisors monitor worker processes and restart them if they fail.

Supervisor.start_link([worker(MyWorker, [])], strategy: :one_for_one)

Implementing GenServer

GenServer simplifies managing state and server lifecycles.

defmodule MyServer do
  use GenServer

  # Starts the server
  def start_link(initial_value) do
    GenServer.start_link(__MODULE__, initial_value, name: __MODULE__)
  end

  # Handles synchronous calls
  def handle_call(:get, _from, state) do
    {:reply, state, state}
  end
end

Best Practices for Concurrent Programming

Follow these best practices for effective concurrent programming:

Avoid Shared State: Keep each process's state independent to prevent conflicts.
Minimize Message Passing: Reduce messaging frequency and complexity.
Design with Supervision: Use supervision trees for managing process lifecycles.

Conclusion

Elixir's concurrency model, rooted in the Erlang VM, enables the building of high-performance, fault-tolerant applications. By mastering process management, message passing, and the OTP framework, you'll be well-equipped to harness the full potential of concurrent programming in Elixir.

Call to Action

Have you explored Elixir's concurrency features? Share your experiences below. For more, check out our Elixir programming resources.

DEV Community: Gustavo Oliveira