From Flowcharts in a Notebook to Node.js: Ariel Díaz on Learning to Code the Hard Way

Before Ariel Díaz ever sat down to write a line of code, he was solving homework assignments that weren't his.

A friend enrolled in an algorithms class at a nearby university sparked something in Díaz that he couldn't set aside. He wasn't registered for the course. He attended no lectures. But every assignment his friend brought home, Díaz worked through anyway — filling a notebook with flowcharts, nudging his way up to pseudo-code, turning abstract logic into something he could hold on paper. By the time his own algorithms class arrived, he already knew the material cold.

In this story, Díaz — an X-Team software developer working in Node.js, React, Redux and MySQL — traces the path from those hand-drawn exercises to the asynchronous JavaScript patterns that changed how he thinks about code, and explains why the pursuit of perfection can be a developer's biggest trap.

The Notebook Before the Compiler

The book that set Díaz on his way was La esencia de la lógica de programación, recommended by a friend who had received a scholarship at another university. Díaz worked through every exercise by hand. Flowcharts first, then pseudo-code — before he had ever touched a real programming environment.

His first language was Pascal. It was not, he acknowledges, the most feature-rich option, but the match with his background made it work. "The statements were very similar to the pseudo-code I was used to," he says. The procedural version of the language introduced him to variables, conditions, functions and modules — and, memorably, the `goto ` statement he used to build an elevator simulator for a class assignment.

He remembers late nights debugging with a friend, both of them on TeamSpeak, the Pascal IDE's distinctive blue screen glowing in the dark. It was unglamorous work, but it built a foundation. By the time he moved beyond Pascal, the fundamentals had been drilled in by hand, one exercise at a time.

The Moment Asynchronous Code Clicked

In 2014, Díaz joined an outsourcing company in a nearby province, working on a team responsible for migrating legacy sites into a custom CMS. One of the tools in the stack — built in Node.js — used promises to write data to a server. For someone who had come up through Pascal, C++ and PHP, it was disorienting.

"Asynchronous code was a thing I couldn't digest at first," he says. Then, one day, it clicked. The promise-based approach suddenly made sense: a request could process one article without blocking others, which was essential when running hundreds of thousands of requests against different servers across multiple migrations.

What sealed his appreciation for the pattern were the JavaScript updates that followed. Arrow functions, introduced in ECMAScript 6, and the `async`/`await` keywords, introduced in ECMAScript 2017, let him express the same ideas with far less ceremony — no deep indentation chains, no callback hell. "You can define your procedures as if they were regular synchronous code," he says, "while preserving the advantages of its asynchronous counterpart." He wishes he had had them during the migrations.

"Perfect Is the Enemy of Good"

Díaz describes himself as someone who has always been obsessed with writing clean code — to the point where, early in his career, he estimates he spent roughly three-quarters of his time making sure every line was exactly right. The tool that helped him break that habit was Prettier.

Prettier imposes formatting rules — things like an 80-character line limit — across a codebase automatically. What Díaz values is not the specific rule but what it represents: a team agreement that makes readability a shared standard rather than a personal crusade. With the formatter handling consistency, he could stop agonizing over individual lines and focus on what he was actually building.

That shift in thinking shapes the advice he gives to developers starting out. "Perfect is the enemy of good," he says. Being able to recognize when something is good enough to move to the next task is, in his view, critical for both progress and for sanity. "I'm not saying you shouldn't code as if the world is looking over your shoulder," he adds, "but pursuing perfection is not a thing you should do if you want to stay productive and accomplish new goals in both code and life."

After nearly a year at X-Team, it is the same principle he applies to his own work: ship clean, stay moving.

Ready to build work you're proud of? Apply for an open role at X-Team.