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.
Top comments (0)