DEV Community: Angelo Dias

Navigating Careers

Angelo Dias — Tue, 17 Sep 2024 15:00:00 +0000

I was invited by Seasoned to work towards the growth of a new enterprise, and it's been a challenging experience.

Writing, per se, has never been something I had a hard time with (you'll understand why in a few paragraphs), but describing how it is to work with something I'm not quite experienced in makes me shiver.

It's not the first time I’ve moved careers — and it won't be the last — and I want to share a bit of how things are going, and how I moved from journalism to graphic design, then to coding, then to tech-leading, then to growth marketing.

First, some context.

A proud generalist

My professional life can be summarized as filling the gaps.

I started studying journalism in 2009 — I loved writing and taking pictures — but soon noticed every journalism student could write (better than me, even), but not one of them could put the text + photos on a pretty page. I saw a gap, I studied it, and I filled it. I finished college as a graphic journalist, a position that didn't exist and that I made for myself. This landed me a job at Latin America's biggest newspaper, Folha de S.Paulo.

Then, as a full-time graphic designer — doing layout, infographics, and the occasional journalistic writing — I realized everyone had a great taste for print, but they had a terrible understanding of the internet and how things could be displayed there. I started studying simple HTML and CSS, then moved to JavaScript, and before I knew it, I was, again, filling a gap. My new job had a simple description (and a fairly complicated execution): to build tools and ways of moving print material to the internet in a beautiful, usable, and even interactive way.

The designers couldn't code. I could. Soon I was not only moving stuff from print to the web but doing stuff web first — damn, I fought to do stuff mobile first! People liked working with me because I knew journalism, I knew design, and I knew the internet and how to work around it.

Then, after moving on from Folha, I started working with heavy-duty programmers and, guess what? Found a gap. They were great coders, way better than I ever was, but terrible communicators. They could make any computer do their bidding, but trembled and sweated in a client meeting. They had conflicts while talking to product people, and a real struggle understanding how the design process worked.

They needed someone that had the technical knowledge, understood how designers work, and also had a love for communication. Well, I could absolutely fill this gap. So I did it.

Since then, this has been my (very hard to advertise) job description — a proud generalist that links developers, designers, and non-technical people. A kind of tech lead that's not just tech. I would code, of course, but mainly get the team processes oiled up so they could do what they knew best, and everyone could be on the same page. I put this on the first part of my website, so that every recruiter could see it.

Movin' on up

After my last project ended, Daniel Weinmann (Seasoned's CEO) called me and invited me to a new — and novel — position. I was coding for the last, hmm, 8 or 9 years, but he wanted something more. When I worked for him as a coder some years ago, he always said stuff like, "I think you're more than just a programmer, but right now we don't have any way of testing that — because the job requires a coder and you are a coder." This time, he had a great team of coders — like, really, people with amazing skills. What he didn't have was someone with the knack for tackling new things, studying stuff from scratch, and doing their best to communicate all that.

For him, I was the guy. He insisted, more than once, that I should try to face this new challenge.

If there's one person I deem persuasive, it's Daniel. I accepted this role and here I am, now, learning a bunch of stuff, going from zero to hero, and doing my best to share all of that. My new position? Head of Growth, someone to tackle all obstacles in growing a new product they are working hard on.

This is not a publicity post, so I won't talk much about what we're building — if you want to check it out, you can visit Flashboard's website — but this is an introduction to whatever will come next. This is the first of (hopefully) a series of articles on how things have been going and what I've been learning.

I hope that, if you find yourself in the same career-moving journey, you find this at least interesting. Let me know if my path has resonated with you below, in the comments. I would love to hear about it.

5 Common Pain Points in PostgreSQL

Angelo Dias — Tue, 10 Sep 2024 18:30:00 +0000

Before building Flashboard (our PostgreSQL admin app), our development team had struggled with a lot of stuff that you might've encountered in your PostgreSQL journey.

I'm not just talking about tracking foreign keys or building extra-complex SQL queries, but also finding a way to make data editable for non-technical folks without needing to build an entire new software to support the main thing — after all, the main thing is where the core of the work should be, right, Project Owners?

Well, here are the most common pain points in PostgreSQL (and, being honest, a bit about how Flashboard solves them at the end of the article).

1. Time-Consuming Query Creation

Building SQL queries is fun — until it isn't. It's like RegEx — you get that big, broad smile when it works, but after the 10th time you just hit ChatGPT and ask it to build it for you. It becomes tiresome, error-prone, and, mainly, time-consuming. The f-in-fun becomes f-in-frustration when you have to redo it all because you got a new client.

2. Navigating Foreign Keys

A good PostgreSQL database probably has a lot of foreign keys — and that's a green flag in architecture design... or at least that's what the architects say. When the developers need to navigate the schema, jumping from one related table to the other, things get confusing — you gain database-performance in exchange for developer-speed.

3. Handling JSON Data

I know the feeling of working with JSON in PostgreSQL. Saving data this way saves time and space, but it's waaaay too difficult to query it. You need special operators and functions, and when you’re working with nested structures, it’s easy to mess something up.

4. Creating Secure Interfaces for Non-Tech Teams

You might need to give access to the database to non-technical users — sometimes there's no time to build a feature in the main app or there's no proper admin panel setup for them. This is hard work — it’s not just about making sure they don’t break anything, but also ensuring sensitive data stays locked down. Building a secure admin interface means juggling encryption, access control, and usability — when you notice it, you are building a secondary software as hard to maintain as the primary one.

5. Scaling Custom Admin Solutions

Continuing from the last topic: what starts as a simple admin panel for a small team can quickly balloon into a mess as your user base or data grows. Suddenly, you’re dealing with performance issues, broken queries, and features that no longer work as expected. Scaling a custom solution is a beast of a task, and unless you planned for it from day one, you’ll probably need to rebuild a good chunk of it down the road.

It would be awesome if a tool existed to solve all of these problems, right?

(read the next sentence as if a TV host from the 80s was saying it)

Well, I have some good news! Flashboard to the rescue!

(ok, serious now)

We got tired of sidetracking our main things to build complicated admin panels, so we made admin panels our main thing. I know this next paragraph might sound a little sale-y, but I promise we're just devs recommending good software for other devs. Yeah, we believe in what we're building — and you know this feeling.

Flashboard instantly generates admin panels, so no more hand-coding complex queries. It simplifies foreign key navigation and JSON querying, so you can breathe easy. Security? Encrypted credentials and tailored user access are built in. And it’s scalable, so whether you're a startup or scaling up, it’ll grow with you.

(now, back with the TV host's voice)

Say goodbye to PostgreSQL admin pain points and focus on what you do best — building awesome stuff.

Comment below what other pain points you find in PostgreSQL! We're totally not going to add that to our backlog 😉

How to run an open-source design project?

Angelo Dias — Sat, 26 Nov 2022 10:49:51 +0000

Disclaimer: no links in this article are NSFW, but they aren't SFW exactly. Please read further

Introduction

I'm working with the BDSMtest team to open-source and modernize it. This work is a personal endeavor — doing something many peers have talked about but never actually started.

A quick introduction: BDSMtest.org is a website where you can test how kinky you are and what kinds of kinks you are mainly into. It's not precisely NSFW — there are no images or explicit wording — but as the theme is sexuality and kink, your work might not approve of you clicking the link during your shift. I'd recommend taking the test, even if you are vanilla.

Don't know what vanilla is? Then, well, take the test.

The website has been up since 2014. Every kinky friend — quite a lot — and even non-kinky people have been using it as an essential source of information on their kinky preferences.

I am a front-end developer looking forward to redesigning the website and modernizing its codebase. After doing that, the idea is to revisit the test structure, questions, and results with the help of data scientists (not my area, but that's what open-source is for, right?)

The question

The first part of any modernization project is to think about architecture: how is the current website organized, and what's the goal of the modernization. In this project, one of my goals is to make it look better. It's not exactly ugly; it's just... old. So, it would need a new design.

I, as a front-end developer, have some knowledge of how open-source coding happens:

you find a GitHub repository;
fork it;
work;
open a PR respecting the CONTRIBUTING guidelines;
Answer comments;
Make requested changes;
(Hopefully) get it approved;
...
(Not) profit!

But, as a designer... how could that work?

Tools

First, design does not have straightforward collaboration tools like GitHub, with granular versioning. There's Figma, of course, but having multiple collaborators in it costs money, and someone can just come and erase everything, right?

It would be necessary to have a clear conduct guideline on how to work on that shared project and also be sure no one is breaking those rules — which would be a manual task, as there are no automated tests or way to compare the current work with the former.

There are also no PRs: any work done happens in the same space. If someone deletes something or changes a component, we'd only be able to notice it after they already done it.

In Figma, all the commits are in main.

So, how to collaborate knowing the source will be preserved while making it possible for new people to add work?

Behavior

If you are a professional programmer, you may know how to group code. The whole GitHub — or GitLab, or whatever tool you prefer — ecosystem is natural to us, as we've been using it forever.

There are straightforward tools inside GitHub, for instance, to prevent commits on main, block PRs if the workflows fail, require specific approvals when merging, etc. There's nothing like that in Figma, for instance.

A quick thought: I'm using Figma as an example because there are no other collaborative design tools in my mind right now. After Figma's acquisition by Adobe, XD isn't even on the table anymore.

How to guide the behavior of new collaborators in an open-source design project? How to avoid destructive workflows? How to maintain project structure while allowing collaboration?

Blocked

This situation blocks my progress with this task. I will start my design process by myself, but I would love for it to be public and collaborative — I don't know where to begin to make this happen.

Do you know the answer? Could you share this with designer friends or start this discussion with your colleagues? Will Figma ever get their hands on this and make it free for open-source software?

I can only kneel and pray — oops, new kink unlocked.

Create Markdown blog posts automatically

Angelo Dias — Sat, 30 Jul 2022 18:17:16 +0000

This was originally published on my personal blog — yeah, they exist. What do you think about going there and subscribing to my 100% non-spammy newsletter?

I had to go through the following process whenever I wanted to create a new blog post in my blog — powered by local Markdown files:

Get inside the "content" folder
Navigate to the "blog" folder
Create a "year" folder
Create a "month" folder
Create a "publication" folder
Add the md file with the blog post slug
Open the md
Open an old, published md
Copy the frontmatter from the old post
Paste it on the new post
Clear the data
Write the metadata
Update createdAt field
Start writing

Ugh, that's a long (and boring list).

This was making me feel not much programmery, so I created a simple script to automate it. Let's go through it together?

You will be able to do the following at the end of this tutorial:

Write a CLI command
Have a .md file automatically created
Have the correct frontmatter in this file
Be in a new git branch
Automatically open VS Code (or other) to edit this file

This tutorial is good for:

New developers that need to lose terminal fear
Anyone who wants to make their workflow faster
People who have locally-hosted MD(X) blogs.

Setting up the environment

For this small project, you only need to have a project that reads md files and that uses node. It can be mdx or anything else you'd like, honestly. It's not framework specific, so feel free to adapt to your system. My Node version is v16.14.2 at the moment writing.

Requirements:

Node
Node-running project (package.json)
Yarn (or NPM, your choice)
Willpower and patience to research and try/error if something does not match exactly your folder structure and project configuration.

Concept

Requirements for the script:

Usable from the CLI;
Two types of content (blog or project, in my case);
Pass the file name so the folders and files are created correctly;
Automatically fill frontmatter in the new files.

Pseudo usage: {script name} {type} {filename}

Example with yarn:

Input: yarn content blog tutorial
Output: folders and files for tutorial.md are created in the blog section, with the blog frontmatter.

Creating the files

At the root of the project, I created a scripts folder and put a few files we will be using — I prefer to split my code:

content.mjs
frontmatter.mjs
getFilename.mjs
getToday.mjs
gitNewBranch.mjs
openInVsCode.mjs

.mjs?

This file is not a simple javascript file, it is a javascript module (hence the m). This makes node understand the syntax we are using without the need to compile each file before running it.

Inside the mjs is plain javascript code, so if your IDE complains about the file extensions, adapt this to your usage.

PS: There might be some configuration needed in your project. Do a little research if some error show up.

Main file

Let's build a function and call it at the end of the content.mjs file:

const newContent = () => {}

newContent()

In order to test this, we will use nodemon — a tool that runs node scripts in watch mode.

I have it installed globally using yarn global add nodemon, or you can add it to your project by yarn add -D nodemon.

In your console, navigate to the root of your project and run nodemon scripts/content.mjs. You will see the console waiting for you to save the file so it can re-run:

[nodemon] 2.0.19
[nodemon] to restart at any time, enter `rs`
[nodemon] watching path(s): *.*
[nodemon] watching extensions: js,mjs,json
[nodemon] starting `node scripts/content.mjs`
[nodemon] clean exit - waiting for changes before restart

Name and Type

We need to get the file type and name from the CLI (see "Concept", above). node gets ,in the process.argv property, all that is passed after the script name as items in an array.

So, if I pass yarn scriptname first second, I'll get an array with [node-path, script-path, 'first', 'second'].

That said, let's add a function to getFilename.mjs file and get the filename and type destructuring the process.argv array.

// getFilename.mjs
export const getFilename = () => {
  // Here we omit the two first argument. We don't need them.
  const [, , type, fileName] = process.argv
}

We also want to make sure that the script stops here if any of these two arguments are not passed:

// getFilename.mjs
export const getFilename = () => {
  const [, , type, fileName] = process.argv

  // In my project, I need the type property to match "blog"
  // or "projects" because of the way my folders are organized
  if (!['blog', 'projects'].includes(type)) {
    throw new Error('Invalid type: should be "blog" or "projects"')
  }

  if (!fileName) {
    throw new Error('You need to pass a filename')
  }
}

We will need to tell our script what's the folder it will save the files we will create in.

Here lies a small quirk in node. I'm used to getting my directory as __dirname in some projects but, by some unknown reason I needed to create my own __dirname variable using fileURLToPath from the native url package, some functions from path, and the global import.meta.url. This is not the focus of this tutorial, so please just do as I do 🤓

Inside join you should put the relative path to where you want your files to be saved. In my case, I want them in the content folder, then inside a folder corresponding to the type.

// getFilename.mjs
import { dirname, join } from 'path'
import { fileURLToPath } from 'url'

export const getFilename = () => {
  const [, , type, fileName] = process.argv

  if (!['blog', 'projects'].includes(type)) {
    throw new Error('Invalid type: should be "blog" or "projects"')
  }

  if (!fileName) {
    throw new Error('You need to pass a filename')
  }

  const __dirname = dirname(fileURLToPath(import.meta.url))
  const contentFolder = join(__dirname, '../', 'content', type)

  return { fileName, type, contentFolder }
}

This function returns an object with the three necessary variables we need to continue. We will import this function (and destructure it) in our main file.

Also, let's include a handy console.log to tell us the script is starting.

// content.mjs

import { getFilename } from './getFilename.mjs'

const newContent = () => {
  const { fileName, type, contentFolder } = getFilename()

  console.log(`Trying to create a new ${type} content: ${fileName}.md`)
}

newContent()

If you save now you should see this message printed in your console.

[nodemon] restarting due to changes...
[nodemon] starting `node scripts/tutorial.mjs blog filename`
Trying to create a new blog content: filename.md
[nodemon] clean exit - waiting for changes before restart

Date

To create our md files in the correct folders, we will get the current month and year from our getToday function. Let's start it.

// getToday.mjs

export const getToday = () => {
  const dateObj = new Date()
}

We need to get day, month and year from the date object. Let's do it by creating these three variables:

// getToday.mjs

export const getToday = () => {
  const dateObj = new Date()

  const month = (dateObj.getUTCMonth() + 1).toString()
  const day = dateObj.getUTCDate().toString()
  const year = dateObj.getUTCFullYear().toString()
}

Notes about the code above:

In node Date, months start in 0, so January is not 1. To circumvent that. we add 1 to the function that gets the month.
We transform every number to string to avoid errors when creating the files and folders.
Yes, getUTCDate is different from getUTCDay. We all end up learning that one day.

There's a problem with the code above: when returning months smaller than October, it returns them with a single digit: 5. In folder organization, it's best to add a 0 before this so it orders correctly, avoiding the following ordering:

And enforcing this:

Let's add a simple helper function that does that for us and return the variables at the end.

// getToday.mjs

export const getToday = () => {
  const addZero = number =>
    number < 10 ? '0' + number.toString() : number.toString()

  const dateObj = new Date()
  const month = addZero(dateObj.getUTCMonth() + 1)
  const day = addZero(dateObj.getUTCDate().toString())
  const year = dateObj.getUTCFullYear().toString()

  return [year, month, day]
}

I only added the day to the above function so you could customize your output. I'm not using it, so we'll only destructure month and year in the main file:

// content.mjs

import { getFilename } from './getFilename.mjs'
import { getToday } from './getToday.mjs'

const newContent = () => {
  const { fileName, type, contentFolder } = getFilename()

  console.log(`Trying to create a new ${type} content: ${fileName}.md`)

  const [year, month] = getToday() // <<<<
}

newContent()

Important: This file will get quite big, so I'll try to cut out parts that we don't use from it. Whenever you see // ..., it means that the code before or after this sign was untouched.

Now, with this data in our hands, we can build our folder path, joining all current information:

// content.mjs
import { join } from 'path'
// ...

// ...
const [year, month] = getToday()

  const folderPath = join(contentFolder, year, month, fileName)
}

newContent()

Creating folders & files

We split this section into two parts: folder and file, and there's a reason for it.

Folder

To create the folders and files in a safe way — not overwriting anything — we have first to check if it exists and, if not, create them using a special option in fs's mkdirSync.

As the name says, mkdirSync is a synchronous function that creates directories. It can be recursive, creating any non-existant directory in a tree.

If I pass mkdirSync('src/1/2/3/4/5') and only src/1 exists, the function will throw an error. But, if I add the { recursive: true } option, it will create all missing folders without error.

// content.mjs
import { existsSync, mkdirSync } from 'fs'
// ...

// ...
  const folderPath = join(contentFolder, year, month, fileName)

  if (!existsSync(folderPath)) {
    mkdirSync(folderPath, { recursive: true })
  }
}

newContent()

First, we check if the folder path exists. If it was not created beforehand, it's created now in a recursive way.

File

In order to get the file name, we use the already created folderPath variable.

The issue is: what if the file already exists? In my use-case, I prefer to throw an error instead of overwriting.

Imagine I accidentally type yarn scriptname blog amazing when I already have a file called amazing in this month? I don't want to lose that content (yeah, I'm using git, but you get my point).

So, I add a failsafe to that:

// content.mjs
import { existsSync, mkdirSync } from 'fs'
// ...

// ...
  if (!existsSync(folderPath)) {
    mkdirSync(folderPath, { recursive: true })
  }

  const folderAndFilename = `${folderPath}/${fileName}.md`

  if (existsSync(folderAndFilename)) {
    throw new Error(
      "There's already a file with that name in this month's folder"
    )
  }
}

newContent()

Writing the file

Finally, to (almost) end our struggle, we can write the file. We know that:

The folders are created
The file name is set
The file does not exist

We are safe to continue, so let's plop this writeFileSync from fs there and get done with this:

// content.mjs
import { existsSync, mkdirSync } from 'fs'
// ...

// ...
  if (existsSync(folderAndFilename)) {
    throw new Error(
      "There's already a file with that name in this month's folder"
    )
  }

  writeFileSync(folderAndFilename, '')
}

newContent()

As the first argument, we pass the intended file path. As the second, we pass what we want written in this file — at the moment, nothing.

Voilá. Done. We have ourselves an automatic md file written in the correct folder for us.

But... that's a little... not that much, right? What if we could already populate it with some template?

Frontmatter templates

In our frontmatter.mjs file, we will create an object with our desired frontmatter. At the moment, we have two types: blog and projects, so each will have its own frontmatter.

Another thing we will do with this template is automatically set the createdAt property filled with... today. My blog uses timestamps, but you can pre-fill anything you want, any way you want.

// frontmatter.mjs

export const frontmatter = {
  blog: `---
title:
createdAt: ${new Date().getTime()}
description:
tags: []
---

Write here
`,
  projects: `---
title:
subtitle:
createdAt: ${new Date().getTime()}
tags: []
image:
  src:
  alt:
---

Write here
`,
}

The spacing is weird on purpose, make sure it has no whitespace before each line to avoid errors in your frontmatter.

Now, on our main file, let's pass this new information to our writeFileSync function — with a little console.log telling everyone of our accomplishments:

// content.mjs
import { existsSync, mkdirSync } from 'fs'
// ...

// ...
  writeFileSync(folderAndFilename, frontmatter[type])
  console.log(`${fileName}.md created succesfully!`)
}

newContent()

But Angelo, what happens if we pass a type that doesn't match the object?

We won't! Remember that this function throws an error if you pass any type other than blog and projects!

Finale (?)

This is the end of the main part of this tutorial.

But there's more to be done, because we are developers and we are absolutely lazy!

Our computer is doing all of this by itself and we still have to create a branch in git for this new file, and navigate to it manually, like the Aztecs? Oh no, not today.

Auto git-branch

In gitNewBranch.mjs file, we will write a simple function using the powers of simple-git package. There's nothing much to be said here: if you understand git a little bit, you will be able to decypher the following code with ease.

But, before, install the package using yarn add -D simple-git.

// gitNewBranch.mjs

import { simpleGit } from 'simple-git'

export const gitNewBranch = async (type, fileName) => {
  console.log('Creating branch and commiting...')
  await simpleGit()
    .checkout('main')
    .checkoutLocalBranch(`${type}/${fileName}`)
    .add('./*')
    .commit('Add starter MD')
}

Important: see the little async in the first line? Yeah, simpleGit is asynchronous so we will use async/await here to make it work perfectly.

Before the simpleGit function, plop that await there.

We need to make two changes in our main function: add an async flag and add await before calling the gitNewBranch function:

// content.mjs
import { gitNewBranch } from './gitNewBranch.mjs'
// ...

//...
const newContent = async () => {
  //...

  // ...
  console.log(`${fileName}.md created succesfully!`)

  await gitNewBranch(type, fileName)
}

newContent()

Opening VS Code

To finalize our script, we will command our terminal to open the file in our favorite IDE — in my case, VS Code.

This is the most obfuscated of all of the files. It takes advantage of exec from node's child-process. It's hard to read and to explain. What it does is simple: it runs in your terminal whatever you pass on the exec first argument.

We will use the code command, as if we were opening a file from our terminal. If something goes wrong, an error will be logged.

// openInVsCode.mjs
import { exec } from 'child_process'

export const openInVSCode = pathAndFileName => {
  exec(`code ${pathAndFileName}`, (error, stdout, stderr) => {
    console.log(stdout)
    if (error !== null) {
      console.log(stderr)
    }
  })
}

Yeah, I know, not the best file. But, if you can open code using your terminal, you can also use it this way. We will add it to the end of our main file:

// content.mjs
import { openInVSCode } from './openInVsCode.mjs'
// ...

// ...
  await gitNewBranch(type, fileName)

  openInVSCode(folderAndFilename)
}

newContent()

And that's it!

Package.json

I promise this is the last step! I swear!

We will add two scripts in our package.json to make this even easier.

  "scripts": {
        // ...
    "post": "node ./scripts/content.mjs blog",
    "project": "node ./scripts/content.mjs projects"
  },

This way, when we yarn post tutorial:

Our script will create a folder with today's year and month
It will add a tutorial folder
Inside it, it will create a tutorial.md file
It will populate this file with frontmatter.blog content
It will create a new branch in git and checkout there: blog/tutorial
It will open VS Code for you to write your file.

Want proof? There you go.

Finale!

See the source code in this website's repo

That's all of it.

Thanks for reading and let me know if you end up implementing this.

Don't forget to share this post with everyone!

Final content of our main file:

import { existsSync, mkdirSync, writeFileSync } from 'fs'
import { join } from 'path'
import { frontmatter } from './frontmatter.mjs'
import { getFilename } from './getFilename.mjs'
import { getToday } from './getToday.mjs'
import { gitNewBranch } from './gitNewBranch.mjs'
import { openInVSCode } from './openInVsCode.mjs'

const newContent = async () => {
  const { fileName, type, contentFolder } = getFilename()

  console.log(`Trying to create a new ${type} content: ${fileName}.md`)

  const [year, month] = getToday()
  const folderPath = join(contentFolder, year, month, fileName)

  if (!existsSync(folderPath)) {
    mkdirSync(folderPath, { recursive: true })
  }

  const folderAndFilename = `${folderPath}/${fileName}.md`

  if (existsSync(folderAndFilename)) {
    throw new Error(
      "There's already a file with that name in this month's folder"
    )
  }

  writeFileSync(folderAndFilename, frontmatter[type])
  console.log(`${fileName}.md created succesfully!`)

  await gitNewBranch(type, fileName)
  openInVSCode(folderAndFilename)
}

await newContent()

Let others judge you

Angelo Dias — Thu, 09 Jun 2022 17:08:27 +0000

The only line of this whole article you need to read is this one, although it goes against much of what other people tell me every day:

Let others, not you, judge how capable you are of doing something.

I'll explain.

First: friends know better

I'd love to say this was smooth and natural, but it wasn't. There was a specific point in time at which I decided to change the way I saw my work. It was a mix of fake it till you make it and shoot the imposter down, a conscient action of looking at my professional journey and giving more to it than what I imagined it was worth.

Some could say this is lying, or even embellishing my CV, but I disagree completely (more on lying later). It's more about a shift of responsibility than anything else.

I was trying to do freelance work and, well, I suck at it. I don't know exactly how to get new clients, how to keep them, how to charge enough money to pay my bills but not too much so they'll run away.

Being for five years on a regular 9-to-5 (or, many times, 5-to-midnight) made me improve other characteristics than having to market myself and my job. I was already employed, all I needed to do was work, not sell what I did every day to different people.

So, while freelancing, I saw the necessity to go back to the regular market. The imposter syndrome, everlasting and overwhelming, made me think a thousand times that I'd never see the happy face of a fixed monthly income in my life, so I asked for help.

This became the whole subject of weekly therapy sessions, and I'm very happy that my therapist didn't give me a ready answer. She made me think a lot about what I was searching for, where I wanted to go, and, especially, who I am (which is the point of therapy after all). Then, one sunny afternoon (maybe not sunny either afternoon, but bear with me), I decided to try something new. I decided to advertise myself as to how my peers said I was instead of what I thought I was.

Feeback is a massive weapon

I started asking my old coworkers what strengths and weaknesses I had. I asked for honest feedback and crushing truths, and asked them from people I trust. They said a good amount of things for me to get better at but, mostly, they said good things. "They are obviously being dishonest", I thought to myself. It's impossible I have all those strengths and so little amount of flaws.

But, as the point of the exercise was judging myself less and letting others do it, I continued. If you, like me, aren't used to getting compliments, you might understand the pain of doing this and getting praise from people. If I'm sounding a little prepotent to you, I propose a challenge. Stop reading, get your phone and ask your three most trusted coworkers for honest, straight, and direct feedback. Ask them to tell you your strengths and weaknesses, and be prepared to understand better what I'm talking about. People will probably praise you more than highlight your issues. If they get to the bad parts, they'll probably not only say you're shit but tell you how to improve. The map is there, we just never asked for it.

I decided to act as if everything my colleagues said was true. I refactored my resumé, highlighted the strengths, and removed the flaws. So, if people said I was good at communication, even though I think I'm a lousy journalist and petty writer? Great, let's put that feature, the one people talked about, way above the others. Do they think I'm a good coder, with quality, readable code, and great with multidisciplinary teams? Let's put that on spots two and three on the list. The list of things I thought was valuable, but that no one even mentioned, were lowered in priority or even scrapped.

A parenthesis about removing the flaws

I've been in enough interviews to know recruiters will find out about your flaws. They might even ask you to talk about them, knowing most people will lie or, at least, make the flaws lighter than they are.

So, I do advocate taking them off your written resumé at all. It's not lying, its editing, showing the important things, and putting the less important out.

End of parenthesis

Storytelling

There is, of course, some narrative building here. I've studied about this, read books, watched documentaries, and done courses. I know that a good story sells, so I had this knowledge beforehand and decided to put that to use. What could be my tagline, my sales pitch, my one-liner?

I tried writing this a hundred, maybe a thousand times. It always sounded one of two: either posh and entitled, or bland and not interesting. I either could present myself as this very interesting gentleman with varied taste in the finest things of the industry or an XYZ language coder with knowledge of ABC and DEF technologies, like many I see around. So, again, I aimed outwards and begin asking questions.

Most of the people I talked to gave me this one-liner on a plate, almost ready to use.

"You do a lot of stuff".

Some of them said it in a good way, as in "you are versatile and find many ways to solve problems, even outside your area". Others highlighted this as a warning: "you spread too thin, knowing a little about a lot and not a lot about anything". Both of them ended up with the same commonality: I was a generalist, not a specialist.

With lots of therapy and some editorial tailoring, I got to where I am now. I am a proud generalist, can understand most of the problems and, if not solve them, find someone who can.

The best part of this whole process (aside from having tripled my salary in a year, of course) was: if at any time, someone found out I'm not all that I claimed (hello imposter syndrome), I could always rely on this simple idea: it was not me that built that persona, it was everyone else. I could tackle anxiety simply by blaming others for my shortcomings, because it's not my fault if someone saw something in me that I'm not, it's their problem. I'm not bad at describing myself, they are the ones that need to tweak their expectations of me.

This took a huge weight off my shoulders, especially the famous "you are not that much" that kept pushing me down and down. This might sound as if I was cheating the system but... well, it works, so sorry, not sorry, society.

Getting practical

After getting a nice idea of what people thought of me, I organized those thoughts (I had noted everything down, as this was a conscient research action), got some tea, and jotted down (in paper! And pen!) the main characteristics they saw in me. From there, I started building this character, like in a Roleplaying Game sheet, of who this Angelo everyone saw was.

I put up bullet points of strengths and weaknesses, highlighted points of improvement, added technical information about the existing topics (eg. they said I was good at coding, but coding what exactly?) and, before I could let the imposter kick in, I had a nice and clear outline of a resumé. I selected some works in which I had put some of those strengths to practice and bam, resumé ready.

A parenthesis about lying in your CV

In short: don't.

If there's something all your colleagues say you excel at, there are good chances they are right. But, if someone says something you know deep down it's a lie, don't consider it.

For instance: let's suppose a friend said I was good at languages. They claim to have seen me speaking to people in Spanish, English, and even some Italian or German. That's a nice thing to put in a resumé, "being good at languages", right?

The problem is: that's a lie.

I'm good at English (and not even consider myself fluent). All the other languages are just attempts at communication, German being something I just started learning and Spanish and Italian being close enough to my mother language that I could do some mix-and-match and eventually get some stuff right.

Putting that in my resumé would lead me to interviews that might need those skills and, adding embarrassment to the plate, I would just smile and deny it when they asked me if I spoke those languages. After that, what in my resumé was true? It would become completely not trustworthy.

A real example: I've been working with code for (way too many) years now, and I sure had a few experiences with backend development. I'm absolutely not a backend developer, though. I learned, with time, to actively say that in interviews so that the recruiter knows I might not be the best fit for a full-stack position.

Even though I've got a colleague that praised me for being able to put up a backend for some services with no prior knowledge, I did not describe it like this in my CV. I preferred saying I was versatile and could tackle some challenges outside my field of work, as long as everyone knew I was not a specialist in these new explorations and that things might break.

Instead of lying, I chose the truth, and that has brought me to good places. Maybe it'll lead you too.

End of parenthesis

With this character sheet — my own, made from parts of me I didn't know or even agree with — I was able to design a resumé, with an attached cover letter from this "character", and started sending it everywhere.

Every. Where.

Second: recruiters are professionals

Go to LinkedIn. Browse to "job search". Put a position you'd like to be in. Be reasonable: don't sabotage yourself with lesser positions than you want (because "you are not good enough"). Some would say "don't apply for positions higher than what you think you can do", but I disagree. Do exactly that, apply for stuff you think you are not capable of. Apply to a lot of things. Trust me, even those positions of leadership, high salary, corner office.

The main point of this section is to repeat to yourself that recruiters are professionals. They are amazing at their jobs and can smell talent from afar. As good professionals they are, they won't turn down a good fit for the company because it does not match exactly the position. Maybe they are looking for a Chief Technical Officer and you do not have the required experience, but your knowledge of making balloon animals or your interest in entomology might make them want you in their company nonetheless.

Their job description is: find and recruit talents. So, my simple question to you is: who do you think is better in knowing who's a fit for a position? You, zero recruiting knowledge, or a person who does that for a living?

So, please, let them do their jobs. Apply for positions. All of them you'd like to try. Again, be reasonable, don't apply for "circus manager" if you don't like traveling and are afraid of clowns, save the recruiter's time. Also, if you start a process and don't feel like continuing, quit it and let them know. Put yourself in their skins.

We are, usually, far too traditional (oh, in so many things) and we do things from tradition without much questioning. What I'm encouraging you to do is challenge whatever tradition pushes you from not applying to the jobs you want. Let the recruiters choose and let them evaluate if you are a fit or not. Be truthful in interviews, know what you want in a job (through exercises or, well, therapy) and go out there, hunt, and be hunted.

Third: your boss knows best

That shiny contract is signed and you are working in this shiny new environment, with a lot of new responsibilities and a good amount of pressure on your shoulders? Nice. I hope the paycheck is as big as the trouble you just find yourself into (if not, back to step 1).

Now, maybe the problem is not "I'll never find a job" or even "I wont apply for fancy positions". The issue at this point of the process is something I'm still living and, well, trying to tell you to do something I have to do myself.

I always (I mean, daily) think I'm not enough at my job. Of course, they will find out I did all that embellishment of my resumé and that, in truth, I'm a loser and an incompetent and a really bad professional. This, as you might know, is imposter syndrome at its best, eating your brain inside out like that terrifying amoeba. It's easy to say "don't care about that" because I know I do care. My mind (to which I trust most of my decisions) is constantly reminding me I might be in the wrong place.

What I've learned to do is: evaluate your surroundings and count how many people failed in their jobs if you end up being the fraud you believe to be. Start from the last section of this article: if you are this bad of a professional, your recruiter sucks. If any of your colleagues ever praised you, they are bad at judging people --- personally and professionally. If you have been through a probation period and passed it, keeping safely employed, your boss is bad at their job and just accepted an unfit professional in the company ranks.

A few people, whose jobs are to make sure the company runs smoothly, might have made horrible mistakes to keep you there, and the coworkers might be blind and/or amazing liars by saying good things about you to yourself.

Put things in perspective whenever the imposter hits. Are you ready to tell all of these people they are bad at their jobs? They might be good at it, right? So, maybe, you are not as unfit as you think. You might be even good at your jobif you let these "inside" thoughts off and just focus on what comes from outside.

Fourth: improve to improve

The whole point of this philosophy of letting others judge you, not yourself, for your professional growth, is exactly to take advantage of their professionalism and skills in finding capable people. You, instead, must focus on getting your goods better or your bads at least at medium. Instead of trying to fit in what you think you should be, work towards improving. Tell them you want to get better, be open about your weaknesses, and be true about what you wouldn't want to pursue.

It's hard to be true to yourself, I do know. Being true to others, though, brings a paycheck home. We think so many bad things about ourselves and never, for once, think we are bad at judging our ability. We might see ourselves as the worse professionals, but never as lousy judges of capacity.

Let the professionals do their jobs: let others judge your value, not yourself, and be surprised by how much people might think highly of you.