There is a strange moment many developers know all too well. It is 6:37 p.m. You merged your last pull request, answered your final Slack message, and your calendar says the workday is over. You stand up from your desk, walk a few steps, and arrive at… your living room. Or your kitchen. Or the same bedroom where you have been working since eight in the morning.
Technically, you have left work. But your mind has not.
While making dinner, you remember a possible cause of the bug you were investigating. When you sit down to watch a show, you wonder whether you should have challenged a decision made during the architecture review. You pick up your phone to answer a personal message and notice a notification from the team. “I’ll just check what happened,” you tell yourself. Ten minutes later, you are reading logs again.
Not necessarily because anyone asked you to. And not because you dislike remote work. Often, the opposite is true: you enjoy what you do, you have autonomy, you are solving interesting problems, and you can work from a place you chose. But when the same space is where we think, produce, rest, eat, and unwind, our brains lose some of the boundaries they relied on for decades to distinguish one part of life from another.
There used to be fairly clear signals. Close the laptop. Take the elevator. Leave the building. Walk to the car. Get on the bus. Listen to music during the commute. Arrive home. Even when commuting was exhausting, it contained something many people have had to deliberately rebuild in remote work: a transition.
And that transition matters especially in software engineering, because our work rarely ends at the exact moment our hands leave the keyboard.
The Workday Ends on the Screen Long Before It Ends in Our Heads
Software development requires us to hold an enormous amount of mental context at once. We are not simply completing tasks. We are understanding systems, anticipating behavior, remembering previous decisions, interpreting code written by other people, comparing trade-offs, and building mental models of things we cannot physically see.
A backend engineer might spend an afternoon investigating why an operation that works perfectly in staging starts failing under a specific load in production. A QA engineer may finish the day thinking about an edge case no one included in the acceptance criteria. A DevOps engineer may go to bed wondering whether the alert they chose not to escalate was really just noise. An engineering manager may continue replaying a difficult conversation with someone on their team.
You can close the code. You cannot always close the intellectual problem.
That is one reason working from home can feel paradoxically comfortable and exhausting at the same time. We eliminated commutes, gained autonomy, and acquired more control over our routines. But we also lost many of the small environmental cues that once helped the brain recognize that one part of the day was over.
After several years of remote work, the challenge is no longer simply proving that we can be productive from home. Distributed teams around the world have already done that. The more interesting challenge now is different: how do we build sustainable remote careers without turning our entire lives into an extension of the workday?
In 2025, Microsoft described a phenomenon it called the infinite workday: a workday that begins extending into the early morning and continues resurfacing at night through meetings, messages, documents, and notifications. The problem is not simply working long hours. It is the feeling that work is permanently available, waiting for us to log back in.
For a developer, that availability has a particular characteristic: there is always something else we could do.
We could review that PR tonight so a teammate does not have to wait tomorrow. We could quickly answer the question that came in after hours. We could use twenty minutes to research that library. We could get ahead on the ticket. We could fix that small thing that “only takes five minutes.”
And each of those decisions, viewed in isolation, seems perfectly reasonable.
The problem begins when the exception slowly becomes the architecture of our routine.
Good software has taught us for years that systems need boundaries. We define interfaces. We isolate responsibilities. We control dependencies. We avoid giving one component unrestricted access to everything. And yet, sometimes we design our own workdays exactly the way we would try to avoid designing a production system: everything connected to everything, permanently available, with no clear boundary between contexts.
Paradoxically, the solution is usually not forcing ourselves to work fewer hours or building the perfect Instagram-worthy home office. For many people, those recommendations are not even realistic. Maybe the desk is in the bedroom. Maybe the apartment is shared. Perhaps the dining table serves as a workspace during the day and, two hours later, becomes exactly what it was meant to be: a table for eating.
That is why it can be far more useful to think about transitions than perfect spaces.
Imagine a developer working from a small apartment in Bogotá. Her desk is in her bedroom because there is no other room available. For months, when the workday ended, she simply closed the laptop and left it on the desk. Every time she entered the bedroom, she saw the screen, the headphones, the notebook, and a list of unfinished tasks next to the bed. Work was over, but it remained visually present.
Then she changed one thing. Before finishing for the day, she wrote down what she had been working on, what she had discovered, and the exact next step for the following morning. Then she closed every application, put the laptop in a drawer, and walked around the block for fifteen minutes.
Nothing sophisticated.
But she had created an ending.
That small ritual solved two problems. First, she no longer needed to keep mentally rehearsing where she had left off because she had externalized the context. Second, the walk created a physical transition between two states that otherwise would have taken place within the same few square meters.
Another engineer might do something completely different. Maybe he works from the dining table in San José and cannot leave his setup there. At the end of the day, he disconnects the monitor, puts away the keyboard and mouse, changes the lighting, and starts making dinner. For someone else, the ritual might be quitting Slack completely. For another person, it could be changing clothes, walking the dog, working out, or putting on music while making coffee.
There is no universal ritual. The important idea is to create a signal consistent enough for the brain to learn: this is over.
That also changes how we think about productivity. Engineering has a long-standing culture that sometimes confuses visible effort with impact. Long hours. Fast replies. Constant availability. But an exhausted developer can produce more lines of code while making worse decisions.
After five hours spent trying to solve a problem, pushing for another two does not always demonstrate commitment. Sometimes the technically smarter move is to document what you learned, write down the remaining hypotheses, and come back tomorrow with a cognitive system that has had a chance to reset.
We have all experienced some version of this. A problem defeats us for hours, we walk away from the desk frustrated, and the solution appears while we are showering, walking, cooking, or doing something seemingly unrelated to programming.
It was not magic.
Our minds needed to stop looking at the problem from exactly the same angle.
Rest is part of the engineering process too.
LATAM Is Building Global Technology. That Should Not Mean Being Available Globally
This conversation takes on another dimension when we talk about LATAM tech talent.
Over the past several years, thousands of engineers from Costa Rica, Colombia, Brazil, Argentina, Peru, Mexico, Guatemala, and other countries have become increasingly integrated into international teams. The growth of software development in Latin America is changing who builds global products and, just as importantly, where those products are built.
GitHub reported that Latin America added approximately 3.2 million net new developers between 2024 and 2025. Brazil, Mexico, and Colombia are among the ecosystems continuing to gain relevance, driven by more mature technical communities, continuous learning, greater access to international opportunities, and the expansion of distributed work models.
Today, it is completely normal for an engineer in Medellín to review code written by someone in California, for a developer in Buenos Aires to work on a platform used by millions of people in the United States, or for a DevOps engineer in Costa Rica to participate in an infrastructure decision with colleagues distributed across several countries.
That represents an extraordinary opportunity for our region.
For years, participating in certain international technology projects seemed to require physically relocating to another country. Today, an engineer can live in LATAM and contribute directly to products, architectures, and decisions with global impact. Nearshore software development has helped remove many of those barriers.
But that opportunity can also create a quiet pressure.
When you work with an international company, it is easy to start proving commitment through availability. Reply quickly. Always adapt. Always be present. Become “the reliable person,” the one everyone knows they can message because you will probably respond.
And that behavior is often celebrated at first.
The person who always replies looks incredibly committed. The one who resolves incidents after hours quickly becomes indispensable. The person who constantly accepts meetings demonstrates flexibility. The one who never seems to disconnect becomes known as someone who is always there.
Until what looked like an advantage begins turning into dependency.
A strong nearshore software development model should not work because an engineer in LATAM is willing to extend the workday indefinitely. It should work because there are clear processes, highly skilled talent, intelligent time-zone overlap, effective communication, solid documentation, and trust.
The real value of nearshore was never having people available for longer.
It is having the right people working nearby, collaborating deeply, and making strong technical decisions.
That distinction should matter to CTOs, VPs of Engineering, and engineering managers too.
If a team requires individual hyperavailability to function, it probably does not have an engagement problem. It has an organizational design problem.
Documentation may be missing. Too much knowledge may be concentrated in a handful of people. Priorities may be unclear. Almost everything may be labeled urgent. Meetings may consume the hours meant for concentration, forcing engineers to do their actual work only after the calls finally end.
A developer who is coding after six is not necessarily demonstrating how much they love their job.
Maybe they simply spent the entire day talking about the work they needed to do.
That is why protecting deep-work blocks, defining what constitutes a genuine emergency, normalizing asynchronous responses, and respecting time-zone differences are not merely well-being initiatives. They are organizational architecture decisions.
Tech culture is written this way too.
It is written when a senior engineer says during a code review, “I don’t understand this part. Can you explain it?” and shows that asking questions does not diminish expertise.
It is written when someone shares a problem before spending six hours trying to prove they can solve it alone.
It is written when a manager avoids sending unnecessary messages at ten at night or, if they need to because that is when they work, makes it clear that no immediate response is expected.
It is written when someone takes vacation and nobody needs to call them because knowledge has been properly distributed.
And above all, it is written through the small behaviors a team eventually learns to consider normal.
Building Great Teams Also Means Building Lives With Room for More Than Work
There is an old image of the great programmer: isolated, completely absorbed in the problem, working for hours until a brilliant solution appears.
Modern software engineering works differently.
The best systems are products of collaboration. Pair programming. Architecture discussions. Code reviews. Mentoring. Documentation. Respectful disagreement. People saying, “I don’t know,” and someone else helping them figure it out.
A strong developer community does more than make us better technically. It also keeps us from individually carrying burdens that should belong to the team.
Imagine an engineer who has been stuck for four hours trying to solve a concurrency problem. They have read the documentation, run tests, reviewed logs, and changed the implementation several times. They begin to feel that asking for help would amount to admitting that they should already know how to solve it.
Eventually, they share their screen with a colleague.
She asks three questions.
Within twenty minutes, they discover they had spent hours investigating the wrong component.
That moment contains a technical lesson, but also a cultural one: collaboration should not appear only after we have failed individually; it should be a normal part of how we practice engineering.
The same is true of learning. Stack Overflow’s 2025 Developer Survey found that around 69% of developers had spent time during the previous year learning new programming techniques or a new language. It is difficult to think of many professions where constant reinvention is such an explicit part of everyday work.
Now add AI. New frameworks. Tools appearing every week. Cloud platforms that evolve constantly. New expectations around cybersecurity, data, automation, and product thinking. Beyond writing code, we increasingly expect judgment, validation, communication, ownership, and business understanding.
The sustainable answer cannot simply be to consume more information for more hours.
We also need room to process it.
That is why a mature engineering culture should ask not only “How can we produce more?” but also “What conditions will allow our people to keep doing great engineering five years from now?”
Because technical retention does not begin only when someone starts considering another job offer.
It begins much earlier.
It begins with how someone feels on an ordinary Tuesday after closing their laptop.
Whether they still have energy.
Whether they still feel curious.
Whether they can make a mistake without feeling that they are proving their incompetence.
Whether they can ask for help.
Whether they have room to learn.
Whether they can disconnect without worrying that something important will happen because they stopped checking Slack for two hours.
At Mismo, this conversation carries particular meaning because working with engineers distributed throughout LATAM means building community without relying on a shared physical office. It means creating closeness among people who may live thousands of miles apart, sharing knowledge across countries, learning from different experiences, and building trust through the work itself.
But community should not exist only within a company.
Something bigger is happening across our region.
A generation of Latin American developers is proving that we do not necessarily need to move to Silicon Valley to participate in global products. We can build them from our own cities, contribute ideas shaped by our own realities, and work alongside some of the best teams in the world without necessarily giving up what we value about our lives.
That deserves pride.
And it deserves protection too.
Because flexibility loses part of its meaning if we work from home but never truly feel that we are at home.
Perhaps that is why the most important conversation about the future of remote work is no longer about how many days we should spend in an office, which tool we should use to communicate, or which country we should hire from.
Perhaps it is a much more human question:
How do we want to feel after many years of working this way?
We want to remain curious when a difficult problem appears. We want to have the energy to learn a new technology. We want to keep enjoying technical conversations with people who know things we do not. We want to build software we can be proud of.
But we also want to close the laptop.
Go outside.
Walk.
Have dinner without checking Slack.
Be present with the people we love.
Sleep without continuing to mentally debug our professional lives.
And come back the next day wanting to build again.
Because being a great developer should never mean being available all the time. It means developing judgment, continuously learning, collaborating generously, and understanding when to keep searching for a solution… and when to put the problem away until tomorrow.
From LATAM, we are helping build a new chapter of global technology.
And at Mismo, that vision comes to life every day through distributed teams, cross-country collaboration, and a culture where professional growth should not require sacrificing what makes a long-term career sustainable.
Because building great products also means building environments where engineers can learn, share knowledge, take on meaningful challenges, and feel part of a community—even when each person is working from a different city, country, or home.
For us, remote work is not simply about connecting from anywhere. It is about creating the conditions for LATAM talent to do high-level engineering, collaborate with global teams, and continue developing professionally without losing sight of something essential: behind every commit, every architecture decision, and every product, there is a person.
That is also the community we want to keep building at Mismo: one where technical talent has room to grow, where great ideas can come from anywhere in LATAM, and where doing great work still leaves room for a great life outside of work.
Because our region is already helping build the future of technology.
Now we also have the opportunity to build a more human and sustainable way of working within it.
