DEV Community: Vitor Paladini

How to Overcome Your TypeScriptoPhobia

Vitor Paladini — Mon, 31 Jan 2022 12:49:03 +0000

Let's face it, TypeScript is kinda scary.

Not too long ago, I used to dread the idea of having to learn and work with it every day.

I'd log off after a busy day at work and have a recurring nightmare where a mob of angry engineers forced me to either use it or face a slow, painful demise. I also couldn't run or fight in the dream, my punches were super slow, and all my teeth would crumble and fall...

Alright, I'm deviating here, but you get the idea.

And now, after a little more than a year of daily TypeScript exposure I... Kind of love it? I'm not sure if "love" is the right word here, but we're surely on amicable terms now.

Using it makes my job so much easier (after making it much harder for a while, let's be honest), and I regret not putting in the effort to learn it earlier in my career.

And that's the reason I'm here today. I want you to learn from my mistakes, eat that damn frog, and start putting some effort into learning TypeScript today!

🎵 cue motivational song 🎵

But first, let's talk about why I avoided it so much.

I used to hate the idea of using it

Hate is a consequence of fear. Fear is a consequence of ignorance. - Albert Einstein (not really)

As human beings, we have emotional responses for every stimulus, and boy, I used to have strong feelings right inside my gut whenever TypeScript popped up on my Twitter feed.

Back then, it looked like one extra thing to learn atop a couple dozen new JS stuff, the syntax looked like something straight out of a World War II cryptography machine, and it felt like I could accomplish the same thing with good old JS.

It all sounded like way too much effort. 😮‍💨

"It will just make me slower!", "It will be another dev dependency to go haywire and break my env!", "I could use that time to write tests!" - I thought.

There is some truth to these thoughts, the syntax does indeed resemble an Enigma machine sometimes, and yes, it is one more thing to learn.

But at the deep end, I was simply afraid of the unknown, too comfortable with my JS-only experience, and very good at unconsciously coming up with excuses.

And all that prevented me from seeing the benefits it could bring to my workflow.

It's kind of like when you're meeting a new person but already have so many negative preconceptions that you instantly hate them. In my case, that person was called TypeScript, a funny name for a person to have if you ask me.

Why I kind of love it now

I kind of love it for a few reasons, it makes my job easier, sure, but I only got to love it once I got to know it.

And I only got to know it because I put myself in a position where I was forced to use it every single day.

I mean, not really forced, but after applying and being hired to a TypeScript-heavy position, I had to damn well get rid of my TypeScriptoPhobia and learn it good.

And here's what I discovered along the way!

TypeScript facilitates communication, like, a lot

TypeScript has a lot of advantages but the thing I like the most in using it is how it forces you to give good names to stuff, especially objects.

In the example below, you'd be able to say something like, "Hey Jess, this method takes a User as param" instead of "takes an object with id, name, and email as mandatory properties."

function createUser({id, name, email}) {
    return fetch('https://example.com/user/create', {
      method: 'POST',
      body: JSON.stringify({id, name, email}),
    ...
    })
}

vs.

type User = {
    id: string
    name: string
    email: string
}

function createUser({id, name, email}: User) {
    return fetch('https://example.com/user/create', {
      method: 'POST',
      body: JSON.stringify({id, name, email}),
      ...
    })
}

This single change in your team's workflow makes the implementation much more straightforward to discuss during code reviews, RFCs, and pair-programming sessions.

That also works very well when working with well-typed dependencies. For instance, when discussing a specific API method, you can say it accepts a LatLngLiteral instead of "an object with lat and lng properties as number."

It actually eases your mental workload over time

TS will make you slower before making you faster, and the sooner you accept that, the better.

But after going through an initial learning curve and type setup, you'll see how a robust type system and a reliable autocomplete saves you some critical mental bandwidth.

Your focus will no longer be interrupted by thoughts like "does this method take an object or an array of strings?" and "I'm not sure if I should explicitly set this argument as null or if I can leave it as undefined...".

TypeScript makes it so that you write the answers before even thinking about the questions. If you try something that doesn't match your declared types, your code editor will let you know instantly.

Here's another scenario:

You're using a framework or dependency you're not super familiar with. You've been through the docs a couple of times but only learned about some key concepts.

Instead of rummaging through the API docs hundreds of times to see if a specific method is called createUser(), createNewUser(), or createEntity('user', ...) you can type down "create", let your editor autocomplete work for you and save countless alt+tabs to the docs page.

It helps you sleep better at night

As your project grows, TypeScript makes it harder for you to shoot yourself in the foot. Harder but not impossible, as self-sabotage is a quintessential aspect of software engineering.

You know, your vanilla JS codebase might look cute and harmless now in its infancy, but you know that if left unattended for too long (or feed it after midnight), it will start to go wild.

It might be challenging to picture that scenario if you've never got close to a vast JS-only project, but trust me, things get messy.

I like TypeScript because it makes your codebase "tighter" in a good way.

It takes away some of that crazy flexibility and permissiveness of JavaScript and creates an environment where you must think a little bit deeper about how you'll organize your data.

After you put in the effort of learning TS, JS codebases feel like poorly built toy that does work, but rattles a lot when you pick it up and shake it close to your ear. You just don't trust it as much.

Every time you write and use a new type, you create a new constrain that prevents you from making bad decisions. And consequently, the trust you have in your own code increases.

Add that to a well-configured CI that checks for TS errors before build, and you'll have a safety net that prevents you from shipping embarrassing (and 100% avoidable) type errors.

Combine that with a well-tested application, and your sleep quality will improve ten-fold during release weeks.

How and where to start

Now, you might not have that very strong "my new job literally depends on learning TypeScript" kind of motivation, so that's what this section is all about.

I'm confident that by now, I've at least made you consider trying it, so here are a few suggestions on how to start.

Just keep in mind that sucking at something is the first step toward being sorta good at something.

1. Sit down, grab a warm beverage, and read through the docs

This sounds obvious, but I'd like to stress how good the TS intro material is. Really, it's got dedicated guides for new programmers, for people with some JS experience, for functional programmers, it is excellent.

Learning styles differ from person to person, but I'm sure that having the theory basics before getting down to business will help you immensely.

2. Start slow with a new project

A calculator, a to-do list, a neat project with Spotify API + react-three-fiber, a large-scale CRM to rival Salesforce's biggest efforts. It doesn't matter what it is as long as it is funny enough to keep you engaged.

Just run $ yarn create next-app --typescript and go to town!

There's one rule, though. Use @ts-ignore or type any and you lose. This will be the golden rule to keep you focused when TypeScript starts testing your faith.

And it will.

3. Gradually migrate a JS project to TypeScript

TypeScript came around when people already had a lot of JavaScript projects up and running. So it is no surprise that we can find a lot of migration tools and guides.

That said, a great way to start cracking some TypeScript is by cloning a JS repo and migrating it to TS. It can be some old project of yours or that small abandoned script on your company's GitHub page.

You can use AirBnb's ts-migrate tool or try a more direct tactic following the Migrating from JavaScript guide.

This approach is somewhat different from the previous suggestion as type any will be a good friend while you sort out a myriad of type errors. But you'll get there; you just gotta keep pushing forward.

Some tips before you start

But wait, there's more!

This article is already getting a little on the longer side. I know, I know... But here are some lessons I learned after this intense year of TypeScript:

1. Take your time reading error messages

TS error messages are really something. They can look aggressively verbose and distract you from the problem at hand.

Try reading them bottom to top and make a solid effort to understand what is wrong before brute-forcing a solution (or giving up and leaving it as any).

2. TS will infer a lot of stuff, get to know how it works

You don't need to type every single line of your code. There's this thing called Type Inference where TS makes an educated guess about types considering information it.

For instance, if you type an array, you won't need to type the argument of a filter or map function.

const potatoes: Array<string> = ["russet", "yukon gold", "la ratte"];

// no need to type the potato arg below 👇
const bestPotatoForMashedPotatoes = potatoes.filter(
  (potato) => potato === "la ratte"
);

Unrelated cooking tip, La Ratte is arguably the best potato for mashed potatoes.

3. Always check for TypeScript support when adding a new dependency

Most big libraries have either their type definitions contained in the same package you installed or under DefinitelyTyped.

Make sure to always search for those type defs whenever you need them.

4. The extra syntax pops up like a sore thumb in the beginning

This is more of an attempt to bring you some comfort rather than an actual tip, but... Yeah, it is a lot of new characters in your editor.

It will look overwhelming for a couple of weeks, but you'll get used to it sooner than you think.

Conclusion

I'd rather not have to use TypeScript.

It would be much easier to fling methods and variables left and right and hope for the best. Unfortunately, I lack the supernatural skill to always ship 100% bug-free code every time.

TypeScript helps me ship better, more reliable work, and I'm glad it exists. Getting acquainted with it was no small feat, but I'm a better engineer today because of it.

So yeah, give it a try if this article resonates with you. I hope it helped ease your TypeScriptoPhobia.

You may not like in the beginning -- or at all -- but it is like eating bitter greens or exercising, you might not enjoy it, but it will be good for you.

Photo by Andy Henderson on Unsplash

9 Hiring Tips for Team Leads and Software Engineers

Vitor Paladini — Wed, 12 May 2021 11:19:07 +0000

This week I realized that ever since my first full-time job as a frontend engineer I was somewhat involved or responsible for hiring new people.

And I always found hiring... Strangely rewarding? I don't know. I have this weird predisposition to deal with work like it is some kind of strategy game. Hiring feels a lot like adding reinforcements to my XCOM squad.

That being said, this hiring game is far from an easy one, and after many screened candidates, many mistakes, and zero formal HR training, I learned a lot of stuff that I'd love to share.

Which brings us to this article, filled to the brim with advice for engineers (and team leads) that suddenly faced a need to add people to their team.

Just keep in mind that while some of my learnings are actionable, some others are straight-up opinions, and both are direct consequences of my professional experience. So grab (and share!) what resonates with you and feel free to skip what you don't find applicable.

Let us begin.

Treat candidates with the utmost respect and dignity

Starting fast with rule freaking zero.

It makes me mad that this needs to be said, but it does. No candidate should ever be ignored; no candidate should ever be left waiting weeks for a status update. That's basic human decency and the absolute minimum you can do when hiring people.

Sorry for the rant, but I've seen friends being treated like crap far too many times. This kind of behaviour is unacceptable and I wonder why it happens so often.

One plausible theory I have is that recruiters (be it HR or engineers) usually fall into this hole where they can't notice the enormous asymmetry of the hiring process and treat people like mere tickets on aboard.

See, as a recruiter, you go through dozens of profiles a day and disqualifying people is just part of the job. When you're finally done, you get a pat on the back, a "job well done", and move forward with other tasks.

Applicants, on the other hand, have much more at stake. Not only because applying for a new job usually takes a significant amount of time, but also because a new job might mean a critical and long-waited career change, more money and safety, a breath of fresh air, a self-realization boost, and fresh, exciting challenges.

Which does not mean you should hire people "because they want that job so badly!!! 😩", but keeping that asymmetry in mind will help you stay empathetic and treat candidates with respect.

Be super specific about what you want, what you can offer, and how you hire

Hiring takes a lot of mental energy. Replying dozens of emails answering the same question about benefits and stipends over and over is not an intelligent use of that energy. So do yourself a favour and write a comprehensive job listing.

Start with a very detailed list of what does the company expects from the position. Think requirements, values, years of experience with XYZ, what the candidate can say or show to increase their chances, etc. Help them help you.

And be as detailed, if not more, about what the company can offer as compensation for the role. Salary is a piece of obvious information that should be up top, and you should try and be as specific as you can, a hard number is ideal, but a salary range that accounts for experience works well enough. Don't forget benefits, PTO and sick-days policies, home-office budget, etc.

Finally, do remember to add a section where you explain how the hiring process will be handled. A couple paragraphs describing each step and how long they usually take is enough to keep candidates informed. Being transparent is critical.

And just like good engineers write new test cases after a newfound bug, make sure to update the job listing with extra info after a candidate emails you with a new question.

Have some kind of system where you can keep track of everything

Sometimes, when I'm feeling a little bit optimistic, I think that recruiters ignore candidates not because they don't care but because they're terribly disorganized.

I mean, that's somewhat understandable. It is easy to see how dealing with hundreds of candidates can be troublesome when you don't have a system to help you go through applications. However, trusting the task of keeping up with hundreds of people to your brain is hard to excuse.

So whenever I have to deal with more than a pair of candidates, I create a Trello board or something similar, like a Google Sheet, to keep control of the process. I'm a fan of creating super-comprehensive pipelines where I can move people through each step so, for a standard hiring process, I'd have columns for:

Application received > Application reviewed > First meeting invite sent > First meeting confirmed > Skill assessment sent > Skill assessment reviewed > Meeting with hiring manager invite sent > Meeting with hiring manager confirmed > Offer sent > Hired

Your mileage may vary depending on how your recruiting process works, of course, but having a clear picture about every single candidate and where they are in the pipeline brings some much-needed peace of mind.

Create a checklist to help you filter our candidates objectively

Success! You've promoted your job listing very well, some industry influencers even shared it on Twitter, and now you have eighteen hundred applications to sift through. Hooray!

Ok, that number of applications is probably not realistic for the majority of job openings. But be it 1800 or 18, you might not have the time to book a 30-minute chat with everyone that sends you an application. So you need a way to filter these candidates in a fast, fair and objective manner.

That's where a checklist comes in handy, and if you wrote a detailed job listing, you're halfway there already.

Start by gathering everything you wrote on the "what we expect from this position" and turn it into a checklist. Does this candidate have 5 years of experience with Node? ✅ Do they have prior leadership experience? ✅ Their past experiences are good evidence of seniority? ✅. And so on.

Doing so provides an objective way to compare suitable applicants and gives you a fair (and quick) way to disqualify candidates that don't match the opening requirements. There is no problem with sending a "Thanks, but we expect more experience for candidates applying for this position" if you were transparent about what that amount of experience means.

Write down with a few canned, well-thought email templates

Great hiring experiences happen when the people behind them are engaged and motivated to do it. So, as it happens in many situations in our industry, if you don't really feel like doing it, you'll do it half-assed.

But don't take that as discouragement. I firmly believe that engineers should be the protagonists of hiring, and "not feeling like it" should be expected from time to time. Hiring is a communication-intensive process that can leave the best, most extrovert engineers feeling drained after a few hours.

And what do we do when we don't want to work on a problem? We find a way to make that problem easier, more pleasurable to work with. And one thing that really helps is emails templates.

Let's go back to our hiring pipeline for a sec:

Application received > Application reviewed > First meeting invite sent > First meeting confirmed > Skill assessment sent > Skill assessment reviewed > Meeting with hiring manager invite sent > Meeting with hiring manager confirmed > Offer sent > Hired

Imagine that you need to update candidates every time their status changes, be it progress or disqualification. Typing down:

Hello candidate,

we are happy to invite you to the next step /
unfortunately, we decided to not move forward with your application

for each step, for each candidate, gets old real quick. So do yourself a favour and write that email only once and use it as a template.

Some pro HR tools like Recruitee gives you some fancy dynamic tags like [candidate_name] or [position_name], so you don't even need to worry about replacing strings. But even if you don't have those, simply copying and pasting a template (and remembering to change the candidate's name, for god's sake) will save you a lot of time.

As a rule of thumb, it is good to have a positive (we're moving you to the next step) and a negative (unfortunately, we're not going forward) template for each stage of your pipeline. Just remember rule zero and write those messages with extra care and respect.

Another good thing to keep in mind is that the longer you took to disqualify a candidate – say, they were dropped out on the last step before hiring – the more invested they were in the position. So take some extra time to write additional feedback for them.

And even if you create a dozen templates, you'll still likely have to write some original replies for edge cases. Just make sure to update your job opening page with the information if it makes sense.

Don't let the ball on your court for long

Long recruiting processes suck. Candidates get more anxious (and uninterested) by the week, recruiters get demoralized by slow progress, and sometimes the process takes so long that the open position starts to get questioned.

"If you need that extra person on your team so badly, why you're taking so long to find them, huh?"

Poor hiring decisions, however, also suck tremendously. And sometimes, the only way to prevent that is investing a lot of time in assessing candidates.

This sounds a lot like a no-win scenario, drag the process for too long and risk losing great candidates to other companies, rush like hell and risk adding a Python backend engineer to your React frontend team. Pretty much an HR Kobayashi Maru.

You can do two things to deal with this impossible situation:

Question your leadership (or yourself) about how long the hiring process should be. It is essential to have a "baseline" process that works most of the time, but sometimes you can speed up one step or two to make things go faster without significant negative impact.

And if the process can't be made any faster, prevent it from going even slower.

If you need to communicate an update to a candidate, do so immediately. If a candidate is unresponsive, check if they're still interested. If other people in the company need to take action, keep bugging that until they do something.

No candidate should be left waiting because you're "like, super busy" with other tasks. An email takes like 2 minutes, even less if you already created some templates.

Be aware of hiring biases

Human beings are fascinating animals.

We tend to look into the mirror and see clear-thinking, rational, fair individuals. But we are constant victims of cognitive biases that very much affect our decision-making without consent and, most of the time, without our awareness.

If we don't stay alert of these biases, we might favour candidates for unfair reasons, like them being surprisingly good looking person, or their life stories being similar to ours.

Another example, sometimes a friend or strong referral applies for the position. Instead of rationally assessing them and weighing pros and cons, we just search for information to confirm the initial assumption that they're a good candidate.

For the sake of brevity – and the already mentioned lack of formal psychology & HR education – this section won't feature a list of biases, only a strong recommendation for you to research more about it on reputable sources. Doing so will help you hire better and give you insights into some unconscious decisions you make every day.

Another thing to keep in mind, and this is a suggestion I'm comfortable with making, try and have at least one more person with you when evaluating CVs and during meetings with candidates.

It doesn't have to be the same colleague pairing with you every time. Just having one more person sharing their thoughts about a candidate is a powerful tool to help both of you recognize and counter biases.

Take action

A few years ago, I found myself in this unusual scenario where three engineers, out of five, left my team in the same month. Each of them had good reasons to do so, and I was happy that they could find new challenges.

One thing I was not pleased about, though, is that my then team had some optimistic goals that were no longer attainable with two people instead of five. And to make things worse, the HR dept was notoriously slow and unresponsive. Some teams usually had to wait for months to meet with a promising candidate, things we're not looking good.

Thankfully (or, should I say, at least), the company had a strong ownership and autonomy culture, so I convinced myself that by jumping over HR and handling recruiting all by myself, I'd be 100% aligned to the company expectations.

And that's what I did. I still had a talk about compensation and benefits with HR – as a mere Team Lead, I didn't have that level of autonomy. Still, our agreement was that I would pick the candidates, and they would just work the final bureaucracy of hiring contracts, background checks and so on.

So for a couple of weeks, I didn't write a single console.log and devoted my time to writing job opening pages, headhunting, screening candidates, assessing tech skills, and doing all the communication.

During that period, I went through HR material like I was reading the docs of a fascinating new framework. Whenever I was conflicted with a decision or unsure about how to proceed, there was good advice on the internet. Hiring is not rocket science.

And things went surprisingly well! We hired three competent junior engineers with great cultural fit and still got to meet the quarter goals. I still catch myself wondering how we did it and feel content to have grabbed that bull but the horns.

So yeah, if there's a moral to this anecdote, it is that sometimes the only way you can put a fire down is by dropping the firehose and finding some more firefighters to team up with.

Remember that there's more to a good engineer than raw coding skills

Filtering candidates is a big, if not the most significant, part of recruiting. You want people to help you on a mission, and you want to pick the best among all applicants.

What makes the "best" candidate varies a lot, though. Being super good with this week's stack is an obvious thing to notice, sure, but there are still many subtle and equally important skills to consider before deciding and who you'll hire.

For instance, try and picture a talented engineer that can't communicate their thoughts clearly, either written or verbally. Or a super fast designer that works fantastically under supervision but lacks the self-motivation to keep pushing when no one is watching.

Doing great work nowadays requires a diverse skill-set, especially if we consider the remote work boom. You need people that: can work under little to no supervision, self-organize over a clear mission, collaborate well while being precise with their words, manages their time efficiently, and display strong emotional intelligence.

Which can be... Hard to find, yeah, but just like a person can be a junior in tech skills, you can expect them to be inexperienced with these so-called "soft skills". This is fine, a good manager/team lead should develop soft skills as much as they promote tech expertise among the team.

Just keep in mind that values like integrity, honesty, and respect are not negotiable and should be expected from the greenest intern to the most seasoned veteran.

Wrapping it all up

I'm quite confident that you'll go from unstructured, chaotic hiring to a pretty darn good process by following these tips. Most of it might sound like straight-up common sense to experienced people, but trust me, the "me from the past" would've love to be taught some of those things.

And with that in mind, I'm 100% sure that I still have a lot to learn about it. I mean, hiring is a complex process with a lot of variation and moving parts, and everything I know is "derived from" and "limited to" my career as a frontend engineer.

For future reference, I have this (very well recommended) book on my reading list called "Scaling Teams" from Alexander and David Loftesness. I should be going through it shortly, so you can expect either a quick revision of this article or a new "lesson learned" article about it.

Stay tuned and until next time. 👋

Photo by Christina @ wocintechchat.com on Unsplash.

Hey, let's connect 👋

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

Responsive Snakes! And what they can teach you about CSS 🐍

Vitor Paladini — Wed, 18 Nov 2020 14:44:58 +0000

"If a snake was responsive..." is my favorite webdev meme. Have a look below if you're not familiar with this extremely important question.

I love it, it is so silly. But at the same time makes us think a little deeper about responsive design and CSS techniques.

And that's what this article is about! Let's talk about four responsive snake implementations, see how they were made and what they can teach us.

🚨 There's a CodeSandbox for you to play with at the end

Squishy Snake

Squishy Snake is the most basic of our responsive snakes. It uses no media queries at all!

Like all the other snakes, it is made by 3 divs: .tail, .body, and .head. And a wrapper, in this case, .snake-1.

<div class="snake-1">
  <div class="tail"></div>
  <div class="body"></div>
  <div class="head"></div>
</div>

There is quite a lot of CSS responsible for drawing the snake itself. But let's focus only on the rules that make it responsive.

In this first case, I wrote CSS rules that say that the tail width should always be 200 pixels long, that the head should be 100 pixels long, and that the body should fill the rest.

.snake-1 {
  display: flex;
}
.tail {
  flex: 0 0 200px;
}
.body {
  flex: 1 0 auto;
}
.head {
  flex: 0 0 100px;
}

You can apply the same technique in real life when your page needs two sidebars and some middle content that should fill the space in between!

Thank you, Squishy Snake 🐍. Next!

Curved Snake

Curved Snake shares the same HTML structure and some CSS, but things get funky when the screen goes short!

The first thing we do is flip the flex order, so instead of horizontal, each snake part is rendered vertically.

.snake-2 {
  align-items: center;
  flex-direction: column;
  height: 62vh;
  justify-content: space-between;
}

Now that flex-direction is vertical, we need to update our snake parts so that they have a fixed height instead of width.

.snake-2 .tail {
  flex: 0 0 30px;
  width: 100%;
}
.snake-2 .body {
  width: 100%;
}
.snake-2 .head {
  flex: 0 0 30px;
  width: 100%;
}

And finally, we link the tail, body, and head with some extra pseudo-elements. These are the green vertical parts that only exist when the screen collapses.

.snake-2::before,
.snake-2::after {
  content: '';
  height: 30vh;
  position: absolute;
  right: 0;
  top: 15px;
  width: 30px;
}
.snake-2::after {
  left: 0;
  top: 50%;
}

Now for the real-life takeaway:

Changing flex-direction to vertical is a life-saver when you're doing responsive pages.

Just stay aware that flex-direction: column inverts how divs flow inside a flex container, so justify-content becomes vertical and align-items horizontal!

Thanks, Curved Snake 🐍. Onto the next one!

Sliced Snake

Sliced Snake is pretty much Curved Snake without the ::before and ::after pseudo-elements.

The other difference is that this one doesn't look so lively.

See, the snake eyes are also pseudo-elements (see the CodeSandbox below). So in order to change its eye, all I needed to do was write this handful of CSS:

.snake-3 .head::before {
  content: "✖";
}

Real-life takeaway: If you slice a snake it dies. Don't try dealing with snakes yourself, call your local environmental protection agency!

Thanks, Sliced Snake, you will not be forgotten.

Next!

Scrolly Snake

I love Scrolly Snake. This one is the absolute laziest take on a responsive snake.

Instead of allowing it to overflow off-screen, simply add some width and overflow-w: scroll to it and you're done.

.snake-4 {
  width: 70%;
  overflow-x: scroll;
}

Now, despite Scrolly Snake looking like a really lazy attempt to responsiveness, it teaches us a great lesson:

There are some times that overflow: scroll is the only solution for a responsive problem.

For instance, imagine that you have a huge table full of columns and need to make it responsive, or a super long string that can't be wrapped.

It is important to know all the tools that you have at hand!

CodeSnakebox

Try editing/playing/breaking the examples below:

Thanks for reading! Can you think of another way to make a snake responsive?

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

Make Your CSS Dynamic 🕺 With Styled Components

Vitor Paladini — Mon, 16 Nov 2020 15:29:20 +0000

styled-components helps you write better CSS in React. It does so by allowing you to wrap all your component's styles into a neat, style-only component.

So, instead of this:

.wrapper{
  font-family: sans-serif;
}

.button {
  background: #2b2b2b;
  color: white;
  font-size: 24px;
  padding: 12px;
  cursor: pointer;
}

and this

import React from "react";
import './styles.css';

export default function App() {
  return (
    <div class="Wrapper">
      <button class="Button">Hello, I am a Button</button>
    </div>
  );
}

You have something like that:

import React from "react";
import styled from "styled-components";

const Wrapper = styled.div`
  font-family: sans-serif;
`;

const Button = styled.button`
  background: #2b2b2b;
  color: white;
  font-size: 24px;
  padding: 12px;
  cursor: pointer;
`;

export default function App() {
  return (
    <Wrapper>
      <Button>Hello, I am a Button</Button>
    </Wrapper>
  );
}

Which might not look like a big change. I know, I know! It looks like all that we did here was merge two files into a single one...

However, by doing so we integrated our styles into styled-components and now that the library controls our CSS it can do all kinds of cool stuff like:

Automatic inject critical CSS
Automatic vendor prefixing
Theming and dynamic styling

This saves us a lot of time and allows us to focus on important stuff like adding borders to buttons and stuff like that.

Now, after this brief introduction to the wonders of styled-components, let's focus on the dynamic styling part.

Dynamic styling with `styled-components`

The point of dynamic styling is saving time and writing less CSS.

Imagine that you have a primary and a secondary button. They are very similar, but you want your primary button to have a flashy color so people actually click on it.

You can do that by adding a primary attribute to your <Button />...

export default function App() {
  return (
    <Wrapper>
      <Button>Hello, I am a Button</Button>
      <Button primary>Hello, I am a Primary Button</Button>
    </Wrapper>
  );
}

...and handling that new attribute on your styled component, exactly like you would with component props!

const Button = styled.button`
  background: ${props => props.primary ? "#6495ED" : "#2b2b2b"};
  color: white;
  font-size: 24px;
  padding: 12px;
  cursor: pointer;
`;

"But what if my component needs a lot of customization?"

It may happen that your buttons need to be extra flexible, while still sharing some basic styles. Maybe you need to have a primary button that also has rounded corners and a fancy box-shadow.

You can do that by applying the same logic as the earlier example. But that can get quite repetitive, look:

const Button = styled.button`
  background: ${props => props.primary ? "#6495ED" : "#2b2b2b"};
  border-radius: ${props => props.round ? "4px" : "0"};
  box-shadow: ${props => props.shadow ? "2px 2px 2px rgba(0, 0, 0, 0.5)" : "none"};
  color: white;
  font-size: 24px;
  padding: 12px;
  cursor: pointer;
`;

What you can do here instead is "lift" the props and do something like that:

const Button = styled.button(
  ({ primary, round, shadow }) => `
    background: ${primary ? "#6495ED" : "#2b2b2b"};
    border-radius: ${round ? "4px" : "0"};
    box-shadow: ${shadow ? "2px 2px 2px rgba(0, 0, 0, 0.5)" : "none"};
    color: white;
    font-size: 24px;
    padding: 12px;
    cursor: pointer;
  `
);

That way, instead of "importing" each prop on a per-line basis, you do it at the very beginning of your styles, so you can be 100% sure of what makes it dynamic!

Just keep in mind that while this technique is cool and makes your styled components look leaner, needing extensive customization might be a sign of bad abstraction.

So before adding a fourth (or fifth) dynamic style rule, make sure that you shouldn't really be creating a new styled component!

And this is it for the day. Thanks for reading!

I wrote this article (at the eleventh hour) for Hashnode Bootcamp II first assignment.

Make sure to check all the other Bootcamp articles and follow me on Twitter!

Simple Chrome Extensions That Make My Work a Bit Easier

Vitor Paladini — Fri, 06 Nov 2020 13:57:14 +0000

No time for introductions!

I've been front-end-ing for a while.

Here are some of the extensions that helped me along the way.

Links on the title.

Let's go! 🏃‍♀️🏃‍♂️💨

Pesticide

Pesticide is great for debugging invisible stuff in CSS. I'm talking margins, padding, and everything that fills some space but you can't quite know where it begins and ends.

The extension couldn't be simpler, really. It works by applying 1px borders to every element on the page, look.

Live CSS Editor

Live CSS Editor, as the name suggests, allows you to add some CSS to every page through a neat little box. It is great for debugging and testing a small style real quick without opening DevTools.

PerfectPixel

PerfectPixel is particularly practical when you need to perfectly place pixels on your page.

But seriously, though. There is no better tool for when your implementation needs to look ridiculously close to the layout.

Just paste a semi-transparent .jpg over your screen and tweak your CSS until it matches.

ColorZilla

Sometimes you just need to pick a color.

ColorZilla is the best color picker for your color picking needs.

TimeShift

If your product needs to support multiple timezones you might know already that working with timezones is a one-way ticket to Frustration Town.

This extension won't solve your problems but it makes the timezone debugging experience slightly less sad by allowing you to fake your browser's current timezone.

GoFullPage

You need to share your progress and you need to share it quickly.

But Chrome, for some unknown reason, doesn't offer you a native way to screenshot the whole page.

This extension fixes that problem.

Thanks for reading! Hope any of these extensions make your work slightly easier.

This week got my super anxious and unproductive so I rushed this article last minute to keep my streak. I need to practice what I preach, after all.

I also might have drank way too much coffee this morning.

Anyway! Follow me on Twitter, leave your suggestions in the comments. Have a good weekend! 😄

Photo by Toa Heftiba Unsplash

Is there a designated place to chat with members of the DEV Community?

Vitor Paladini — Fri, 30 Oct 2020 19:25:38 +0000

I miss a place where we can chat, share tips, and build stronger bonds. Is there a Discord server that people around here use or something similar?

I'm aware of DEV Connect but never really understood how it works. 😅

Grab your user's attention with the :focus-within CSS selector

Vitor Paladini — Fri, 30 Oct 2020 11:52:10 +0000

Here's a neat little trick:

You can use the :focus-within selector to style the parent of a focused element.

That allows you to create some interactive form UI without a single line of JavaScript. Try the example below:

This demo uses :focus-within, plus the ::before pseudo-selector and some absolute positioning magic. We'll go through the details but you can check the full source below.

`:focus-within` selector + `::before` pseudo-elements + absolute positioning

All in a single declaration block! Let's have a look at the most important part of this example.

body:focus-within::before {
  content: "";
  position: absolute;
  top: 0;
  left: 0;
  width: 100%;
  height: 100%;
  background-color: rgba(0, 0, 0, 0.7);
}

`body:focus-within`

This selector will apply styles whenever there is focus... within the body!

Oh, and :focus-within works with any element. We're sticking with body only for this example.

You can be creative and come up with .literallyAnyElement:focus-within and use this selector as you please.

`body:focus-within::before` + absolute positioning

In our example, that means that whenever any field is focused on the body, a ::before pseudo-element will be created with those styles:

content: "";
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
background-color: rgba(0, 0, 0, 0.7);

The content: '' property is required for pseudo-elements and everything else are properties used to create a dark, transparent overlay that fills the whole screen!

Extra stuff to make it work properly

Keep in mind that you still need to make a couple of tweaks to make the overlay work perfectly.

html,
body {
  height: 100vh;
}

This makes sure that the overlay fills the whole screen even if there isn't enough content on the page.

form {
 position: relative;

This position: relative; ensures that the overlay renders below the form.

And that's it for this week's neat little trick. Thanks for reading!

Make sure the check the other tricks in the series and follow me on Twitter if you found any of my articles helpful 😄

EDIT: Make sure to check Andrew's suggestion in the comments below!

Photo by Stefan Cosma on Unsplash

How I Manage Impostor Syndrome, Fear of Failure, and Other Common Programmer Problems

Vitor Paladini — Fri, 23 Oct 2020 12:04:29 +0000

Sometimes your own bugs are much harder to fix.

One thing that I noticed after all those years in the industry is that mastering the tech is only half of the battle. You know, being fluent in JavaScript isn't worth much if you are paralyzed by fear of failure and never step out of your programming cave.

However, some other thing I also realized is that with a little bit of work and self-reflection you can handle the inner side of programming just like you handle your codebase.

You just need to approach these issues like optimization opportunities instead of bugs to fix once and for all.

So let's talk about how to deal with those kinds of issues.

Check out this neat table of contents:

Impostor syndrome
Dealing with failure
Comparing yourself to others
"There's too much to learn"
Conclusion

Impostor syndrome 😥

I had plenty of episodes of impostor syndrome in my career, the biggest one was when I accepted my first leadership position at a big payment company.

See, I had some tech lead experience under my shoulders already but never at a big company, my previous leadership role was more a matter of necessity than hierarchy. And to make things worse, a was a complete newbie in the payment industry.

So, for the first time ever, I was a tech lead among other tech leads, and all of them looked so much smarter and capable than me. I'll tell you, my friend, I felt like a fraud.

"What the hell am I even doing here?" was a common thought.

Fortunately, during that time, I found a few pieces of advice that helped me shake off that feeling. Nowadays, whenever insecurity strikes, I make a conscient effort to remind myself of these tips, it helps a lot.

Here they are:

The people that hired you are not stupid. Seriously, they would not have hired you if they didn't think you were capable of doing the job. Hiring good people is literally their job description. They probably even picked you among a handful of other very good people. You're good.

You're not a manipulative mastermind. Fooling people is hard work. Your coworkers are aware of your flaws, it's okay. They are also full of them and can be more supportive than you imagine.

Help people. Helping people instantly stave off impostor feelings. By being helpful you are able to see instantly how what you know can make people's life easier. It is a very rewarding feeling.

Use social media wisely. It is a petty feeling, but nothing triggers my impostor syndrome so much like scrolling through twenty tweets of people doing an amazing job in this industry. It makes me feel like "how can they even do all of it?".

One thing that helps (other than quitting Twitter for a couple of hours) is following people that are still learning and can benefit from your insights.

What I'm trying to say here is, by all means, follow the masters, but also follow some newbies.

Not being the smartest person in the room is actually a very good thing. Try to see the knowledge gap between you and your peers not as a flaw but as learning potential. We all learn from each others experience and it is a privilege to work with people that can teach you a lot.

Know what you don't know. Sometimes the impostor syndrome hits and it feels like you don't know shit. When it happens, try and make a realistic list of everything you should learn to stop feeling like an impostor and compare it with everything that you know already.

This exercise gives you clarity and, even if you still feel like an impostor, you'll find a new focus to learn what you should learn.

Dealing with failure 👎

I hate failing.

Not up to a point of stopping me from embarking on new, bold endeavors but, truth be told, failing fucking sucks.

I see a lot of advice around the internet like "you should love to fail, yadda-yadda" but, let's be honest for a moment, if it didn't hurt when you failed it means you didn't put enough effort.

You'd need to be an ultimate-zen-monk-master-of-emotional-intelligence to not feel bad after giving your absolute best and failing. It's natural, feel free to hate failing, hate it with passion. 😡

But learn to love feedback and the lessons that each failure teaches you. 😌

Be humble and accept your responsibility for the failure. This is the first step, the only way to learn from your failures is to own your mistakes and find a way to prevent them in the future.

However…

You can do everything right and still fail. You can be the perfect candidate, master all the algorithms, and ace the whiteboard interview, only for the company to hire a friend of the CTO. Life is an unpredictable crazy ride that's far from fair. Understanding it makes some failures easier to swallow.

Understand that every failure teaches you something. Give yourself some time to think about a failure. Try to write down what you could've done differently. Heck, write a damn incident report about your failure as a blog post, sharing what you learned through failure is a big act of generosity.

Failing is better than "what if-ing". I've failed quite a lot during these years and I can say that the pain of failing fades much quicker than the bitter taste of "I should have at least tried it...".

Comparing yourself to others 👀

This one is a cousin of impostor syndrome and a bad habit I'm particularly guilty of.

There are a lot of brilliant, talented people in this industry and I'm grateful for their contributions. Prolific programmers make my life so much easier!

Sometimes, however, it gets hard to shake off the "this person is 10 years younger and much more successful than I'll ever be" feeling.

Whenever I feel that way I try to remind myself of a few things:

Am I doing my best to make progress without harming my mental health? Every person has their own limit. Working 80 hour weeks while maintaining 16 open source repositories might make a person's career skyrocket, but at what cost?

It is much better to make consistent progress at a slower rate than wreck your health trying to maintain a rhythm that is not your own.

Hard work pays off, but luck plays a huge role. And I'm not the one saying it. Here's a very interesting article from Scientific American on the matter.

Try remembering that next time you find yourself comparing your work to another person's. You'll never be able to know for certain because–sorry for being repetitive here–life is an unpredictable crazy ride, but it could have been luck. Plain simple luck.

Everyone has their own set of personal challenges and privileges. One final reason to put you back on track when this kind of thought pops in: it is a whole different race for everyone. No other person had the same start nor has the same finish line. Stay focused on your lane and strive for greatness at your own speed.

"There's too much to learn" 😫📚

I was lucky to start working exactly when Flash was being discontinued on the web and jQuery was rising to stardom.

I consider myself so lucky because I was able to witness the state of front-end development becoming increasingly more complex while I was an active member of this industry. So I had the privilege to learn new stuff as they were coming up.

That being said, if I saw a roadmap of "How to become a front-end developer" as a beginner nowadays I'd feel scared, overwhelmed, and consider a career as a long-haul driver. I mean it!

But here are some words of encouragement my fellow beginner, for there is no other way than the way of knowledge!

Seriously, there is no other way. You have to be okay with the fact that you'll be studying your whole life. Such is the blessing and curse of the programmer.

Things change, new languages and frameworks are created every year, you don't have to learn everything but it is very important to stay curious and find joy in learning new nerdy programming stuff.

Learn how to learn. You have a lot on your plate, mate, so be sure to make good use of your study time. There are plenty of tools to help you so, a nice one is called the VARK Questionnaire and helps you identify how you learn better.

Personally, I like watching hour-long introductions to new tools before moving to articles, docs, and tutorials. And only then I move to the more practical stuff.

Pick a path. Try to learn everything and you'll suck at a lot of stuff. One of the best things I did career-wise was to give up on being a mediocre full-stack developer and focus on being a really good front-end engineer.

Narrowing down your focus reduces the amount of stuff you need to learn and gives you time to really develop a skill. Just be sure to pick a path that's viable and have enough job openings.

Apply what you learn. Cramming a bunch of theory with no practice is a surefire way to burn-out. Try tinkering with the stuff you just learned. See if that library works as nice as it's docs says.

Break stuff! You're the sole responsible for your learning, so make it fun!

Start with the basics. I'm ending with the most important one. Even if you have a lot to learn and are in a hurry, learning the basics will make your journey much smoother.

If you're starting as a front-end developer, give yourself plenty of time to learning the basics of HTML, CSS, JS, and how browsers work before moving into harder stuff like React and bundlers.

The same applies to other areas. You can't build a strong house without well-laid foundations!

Conclusion

Aaand that's a wrap. I covered every single one of my learnings about these classic problems.

If you just scrolled to the conclusion, here's a quick summary:

Being an actual impostor is hard and you're probably doing fine.
It is ok to feel bad about failure as long as you learn (and teach!) from it.
People’s stories are different and comparing yourself to them is a bit dumb.
Yes, there is a lot to learn. Pick an area and try to improve consistently.

And as a final takeaway. Don't worry about fixing any of these issues, they come and go.

Instead, use your energy to learn how to deal with them and you'll make your career a more enjoyable race to run.

Please let me know your thoughts on this article, share your tips in the comments!

I still have a lot to learn and will certainly publish an updated edition of this article in the future. So stay tuned and follow me on Twitter for takes on front-end, career, soft-skills, and the occasional shitpost.

Oh, and if you found this article genuinely helpful, please share it with your friends and peers. 😄

Photo by Max van den Oetelaar on Unsplash

Hey, let's connect 👋

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

Say Goodbye to Pesky Overflowing Text With the text-overflow CSS Property

Vitor Paladini — Wed, 14 Oct 2020 11:54:17 +0000

Here's a neat little trick:

You can use the text-overflow + overflow CSS properties to deal with long strings that break your UI.

Check it out:

This is better than truncating the string with JavaScript because you can still copy and paste it fully.

And it is way more flexible because it adapts to the container's width.

And that's it! There ain't much more to it, really. This is a neat little trick in its purest form, a small piece of webdev wisdom fit to a small specific problem.

Oh, and text-overflow has been around for a while so I'd say that even the Nintendo DS Browser supports this property. 😄

Does anybody know who's the creator of that classic CSS IS AWESOME logo? I've seen it in mugs and stickers everywhere but couldn't track the creator to give them credit.

Hey, let's connect 👋

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

I Got the 16 Week Streak Badge. Here’s Everything I Learned About Consistency

Vitor Paladini — Wed, 07 Oct 2020 12:03:43 +0000

Last week I got the 16 Week Streak badge 🥳

This is the longest I've been writing consistently. I'm sure that I couldn't have done it if it wasn't for this beautiful community.

I'm beyond grateful.

And to celebrate that here's my 16-week review. Today I'll be looking back to early June and sharing everything I've learned since then. Stick around if you struggle with consistency, some of my learnings might be useful.

Let's start from the beginning:

Why I started writing

I'll be honest you here, I began writing for pretty selfish reasons.

See, I'm a front-end developer, I've been doing it for quite a while now and I love it. But, simply put, I don't feel like doing it full-time for the rest of my life.

I look forward to another decade or so of slinging divs and pushing pixels. After that, I want to quit the grind and be an educator much like Wes Bos, Kent C. Dodds, and so many others.

So yeah, I started writing here because I need to build an audience. This was another step in my career plan. But something interesting happened during these four months...

The more I kept publishing the more I realized that my work was actually helping quite a lot of people. And that felt very, very rewarding. Which in turn gave me even more strength to keep doing it.

So, for the first time in my career, I feel that I'm truly giving back to the community that helped me so much. And that's a very powerful feeling.

What I learned and how I kept writing

One thing that kept me here in the past few months is that DEV became a safe haven for me during this pandemic.

Instead of obsessing about how crappy this year has been, I could stick around and have pleasant conversations with the community. Writing stuff and engaging in the comments became some kind of therapy.

But hey, I have better advice than this personal anecdote!

Here are some consistency tips:

1. Have a clear writing goal

To be consistent you must first be aware of what consistency means for you. You have to have a clear goal in mind. My goal to publish an article every week, as long as I'm doing it I pass the consistency check.

One thing that helps is to have a somewhat flexible goal though. No matter how much you prepare, sometimes life happens so it is better to have some leeway.

For instance, my goal is to publish an article every Wednesday. I'm okay with publishing it Thursday or Friday if something happens. But Friday 11:59 PM is my absolute deadline.

2. Use your idle time to think about your content

Ideas need some time to ferment.

Using your free time to actively think about your content makes it easier to put it down when the time comes. Try to come up with core ideas first and let them bounce inside your head for a couple of days.

But don't push yourself too hard! You can do it whenever your mind is wandering, like when you're doing the dishes or taking a shower. You'll see how much easier is to write down a concept after you allowed it to mature.

3. Be ok with publishing imperfect work

There are weeks where I write excellent work and feel like a genius. Some other weeks I can't write anything that I'm happy with. In both cases, I publish what I wrote.

See, the single most important thing you need to do keep consistency is… to be consistent!

I know that this sounds obvious but you must keep momentum. It is much harder to go back to writing after you stopped, even if it was for a week only. So keep in mind that publishing imperfect is bad, but breaking your streak is much, much worse.

4. Engage with the community

Writing for the sake of writing will only get you so far.

Having a genuine interest in your reader makes the writing experience more satisfactory. Finding fun in the comments in one more incentive to keep you writing every week.

And here are some more general tips:

5. What seems obvious to you can be outstanding to beginners

I started my neat little tricks series focused on code newbies and I find great joy writing for that audience. And as long as there are beginners, there will be opportunities to teach, share, and learn.

6. Don't be put off by other peoples' work

Another good thing to keep in mind is that even if there are a million articles about a certain subject, you should still write yours.

But make it truly yours, let your personality shine and write it in a way that no one else could.

7. Try not taking yourself too seriously

One funny thing about this writing experience is that my most viewed articles are the ones I had the most fun writing.

Programming is a hard subject and adding a little bit of playfulness can make your content easier to digest.

What do I expect for week 32

Well, I'll still be around here writing, I'm sure about that.

Hopefully, in the next four months, my reach will increase even faster, so I'll be able to help more people. That's something I look forward too.

I also want to write more creative articles like "VS Code shortcuts that I would teach myself if I had a time machine with limited fuel". I had a blast writing this one and was very much surprised by how well it performed.

I'm not sure if I have the time for writing more than one article a week. But that definitely something that I look up to.

And I'll keep working on the "Extremely reusable components" and "Neat little tricks" series" as there's still quite a lot of good content to squeeze there!

But if 2020 has taught us something is that everything might change, so who knows? 😄

Thanks for reading! And thanks for skimming if you just scrolled around a little bit. That's ok, we all do that.

I hope that my learnings serve you well on your journey toward consistent writing. Leave a comment if you need any help with it, I'm far from an expert but I can help. We're all in the same boat here.

Hey, let's connect 👋

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

Show and Hide Content Easily With details and summary HTML Tags

Vitor Paladini — Wed, 30 Sep 2020 12:00:09 +0000

Here's a neat little trick:

You can use the <details> and <summary> HTML tags to create a simple accordion/collapsible UI.

The only problem here is that it looks rather plain and uninteresting.

But nothing that a few lines of CSS can't fix! Here's how it looks with just a little bit of styling.

Remember that you can click the "Open Sandbox" button and edit the styles yourself. I'm sure that you can make it look even nicer. 😄

Oh, and here's the CSS, take a look. It features a couple hacks with padding and box-shadow to make the "border" look consistent but, other than that, it is a pretty simple change.

/* The --padding variable help us control 
the <details> and <summary> spacing */
:root {
  --padding: 16px;
}

details {
  padding: 0 var(--padding);
  box-shadow: inset 0 0 0 4px;
  border-radius: 4px;
}
details[open] {
  padding-bottom: var(--padding);
}

details > summary {
  display: flex;
  padding: var(--padding);
  margin: 0 calc(var(--padding) * -1);
  border-radius: 4px;
  font-size: 24px;
  cursor: pointer;
  justify-content: space-between;
  list-style: none; /* Hides the default arrow */
}
details[open] > summary {
  box-shadow: 0 4px;
}
/* Adds an icon when the <details> is closed... */
details > summary::after {
  content: "+";
}
/* ...and switches it when <details> is open */
details[open] > summary::after {
  content: "-";
}
/* Removes the ugly default arrow on Chrome */
details > summary::-webkit-details-marker {
  display: none;
}

I love how much you can accomplish with plain HTML and CSS.

And by using standard HTML tags you get great accessibility for free!

But wait, there's more!

You can go even further and transform these two tags into a powerful and, dare I say, extremely reusable component.

Let's add some React to it! ⚛️

These two tags work very well with React's component composition pattern.

So you can just go ahead and create a component to help you toggle stuff more consistently and easier.

Look:

Then you can import that component and use it like so:

This is a great component to have on your toolbelt for when you need to implement a few accordions quickly.

Thanks for checking out this neat little trick 👋

I hope it comes in handy soon!

Do you have a suggestion for a neat little trick? Leave it on the comments!

Oh! And remember to check the other articles on this series below. They are some spicy little nuggets of webdev knowledge.

Cover photo by Dominik Vanyi on Unsplash

Hey, let's connect 👋

Follow me on Twitter and let me know you liked this article!

And if you really liked it, make sure to share it with your friends, that'll help me a lot 😄

How do you deal with the endless stream of interruptions that we have nowadays?

Vitor Paladini — Sun, 27 Sep 2020 23:39:29 +0000

Programming is deep work and requires concentration, we all know that.

However, there are some days that I can help but interrupt myself by browsing Twitter or Hacker News when I'm stuck with a task. Which only makes things worse.

How do you deal with that? I can see that being laser-focused would make me much more productive but I have been having trouble reaching that kind of concentration.

DEV Community: Vitor Paladini

How to Overcome Your TypeScriptoPhobia

I used to hate the idea of using it

Why I kind of love it now

TypeScript facilitates communication, like, a lot

It actually eases your mental workload over time

It helps you sleep better at night

How and where to start

1. Sit down, grab a warm beverage, and read through the docs

2. Start slow with a new project

3. Gradually migrate a JS project to TypeScript

Some tips before you start

1. Take your time reading error messages

2. TS will infer a lot of stuff, get to know how it works

3. Always check for TypeScript support when adding a new dependency

4. The extra syntax pops up like a sore thumb in the beginning

Conclusion

9 Hiring Tips for Team Leads and Software Engineers

Treat candidates with the utmost respect and dignity

Be super specific about what you want, what you can offer, and how you hire

Have some kind of system where you can keep track of everything

Create a checklist to help you filter our candidates objectively

Write down with a few canned, well-thought email templates

Don't let the ball on your court for long

Be aware of hiring biases

Take action

Remember that there's more to a good engineer than raw coding skills

Wrapping it all up

Hey, let's connect 👋

Responsive Snakes! And what they can teach you about CSS 🐍

Squishy Snake

Curved Snake

Sliced Snake

Scrolly Snake

CodeSnakebox

Make Your CSS Dynamic 🕺 With Styled Components

Dynamic styling with styled-components

"But what if my component needs a lot of customization?"

Simple Chrome Extensions That Make My Work a Bit Easier

Pesticide

Live CSS Editor

PerfectPixel

ColorZilla

TimeShift

GoFullPage

Is there a designated place to chat with members of the DEV Community?

Grab your user's attention with the :focus-within CSS selector

:focus-within selector + ::before pseudo-elements + absolute positioning

body:focus-within

body:focus-within::before + absolute positioning

Extra stuff to make it work properly

How I Manage Impostor Syndrome, Fear of Failure, and Other Common Programmer Problems

Impostor syndrome 😥

Dealing with failure 👎

Comparing yourself to others 👀

"There's too much to learn" 😫📚

Conclusion

Hey, let's connect 👋

Say Goodbye to Pesky Overflowing Text With the text-overflow CSS Property

Hey, let's connect 👋

I Got the 16 Week Streak Badge. Here’s Everything I Learned About Consistency

Why I started writing

What I learned and how I kept writing

1. Have a clear writing goal

2. Use your idle time to think about your content

3. Be ok with publishing imperfect work

4. Engage with the community

5. What seems obvious to you can be outstanding to beginners

6. Don't be put off by other peoples' work

7. Try not taking yourself too seriously

What do I expect for week 32

Hey, let's connect 👋

Show and Hide Content Easily With details and summary HTML Tags

But wait, there's more!

Let's add some React to it! ⚛️

Thanks for checking out this neat little trick 👋

Hey, let's connect 👋

How do you deal with the endless stream of interruptions that we have nowadays?

Dynamic styling with `styled-components`

`:focus-within` selector + `::before` pseudo-elements + absolute positioning

`body:focus-within`

`body:focus-within::before` + absolute positioning