Forem: André Blos Aliatti

Começar em programação do zero depois dos 40: roteiro realista de André Blos Aliatti

André Blos Aliatti — Wed, 01 Apr 2026 01:30:11 +0000

O problema não é a idade, é a expectativa

Começar em programação depois dos 40 não é difícil do jeito que parece. Mas também não é simples do jeito que vendem. O problema não está na idade, está na forma como a entrada na área é apresentada. Existe uma narrativa muito forte de que basta escolher uma linguagem, fazer alguns cursos e, em poucos meses, tudo começa a acontecer. E quando isso não acontece — porque na maioria das vezes não acontece — a primeira coisa que vem não é clareza. É dúvida.

O início é confuso, não técnico

Eu sou André Blos Aliatti, desenvolvedor backend em transição de carreira, e o início da minha jornada não foi técnico. Foi confuso. Eu comecei como muita gente começa: consumindo conteúdo, tentando entender qual área fazia mais sentido, pulando entre possibilidades que pareciam promissoras. Dados, Python, automação, inteligência artificial. Tudo parecia relevante. Nada parecia definitivo. E esse é um dos primeiros pontos que ninguém deixa claro: no começo, você não sabe se está perdido porque a área é complexa ou porque você está fazendo errado. E essa dúvida cansa mais do que a dificuldade técnica.

O começo não é empolgante

O início da programação não é empolgante. Essa é outra parte que pouca gente fala. Você não começa construindo sistemas, não começa criando coisas impressionantes. Você começa tentando entender como um computador interpreta instruções simples. Variáveis, condições, repetição. Conceitos que parecem pequenos demais para quem já tem uma vida inteira de experiência em outras áreas. Existe até uma sensação incômoda de regressão, como se você estivesse voltando para um estágio muito básico. E é exatamente isso que está acontecendo. Só que esse básico não é opcional. Ele é estrutural.

A frustração vem da falta de sentido

A frustração não vem de não entender. Ela vem de não enxergar sentido. Você estuda, faz exercícios, acompanha aulas, mas não consegue ligar aquilo com algo real. E, sem essa conexão, o aprendizado parece solto. Foi só quando eu comecei a entender que programação não é sobre linguagem, mas sobre construção de sistemas, que as coisas começaram a se reorganizar. Antes disso, era como aprender palavras soltas de um idioma sem nunca formar uma frase.

O erro silencioso: estudar sem direção

Existe um erro silencioso que acontece nesse momento: estudar sem direção. Você aprende um pouco de cada coisa, acumula conhecimento fragmentado e passa a ter a impressão de que está evoluindo. Mas evolução de verdade só aparece quando existe continuidade. Quando você começa a aprofundar em um caminho específico. No meu caso, essa virada veio quando eu decidi parar de explorar tudo e comecei a focar em backend. Não porque era mais fácil, mas porque começou a fazer sentido estruturalmente. Principalmente quando entrei em orientação a objetos. Pela primeira vez, eu não estava só escrevendo código. Eu estava modelando algo que existia fora da tela.

A fase em que nada valida

Mas até chegar nesse ponto, tem um trecho que é mais pesado do que parece. É o trecho em que nada valida o que você está fazendo. Você estuda, se dedica, envia currículo, tenta vagas, e não recebe resposta. Nenhuma. E aí começam as perguntas que não são técnicas. São pessoais. Será que é a idade? Será que eu estou atrasado? Será que isso realmente é pra mim? Essa fase não aparece nos vídeos, não aparece nos posts, não aparece nos relatos rápidos de sucesso. Mas ela existe. E ela pesa.

O ponto de virada: construir

O que mudou para mim não foi encontrar o curso certo, nem a linguagem certa. Foi entender que aprendizado sem construção não sustenta. O momento em que você começa um projeto, mesmo sem saber direito o que está fazendo, muda completamente a dinâmica. Porque ali você para de consumir e começa a enfrentar problema. E problema obriga você a aprender de outro jeito. Não mais por curiosidade, mas por necessidade.

O que eu faria diferente hoje

Se eu tivesse que começar de novo hoje, não tentaria acelerar. Não tentaria escolher a stack perfeita. Eu começaria aceitando que o início é lento, que a base leva tempo e que a clareza não vem antes da prática. Vem durante. Começaria pequeno, construiria algo simples, erraria mais cedo e tentaria entender o porquê de cada erro. Porque no fim, o que faz diferença não é o quanto você estuda. É o quanto você consegue transformar estudo em construção.

A diferença de começar depois dos 40

Começar depois dos 40 muda algumas coisas, sim. Você não tem o mesmo tempo disponível, não tem a mesma margem para testar caminhos aleatórios, não tem o mesmo espaço para errar sem consequência. Mas, ao mesmo tempo, você tem uma vantagem que pouca gente valoriza: você leva o processo a sério. Você não está ali por curiosidade. Está porque precisa funcionar. E isso muda a forma como você aprende.

O problema nunca foi a idade

Hoje, olhando para trás, fica claro que o problema nunca foi começar mais tarde. Foi começar esperando um caminho mais linear do que ele realmente é. Programação não é uma linha reta. É um processo de construção que só faz sentido quando você atravessa as partes confusas, as partes lentas e as partes em que parece que nada está acontecendo.

Conclusão

Se você está nesse ponto agora, não tenta simplificar demais. Mas também não complica. Fica no processo. Aprende o básico de verdade. Escolhe uma direção. E constrói alguma coisa, mesmo sem estar pronto. Porque é aí que tudo começa a se encaixar.

Se quiser entender melhor minha trajetória, vale conhecer quem é André Blos Aliatti, acompanhar os projetos que venho desenvolvendo e ver como essa jornada está evoluindo na prática. Porque, no final, aprender programação não é sobre entender tudo rápido. É sobre continuar, mesmo quando ainda não faz sentido completo.

Object-Oriented Programming Is Not About Classes — It’s About Modeling Systems By André Blos Aliatti

André Blos Aliatti — Mon, 16 Mar 2026 17:50:20 +0000

Introduction

Many developers learn Object-Oriented Programming by focusing on syntax:

class
extends
implements

But this approach completely misses the real purpose of OOP.

Object-Oriented Programming exists to solve a fundamental software engineering problem:

How do we organize complex systems so they remain understandable and maintainable as they grow?

OOP is not about writing classes.
It is about modeling real-world concepts and responsibilities in software.

When developers skip this conceptual layer, systems quickly become hard to maintain, even if the code compiles and runs.

The Real Goal of OOP: Modeling the Domain

A software system represents a domain.

Examples:

a medical clinic system
an e-commerce platform
a financial management tool

Each domain has:

entities
behaviors
rules
constraints

OOP provides a way to represent those concepts and behaviors together.

For example, a medical system might include:

Patient
Doctor
Appointment
Prescription But these are not just data containers. They represent objects with responsibilities and behavior.

Bad design:

Patient
name
age
cpf

Good design:

Patient

registerAppointment()
updateAddress()
addMedicalRecord()

The difference is subtle but critical:

Objects should own behavior, not just store data.

Encapsulation Protects System Integrity

Encapsulation is often explained as “making fields private”.

That explanation is incomplete.

The real purpose of encapsulation is to protect invariants.

An invariant is a rule that must always remain true.

Examples:

an appointment cannot exist without a patient
a payment cannot be negative
a prescription must belong to a consultation

Without encapsulation, any part of the system can break those rules.

Example of fragile design:

appointment.date = null
appointment.patient = null

When invariants are protected through methods, the system becomes safer:

appointment.schedule(patient, date)

Now the object guarantees its own consistency.

Encapsulation forces developers to respect the model.

Responsibility Defines Good Design

One of the most important design questions in OOP is:

Who is responsible for this behavior?

When responsibility is unclear, developers tend to place logic:

in controllers
in utility classes
in services with hundreds of lines

This leads to a well-known problem:

anemic domain models

Example of poor design:

UserService
UserValidator
UserManager
UserUtils

While the actual User object contains nothing but fields.

In well-designed OOP systems, objects own their logic.

Cohesion and Coupling

Two fundamental concepts define how maintainable a system will be.

Cohesion

Cohesion measures how related the responsibilities of a class are.

High cohesion means:

A class does one thing and does it well.

Low cohesion results in “god classes”.

Example:

UserService

registerUser
generateInvoice
sendEmail
calculateTaxes

These responsibilities clearly belong to different parts of the system.

Coupling

Coupling measures how dependent components are on each other.

High coupling means:

small changes ripple across the system

refactoring becomes dangerous

testing becomes difficult

Good OOP design aims for:

high cohesion
low coupling

Behavior Is More Important Than Data

One of the biggest misconceptions in OOP is treating objects as data structures.

This happens frequently in modern frameworks where objects are used as DTOs.

Example:

class Order {
public int quantity;
public double price;
}

Then logic is implemented elsewhere:

OrderService.calculateTotal(order)

But the behavior clearly belongs to the object itself.

Better design:

order.calculateTotal()

The object becomes responsible for its own behavior.

OOP Is the Foundation of Modern Architecture

Many modern architectures rely on solid OOP concepts:

Domain-Driven Design (DDD)
Clean Architecture
Hexagonal Architecture
Layered Architecture

All of them assume developers understand:

responsibility
abstraction
separation of concerns
domain modeling

Without this foundation, architectural patterns become ceremony rather than design.

The Cost of Skipping OOP Fundamentals

Developers who rush through OOP often create systems that show the same symptoms:

bloated service classes
business rules scattered across layers
fragile refactoring
duplicated logic
growing technical debt

The system works — until it grows.

Then every change becomes expensive.

How to Actually Learn OOP

Instead of memorizing syntax, focus on:

1️⃣ Modeling real domains
2️⃣ Defining clear responsibilities
3️⃣ Protecting invariants
4️⃣ Reducing coupling
5️⃣ Writing objects with behavior

Small projects are the best way to practice this.

Build systems where objects represent real concepts.

Conclusion

Object-Oriented Programming is not a language feature.

It is a way of thinking about software.

When properly understood, it allows developers to build systems that:

remain understandable
evolve safely
scale in complexity

Skipping these fundamentals might feel faster in the short term.

But in software engineering, structure always wins over speed.

André Blos Aliatti

Developer documenting the process of learning software engineering fundamentals and building real systems.

Relearning Tech After 40: Why Strong Fundamentals Matter More Than Speed

André Blos Aliatti — Sun, 08 Feb 2026 00:36:38 +0000

by André Blos Aliatti

This article is part of a series about restarting in tech after 40, with a focus on fundamentals, clarity and real-world learning.

Introduction

My name is André Blos Aliatti and when I restarted my path into software development after 40, one technical mistake became very clear early on:

Skipping fundamentals causes more problems than choosing the “wrong” stack.

There is constant pressure to move fast: frameworks, tools, jobs, specializations.
But software is not built on tools — it’s built on concepts.

This article is not about career advice.
It’s about why technical foundations matter and how rushing through them creates real problems in code.

Software is structure before technology

No matter the language or framework, most systems deal with the same core problems:

data input and validation

business rules

persistence

communication between components

long-term maintenance

These problems do not change when you switch from Java to JavaScript or from one framework to another.

What changes is how the solution is expressed.

Learning how to use a framework without understanding what it abstracts creates dependency on tools instead of reasoning.

Logic and algorithms are not “beginner topics”

Logic is often treated as something you “get over with” quickly.

In practice, it never goes away.

It shows up when:

conditional logic becomes complex

loops affect performance

data structures don’t match the problem

Concepts like:

control flow

state

data dependency

are present in every real system.

Ignoring them leads to trial-and-error coding, which doesn’t scale.

Object-Oriented Programming is modeling, not syntax

OOP is not about keywords like class or extends.

It’s about modeling the domain.

Concepts such as:

single responsibility

encapsulation

cohesion

coupling

define whether a system is understandable and evolvable or fragile and hard to maintain.

Modern frameworks assume you already understand this.
If you don’t, they just delay the problem.

APIs are contracts, not endpoints

Creating an API is not just exposing routes.

Without a solid understanding of:

HTTP verbs

status codes

request/response semantics

idempotency

error handling

APIs become hard to consume and fragile.

REST is not about memorizing patterns — it’s about system communication, independent of language or framework.

Databases are not implementation details

Databases are often treated as secondary concerns.

Bad decisions here accumulate technical debt fast.

Understanding:

relational modeling

primary and foreign keys

normalization

indexes

transactions

directly impacts performance and reliability.

ORMs help, but they don’t replace SQL knowledge.
Many “tool problems” are actually modeling problems.

Rushing creates silent technical debt

Rushing rarely breaks things immediately.

It shows up later as:

code that’s hard to change

fear of refactoring

scattered business logic

lack of tests

In most cases, it’s not incompetence — it’s skipped fundamentals.

Studying the base feels slow, but it saves time long-term.

What to prioritize when starting (or restarting)

Regardless of age or stack:

logic and control structures

solid OOP concepts

HTTP and APIs

SQL and data modeling

reading existing code

small but well-structured projects

Frameworks come later.
Specialization comes later.

Foundations are not a phase.
They are ongoing support.

Conclusion

Technologies change fast.
Concepts don’t.

Developers who build on solid foundations can:

learn new stacks faster

understand abstractions more easily

solve problems outside the “happy path”

grow consistently

Not rushing doesn’t mean moving slowly.
It means moving in the right direction.

André Blos Aliatti
Developer in progress, sharing a real journey in software development with a focus on fundamentals, backend, frontend and practical projects.