DEV Community: Renato

How I Beat Procrastination on My Side Project

Renato — Fri, 09 May 2025 15:19:58 +0000

It happens to many of us: you start a side project excited, but then progress slows down. Things stall, the next task looks too big, and you start putting it off. I have this app idea (will talk about it on another post) that I've been trying to develop for a while, and I'm happy to say I'm very close to the MVP.

Not getting that project done was something that was making me frustrated for the past couple years. Having delivered multiple and way more complex projects at work, it was really bothering me that I couldn't finish my personal project.

So this year I decided I had to get this done, and this is the strategy I defined for it:

1. Use Task Management

Treat your side project like you treat your work tasks.

Pick a System: Use a Project Manager App, a simple to-do list, or even sticky notes. It doesn't matter what you use, just that you have a system to track what needs doing. Writing it down makes the plan clearer and less overwhelming.

2. Define a Clear MVP

Trying to do too much kills side projects. A clear Minimum Viable Product keeps you on track.

Focus on the Core: What's the absolute minimum needed to get a first working version out? Put off all the extra features until that core is done. Make sure your tasks aim straight for the MVP.

3. Break Tasks Down (A Lot)

If you tend to procrastinate, two things definitely contribute: when your next step isn't clear, or when it feels too big.

Make Them Small: Break features and fixes into tiny steps, ideally things you can finish in 30-60 minutes.
Get Quick Wins: Finishing small tasks feels good and gives you momentum. It makes it easier to spend an hour here or there, which adds up to real progress over time.

4. Use AI to Speed Things Up

Even experienced developers get stuck. Being a software engineer with over a decade of experience, I'm among the ones that make fun of the vibe coders generation. But don't be afraid of using AI to speed things up.

Get Unstuck Faster: If you're blocked, ask an AI for help getting started or figuring out a tricky part. And I'm not just talking about letting copilot predict what your new function does, don't be afraid of simply telling your favorite LLM what you want a screen or component to do.
Clean Up Later: You can always review and improve AI-generated code later. The main goal here is to avoid getting stuck and keep making progress.

5. Build and Test Early (Prototype)

Don't wait for the full MVP to see your ideas in action.

Get Something Running: Aim to get a basic, usable prototype working relatively quickly. In my case, applying the steps above got me a working version on my phone after about 10-15 hours of work spread across a few weeks.
Learn and Adjust: Testing even a simple prototype provides valuable feedback. It helps confirm if you're on the right track and might even lead you to adjust your MVP based on seeing how features work in practice.

Key Takeaways:

Plan Your Project: Use a task list or board, just like at work.
Make Tasks Smaller: Aim for tasks you can finish quickly, fitting them into small bits of free time.
AI for Speed: Don't hesitate to use AI, or even vibe coding, to get unstuck quickly. Review and improve the code later, but prioritize making progress.
Prototype Early: Build and test basic versions to get feedback and refine your goals.

Getting a side project done isn't about finding huge chunks of time. It's about setting up a way to make small bits of progress consistently. Little steps, done often, get the project finished.

In the Era of AI, Is Human Code Review Still Necessary?

Renato — Sun, 25 Jun 2023 11:00:00 +0000

AI is transforming the way we approach problem-solving and decision-making. With the rise of AI-powered tools and automated code analysis, some may wonder if human code review is still necessary. In the next lines I’ll explore 5 reasons why I believe human code review is still important for improving collaboration and code quality.

Complementing AI: The Power of Human Perspective

We can bring to code review what AI still lacks, such as context, experience and domain expertise. So while AI-driven code analysis tools are great recognizing patterns and common errors, we can take into consideration factors they might overlook, such as code readability, maintainability, and scalability.

Unleashing Creativity and Design Decisions

Code review isn't just about catching bugs. It involves assessing the overall design and architecture. We can dive into the nuances, evaluate design decisions, and offer valuable insights for improvement. They consider

Opportunity for Collaboration and Knowledge Sharing

Code reviews foster collaboration and knowledge sharing within development teams. It’s an opportunity for developers to engage in discussions, share insights, and mentor junior members. It creates learning opportunities, spreads best practices, and stimulates the exchange of ideas. Human interactions during code reviews can strengthen team unity.

Detecting Complex Logic and Edge Cases

AI tools excel at recognizing patterns and spotting common errors. But, they may struggle with intricate logic flaws or anticipating edge cases that need deep understanding of the application's requirements. Developers bring critical thinking to the table, catching potential pitfalls and ensuring the code meets desired business goals.

Beyond Technical Aspects

Code reviews is more than just technical aspects. They evaluate code readability, maintainability, and adherence to coding standards. We can assess the clarity of comments, naming conventions, and code organization, ensuring the codebase remains understandable and maintainable by the team in the long run.

Conclusion:

In the age of AI, human code review is still an important resource to have high-quality code and collaboration within the team.

While AI-powered tools automate certain aspects, they can't replicate the critical thinking, domain expertise, and contextual understanding that we can bring to it. By combining AI-driven code analysis with human code review, we can maximize the benefits of both approaches, resulting in stronger codebases, improved collaboration, and well-rounded developers.

Embrace the power of AI tools in code review, but remember that the human touch is irreplaceable.

Are your CICD and DevOps tools really making developers' lives easier?

Renato — Mon, 13 Feb 2023 11:00:00 +0000

If you are responsible for your team’s CICD and DevOps tools, have you ever asked yourself if the tools you built are really making developers' lives easier? Or are they there just to reinforce the rules you've set?

It's your responsibility to make sure the tools and procedures you've implemented are truly helping software developers do their job.

After setting your CICD tools, how frequently have you asked the developers for feedback? How many times have you changed/updated those based on feedback from the developers? Or are all your changes to support new requirements, infrastructure, and analysis tools?

You might think: “My tools are running code analysis, and automated tests, so they are helping the developers catch errors early.”. But are they?

I've discovered that one of the major reasons for bugs in many of my projects is that developers only test their code locally. My usual response to that was asking my team “Why aren’t you deploying to the dev environment to test it?”. And that would improve things for a while, then the same problem would come back.

Then, after a while, I decided to change my approach, and ask the developers what they thought of the DevOps tools we had, and some comments I heard were:

Code analysis and test automation are good, but do we really need those just to deploy to the dev environment?
The pipeline to deploy to the dev environment sometimes takes 15 minutes to complete.
I constantly have to wait for other developers to finish their tests before I can deploy my code to the dev environment.

At first it wasn't easy to admit I was not noticing those pain points, but I've decided to accept it, and started tackling those.

First: Make deployment to the dev environment as simple as possible.

I already had all my validations running in pull requests and other environments. So, for the dev environment, let's just keep it simple with just build and deployment.

Next: let’s shorten the time, by parallelizing all possible jobs.

Unneeded jobs were already removed, but maybe we can deploy the backend and frontend in parallel as well as any other jobs that also need to be executed.

Lastly: Why have only 1 dev environment? How about automating environment creation?

For this, you can integrate it with your project management tool. Every time a developer moves a card to “in progress” it can automatically create a new environment. You will, of course, need Infrastructure as Code to do that.

After those changes, the deploys to dev environment were more frequent, and the quality improved. But the developers didn't change their attitude just because it was faster to deploy, it was the fact that they felt they were being heard, and they could see the actions their feedback triggered, and that motivated them to contribute more to finding solutions for the problems we had.

And remember the cases presented here are just examples, these were the pain points of some of my developers. It might not be the same case for your team.

It's important to ask your team what they think. Do they find the tools and processes user-friendly and helpful, or are they a headache?

Think about it – CICD tools are supposed to support developers, not control them. That's why it's so important to regularly get the developers' input and make sure your tools and processes are working for them. The ultimate goal is to make the development process as smooth and stress-free as possible.

The pitfalls of unit test high code coverage and how TDD can mitigate them

Renato — Tue, 31 Jan 2023 11:00:00 +0000

High unit test code coverage is often viewed as a key indicator of code quality, and for good reason. It demonstrates that a significant portion of the codebase has been tested and is less likely to contain bugs. However, if you just see the numbers, how can you be sure that your business logic is covered? Or that your code is easy to maintain?

More often than it should, when you look at what is under that report, you will find poorly written unit tests, with the sole purpose of getting high code coverage.

The 2 most common pitfalls of high code coverage are:

Tests that deliberately leave out complex parts of the business logic, because writing those can take time, and focused on parts easier to test, like utility functions and data access layers.
Test that, at least in the reports, seem to cover business logic, but when you look at the tests you can’t tell what they are testing, so if they fail, you don’t really know why they failed.

Those can give you a false sense of security, when in reality, the most important part of the codebase is not being tested at all, leading to issues when a change in the business logic breaks the codebase, and the test suit is not able to detect it.

How to avoid those pitfalls?

To avoid these pitfalls, it's important to focus on the quality of the unit tests, not just the quantity. Here are a few best practices to follow:

Write tests that cover all aspects of the business logic, including complex parts. This will ensure that the most important parts of the codebase are being tested.
Use clear and descriptive test names and assertions. This will make it easy to understand what the test is checking for, and why it has failed.
Follow Test-Driven Development (TDD) principles. This approach encourages developers to write tests before writing the code, which can help ensure that the code is well-tested from the beginning.
In code reviews, give a special attention to unit tests. Are the tests are easy to understand? Are they really testing business rules? Or are they using meaningless values just to make sure they hit the conditionals?

How can TDD help?

Let’s see an example when building a feature to validate the password creation. The development team would receive a requirement like this:

The new password must be at least 8 characters long, and have at least 1 lowercase letter, 1 uppercase letter, 1 digit and a special character.

First without TDD

What is the first thing a dev who doesn't follow TTD will probably do?

After finding the regex they want on Google they will write a function like this:

function validateNewPassword(newPassword) {
  let passwordRegex = new RegExp(
    /^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[@$!%*?&])[A-Za-z\d@$!%*?&]{8,}$/
  )
  return passwordRegex.test(newPassword)
}

Then, time for the unit tests:

test('valid password', () => {
  expect(validateNewPassword('Abcdefg1!')).toBe(true)
})

test('invalid password', () => {
  expect(validateNewPassword('Abcdefgh1')).toBe(false)
})

Running the test, both tests would pass, and we would have 100% code coverage. Great, right?

Except there are 2 big problems with that approach.

First, the 100% test coverage was reached by testing only 1 out of at least 5 invalid password scenarios.

Second, Regex is not easy to understand, especially long expressions. And as the tests are not descriptive enough, if another developer had to change that code later, it would take a while to understand how the validation is done.

Now let's see how the code could be written differently by applying TDD.

Our first requirement is minimum length =8.
Let's write a test for that:

test('password minimum length', () => {
  expect(validateNewPassword('a'.repeat(7))).toBe(false)
})

And we start the implementation by applying just making that first test pass:

function validateNewPassword(newPassword) {
  if (newPassword.length < 8) {
    return false
  }
  return true
}

OK, now the second requirement. At least one uppercase letter.
Let's write a test for that:

test('password must contain at least one uppercase letter', () => {
  expect(validateNewPassword('abcdefgh1!')).toBe(false)
})

To make this test pass, we can add a check for uppercase letters in our validation function:

function validateNewPassword(newPassword) {
  if (newPassword.length < 8) {
    return false
  }
  if (!newPassword.match(/[A-Z]/)) {
    return false
  }
  return true
}

Now, lowercase letters:

test('password must contain at least one lowercase letter', () => {
  expect(validateNewPassword('ABCDEFGH1!')).toBe(false)
})

And we add the lowercase validation to our validation function:

function validateNewPassword(newPassword) {
  if (newPassword.length < 8) {
    return false
  }
  if (!newPassword.match(/[A-Z]/)) {
    return false
  }
  if (!newPassword.match(/[a-z]/)) {
    return false
  }
  return true
}

Next, let's move on to the next requirement: at least one digit.

test('password must contain at least one digit', () => {
  expect(validateNewPassword('Abcdefgh!')).toBe(false)
})

To make this test pass, we can add a check for digits in our validation function:

function validateNewPassword(newPassword) {
  if (newPassword.length < 8) {
    return false
  }
  if (!newPassword.match(/[A-Z]/)) {
    return false
  }
  if (!newPassword.match(/[a-z]/)) {
    return false
  }
  if (!newPassword.match(/\d/)) {
    return false
  }
  return true
}

Finally, let's test for the last requirement: at least one special symbol.

test('password must contain at least one special symbol', () => {
  expect(validateNewPassword('Abcdefgh1')).toBe(false)
})

To make this test pass, we can add a check for special symbols in our validation function:

function validateNewPassword(newPassword) {
  if (newPassword.length < 8) {
    return false
  }
  if (!newPassword.match(/[A-Z]/)) {
    return false
  }
  if (!newPassword.match(/[a-z]/)) {
    return false
  }
  if (!newPassword.match(/\d/)) {
    return false
  }
  if (!newPassword.match(/[@$!%*?&]/)) {
    return false
  }
  return true
}

Now we have a validation function that follows the requirements, and is well-tested. Additionally, the tests are now more descriptive, so it's easier for other developers to understand how the validation works.

But some might say: "look at all those if's, it doesn't look good". Ok, let's rewrite it for readability:

const LOWERCASE_REGEX = /[a-z]/
const UPPERCASE_REGEX = /[A-Z]/
const DIGIT_REGEX = /\d/
const SPECIAL_CHAR_REGEX = /[@$!%*?&]/

function validateNewPassword(newPassword) {
  return (
    newPassword.length >= 8 &&
    LOWERCASE_REGEX.test(newPassword) &&
    UPPERCASE_REGEX.test(newPassword) &&
    DIGIT_REGEX.test(newPassword) &&
    SPECIAL_CHAR_REGEX.test(newPassword)
  )
}

And our unit test file would look like this:

describe('Password validation', () => {
  test('password minimum length is 8 characters', () => {
    // refactored after the first example to make sure the only reason for the test to fail is the length
    expect(validateNewPassword('Abcde1!')).toBe(false)
    expect(validateNewPassword('Abcdef1!')).toBe(true)
  })

  test('password must contain at least 1 uppercase letter', () => {
    expect(validateNewPassword('abcdefgh1!')).toBe(false)
    expect(validateNewPassword('Abcdefgh1!')).toBe(true)
  })

  test('password must contain at least 1 lowercase letter', () => {
    expect(validateNewPassword('ABCDEFGH1!')).toBe(false)
    expect(validateNewPassword('AbCdefgh1!')).toBe(true)
  })

  test('password must contain at least 1 digit', () => {
    expect(validateNewPassword('Abcdefgh!')).toBe(false)
    expect(validateNewPassword('Abcdefgh1!')).toBe(true)
  })

  test('password must contain at least 1 special symbol', () => {
    expect(validateNewPassword('Abcdefgh1')).toBe(false)
    expect(validateNewPassword('Abcdefgh1!')).toBe(true)
  })
})

By following these best practices, not only you can ensure that your unit test code coverage is an accurate indicator of code quality, and that your business logic is well-covered. But you can also improve the maintainability and readability of your code.

Time to give back to the Dev community

Renato — Mon, 05 Sep 2022 01:07:22 +0000

After eight years in software development, I decided it was time to contribute more to the developer community. And you know what? It feels good. So in this post, I want to share a few ways I found to contribute.

When I first had this plan, the idea was to write lots of blog posts with many tutorials and "How to" content.

Well, that didn't actually happen. But I've realized there are many other ways to contribute. And most of those are things that were part of my routine, I just had to do it for a broader audience.

Stack Overflow, there is more to it than just answering questions.

So another one of my first ideas was to start answering questions on Stack Overflow. Which I did, and still do, maybe not on a regular basis.

My strategy was to go through the list of questions quickly, and answer the questions I had the solution out of the top of my head.

After doing that a few times, I noticed that I couldn't answer many questions. Not because the problem was too difficult, but because the question was not clear.

That reminded me of junior developers at work coming to me for support. And how many times I had to ask the junior developer to stop and start again. This time, I would ask the questions to understand the problem better. What are you trying to accomplish? What have you tried so far?

With this realization, I could see the real value of the edit and comment features of Stack Overflow. Even if I might not have the answer to the posted problem, I could at least help them make it more clear so other contributors could answer it.

1 on 1 coffee chats

On my journey to contribute more, I started to engage more on Twitter. There is where I found out about the #100devs, this great initiative from Leon Noel to teach new developers from zero.

The people doing the BootCamp formed an impressive big community, and somehow I was in one of their threads. And they were talking about coffee chats. Where they would have quick talks with developers already working in the industry.

So I started to make myself available for those. Quick 15~30 minutes call. And the topics can vary a lot. From how I started, to technologies and skill I think are worth studying.

And those talks were really interesting. Talking with these people eager to start a software development career can give you a real boost to your motivation as well.

Conclusion (TL;DR)

I believe many devs like me don't know how to start when they want to contribute more to the community. And i hope that with this post you can see that you don't have to answer really complex questions on Stack Overflow, or write tech tutorials (I haven't given up on that one, though).

Here I gave just to simple ideas of how you can easily start contributing without having to commit too much of your time to it. By simple being available for a quick call, or making Stack Overflow questions more clear.

If you have found other ways to do it, please leave your ideas in the comments.

Image by alvaro_cabrera on Freepik

The constant change of technologies may sound bad for your career, but it can actually help you.

Renato — Tue, 08 Feb 2022 14:44:55 +0000

When starting a developer career, you might think it’s a good idea to focus and master a particular technology or one small set of technologies. I know that at least I did. But it didn’t take long for me to change my mind.

I started my career as a .Net developer. And at first, I was enjoying the technology, and focusing on it seemed a good idea. But one year later came the first opportunity to change technologies.

The company I worked for had just signed one of their biggest clients, and it was a huge mobile project. With that came an offer to train me in iOS development if I was willing to change technologies.

If it were any other technology, I would have said no. But Apple products in Brazil are expensive, making iOS developers rare and their salaries quite high. So I went for it. That was my first career bump due to technology change.

After that, I changed projects a few more times, jumping back and forth between iOS and .Net. The more I demonstrated handling both technologies well, the more I had managers requesting me in their projects. And I used that to argue for a promotion. Second career bump, thanks to changing technologies.

Not long after that, an opportunity to be transferred to Japan was announced.

I applied to it, as well as dozens of my colleagues. So I thought my chances were slim.

But I still managed to be among the selected ones. And when I asked the managers why they picked me, they said “How fast you can navigate between different technologies” was one of the main reasons. And that is the third career change, now a big international transfer from Brazil to Japan.

In Japan, in a smaller office with a reduced development team, developers, more than ever, had to be able to adapt fast to new technologies.

At this point, my mindset had shifted entirely into the pro-change mode, and I embraced as many technologies as possible. But I’m not going to lie, saying all changes were as exciting as my first migration to mobile development. But I’ve never passed on an opportunity to change.

That lead me to work with: .Net, iOS, Kotlin, Drupal, PHP, Nodejs, Python, Typescript, Reactjs, Vuejs… Some were really cool, others really boring. But they all helped me get where I am today.

If a stack change didn’t open doors for me later, it for sure made me a better developer/architect. Being exposed to different ways of solving the same problem will really change how you think and improve your problem-solving skills. And that is what being a developer is all about, solving problems.

Now, many years have passed. I took the Software Architecture path in my career. Changed jobs. And I’m now able to be the architect for different projects with completely different technology stacks.

Conclusion (TL;DR)

I don’t know where I would be if I said no when I had the chance to change my career from .Net to iOS. Maybe I would have mastered .Net know all the details of the framework and the language.

But what I do know is changing technologies opened the door for promotions, international transfer, and even new jobs.

Just getting exposed to different technologies can open your mind, change how you think when solving problems, and make you a better developer.

So even if you don’t have the chance to do it at work, I definitely recommend you do it on your side projects.

Why I chose Jekyll for my personal site

Renato — Fri, 07 May 2021 02:31:20 +0000

Why I decided to create my own blog on Github Pages with Jekyll instead of using popular platforms like Medium, Dev.to, or Hackernoon.

When I first came up with the idea of creating a blog, Medium seemed the right choice. Popular platform, no concerns about hosting or configuration. I could just start writing.

But I stopped for a moment and decided to do a little research on Medium. And I found some concerns about the paywall, user tracking, and other issues. This already made me rethink the idea.

Then, I also found this article called Medium Was Never Meant to Be a Part of the Developer Ecosystem, and it made me see how all the Medium restrictions and policies actually make it harder for us developers to find the information we need.

After that, I gave up on Medium.

OK, Medium is not fit for Developers. But what about the other platforms?

The research about Medium made me cautious about the others as well. So I did my research on each of the platforms, but different from Medium, I didn't find anything to be concerned about.

Actually, reading the "About" section for both Dev.to and Hackernoon I found out they both have good policies and the goal of having an open space for developers to share knowledge. And I was really considering writing directly in one of those.

That was when I found a post about Why you should not publish content on Dev.to and why we should follow the POSSE principle.

Publish (on your) Own Site, Syndicate Elsewhere

After reading that, I started to like the idea of having my own blog and using Dev.to and Hackernoon to share it.

But why not WordPress or any other CMS?

Well, I had my experience with WordPress years ago. Setting up a host for it, plus all the trouble for the configuration didn't seem worth it.

Then I remembered GitHub Pages and the fact that it supports Jekyll. GitHub would provide free hosting, and Jekyll would allow me to blog by simply committing markdown files.

Free hosting with custom domain support, plus being able to blog from my IDE? That sounded really good.

So I decided to give it a try. And with only 2 hours I got it up and running. (most of the time was spent deciding on the theme)

Now, here I am, writing my first post.

Conclusion (TL;DR)

If you are writing to help other developers, Medium, with its paywall and other limitations, doesn't seem the right platform for it.

Dev.to and Hackernoon are good platforms for developers. And I definitely recommend those if you don't want the trouble of hosting your blog, worrying about a theme, and so on.

But if you want the advantages of actually owning your content, without spending too much time setting up a host and configuring a blogging tool, GitHub Pages and Jekyll might be a good choice for you, and you can still use Dev.to and Hackernoon to share your content.