DEV Community: João Felipe

You should be this type of developer

João Felipe — Thu, 13 Feb 2025 16:46:21 +0000

🎯 Introduction

There are a lot of developer types, but this one is always a good fit for the most projects or companies.

Have you ever worked with a developer who just ‘gets’ the product? Someone who doesn’t just code but also thinks about the user experience, business impact, and long-term product vision? That’s what a Product-Minded Developer is all about.

We have many benefits having this type of dev in our team:

Users: Usually, they think about the user experience first, not just about tech.
Context: Mainly because this dev has a lot of context about all the product, it's easier to create new features in different parts of the app.
Communication: Normally, the product-minded developers have a good relation with non-tech people, probably because they make sure to have an understandable communication (E.g., if the API endpoint is down, they can explain it to the product owner not using technical terms).
Time: They can save a lot of time for the team, because they can understand the product better.

For now, we'll explore some ways to be a product-minded developer.

🧠 A little obvious, but: Understand the product

The first step to be a product-minded developer is to understand the product.

You should ask questions, and you should be curious about the product. Make sure you know what problem the product is solving, and how it's being used.

Try to answer questions like:

What problem is the product solving?
Who is the product for?
How is the product being used?
What are the main features?

Tip: take a deep look at the landing page product, usually we have a really good summarized version of the product there.

👥 Get to know the users

You should know who the users of the product are, and what they expect from the product.

Try to answer questions like:

Who are the users?
- Normally, are they using the product on desktop, mobile, or both?
- What about the age? Are they already experienced or not?

For example, if the product you're working on is a CRM system, probably the device more used is desktop, so we don't need to care so much about the mobile experience.

❓ New features: a new opportunity to ask questions

When you're working on a new feature, you should ask questions about the feature.

Try to answer questions like:

What problem is the feature solving?
Why are we fixing this problem in that way and not in another?
Who is the feature for?

💼 Consider business goals, not just tech ones

When you're working on a feature or a bug, you should consider the business goals.

Try to answer questions like:

This piece of code is solving a problem, but is it solving the right problem?
Is this feature helping the business to achieve the goal?
Is this bug affecting the business?
How are we adding value to the user?

We, as developers, are normally focused on the code and some topics like performance, architecture, and so on. But, sometimes, we have choices to make, and we should consider the business goals.

🤝 Your product manager is your best friend

Your product manager is your best friend. They can help you to understand the product better, and they can help you to understand the users better.

Your tech lead will review your code, but usually they are not the best person to ask about the product.

Before starting a new project, it would be nice if you schedule a meeting with the product manager to understand the product better and ask questions about the context/market/users/etc.

💡 Come up with suggestions

You should come up with suggestions about the product. Think about it: you're a developer in this project/product, but you're a user in another one.

Try to think as a user, and come up with suggestions about the product.

For example, I was working on a feature that the visual was a form and a preview in a grid template, if the user changes the form, the preview should be updated, something like that:

If the user tries to change a field below in the form, the preview is fixed at the top of the page, creating a bad user experience.

I've suggested to the team to make the preview sticky, so it will follow the user when they scroll down the form.

A simple improvement, but in a large-scale project, it can save a lot of time for the users and create a better vision for our product.

🔑 Key Takeaways

Product-minded developers go beyond coding—they understand the product, users, and business.
Asking the right questions is crucial when developing features.
Collaboration with product managers leads to better decision-making.
Small UX improvements can have a big impact on the overall experience.

🎬 Conclusion

Being a product-minded developer is more than just writing great code, it's about understanding the bigger picture. When you deeply understand the product, its users, and the business goals, you become a more valuable team member, capable of making smarter decisions and delivering better experiences.

By asking the right questions, collaborating with product managers, and thinking beyond technical implementation, you can bridge the gap between development and product strategy. This mindset improves the quality of the product and makes your work more impactful and fulfilling.

At the end of the day, great products aren’t just built with great code, they're built with great perspective. So, be curious, stay engaged, and always think beyond the code! 🚀

How do you apply a product-minded approach in your work? Let’s discuss in the comments!

📝 Resources

The Product-Minded Software Engineer

Impostor Syndrome Doesn’t Define You, Dev

João Felipe — Fri, 25 Oct 2024 13:44:33 +0000

If you're a developer, you've probably experienced moments when you lack confidence in making decisions or feel like you don't deserve to be where you are.

This feeling has a name: Impostor Syndrome. In this post, we'll explore some ways to deal with it.

Have a mentor

First of all, it would be really cool if you had a mentor, someone with more experience than you, probably some senior developer or tech lead from your company.

A mentor can guide you with the best practices, technically and non-technically (like communication or leadership).

With their experience, they can help you identify where you're doing well, where you're struggling, and where to focus your efforts. And this is awesome for you, if you know it, it's much easier to take the right steps to grow your skills and become a better developer.

Understand what they expect from you

You have a mentor, right? Now, you need to understand what is expected from you. To do this, my best advice is a little bit obvious but efficient: ask it.

"What do you expect from me?"
"In 6 months, what do I need to achieve for you to be sure that hiring me was worth it?"
"What are the characteristics you expect me to demonstrate in my daily work?"

You can schedule a call with your mentor/leader and ask some questions like that. You'll demonstrate interest, and you'll have the details of expectations.

Come up with a plan

You already know what they want from you, it's time to create a plan to achieve it.

There are a lot of ways to create this plan, you can select some books to read or even define some goals for your week.

But my main advice is: be practical. Create some tasks based on what they literally expected from you.

A communicative developer? Create reports every month to your leader with your best tasks.
A programmer addicted to learning/curious? Write some posts about your learning and share them with your coworkers.

In a nutshell, create practical tasks to achieve what they expect from you.

You'll not achieve all these skills overnight, relax and enjoy the process.

Ask for feedback, A LOT

How will you know if you are getting better or not? Feedback!

Seriously, feedback will be your best friend in dealing with imposter syndrome and being more confident. With it, you'll receive some compliments (it'll increase your confidence) and some negative reviews, which are ok, nobody is perfect.

"But how regularly should I ask for feedback?"

In my humble opinion: the more, the better. If you can ask it every single day, ask it.

Create something new

Sometimes, when you work on the same project/product for a long time, you'll feel that you are not learning or improving.

You'll say to yourself: "I'm doing the same thing every single day, it is not making me better.".

To keep learning and FEEL that you are learning, my advice is to create some personal projects. You can test that tool that you thought was nice, but your company does not use it.

Share this knowledge with the community, You can create a post on LinkedIn about your project and describe what you learned.

Be careful with AI

The AI is here to help our lives, Cursor is a good example. But be careful about it, tools like these can affect your confidence.

Have you ever felt indestructible when you finished a very hard task? Or when you finally discovered the solution to that problem, for example. Actions like these increase our confidence because they show that we can solve problems and create nice things.

You MUST practice your code skills, whether formatting some complex data, creating a more reusable component for FE, or learning what you should do to reduce the API response time. You must know how to solve these problems, not just how to create the best prompt to get the solution.

Summing up, use AI for productivity and automation, but not as a crutch.

Conclusion

To cut a long story short, this article described 6 topics that can help you to feel more confidence and improve your skills.

Moreover, the text makes it clear that you are not alone, you are not the first, and you'll not be the last who feels like a fraud.

Finally, feel free to share more ways to deal with this feeling.

Lefthook: benefits vs husky and how to use

João Felipe — Tue, 24 Sep 2024 20:58:28 +0000

In the world of Git hooks, two popular tools often come up: Lefthook and Husky. Both are designed to manage Git hooks efficiently, but they have different features and use cases. This article will compare the benefits of Lefthook over Husky and provide a step-by-step guide on how to use Lefthook in your projects.

Benefits of Lefthook vs Husky

Performance
Lefthook is known for its performance. It is written in Go, which makes it faster and more efficient compared to Husky, which is written in JavaScript. This can be particularly beneficial for large projects with many hooks.
Parallel Execution
Lefthook supports parallel execution of hooks out of the box. This means that multiple hooks can run simultaneously, reducing the overall time taken for pre-commit or pre-push operations. Husky, on the other hand, executes hooks sequentially.
Configuration
Lefthook uses a YAML configuration file, which is straightforward and easy to read. Husky uses a JSON configuration, which can be less intuitive for some users.
Language Agnostic
While Husky is tightly integrated with Node.js and npm, Lefthook is language-agnostic. This makes Lefthook a better choice for projects that are not primarily JavaScript-based.
Flexibility
Lefthook provides more flexibility in terms of hook management. It allows you to define hooks for different environments and conditions, making it a versatile tool for various workflows.

How to Use Lefthook

Step 1: Install Lefthook

First, you need to install Lefthook, one of the most used ways is with NPM:

npm i -D lefthook

You can check the other methods here.

Step 2: Install Dependencies

Before setting up our scripts, we need to install the necessary dependencies. Typically, we use ESLint and Prettier for code linting and formatting. Install these dependencies by running:

npm i -D eslint prettier

Step 3: Add lint and format scripts to package.json

Typically, in our projects at Quave, we include three scripts in our package.json file: one for ESLint, one for Prettier, and a combined script that runs both. This combined script is usually what we use as our pre-commit hook. Here's how you can set up these scripts:

Add the following to your package.json file:

"scripts": {
  "lint": "eslint . --fix",
  "format": "prettier --write \"**/*.js\"",
  "check-code": "npm run lint && npm run format",
},

These scripts allow you to:

Run ESLint with auto-fix (lint)
Run Prettier to format your code (format)
Run both lint and format in sequence (check-code)

The check-code script is what we typically use in our pre-commit hook to ensure both linting and formatting are performed before each commit.

Step 4: Configure Lefthook

Create a lefthook.yml file in the root of your project. This file will define the hooks you want to use. Here is an example configuration:

pre-commit:
  commands:
    check-code:
      run: npm run check-code
    update-index:
      run: git update-index --again

This is a base example that we use here at Quave. We added the check-code to run our eslint and prettier.

The update-index command is crucial here. When we run ESLint with the --fix option and Prettier, they modify our files to fix linting issues and format the code. These modifications would normally be left unstaged, meaning they wouldn't be included in the current commit. By running git update-index --again, we ensure that these automatic fixes are included in the current commit. This prevents a situation where you'd have pending changes to commit immediately after making a commit.

Step 5: Initialize Lefthook

Navigate to your project directory and initialize Lefthook:

lefthook install

This command will create a .lefthook directory in your project.

Step 6: Use Quave ESLint config (Optional, but recommended)

Install the npm dependency

npm i -D @quave/eslint-config-quave

Add to the root of your package.json

  "eslintConfig": {
    "extends": [
      "@quave/quave"
    ]
  },

Create in the root of your project prettier.config.js file and paste this

module.exports = require('@quave/eslint-config-quave/prettier.config')

Also, you can create a file called .prettierignore, this file is used to tell Prettier to ignore certain files or directories from being formatted.

Step 7: Run Lefthook

Now, when you commit or push changes, Lefthook will automatically run the defined hooks. You can also manually run Lefthook to test your configuration:

lefthook run pre-commit

Conclusion

Lefthook offers several advantages over Husky, including better performance, parallel execution, and greater flexibility.

By following the steps outlined above, you can easily set up and configure Lefthook in your project, ensuring that your Git hooks run efficiently and effectively.

Whether you are working on a small project or a large codebase, Lefthook can help streamline your development workflow.

Boosting UX: How I Transformed Data Management in Our App with this lib

João Felipe — Thu, 09 May 2024 17:57:49 +0000

In this article, I'll talk about the time I improved the UX in software I'm currently developing at work just using this lib: React Query (or TanStack Query).

🚨 The Problem

In this software, we have a lot of lists and tables, being able to access the details of this data. Something like that:

But every time the user click on table row, goes to detail page and return to the table page, all data starts reloading...

We was using the useEffect pattern: create the request function, trigger inside an useEffect and put the data in a state. We used to create some Context too, trying to create a kind of entity hook, like useUser or useNotification.

But calm down, we already fetched this data, how can we improve the UX?

💡 The Game-Changing Solution

When I asked myself this question it coincided with the time I was studying more ways to scale frontend applications in different aspects, such as request management.

And it was the perfect match ✨: why not start to use React Query to scale the app and, at same time, improve the UX navigation?

🔎 How

Service Separation: Before we only had the request functions inside a Context and trigger these functions inside an useEffect. But We decided to migrate API requests to a dedicated services folder, neatly organizing functionality by entity.

const getUser = async () => {
  const user = await api.get('/user');

  return user;
};

const userService = {
  getUser,
};

export default userService;

Query creation: We created a queries folder and put all the queries, separated by entity.

import { useQuery } from 'react-query';

interface UseUserParams {
  userId: string
}

export const useUser = ({ userId }: UseUserParams) => {
  return useQuery({
    queryKey: ['/user', { userId }],
    queryFn: userService.getUser,
    enabled: Boolean(userId)
  });
};

Empowering Components: With this, we can now use queries through components.

import { useUser } from '../../api/queries/user';

const Profile = () => {
  const userId = localStorage.getItem('userId');

  const { data: user, isLoading: isUserLoading } = useUser({
    userId,
  });

  if (isUserLoading) {
    return <span>Loading...</span>;
  }

  return (
    <div>
      <span>Name: {user.name}</span>

      <span>E-mail: {user.email}</span>
    </div>
  );
};

export default Profile;

⚠️ Not Every App, Every Time

While React Query revolutionized our UX, remember: not every application requires such finesse. Prioritize value addition, especially in MVP scenarios.

✅ Conclusion

With all these changes, We had some benefits:

Code level: Now we have a code that is more organized, reusable and not full of states, like isLoading or isError.
UX level: the user no longer needs to wait for new data, we show the "old" data while revalidating in the background.

As FrontEnd Engineers, our main stakeholder is the user, so if we can, we should improve the UX with code.

Do this and stop wasting time creating React components

João Felipe — Sat, 07 Oct 2023 18:36:23 +0000

In this article, I will talk about Plop, which is a little tool that saves you time and helps your team build new files with consistency, as the documentation suggests.

The Common Challenge

Let's suppose that for the architecture I'm using, I'm going to create a component called Button. In this architecture, I will create a folder called Button/ and the following files:

Button.tsx
index.tsx
styles.ts
Button.test.tsx
stories.tsx

And fill in a minimal amount of code in each of them to get started.

Doing all this takes a lot of time, right? 😭 Until now... Imagine doing this with one command.

The Ingenious Solution

With Plop, you'll automate all the entire file creation flow, you just need to create some configuration. Let's do this.

For this example, we'll focus on creating a React component, covering component and style files. However, you can adapt this workflow to other file patterns or extend it by including tests and stories for React components.

1. Installing Plop

Begin by installing Plop as a development dependency:

npm install --save-dev plop

2. Create a Plop Configuration

I recommend creating a folder called generators in the root directory and placing the plopfile.js inside it:

generators/
   plopfile.js
public/
src/
   components/

3. Initiating the Automation

With the plopfile created, we can start to create our generators:

module.exports = (plop) => {
    plop.setGenerator('component', {
        description: 'Create a component',
        prompts: [],
        actions: [] 
    });
};

In this configuration, you specify the generator name (in this case, 'component') and its associated configuration. The prompts will be the questions asked when you run the generator, and actions will define the steps to create the files.

Since we want to create a component, we need to get the component name, with this prompt:

module.exports = (plop) => {
  plop.setGenerator('component', {
    description: 'Create a component',
    prompts: [
      {
        type: 'input',
        name: 'name',
        message: 'What is your component name?'
      }
    ],
    actions: []
  })
}

So you set the prompt type (input to collect data), the name (like a variable name to use in the future), and the message (the question).

4. Create the Templates

Templates serve as the initial code structure for your files.

For this, create a templates folder within the generators directory:

generators/
   templates/
      Component.tsx.hbs
      styles.ts.hbs
   plopfile.js
public/
src/
   components/

Next, I will create two files: Component.tsx.hbs and styles.ts.hbs.

Component.tsx.hbs:

import * as S from './styles'

const {{pascalCase name}} = () => (
  <S.Wrapper>
    <h1>{{pascalCase name}}</h1>
  </S.Wrapper>
)

export default {{pascalCase name}}

You can notice that we use the {{}} syntax to define what will be dynamic in the file. Here, the component name (collected through the prompt) is used for variable names, component titles, and exports.

styles.ts.hbs:

import styled from 'styled-components'

export const Wrapper = styled.main``

5. Completing the Automation

Now, we just need to create the actions, right? So let's do this!

module.exports = (plop) => {
  plop.setGenerator('component', {
    description: 'Create a component',
    prompts: [
      {
        type: 'input',
        name: 'name',
        message: 'What is your component name?'
      }
    ],
    actions: [
      {
        type: 'add',
        path: '../src/components/{{pascalCase name}}/index.tsx',
        templateFile: 'templates/Component.tsx.hbs'
      },
      {
        type: 'add',
        path: '../src/components/{{pascalCase name}}/styles.ts',
        templateFile: 'templates/styles.ts.hbs'
      }
    ]
  })
}

And, finally, we create the actions: it's defined by type (add a file in this case), the path to the new file, and the template we created.

6. Create a Convenient Script (Optional, but Recommended)

Within your package.json file, you can create a script to generate a new component:

"scripts": {
    "generate": "npx plop --plopfile generators/plopfile.js",
  },

Now, whenever you need to create a new component, simply run:

npm run generate

Using This Mindblowing Tool

Running npm run generate in the terminal, I get this result:

In VSCode:

Conclusion

So why not give Plop a try? Start automating your file creation process today and experience the benefits of a more efficient and consistent development workflow.