Forem: Luís Serrano

Managing humans

Luís Serrano — Mon, 20 Mar 2023 00:00:57 +0000

I recently became a team lead at the company I work for, a role I had been aspiring for some time. It's ironic because as an engineer, I never imagined myself managing others. I always strove to be a 10x engineer and dedicated myself to that goal.
Until it didn't make sense anymore.

Life can be full of surprises, and I'm continually amazed at how my outlook on the future and my personal growth have evolved. While I still have a passion for tackling complex problems and immersing myself in finding solutions, I'm finding myself drawn more toward the idea of having a multiplier effect on my team's outcome, focusing on improving purpose, people, and processes.

I've always believed that people are the heart of any organization. Early in my career, I learned that the quality of your relationships with your colleagues can make or break your work experience. When you genuinely enjoy working with your teammates, everything becomes more manageable. You feel more motivated to start each day, you're more likely to speak up and contribute ideas, and you're more likely to solve problems collaboratively. Ultimately, you're more likely to have a fulfilling and enjoyable experience at work.

I'm sure I'm not alone when I say that, as software engineers, we're often privileged to have the ability to switch jobs frequently. However, I've left previous teams not because of the work itself, but because I didn't share the same values as my colleagues. If I have the opportunity, I will not waste my life working with someone that doesn't share my values.

The idea of becoming a manager came to me during a difficult time when I was feeling burnt out and depressed. I knew I needed a change, so I stepped out of my comfort zone and pursued a role where I could make a meaningful impact by helping people. For the first time in a long time, I felt excited about the future.
Despite the challenges that come with any new role, I'm eager to learn and grow. I know that I have much to learn as a manager, but I'm motivated to do so, and caring about people makes 50% of the job easier.

What has been working for me?

As a new manager, I've been experimenting with different approaches to support and manage my team. I've found that being proactive and organized can make a big difference.
One thing that's been particularly effective is creating individual pages for each of my team members in Notion.
Here, I document everything I know about them. From personal and professional interests to their performance and other relevant details.

This approach is essential in ensuring that I don't forget anything when preparing for our 1-1 meetings or any other conversation. It's important to show your team members that you care about them, and remembering details from previous conversations is a great way to demonstrate this.

To ensure that our 1-1 meetings are productive, I take a few minutes the day before to prepare an agenda with topics I want to discuss. Typically, I cover topics related to their growth, how I can better support them in their work, any blockers they are facing, feedback, and a general reflection on how things are going. These meetings are critical in defining expectations, having honest conversations, and building trust.

After each 1-1 meeting, I take some time to jot down notes on what we discussed. This helps me to follow up on any topics in the future. Whether it's an ill parent, a sick pet, or a book they're interested in reading, I make sure to keep track of these details to show my team members that I'm invested in their lives both inside and outside of work.

In addition to creating private pages for each team member, I’ve also created a shared Notion page with each report.
I use this page to maintain a history of our 1-1 meetings and prepare for upcoming meetings. It's also a place where we can collectively track progress toward their career goals, identify areas for improvement, and create a growth plan.
Another useful feature of this shared page is the Brag document, where they can highlight their accomplishments and celebrate successes.
We've also included a book recommendation section, which encourages them to continue learning and growing. As part of our commitment to personal and professional development, we have a learning budget each team member can use to invest in their growth.

To wrap things up, I'd like to share some book recommendations that have been keeping me busy lately.

The making of a manager
Managing humans
An Elegant Puzzle- Systems of Engineering Management
The manager's path
Radical Candor
The unicorn project
Overcoming the five dysfunctions of a team
Become an effective software engineering manager

This is just the first of many posts where I'll be sharing my insights and learnings from my new role. My goal is to offer an honest perspective on what's worked for me so that you can apply it to your own situation if it aligns with your own point of view.

✌️

Configure ESLint, Prettier and path aliases with Next.js

Luís Serrano — Tue, 11 Jan 2022 15:37:56 +0000

If you don't like seeing ../../../../component/example.jsx on your codebase, you're not alone.

This is a quick guide for you to start your Next.js project, with ESLint, Prettier and path aliases configured the right way! :)

The easiest and quickest way to get started with Next.js is by using create-next-app. This CLI tool developed by the Next.js team enables you to quickly start building a new Next.js application, with everything set up for you.

You can start with:

npx create-next-app@latest
# or
yarn create next-app

create-next-app will give you already eslint and eslint-config-next, but we need some additional packages to install. If you don't have these on your project, you will need to install them.

Configuration and packages to install

eslint-import-resolver-alias
eslint-config-prettier
prettier

Configure `ESLint` and path aliases

We're going to configure ESLint to allow us to have path aliases and warnings on our code editor when the path is wrong.

prettier will help us as a code formatter and I honestly recommend everyone use it!

Create and configure `.eslint.json`

We need to tell eslint which plugins we want to use and which settings we want to configure for each plugin.

In this case, we're extending eslint with the prettier and import-resolver-alias libraries and also telling import/resolver that for .js and .jsx extensions, we will map @ to . root folder.

By doing this, eslint will not warn us when using e.g: @/src/component/example.jsx.

Note: the order of the extends list matters.

{
  "extends": [
    "plugin:import/errors",
    "prettier",
    "next"
  ],
  "settings": {
    "import/resolver": {
      "alias": {
        "extensions": [".js", ".jsx"],
        "map": [
          ["@", "."]
        ]
      }
    }
  }
}

Create `jsconfig.json`

Let's add the alias we need, shall we? Here is where we're actually defining which aliases we want.

{
  "compilerOptions": {
    "module": "commonJS",
    "target": "es2017",
    "jsx": "react",
    "baseUrl": ".",
    "paths": {
      "@/*": ["./*"]
    }
  }
}

This is an example, but you can add whatever you like. Left side of the tuple is your alias, on the right side is where the alias should map to. In this case, @ resolves to the root folder .

Create `next.config.js` for webpack

const path = require("path");

module.exports = {
  webpack: (config) => {
    config.plugins = config.plugins || [];

    config.optimization.providedExports = true;

    config.resolve.alias = {
      ...config.resolve.alias,
      "@": path.resolve(__dirname, "./"),
    };

    return config;
  },
};

This is for the production build. Since nextJS uses webpack to build everything for production, we need to configure the resolver and tell webpack how to read our imports.

Hope this is useful, if you follow all steps you will get a working project with ESLint, Prettier and path aliases :)

How to structure your SASS code

Luís Serrano — Thu, 01 Oct 2020 00:14:21 +0000

By already worked on different companies, with different sizes and codebases, I've seen multiple codebase structures and helped created some of them from the ground up.

Working with a small team (two or three devs) is one thing, working +10 is another and it's very important to define a good structure from the beginning to help us scale the team and keeping the same level of productivity and good code.

From my experience and by following the pattern by Hugo Giraudel, the 7-1 Pattern, with a personal twist on almost all of the projects I've worked, I've found the right structure that until today, it's working fine with all good practices in place.

Of course today, you are probably using styled-components/Emotion on your React or Vue project but there are a lot of projects that only needs CSS or SASS. Let's proceed...

I think SASS, specially the .scss file extension, gives important features that don't exist yet in CSS, like nesting selectors, mixins, functions, variables (although css has now custom properties but they have differences), that increases our productivity.

Using the 7-1 pattern as a baseline, you have all your sass partials in 7 different folders and a single file at root level that imports all folders. This is used to later compile everything to a single CSS stylesheet.

base/
components/
layout/
pages/
themes/
abstracts/
vendors/
main.scss

This has been our go-to architecture, since then we're following almost all recommendations.
There are some nuances in this pattern that over time made us refactor and create our own architecture to fit small to big projects.

main.scss with all the imports

We didn't like the idea of having a file importing every sass file on the project. To create pages that only import the CSS that it needs, this approach doesn't help.

Example: you have a simple sign-in page, should this page import all the CSS of your website? Off course not, right?

Our solution:

There are only two folders that we need to import on any page, the abstracts and the base folder.

For these folders, we've created a _global.scss file where we're importing all files inside.

/abstracts
    _functions.scss
    _variables.scss
    _mixins.scss
    _global.scss
/base
    _general.scss
    _fonts.scss
    _global.scss

On each _global we're importing:

// abstracts/_global.scss
@import 'variables';
@import 'functions';
@import 'mixins';

// base/_global.scss
@import '../abstracts/global';
@import 'general';
@import 'fonts';

Since we need all files of the abstracts folder on any scss file to be able to use the mixins, variables or functions, we can save some time and import the _global.scss of the abstracts folder in the _global.scss of the base folder. Without doing this, we had to import the abstracts _global.scss on every page .

To create a specific CSS file for each page and importing only what it needs, you can use webpack or parcel to generate multi entries and outputs. You can find more info on how to use webpack with SASS here.
With the solution above, we can create a sign-in.scss file in the page folder that will import all the defaults and specific components to be rendered on the page.

// sign-in.scss
// scss/ is an alias

@import 'scss/base/global';
@import 'scss/layout/header';
@import 'scss/layout/form';
@import 'scss/components/buttons';
@import 'scss/components/auth';
@import 'scss/components/loaders';

Using less folders

We've started following the folder structure that the 7-1 pattern suggests, but on all projects that we've worked with, none of them had to use all the folders.

I believe this suggestion below works for most cases, for small and big projects.
As it happens with small or big projects, you need to start defining your default Sass code like colors, font-sizes, resets, etc and then pages and components.

Here, there's no difference between a small and big project, only the number of files.

/abstracts
    _functions.scss
    _global.scss
    _mixins.scss
    _variables.scss
/base
    _fonts.scss
    _general.scss
    _global.scss
    _typography.scss
/components
    _header.scss
    _form.scss
    _buttons.scss
    ...
/vendor
    _bootstrap.scss
    _normalize.scss
/pages
    auth.scss
    homepage.scss
    ...

Abstracts

The /abstracts folder contains all the sass helpers you can create to help you out on your project. This is all about sass tools, variables, mixins, functions, placeholders, etc.

We're using the _global.scss to import all files so we don't bloat another file with these imports.

Base

The /base folder contains all the boilerplate of the project. It's where we set the default styles, import custom fonts, set the default style for the headings, paragraphs, hyperlinks.

Components

Following the thought process when using a Javascript framework like React, everything is a component. These are independent, reusable pieces of the UI and you can think of components like a navbar, a header or a button.

That's why instead of using a layout folder for elements like a Footer or an Header, we create pages that are composed by components.

Vendor

The /vendor folder contains all the third party files that the application needs. It can be a reset css file, bootstrap, anything you could think of.

If these files should be included in any page of the website, we import in /base/general.scss.

Pages

The /pages folder should contain the specific styles for each page with the filename being the name of the page. In our use case, we use webpack to create specific CSS files for each page and import all the default styles and the components that I need for each page. You can find more information how we do this here.

This approach allow us to import only the code that the page needs and reduce the size of the file.

An example could be something like this:

// billing.scss
@import 'scss/base/global';
@import 'scss/components/header';
@import 'scss/components/footer';
@import 'scss/components/form';

.billing {
  max-width: 640px;
  margin-top: pixelToRem(90px);

  &-section {
    margin-bottom: pixelToRem(60px);

    p {
      margin-top: pixelToRem(5px);
    }
  }
}

If you're not using something like webpack to bundle and convert your javascript and sass/less files and you have a main.scss where you import everything, this approach allows you having a _global.scss file per folder importing all the other files and import these globals to your main file.

// main.scss
@import 'scss/abstracts/global';
@import 'scss/base/global';
@import 'scss/components/global';
@import 'scss/pages/global';
@import 'scss/vendor/global';

I hope you find this article helpful.

The 7-1 pattern helped us with the foundation and we tweaked a bit to fit our needs. This approach, where everything is a component and pages are composed by independent, reusable pieces help us creating smaller CSS files shipped to the user and have a more modular Sass structure to scale when the project and team grows.