DEV Community: Victor A. Barzana

I Threw Away My Dev Coffee Cup This Morning

Victor A. Barzana — Wed, 07 May 2025 07:44:41 +0000

This morning, during my usual coffee routine, I finally decided to get rid of my old developer cup. I had been thinking about it for a while. It used to have that iconic meme:

"My code works, I don't know why. My code doesn't work, I don't know why."

I realized I no longer resonate with that quote. In fact, I felt weird even showing that cup during meetings. Why? Because it’s not true anymore.
I always know why my code works.

After 9 years of formal study, 4 as a Computer Technician and 5 as a Software Engineer in Cuba, followed by 13 years in the industry working in Germany, Latvia, and Finland, I’ve built software for companies of all sizes and developed a deep-rooted expertise in the craft. From creating games in C#, to building full-stack frameworks from scratch in PHP, developing real-time WebSocket demos for the community, building scalable SaaS applications and and tackling complex projects for both startups and big cap enterprises, I’ve simply outgrown that meme long time ago!

The Early Years: Embracing Chaos

In your first few years of software development, things often feel like magic. You write code, and sometimes it works—even when you don't understand how. Other times, it doesn't work, and no amount of Googling, Stack Overflow diving, or rubber ducking seems to help.

This is normal. Every developer goes through it.

When you're just starting, your mental model of how systems work is incomplete. Programming languages, frameworks, compilers, async behavior, state management, edge cases, and debugging tools are still new territory. You're learning to drive while also trying to build the car.

Mid-Level Mastery: Patterns Start to Emerge

Eventually, things begin to make more sense. You start to see recurring problems and recognize common solutions. Your bug reports get more precise. You rely less on hope and more on logic. You learn to read stack traces, track memory leaks, and use tools like debuggers and profilers effectively.

You still hit unknowns, but now you know how to approach them.

Senior Level and Beyond: Clarity Over Luck

When you become truly experienced, the days of "I don’t know why" become rare. Instead of guessing, you investigate. You build systems with observability in mind. You write tests to cover edge cases before they bite you. You review logs and metrics before bugs become critical. You code defensively, architect with intention, and apply experience to avoid known pitfalls.

You no longer celebrate when your code works – you expect it to, because you've built it deliberately.

The Meme Still Resonates (And That’s Okay)

Even the best developers hit walls. APIs change, infrastructure evolves, and no one is immune to edge cases or integration nightmares. But the key difference is: experts have the mindset, tools, and experience to figure out why.

So next time your code works and you don’t know why, laugh it off—and then dig in to understand it. Every bug is a chance to learn. Every surprise is an opportunity to grow.

A Personal Note from the Trenches

Now, I’m riding the wave of the AI coding trend. People criticize it a lot, but it's an incredibly powerful tool. You can build full applications in just hours. This not only shifts the market but redefines the developer role. I believe that soon developers will evolve from writing code to reviewing it. No matter how deep your knowledge of syntax, data structures, algorithms, or architecture goes, AI will eventually surpass it all. There's no stopping it.

Sometimes I build complete designs in Lovable.dev, download them locally, continue development in Cursor, and integrate prototypes with any backend framework I need. And the most important skill? Experience. The more you have, the better your reviews of AI-generated code will be.

Sure, AI messes up sometimes. But that’s what the review process is for. I have AI make pull requests, and then I use tools like Coderabbit to review that AI-generated code—yes, AI reviewing AI. Add a strict code coverage policy on top of that, and I can rest easy knowing any change is well-tested and safe.

Welcome to the new age of development. Review-driven. AI-accelerated. Experience-backed.
Thank you for reading!

Enhancing Pino to Support (Message, Payload) Logging Without Breaking Pretty Logs

Victor A. Barzana — Wed, 19 Mar 2025 12:14:04 +0000

Introduction

Pino is a blazing-fast logging library for Node.js, built for structured logs and high performance. However, one common frustration developers face is that Pino does not natively support logging a message alongside an object the way console.log does.

Note: this is my approach and a solution that works well for me. If you have any suggestions, improvements, or use a different method in your projects, I’d love to hear your thoughts!

Migrating to Pino: Common Pitfalls and Issues

When migrating an existing codebase to Pino—whether from Winston, another logging framework, or even the raw console API—you may expect it to work similarly. However, Pino handles logging differently, requiring adjustments to your log statements.

1️⃣ See for example, logs that work in console or Winston but fail in Pino

console.log('User created', { userId: 123 });
logger.info('User created', { userId: 123 }); // Winston

Expected Output:

INFO  [12:30:45]  User created { userId: 123 }

Pino Output (Incorrect):

INFO  [12:30:45]  User created

🚨 The second argument is ignored because Pino expects an object as the first argument.

2️⃣ Using `%j` to Force JSON Logging

logger.debug('User created %j', { userId: 123 });

🚨 While this works, it flattens the JSON into a string:

DEBUG  [12:30:45]  User created {"userId": 123}

This prevents structured log processors from parsing the data properly.

3️⃣ Moving Messages Inside JSON

To properly log both the message and object, you might be forced to rewrite logs like this:

logger.info({ msg: 'User created', userId: 123 });

✅ This works with structured logging but requires changing every log statement in your codebase.

4️⃣ The `%j` Issue With Errors

If you log errors using %j:

logger.debug('hello %j', { error: new Error('some crazy error') });

🚨 The error loses its stack trace and serializes incorrectly:

DEBUG  [12:30:45]  hello {"error":{}}

With our fix:

logger.debug('hello', { error: new Error('some crazy error') });

✅ Logs correctly in dev mode with pino-pretty:

DEBUG  [12:30:45]  hello 
{
  "error": {
    "type": "Error",
    "message": "some crazy error",
    "stack": "Error: some crazy error
 at file.js:12:34"
  }
}

✅ Fixed Behavior: Error Serializer Works in Dev Mode

With our fix:

logger.debug('hello', new Error('some crazy error'));

🎉 Logs correctly in development environments with pino-pretty:

DEBUG  [12:30:45]  hello 
{
  "error": {
    "type": "Error",
    "message": "some crazy error",
    "stack": "Error: some crazy error
 at file.js:12:34"
  }
}

✅ Preserves the error stack trace.
✅ Works seamlessly in pino-pretty and JSON logs.

The Right Fix: Supporting `(message, payload)` While Preserving Pino's Structure

To fix this behavior, we need to:

✅ Detect when the first argument is a string and second is an object.
✅ Ensure %s, %d, and %j placeholders still work correctly.
✅ Preserve Pino’s structured JSON logging.
✅ Ensure compatibility with pino-pretty, transports, and serializers.

Let's fix your logger.ts file with just a few lines

import pino, { LogFn, Logger, LoggerOptions } from 'pino';

const isDevelopment = process.env.NEXT_PUBLIC_NODE_ENV === 'development' || process.env.NODE_ENV === 'development';

const pinoConfig: LoggerOptions = {
  level: process.env.LOG_LEVEL || 'debug',
  // We recommend using pino-pretty in development environments only
  ...(isDevelopment
    ? {
        transport: {
          target: 'pino-pretty',
          options: { colorize: true, translateTime: 'HH:MM:ss Z', sync: true },
        },
      }
    : {}),
  hooks: { logMethod },
  timestamp: pino.stdTimeFunctions.isoTime,
  serializers: {
    err: pino.stdSerializers.err,
    error: pino.stdSerializers.err,
  },
};

const logger = pino(pinoConfig);

function logMethod(this: Logger, args: Parameters<LogFn>, method: LogFn) {
  // If two arguments: (message, payload) -> Format correctly
  if (args.length === 2 && typeof args[0] === 'string' && typeof args[1] === 'object' && !args[0].includes('%')) {
    const payload = { msg: args[0], ...args[1] };

    // If the object is an Error, serialize it properly
    if (args[1] instanceof Error) {
      payload.error = payload.error ?? args[1];
    }

    method.call(this, payload);
  } else {
    // any other amount of parameters, or order of parameters will be considered here
    method.apply(this, args);
  }
}

export default logger;

How This Fix Works

✅ (Message, Payload) Now Works as Expected

logger.info('User created', { userId: 123 });

➡️ Logs correctly:

INFO  [12:30:45]  User created { userId: 123 }

Before: ❌ Second argument ignored

Now: ✅ Structured properly.

✅ Preserves String Interpolation

When a string interpolation is present in the message, we fallback to the default behavior of Pino to handle string interpolations. See pino docs for more details: https://github.com/pinojs/pino/blob/main/docs/api.md#logmethod

logger.info('User %s created with ID %d', 'John', 123);

➡️ Logs:

INFO  [12:30:45]  User John created with ID 123

✅ Ensures Error Serialization Works

logger.error('Something went wrong', new Error('Oops!'));

➡️ Logs:

ERROR [12:30:45]  Something went wrong { error: { msg: 'Oops!', stack: '...' } }

Before: ❌ Pino didn't include the error in the logs
Now: ✅ Uses Pino's error serializer.

Why I believe This Fix is The Right Approach

Respects Pino’s structured logging (doesn’t mutate logs).
Fully supports pino-pretty formatting.
Doesn’t break child loggers, transports, or serializers.
Makes Pino more intuitive without hacks.

Final Thoughts

With this fix:

Pino behaves the way you expect.
Messages and objects log together properly.
Pino remains fast, structured, and developer-friendly.
If you have a big codebase based on console logging API or Winston, your transition to Pino will be very smooth.

Happy coding!

Big news, I was ascended from Team Lead to CTO of tourware GmbH

Victor A. Barzana — Wed, 01 Dec 2021 05:17:26 +0000

This definitely got me by surprise, today I was told that I am gonna be the new CTO of tourware GmbH. I really wasn't expecting that so many years of dedication and love into this project would give me such an opportunity and when less you think of it, bum, CTO in one day.

What is tourware GmbH?

tourware GmbH is a small startup with big dreams, one of the German leading tour operator software providers with a growing customer base. At tourware we implement cutting edge technologies and we love what we do, by the looks of it our customers too :) We have launched in less than a year of work, a brand new cloud for tourism agencies and a complete integration with customer websites in different platforms (Wordpress, Angular, Vue) and other technologies. With the help of our team we have developed an API that allows our customers to access their travels via a REST API allowing us to expand fast.
Our main packages offer under a suitable monthly price for tour operators, a brand new website or integration with the existing customer websites and a fully featured backoffice where users can customize their website, create travel packages, itineraries, manage their contacts, accommodations, suppliers, prices, and everything is publicly online in customers website once you click save. If you are in the tourism industry, you may know that any tourism software will cost you big money and you not always get the best out of it. What I like the most about tourware is that our product is simple, modern and very solid.

As the CTO what will be my job from now on?

With many years developing Software Applications, focusing on the budget has not been my main goal, but mostly orchestrate things to work good and performant. However, from now on, my biggest goal should be to focus on saving costs to the company by taking life changing decisions not only for me, but for the complete infrastructure, for our team, and more importantly for our customers.
As many of you may already know, dealing with tourism sector is always complex, especially when you deal with multiple tour operators all in one cloud. Everyone has different needs, and let's not even get started talking about prices calculation, everyone does it different. Now imagine writing an endpoint that does this in a way that suits everyone.
I still need to learn a lot about being a CTO, this is definitely going to be a wonderful experience and a looooooong career.

Will I be able to get back to the code?

I have been thinking about this, but I would say this is mostly a question for the community, it would be nice to hear your story the pros and cons and maybe what and what not to do being a CTO. I think that from now on, I should not only emphasize on code quality, but for sure I can't block myself anymore in coding tasks, the most important is to be able to pass on to my colleagues my experience, explain what I think is correct and what is not, but more importantly listen to everyone and be the connector between business and technology, something that we have been striving for.

What the future awaits...

With a growing customer base at tourware, we have many chances to become the next multimillion tourism industry, we just have to keep working hard as we have proven so far, increase our team and keep an eye on costs to not explode. I am sure that I will be able to manage my new role, can't be happier and more thankful to our CEO Simon Milz for giving me this opportunity.

Let's meet in ITB Berlin

This will also be my first year when I join to the ITB Berlin event, so if you are around I will be happy to talk with you.

Conclusions

I am thrilled with this new opportunity, happy to be able to sail this boat alongside my team, I am still a newby in the CTO field, but for sure will be able to handle this as I did before in other fields of my career.
If any of you have experience with being CTO and you want to give me an advice, I am open to listen to everybody. Thank you for reading.

PS: Next article goes to our infrastructure and how we manage to scale NodeJS/MongoDB to the heaven :)