DEV Community: Shaundai Person

How to switch to using new version of node using nvm

Shaundai Person — Thu, 13 Feb 2025 17:02:11 +0000

SWITCH TO A NEW VERSION (TEMPORARY)
If you want to switch to a new version of node temporarily, use the command
nvm use [version]

where version is the version number. For example, to switch to node 18.20.0, your command will be
nvm use 18.20.0

This will switch the node version until you close your IDE, and then it will restore the default version.

SWITCH TO A NEW VERSION (CHANGE DEFAULT)
If you'd like to change the default node version you're using so that you don't have to continue to change versions every time you re-open your IDE, use the keywords alias default with nvm like this:
nvm alias default [version]

where version is the version number. For example, to switch to node 18.20.0, your command will be
nvm alias default 18.20.0

How to install a new version of node using nvm

Shaundai Person — Wed, 12 Feb 2025 14:41:33 +0000

Just use nvm install [version] where version is the version number. For example:

nvm install 18.20.4

Making Styles Repeatable: Dynamic Styling in React using Styled Components

Shaundai Person — Fri, 18 Jun 2021 23:20:28 +0000

The styled-components library makes it easy to create dynamic styles. At the most fundamental level, Styled Components are just React components with CSS styles attached. Thus, they can be used the same way we'd use any React component. Styled Components also come with out-of-the-box constructors that allow you to pass props and functions into your styles, which is what gives them their dynamic abilities.

Before we get into the how though, let’s talk about the why. Why would we want to use dynamic styles in our React apps?

DRY and Maintainable: Instead of declaring the same styles again and again each time you need them, dynamic styles are declared once and exported as needed. This means that any future changes to styles only need to be made in one place. When you Don’t Repeat Yourself (DRY), maintaining and updating your codebase is simpler.
Less Error Prone: Now that we only need to make our changes in one place, it's also less likely we’ll accidentally miss a change somewhere. For this reason, DRY code (via dynamic styling) is more trustworthy.
Clean and Easy to Read: Dynamic styling allows us to change up our styles without injecting or removing class names, making our stylesheets shorter and cleaner. Styles can even be declared within the .js file using the styles, making them really easy to find later!

Starting with a Basic Button

Start by declaring a variable with a descriptive name (like PrimaryButton below) and setting it equal to styled.[HTML-element-we-want-to-use]. The styles are declared between two backticks at the end of the Styled Component declaration.

import styled from 'styled-components'

export const PrimaryButton = styled.button`
  background-color: darkcyan;
  color: white;

  border-radius: 8px;
  border-color: transparent;
  width: 250px;
  padding: 14px;
  font: 20px Georgia;
  &&:hover {
    background-color: rgb(0,139,139,0.5);
  } 
`

PrimaryButton contains a lot of styles that we'll be using frequently in our app. Luckily - since PrimaryButton is fundamentally a React Component - we don't need to retype these styles each time we need to use them. We also don't need to worry about adding class names to link our styles to a separate stylesheet. To use PrimaryButton styles, all we do is swap the old HTML element <button>...

Before

<button> I am a button <button>

...with our new PrimaryButton Styled Component.

After

<PrimaryButton> I am a button </PrimaryButton>

If our marketing team later decides to change our app’s theme colors from darkcyan to green, all we need to do is make a one-line change to PrimaryButton to change all instances of PrimaryButton to green at once.

Extending Custom Styles

What if we want two different-but-fairly-similar types of buttons in our app? For instance, what if our primary buttons are darkcyan, but we also want some buttons with a red background to indicate to users that an action is permanent? Other than the color, these red “destructive buttons” will be identical to the PrimaryButtons we built in the previous example.

Rather than creating a new class for our destructive style, we extend the PrimaryButton styles that we want to use and override the styles we don’t need. This is all the code we need to tell Styled Components “PrimaryButton, but red.”:

const DestructiveButton = styled(PrimaryButton)`
  color: ‘red’;
`

We can use our new DestructiveButton in place of PrimaryButton wherever we'd like the red buttons to appear. Our code is much cleaner and easier to maintain. If our marketing team comes back and wants to change the padding for all buttons to 12px instead of 14px, we only need to change the single padding declaration in PrimaryButton to update the padding for all buttons, Primary and Destructive alike.

Making Styles Dynamic

Now let’s get into the dynamic styling. In this example, we want a button to be darkcyan some of the time and red some of the time (for example, the submit button on a form that only turns red when the user has entered invalid information).

How can we make our styles change based on the current status of elements in our UI? If we were using just CSS, we'd need to add or remove a class when the input is empty. If we were using React, we might use a function that accepts props. Based on the value in those props, our function could set the color equal to either red or darkcyan. Since Styled Components is just React, we have an easy way of doing the latter.

Styled Components comes with an Attributes constructor (attrs) that accepts static props or dynamic props. We're going to use dynamic props for this example.

We start from scratch with a styled button component - MainButton - which can dynamically render three variants: primary, destructive, and line (inverted primary colors). We'll use the attrs constructor to make the background-color, border-color colors, and hover colors change dynamically.

Below, we start with three objects each defining the colors by variant.

const ButtonBackgroundColors = {
  primary: 'darkcyan',
  destructive: 'red',
  line: 'white'
}

const ButtonBorderColors = {
  primary: 'transparent',
  destructive: 'transparent',
  line: 'darkcyan'
}

const ButtonHoverColors = {
  primary: 'rgb(0,139,139,0.5)',
  destructive: 'rgb(255,0,0,0.5)',
  line: 'rgb(0,139,139,0.5)'
}

To use attrs, we add it onto the end of the template literal declaration. attrs accepts a function that takes in the props from our instance of <MainButton>. The attrs function returns an object, and we've set those props equal to the object's keys. In other words, to use colorVariant in an instance of MainButton, all we need to do is add colorVariant as a prop like this: <MainButton colorVariant="primary">.

It is good practice to also include a fallback or default option in case the developer does not add any colorVariant props to MainButton. Setting colorVariant equal to either props.colorVariant or 'primary' means that if colorVariant is not present, we will always use primary as our variant.

In this example we're only changing colors using a colorVariant prop, but the variant possibilities are endless! In the future, if we wanted to add, say, a sizeVariant that manipulates the height, width, and padding of the button based on variants of small, medium, and large, we could add that to our object as well.

export const MainButton = styled.button.attrs((props) => ({
  colorVariant: props.colorVariant || 'primary',
}))`
  background-color: darkcyan;
  color: white;

  border-radius: 8px;
  border-color: transparent;
  width: 250px;
  padding: 14px;
  font: 20px Georgia;
  &&:hover {
    background-color: rgb(0,139,139,0.5);
    }
`

So far, we've told MainButton to look out for the colorVariant prop, but we haven't yet provided it our colors. Let's start with background-color. Below, we set it equal to a function that accepts the props from attrs. We return the property in ButtonBackgroundColors that has the color variant we used (in this case, primary) as a key.

export const PrimaryButton = styled.button.attrs((props) => ({
  colorVariant: props.colorVariant,
}))`
  background-color: ${(props) => ButtonBackgroundColors[props.colorVariant]};
  color: white;

  border-radius: 8px;
  border-color: transparent;
  width: 250px;
  padding: 14px;
  font: 20px Georgia;
  &&:hover {
    background-color: rgb(0,139,139,0.5);
    }
`

Alternatively, we can make our color function a bit cleaner using object destructuring. Below, we destructure props in our declaration function for background-color. (Note, the code in background-color below does exactly the same thing as the background-color above. Destructuring as we've done below is a matter of personal preference).

We also use our ButtonBorderColors and ButtonHoverColors objects to give dynamic styling to border-color and hover background-color. props has been destructured in their declaration as well.

export const PrimaryButton = styled.button.attrs((props) => ({
  colorVariant: props.colorVariant,
}))`
  background-color: ${({colorVariant}) => ButtonBackgroundColors[colorVariant]};
  color: ${({colorVariant}) => ButtonTextColors[colorVariant]};

  border-radius: 8px;
  border-color: transparent;
  width: 250px;
  padding: 14px;
  font: 20px Georgia;
  &&:hover {
    background-color: ${({colorVariant}) => ButtonHoverColors[colorVariant]};
    }
`

Now we're ready to use our dynamic styles! We can provide props to our button like this:

<MainButton colorVariant="destructive">Press Me</MainButton>

or we have the option of using a function that passes in the correct color based on props or events:

<MainButton colorVariant={getColorVariantFunction}>Press Me</MainButton>

Conclusion

Dynamic styling gives us clean, DRY code that can be easily reused. Our codebase is more trustworthy and easier to maintain; any future changes only need to be made in one place. Best of all, we have a way to change styles without the messiness of adding class names, eliminating the chances of making silly errors that cause bugs in production.

I'm building a TypeScript course - TypeScript for JavaScript Developers! Sign up for updates here

...or find me on Twitter

How Potty Training Shaped My Tech Teaching Style

Shaundai Person — Sat, 05 Jun 2021 17:56:07 +0000

This post was inspired by my interview on Hanselminutes podcast

For the first few days, my son and I were both pretty frustrated with the idea of potty training. After Lysoling and mopping the floor for the billionth time, I remember trying to explain to him once again that he needed to stay seated until he “went.” He wanted to go play. He stood up again. I could tell from the tired look in his round eyes he just wanted things to go back to the way they were before. I did too.

“Forget it,” I sighed. I exhaustedly put down the empty paper towel roll in my hand, turned up the sound on the TV, and quietly walked into my closet and shut the door behind me - jaw clenched the whole way. Confident that my baby wouldn’t hear me, I screamed at the top of my lungs until I ran out of breath.

I used a potty training method from a book that promised to have him trained in 3 days. It came highly recommended from parents I trusted. They swore the method worked like magic. Instead, I was emotionally drained and ready to quit on day 2.

Feeling defeated, I called my mom for advice. “I’m following these instructions exactly and there’s absolutely no way he’ll be potty trained by tomorrow. Maybe it’s just too early to be trying this. We’ll try again in 6 months.”

I could almost hear her shaking her head through the phone. “No. He’s ready now,” she said. “Remember, all of this is completely new for him. Think about what you’re doing. You’re giving him a tool he’s never seen before, language he’s never heard before, and expecting him to just put it together to ‘instinctively’ do something he’s never done before. You need to rethink the way you’re trying to teach him.”

As usual, my mother was right. With small changes to my teaching style, my kiddo was potty trained in a day.

When it came to teaching programming, I wanted to avoid the mistakes I’d made when I first started to potty train my toddler. Often, I hear stories from students whose learning starts out the same way. They’re given:

tools they’ve never seen before (ex. VS Code, new libraries)
language they’ve never used before (new technical terminology),
...and an unfair expectation to ‘instinctively’ put these together to do something they’ve never done before.

In the end, both the teacher and student end up frustrated or just giving up because the concepts just aren’t clicking for the student. Though the teacher means well, there’s a huge piece missing here - the part where the teacher closes the gap in understanding by providing context.

Giving Context

Initially as a potty training teacher (potty trainer?? Potty coach?? Potty sherpa.), I let the curse of knowledge] get in the way of my ability to be effective. I’d forgotten what it was like to be an absolute beginner at this. After empathy, context is the most important resource I could provide to my little student.

Context is the language before and after a statement that helps you to understand its meaning.

When it comes to teaching, providing context involves relating the new concept to something they’re familiar with. Making the connection between difficult and already-familiar topics helps the student to

Understand concepts quickly and thoroughly
Retain information for longer periods of time
Apply learning effectively and accurately (because they have a deep understand)

For me, this translates to using a lot of analogies and storytelling. Here’s an example of using analogies to explain React state and setState

Analogies don’t have to be an elaborate 1-to-1 metaphor. Stories can be silly. In fact, I’d argue that if silliness is what captures your students’ attention and makes a difficult topic more approachable, silly content is that much better. Just because it’s technical doesn’t mean it needs to be complicated!

When building educational content for a large demographic, providing context also involves setting upfront expectations with people who consume your content to make sure that you are meeting them at their current level of understanding (well, getting them to meet you at the right starting point).

Here are some examples of how to set expectations:

“This course requires a fundamental knowledge of JavaScript”
“This is a course about CSS for JavaScript developers”
“This post assumes the reader has a working knowledge of AWS”
“If you don’t yet know what recursion is, here’s a link to a blog post that explains more. Read this first!”

Saving the Jargon

Potty training also helped me to realize that simply “spewing a bunch of technical jargon” is not the same thing as teaching. Words are, after all, just symbols we use to represent thoughts and actions. Without the actual concepts behind the words, words are meaningless.

With my 2-year-old, a mistake I made was trying to use too much vocabulary (ex: “you need to tell me when you need to use the potty”) when he hadn’t gotten the actual concept (connecting a feeling to an action) down yet. Once I instead focused on limiting my use of vocabulary and SHOWING him what I wanted him to do, I saw a night-and-day difference in his understanding.

This doesn’t mean technical terms aren’t important. It does mean that the technical jargon shouldn’t be the only thing we’re teaching. I’d argue that in most cases, technical terms shouldn’t even be the first thing we teach. If we effectively teach the how, the what can come so much more easily afterward.

But Shaundai - how can I teach technical concepts without starting with the technical terminology?

Here's an example explaining how heat is transferred from one object to another:

Jargon Last

Let’s say you’re cooking food on the stove in a big pot. A metal spoon is sitting inside the pot. When you touch the spoon, you realize that it’s hot. The pot is warmed by the fire on the stove, but how did the spoon get hot? This happens through convection, where the solid spoon is warmed by the hotter solid pot it is touching. This is 1 of 3 methods of heat transfer between objects.

The two technical terms I wanted you to learn were “convection” and “heat transfer”. Both came later in the paragraph, after I’d described a scenario you were familiar with. What if I instead gave you the definitions upfront?

Jargon First

Convection is the movement caused within a fluid by the tendency of hotter and therefore less dense material to rise, and colder, denser material to sink under the influence of gravity, which consequently results in heat transfer.

Most people would check out after reading the first few words. Instead of putting such a strong emphasis on teaching the technical terms, put an emphasis on teaching the concepts and what the code is doing. The jargon can always be injected at the end.

I'm currently build a course - TypeScript for JavaScript Developers! Sign up for updates here

...or find me on Twitter

State and setState Explained with Emotion

Shaundai Person — Mon, 03 May 2021 18:24:31 +0000

This article is part of a React Family series inspired by my conversation with Jason Lengstorf on this episode of Learn with Jason.

Cover photo by Tengyart on Unsplash

In this example, we have three React components. One, <Mom /> is, of course, the parent component. The others are children of <Mom />:

<Toddler /> and
<Teen />.

1 const Mom = () => {
2 
3   return (
4     <div>
5       <Toddler />
6       <Teen />
7     </div>
8   )
9 }

These components don't do or show anything just yet, but using this small React family, we'll see how state can be set and passed between ~~family members~~ components.

State at a High Level

State, like props, is an object containing information used to determine what's rendered by your React app. This could be anything, from colors to a tally to whether a modal should currently be displayed on the page or hidden from view. React state, in this example, is going to be the emotional state of our components.

Unlike props, state is managed within the component it lives on. By contrast, props is set and managed outside of the component, then passed into the component using it.

State should always live on the highest-order component that’s involved in its use. There are two reasons for this:

State-setting functions can only be used to set state for either (1) the component that holds the function or for (2) one of its parents. A parent, or higher-order component, cannot have a set state that lives on a child component.
State can be passed from parent to child (via props), information about state can be passed from child to parent (via state-setting functions), but information can only be passed from sibling-to-sibling by going through the parent (via a combination of state-setting functions and props).

We’ll explore these in further detail, but for now just understand that in our case state will need to live on <Mom /> because she is the highest-order component involved in using our state.

When a React component is rendered, it uses state's initial value. This value could be any Javascript data type or structural type including null, undefined, 0, or just a blank value (like an empty string). In our example, our parent component <Mom /> has an initial state of string ‘happy’. We set the initial state to happy using the useState hook and render it in the DOM using JSX on line 9 below.

1 const Mom = () => {
2 
3 const [emotion, setEmotion] = useState('happy')
4 
5   return (
6     <div>
7       <Toddler />
8       <Teen />
9        {emotion} //happy
10    </div>
11   )
12 }

Setting State

Components setting their own state

Just like your emotional state, React state can be changed and maintained by a trigger (a function). In class components, these functions would be called setState functions. We’ll be using React Hooks, so our function can be called whatever we want to call it. Common convention is to call it set + WhateverTheFunctionDoes. Anytime state is changed, the component is re-rendered.

<Mom /> can hold these functions to update her own state, as below. handleMeditation() changes <Mom />’s state to ‘calm’. When a user clicks the button we've added to lines 13-15, setEmotion is triggered and our state of emotion is changed to calm.

1 const Mom = () => {
2 
3 const [emotion, setEmotion] = useState('happy')
4 
5 const handleMeditation = () => {
6   setEmotion('calm')
7 }
8 
9  return (
10    <div>
11      <Toddler />
12      <Teen />
13       <button onClick={handleMeditation}>
14         {emotion}  //changes to 'calm' once button is clicked
15       </button>
16    </div>
17   )
18 }

Passing information from parent to child

From here, <Mom /> can pass her emotional state on to her children 😃 as props. <Toddler /> and <Teen /> will both get passed the initial props of happy. Any time <Mom />’s state changes, the emotional state of the children will be updated to match <Mom />’s.

1 const Mom = () => {
2 
3 const [emotion, setEmotion] = useState('happy')
4 
5 const handleMeditation = () => {
6   setEmotion('calm')
7 }
8 
9  return (
10    <div>
//initial props value of 'happy' changes to 'calm' in Toddler and Teen once button is clicked
11      <Toddler emotion={emotion} />
12      <Teen emotion={emotion} />
13       <button onClick={handleMeditation}>
14         {emotion}  //changes to 'calm' once button is clicked
15       </button>
16    </div>
17   )
18 }

Passing information from child to parent

State-setting functions can also be passed down to children as props. If a child has access to any trigger - or function - that is paired with <Mom />’s state, the child thus has the ability to manipulate <Mom />’s - or the parent component’s - state.

Let’s say that <Mom /> has a different handler function called handleTemperTantrum(). <Mom /> passes this function to child <Toddler /> as a prop:

1 const Mom = () => {
2 
3 const [emotion, setEmotion] = useState('happy')
4 
5 const handleTemperTantrum = () => {
6   setEmotion('annoyed')
7 }
8 
9  return (
10    <div>
11      <Toddler handleTemperTantrum={handleTemperTantrum} />
12      <Teen />
13    </div>
14   )
15 }

Now, <Toddler /> has the ability to ~~manipulate~~ update and manage <Mom />’s state on its own! <Toddler /> uses this function to change <Mom />’s state to 'annoyed' any time the button on lines 4-6 is clicked.

Toddler Component:

1 const Toddler = ({handleTemperTantrum}) => {
2 
3  return (
4    <button onClick={handleTemperTantrum}>
5      
6    </button>
7   )
8 }

This button does not actually display anything except an empty button, though. Since the actual state of emotion still lives on <Mom />, we'll need to pass emotion down to her child. In fact, since parents can pass state down to any children as props, we can pass annoyed to both <Toddler /> and <Teen /> as props for them to use.

Mom Component:

1 const Mom = () => {
2 
3 const [emotion, setEmotion] = useState('happy')
4 
5 const handleTemperTantrum = () => {
6   setEmotion('annoyed')
7 }
8 
9  return (
10    <div>
11      <Toddler handleTemperTantrum={handleTemperTantrum} emotion={emotion} />
12      <Teen emotion={emotion} />
13    </div>
14   )
15 }

Toddler Component:

1 const Toddler = ({handleTemperTantrum, emotion}) => {
2 
3  return (
4    <button onClick={handleTemperTantrum}>
5      {emotion} //now this will say 'calm', or will change to 'annoyed' once this button is clicked
6    </button>
7   )
8 }

Any time <Mom />’s state is updated, <Toddler />s and <Teen />s emotional states are updated accordingly.

State-setting functions can either live on the component that the state lives on, or on one of its children.

Passing information from sibling to sibling

Siblings can pass state between one another, but they have to do it through their common parent. Just as we did in the last example, <Toddler /> can pass state to <Teen /> using this workflow:

<Toddler /> has the setTemperTantrum() function, which manages and updates the state that lives on <Mom />
<Toddler /> sets <Mom />’s state to annoyed
<Mom /> passes annoyed as a prop to <Teen />
<Teen /> accepts emotion as a prop.

Find me on Twitter or LinkedIn.

Using LocalHost for Mobile Development

Shaundai Person — Sat, 09 Jan 2021 22:01:01 +0000

This short tutorial is for Mac users

You may have known Chrome DevTools enables you to test the look and feel of your web application on differently-sized devices, but did you know that you can also use run localhost on any device that can connect to the internet? As you run localhost:3000 (or whichever port) on your local machine, your phone and tablets can run your program in real time for developing and testing on mobile.

Why is this important?

The Chrome DevTools Device Toolbar is a great tool that saves a lot of time, but it’s not perfect. After deploying my personal website for example, I was surprised to find that the version of my site I saw in my iPhone’s browser looked quite different from the local DevTools version I’d spent hours with, tweaking media query after media query. When I later pulled up my site on my monitor’s wide screen, I discovered that I’d never actually accounted for screens wider than the 13” laptop that I’d been programming on, either.

To avoid these types of glitches and UI/UX bugs before deploying for the whole world to see (ideal, right?), it’s essential to test your app on physical devices of different sizes. One cool thing about running localhost from your mobile device is that, just like with localhost on your computer, you can see realtime changes to your app as you code.

**The How-To (for Mac users):**

(1) Run your program on your Mac’s localhost
Make sure your program is running on localhost. When you go to the localhost port you’re running (ex. localhost:3000), the current version of your app in development should be visible.

Take note of the port you are using. Common port numbers are 3000, 3001, 8000, or 8080. You can find the port number in your URL bar after “localhost:” In this instance, my localhost port is port 3000.

(2) Find the IP address of your Mac
Here, we want to find the IP address of the Mac running localhost. To find the IP address, start by clicking the apple logo in the top left corner of your Mac to open the dropdown menu.

Choose System Preferences from the menu to open up your System Preferences.

Next, choose Network from the list of options in System Preferences. Your Network App should open up.

Your IP address will be in the middle box on the right, under Status. Underneath your network's status, find the sentence telling you the wi-fi network you're connected to and your IP address. In my case, the IP address is 123.45.6.08 . Take note of the IP address because we will need it for the final step.

(3) Connect your mobile device to the same wi-fi network as your Mac

If this isn’t already the case.

(4) Open localhost on your mobile device
In the URL bar in your phone, go to

http://{your-IP-address}:{your-port-number}

In my case, I’d put this into the URL bar:

http://123.45.6.08:3000

Now you should see your app locally on your mobile device. Now go build something great!

Connect with me on Twitter and on LinkedIn.

One Thing That Made My Job Application Stand Out

Shaundai Person — Thu, 31 Dec 2020 21:36:43 +0000

TL;DR: it’s video. Video is the one thing.

I moved into software engineering after 12 years in a non-technical career. I’m a self-taught developer; the most formal software training I’ve got under my belt is the 3/4 of the Codecademy Pro web development track I completed.

When it came to applying for engineering roles, my biggest concern was getting my resume to stand out. These days, companies have the advantage of a huge pool of qualified candidates to fill a small number of roles; I knew I’d be up against dozens of others competing for the same spot and many other applicants likely had better experience or more relevant education. Though I felt confident that my 1 ½ years of building projects earned me the skills to make a great Junior, the tricky part would be convincing hiring managers to also see what I saw in myself.

Using what I knew

The previous 12 years of my career were spent in sales, cold calling and emailing people who’d never heard of me or my company to ask them for tens of thousands of dollars. The trickiest part in prospecting was standing out from other sellers and from the rest of the noise in my prospects’ inboxes. Once I finally got the prospect’s attention, I needed to deliver a compelling message that was interesting enough to get them to take another call with me. Then another call, then another call, and so on, until I got the signed contract.

How is all of this relevant to applying for jobs, you ask? Well, applying for jobs is a form of prospecting! In both cases you’re trying to stand out from the competition, get the attention of someone who’s never met you, show enough value so that they are interested in having a conversation with you, and then once you’ve sold them on the conversation, get them - in a very short span of time - to trust you enough to bet on you.

Okay so here’s the point of this post - you don’t have to be a stellar salesperson to get the attention of recruiters. I’m going to tell you about the one game-changing prospecting tactic that I attribute to my success in switching careers.

Why video?

Using video in prospecting can increase reply rates by 25%. Video helps to:

Establish a human connection between you and the recipient
Cause the recipient to become familiar with and comfortable with you
Make you noticeable and memorable
Convey emotion and context that is difficult to derive from written text

…in other words, video gives you the ability to STAND OUT!

Types

Two types of videos work best when it comes to job applications:

Project Demos: short overview video of a project in your portfolio. You may or may not be on camera. In this video, you’ll walk through your completed project (not the code).
Introduction Videos: short video introducing yourself, talking about your professional accomplishments and personal interests, and explaining why you are a fit for the role (think cover letter, but in video form). You’ll be on camera for this one.

Tips for good video

Keep in mind that you don't need to spend a lot of time making these videos. If you find yourself working for hours on editing and adding special effects, you’re doing too much! In fact, videos that look too marketing-y (yeah, I said it) can actually leave a negative impression on the hiring manager. Remember, the goal is to show you – the authentic, real, human you. Once you’ve completed your portfolio project, designate a half hour max to making the demo video. This includes writing up bullet points about what you want to talk about, practicing, and recording.

Length

Learned this from my marketing friends – it’s important to keep the length down. Demo videos should be no more than 2 minutes but the shorter, the better. If you’re like me, you may find yourself thinking “there’s no way this video will be longer than 40 seconds” only to realize you’ve recorded a 5 min 26 second intro! Keep it short and sweet to avoid losing the attention of your audience.

Location

When using the videos in an email, stick the video in the body of the email - not as an attachment or link. We want to put the fewest number of clicks between the recipient and the actual video in order to make it easy for him/her to access. Links and attachments are also too easy to overlook; including the video in the body of the email prevents the hiring manager from accidentally missing your video entirely. If you have to use a link, make sure to draw attention to it using bold, capitalized text that clearly draws attention to the fact that it’s a SHORT PRODUCT DEMO VIDEO.

“…but I’m filling out applications on the company website. Where should I put my videos?”

I get it - for most of the jobs you’ll be applying for you’ll be applying using a form on a website. There may not necessarily be somewhere to stick the videos (like in an email). Some ideas:

Oftentimes, there is an additional field for “attachments” where you can stick your CV and other relevant materials to your application. Attach your video to your application here.
If you’ve put together an online portfolio, embed the demo videos on your portfolio page.
For the top 5-10 companies you’re applying to, use LinkedIn or on the company website to find out who the hiring manager is and email them directly (video included, of course). Include a demo video in a message the day before the interview telling them how excited you are for the upcoming interview and that you wanted to send along a demo you made them of a project that showcases your skills in (insert skill relevant to role).
After the interview, include a demo video in a thank you email. Or, use a video as your thank you email. Send a recording of you thanking the interviewer for their time and re-iterating why you’re a perfect fit for the role.

Sound human

Given that we only have a couple of minutes to convey our message, it’s important to sound both interesting and human. Have fun with it! It’s okay to stumble on your words a bit (all part of being human). If you consider yourself a novice when it comes to public speaking, practice using a relaxing tempo and voice inflections that make you sound interested in the product you’re demonstrating.

Get in the user’s shoes

As a seller, this is the one that’s nearest and dearest to my heart (and probably the most important). Talk about the value of your portfolio project from the user’s perspective. You don’t need to answer every single one of these questions in the video, but here are some ideas of ways to get into the user’s shoes?

What problem is your project solving?
In what ways does this feature make something easier or better for the people using it?
What did you put in the app to make it a product that your users will want to use?
What considerations did you make for other people who might be working with you on this project if it were for a company?
Intro videos - why you for this role? What do you like about this company? What can you bring to the table?

Let’s say you’ve built a weather-forecasting app that you want to showcase through video. You used aria-labels, color contrast, and gentle transitions that make your app more accessible. In your video, make sure to call out how you put some serious thought into accessibility because you know how important it is for apps to be accessible to all.

Software (free):

There are lots of great free options, but my favorites are Vidyard and OBS. What I like about Vidyard is that you can see when someone has watched your video. OBS is better if you’re trying to do more cutting and editing (probably overkill for a demo video, but a great option for introduction videos).

5 Traits of Good Developers

Shaundai Person — Thu, 24 Dec 2020 02:47:38 +0000

I hate to admit it but certain stereotypes about developers kept me from even considering a career in programming for decades. I thought the same way that many people outside of tech still think - software engineering isn’t a field I’d ever be able to get into because developers must [insert stereotype of choice: have CS degrees from top universities, be terrible in social situations, know how to program FPGA chips at birth, etc].

I’m here to tell you that many of those entry-blocking stereotypes are invalid. In fact, common traits of the best developers are traits that you likely already have! Put plainly, you ~~can~~ will be an amazing developer, even without that advanced degree in trigonometry.

(1) You Love to Learn

Even at the most senior levels of engineering, you’ll never be expected to know everything. With so much information out there and with technologies changing and evolving every day, it’s impossible to know it all. No matter how long you’ve been in the software game there will always be more to learn: more programming languages to master, newer techniques to try, better ways to collaborate with others.

The best developers are the ones who embrace the change and who continually seek new opportunities to learn. These individuals adapt more quickly, develop and hone a broader range of skills, and are able to think more creatively. For these reasons, developers who love to learn also tend to enjoy their work more. And who doesn’t want to be happier at work?

(2) You Like Puzzles

A common misconception is that all software engineers are good at math. The truth is that most areas of software engineering don’t require math skills at all. What they do require is the ability to solve puzzles.

If you consider yourself the type of person who likes puzzles - whether you prefer jigsaw puzzles, logic problems, or you’re great at figuring out the ending of mystery movies midway through the film - you have a key trait common with the best developers. Coding - like puzzles - requires use of both sides of your brain (the left side for analytic thinking and the right for creativity) to answer questions like:

Why did this break?
How can I get this to work?
How can I make this happen using the skills/tools available to me now?
Why did this break? (yeah, I know this is on here twice but it happens a lot)

Writing code is a puzzle with so many unique correct (and also incorrect) solutions.

(3) You’re Good at Recognizing Patterns

If you like to solve puzzles, chances are that you’re also good at recognizing patterns. Our human brains solve puzzles by looking for patterns among the information available to us.

From the day you start learning to code, you’ll similarly use patterns to solve problems. As you become more skilled, you’ll be able to quickly recognize problems similar to those you’ve encountered before and reuse code or similar solutions (aka software patterns) that work.

(4) You’re A Problem Solver

Any developer will tell you that a great deal of time at work will be spent troubleshooting and debugging your code. If you’re working with others, you’ll also need to fix errors in code you might only be seeing for the first time. Your success depends on your resilience as well as your ability to break up big problems into smaller parts in order to find a solution.

Debugging can be really frustrating - especially when you’re new. Invest time in learning to use the developer console and debugging methods in the language(s) you are programming in.

(5) You're Good at Google

I mentioned this before but as a developer, you’ll never know everything. I’ll add that it’s impossible to retain all of that great knowledge you’ll be building at work. Chances are, you’ll find yourself Googling things like “what does git pull origin master mean” day after day.

Believe it or not, efficient Googling is an important skill for developers. No matter which programming language you use, Google (or whichever search engine you prefer) is going to be one of the most used tools in your tech stack throughout your entire career. Knowing what to put in the search will save you LOTS of time that would otherwise be spent reading through pages and pages of Stack Overflow questions to find the answer you're really looking for.

Connect with me on Twitter and on LinkedIn.

5 Things I Learned by Asking Developers One Question

Shaundai Person — Mon, 07 Dec 2020 02:49:12 +0000

Breaking into engineering is no easy task.

Over the past year, I’d gradually built the skills needed to transition from the only career I’ve ever known - sales - into UI engineering. Prior to beginning this self-taught journey, I had no technical background (uh, unless a basic working knowledge of Excel counts)!

As a full-time working mom, I needed to be strategic about how I spent my time. To make sure I was learning the right things and building the right stuff, I went to developers at all levels - from Junior to VP - and asked the same question: As someone coming from a non-technical role - how can I make myself stand out?

**(1) Yes, you should build a portfolio**

Especially consider putting together a portfolio if you’re coming in at an entry level or switching to engineering from an otherwise non-traditional role (like me). Don’t worry - you don’t need to spend months building a portfolio from scratch. Host one easily using Github Pages or a website-generation platform like Wix or Squarespace.

The most important part is being strategic about the types of projects you put in your portfolio. Remember that recruiters and hiring managers are looking through a lot of other portfolios like yours and when they get 200 applicants for one opening, they need to make tough decisions about how to narrow down the applicant pool. Make your portfolio stand out:

Make it obvious which languages/frameworks you've used so they can see how your skills match the role you’re looking for.
Narrow it down to 2-4 key projects that really show the breadth and depth of your skills and only include these in the portfolio. There is no way a recruiter is going to look through all 25-30 of the projects from every single candidate who crosses their path.
IMPORTANT: Go for "corporate-style" projects. Yes, the random gif generators and random cat generators are adorable. If you're applying to work at a corporation (or an agency that does work for corporations), the recruiter will want to see polished projects that aim to serve a business purpose. (Think fake client websites, clones of part of an existing platform like Twitter or Uber, or something that solves a problem in your everyday life).

(2) Build a network

You might be wondering why/if building a network is really important.

First, being an employee referral increases your chances of getting the job by 10x. That’s not all — building a network will help you to stay on top of new things going in the tech industry, meet potential mentors/mentees/advocates/hiring managers/etc, enhance the skills you'll need to level up your career, and keep you motivated during those tough times.

For the introverts out there, I get it. Networking can be pretty awkward and super stressful. But it's a necessary evil and with practice, it will just get easier.

(3) If you want to be a good frontend developer, you should learn at least a little about a backend framework

Or vice versa. While you’re at it, learn a little bit about design, too - especially if you want to freelance, work for a large company, or eventually move into management. Your work as a dev will require you to understand requirements from someone who essentially is speaking a different language than you, then pass off your work to someone who uses another language!

Coming from the software sales world, I see how often devs get stuck in their own bubble and oftentimes don't even know how to use the product they're building! They don't take the time to get a wholistic understanding of their product from the customer side, sales side, or even the design side. You can make yourself stand out by understanding at least a little about what is going on over the fence and how the work you do will make an impact, or what you could do to make your colleagues' jobs easier. Take a course in something new or talk with someone else who is in the role.

(4) Several lines readable of code > one line of code that only you understand

This goes along with the last piece of advice. Even if you don’t expect to be working on a team, remember that one day, you’ll need to read your own code again after not-having looked at it for several months. Do your future self/future colleagues a favor and name your functions something like formatPhoneNumber instead of fixFon.

(5)Talk about what you're working on (a LOT)

It’s YOUR JOB to make sure you’re putting your work in front of the people who need to see it. Talk about what you’re working on (often) and show off your progress. It’s a tough shift to make for people who - like me - were taught that tooting your own horn makes you braggy. Here are some ways to put yourself out there without coming off as obnoxious:

Solve a problem/complete a project, then write a blog post about how you did it. Share the blog post with an engineering manager and ask for feedback
Commit to writing social media posts 3x week about the progress on your current project
Invite engineers from your company or from meetups to talk 1:1 over coffee (or tea. or water.) Ask about their career journey and exciting projects they are working on. Tell them what you're working on and ask for their feedback on current projects or your portfolio.
Accept compliments by simply saying “thank you.” This may sound like a no-brainer but for women in particular, we often meet compliments with fairly negative comments or we use it as an opportunity to give someone else credit for our work ("Well, without so-and-so, this would have never gotten done!" or "Oh, this was so stressful to do and I'm not really happy with the way it came out because..."). Just say thank you.

What advice would you give to developers trying to move into engineering from non-traditional roles?

Connect with me on Twitter and on LinkedIn.

How to Switch to the Engineering Team at your Current Company

Shaundai Person — Sat, 05 Dec 2020 23:07:44 +0000

I started a sales role at SalesLoft when I moved to Atlanta, 11 years into a successful career in sales. At the time, I had exactly 0 years of professional experience as a developer. (If you’re interested, check out this article about my decision to switch careers).

A little over a year into my SalesLoft journey, I accepted an offer as a Junior UI Engineer. The advice in this post is for anyone looking to make a similar switch. Whether you’re coming from a non-traditional role or you're already pretty technical, here are some tips to moving into engineering without leaving your current company.

Side note: In this post, I mention "hiring manager" quite a bit. I understand that in most cases, there is no open Junior position just yet. The "hiring manager" is the person who - when your ideal position opens up and you get the job - will be your new manager.

Find a Mentor

Find an Internal Advocate

Go for Coffee

Toot Your Own Horn

Do a Good Job

Find a Mentor

A mentor:

Does not necessarily have to work at your company (but in this case, it’s better if he/she does)
Is 1-3 levels above where you are in your career
Works with you formally or informally on your career objectives
Can work with you to discuss challenges in your code and help you get unstuck when you hit a problem
Follows your lead. You drive the relationship - deciding what to meet about, bringing forward questions that you have, facilitating times to meet, etc.

Remember that you can have more than one mentor. In fact, I’ll just go ahead and say that you should try and find more than one mentor. Different mentors can help with different areas of your life. For example, you may have a mentor for parenting, a mentor for becoming a better JavaScript developer, and an internal mentor at your company who helps you navigate your career as an engineer.

Your relationship with your programming mentor doesn't have to be incredibly formal; you can choose to only meet when you have questions. The important part of mentorship is to have a go-to person for your questions. Your mentor doesn't need to have all the answers, but he/she can help you figure out where to go to find them. They can help you determine which learning areas to focus on and which aren't worth your time. In my case, sticking to a regular weekly meeting with my mentor also forced me to stay accountable for keeping up with my coding even when life got busy. I didn't want to show up to our meeting "empty-handed" so I made sure to work on my projects or take part of a course during the week so that I had good questions to talk through when we met.

Quick Tips:

Finding a mentor can be tough. It requires a huge investment of time from both sides. Don't get discouraged if someone you want to be your mentor can't take it on because of other priorities.
A good way to find a mentor is to invite people for coffee (see below) as a way to kind of "date" potential mentors and let a mentoring relationship naturally blossom when you find a good fit.

Find an Internal Advocate

This person is likely a different person from your mentor, but it could be the same person. An internal advocate will go to bat for you when you're not around. They will get in front of the right people (and make sure that YOU'RE put in front of the right people) with the message that you rock and you would make a strong fit on your company's engineering team. In addition, advocates will push you to advocate for yourself. Here are some qualities of a good advocate:

Works for your company at a senior leadership or higher
Provides you with helpful information about how to stand out at your organization
Is trusted and respected by the people who make the hiring decisions on your engineering team
If put in front of one of the people who make the hiring decision on your engineering team, is willing to speak on behalf of you
Speaks highly of you (and often) when you're not around
Pushes you to "toot your own horn," even when you feel shy/humble/nervous about it

Quick tips:

Give him/her talking points! Make a point to regularly reach out to show them projects you're working on and ask for their feedback. Ask: "If I were building this for (your_company_name_here or your_customer_name_here), what would I add?" "If I were working on this project with others, what kinds of things should I incorporate?" "Is this something you'd find useful? What would you change?"

Go for coffee

Invite someone from your engineering team out for coffee once a week. I mean, it doesn't have to be coffee. Could be tea. Could be for a walk and talk over the phone.

You've probably heard this before (and it's true!) - it's not always what you know, it's WHO you know. When it comes down to you vs another internal candidate, if more people on your engineering team already know you and start to see you as a natural fit for the team, they are going to advocate for YOU to be the next engineering hire. When it comes time for the technical interview, you'll probably be interviewing with someone you've already won over with your coffee and conversation months before.

Quick tips:

Spread the love to different people. Make it a goal to meet with 2 new people each month.
Plan a few questions beforehand so that you have something to talk about. People love talking about themselves, so here are a few good conversation-starters:
- Tell me about your journey into tech/engineering.
- Here's what I'm doing: _____. What else can I do to stand out to the hiring managers?
- What was your interview like here?
- Did you always see yourself as an engineer?
- Do you work on side projects in your spare time? If so, what are you working on these days?
- I think I'm going to learn (insert language, technology, platform, etc) next so that I can stand out among the other candidates for the next Junior role here...do you think that's worth my time?

Toot your own horn

Self-advocacy makes a lot of us feel uncomfortable. It can feel like bragging or showing off. But if you're not letting people know about what you're working on, no one will know. When it comes time to apply for the Junior opening at your company, you are going to need more than just your resume to stand out against others who have more technical experience. A great way to do this is to open up, get vulnerable, and let others into your journey by showcasing your work!

Quick Tips (without feeling too "braggy"):

Set up quarterly meetings with the (future) hiring manager to talk through progress. I used a spreadsheet in one of my conversations to highlight the projects that I'd done and how they mapped to the skills on our company's Junior job listing. Ask the hiring manager for feedback on your learning plan.
In one of your coffee conversations, ask how engineers at your company show what they're working on to others. Is it through a private Slack channel (could you get an invite to join?)? Is it through submissions to a Google Form or company newsletter (can you get the link so you can add your projects)? Maybe its through 1:1 meetings with their manager (in this case, it's definitely important to get those regularly-scheduled meetings with one of the managers of the role you'd like to eventually apply for.

Do a Good Job!

Even if you work for a big company where you're pretty confident that your current manager doesn't have any contact with the hiring manager of the team you'd like to move to, rest assured - your future manager will find out about your work ethic, ability to contribute to a team, and overall fit from members of your current team.

Make sure you're doing a great job in your role today!

Connect with me on Twitter and on LinkedIn.

How to: Deploy Create-React-App on Surge

Shaundai Person — Sat, 05 Dec 2020 14:43:38 +0000

Have a React app you're ready for the world to see? Check out these 5 easy steps to deploy that bad boy!

1. Install Surge

First things first - let's make sure you have surge installed.

Install Surge globally ("globally" means that all of your projects will have access to Surge, not just this one) by typing this into your terminal:

npm install --global surge

2. Create a build folder for your repo

In the terminal, get to the root directory of your completed React app ("root directory" is the highest-level folder for your app). If you used create-react-app to get your app running in the first place, type npm run build in the command line and press enter.

npm run build

Npm will create a build folder, which is basically a deployable version of all of the React files you've worked so hard on, minus the junk and the secret information you wanted to keep hidden.

Now navigate to your build folder by typing the following into the command line.

cd build

3. Deploy to Surge

We're going to deploy to surge at this point, which is as easy as typing one word in the command window to activate the program: surge. Type surge into the command line and press enter.

surge

4. Create a Surge Account (or log into your existing account)

Surge will prompt you to either create an account or log in. If this is your first time using Surge, use your email address and create a password to create a Surge account through the command line. If you've used surge before, your most recently used credentials will appear and you can press enter to keep it moving or create a new account/enter a different login from there.

5. Get your Domain

Surge will make up a domain name for you. You can keep the domain they give you, change the surge sub-domain to your own available name (for example: 'my-customname.surge.sh'), or use a custom domain by following the instructions here

Press enter.

You're done! Enter the link in your browser to see your app live in action.

Connect with me on Twitter and on LinkedIn.

Creating a Gatsby Blog Hosted on Netlify

Shaundai Person — Sat, 05 Dec 2020 14:29:37 +0000

Netlify makes it SO EASY for developers at any skill level to build and manage a static websites. If you're thinking of hosting a blog with Netlify as well, let me assure you that the Gatsby + Netlify CMS is the way to get this blog up and running in 10 minutes. Add blog articles is a breeze; Netlify provides an admin dashboard that allows you to add future posts without having to spending time duplicating code over and over.

Let's start by adding a Gatsby blog to your existing Netlify site with a custom domain. Here’s what you’ll need:

Netlify site with custom domain (I purchased my domain from Netlify)
Gatsby CLI Installed
A GitHub account

Let’s start out with a simple Gatsby blog. Gatsby provides a simple, yet elegant, starter blog for you to work with.

Creating your Gatsby blog:

In your terminal, type the following command to create a new Gatsby blog site using gatsby-personal-starter-blog. [your-project-title]should be the name of your blog (so...whatever you want it to be). The github.com link needs to be exactly as typed below.

gatsby new [your-project-title] https://github.com/thomaswangio/gatsby-personal-starter-blog

Give Gatsby a moment to install all of the required packages and dependencies (about 3-4 minutes).

Once it's finished installing, cd into your project and run your project locally to see the updates in real time before sending to production. To do this, type into your terminal:

cd [your-project-title]
gatsby develop

You officially have a Gatsby site! How easy was that?! To see the local site, go to http://localhost:8000

Now, let’s make a few customizations before deploying to GitHub.

Customizing your blog site:

This part will be essential for managing your Gatsby site using the admin dashboard. Open this project in your favorite code editor and open static/admin/config.yml. On line two, change the name from name: test-repo to name: github. Press enter to add another line for line 3 and type repo: [username]/[repo-name]

[username] should be your GitHub username. [repo-name] should be the name of the GitHub repo where this project lives. Here's how that section should now look:

backend:
  name: github
  repo: [username]/[repo-name]

Now you can check out your gorgeous new admin dashboard: http://localhost:8000/admin.

Continue to make the blog your own by opening gatsby-config.js in your code editor. You'll find the default siteMetaData there; edit it to make it yours.

Also, scroll down to the bottom to change the favicon (called icon) to something other than the Gatsby logo, and to make more customizations to the background color and name of your blog.

Connecting your blog to GitHub repo:

In GitHub, create a new repo (make sure to give it the same name as your project). You’ll push your code to GitHub by typing the below into your terminal:

> git init
> git add .
> git commit -m “initial commit”
> git remote add origin https://github.com/[username]/[repo-name]
> git push -u origin master

You're done! Give yourself a pat on the back.

Connect with me on Twitter and on LinkedIn.

DEV Community: Shaundai Person

How to switch to using new version of node using nvm

How to install a new version of node using nvm

Making Styles Repeatable: Dynamic Styling in React using Styled Components

Starting with a Basic Button

Extending Custom Styles

Making Styles Dynamic

Conclusion

How Potty Training Shaped My Tech Teaching Style

Giving Context

Saving the Jargon

State and setState Explained with Emotion

State at a High Level

Setting State

Components setting their own state

Passing information from parent to child

Passing information from child to parent

Passing information from sibling to sibling

Using LocalHost for Mobile Development

This short tutorial is for Mac users

Why is this important?

The How-To (for Mac users):

One Thing That Made My Job Application Stand Out

TL;DR: it’s video. Video is the one thing.

Using what I knew

Why video?

Types

Tips for good video

Length

Location

Sound human

Get in the user’s shoes

Software (free):

Other video quick tips

5 Traits of Good Developers

(1) You Love to Learn

(2) You Like Puzzles

(3) You’re Good at Recognizing Patterns

(4) You’re A Problem Solver

(5) You're Good at Google

5 Things I Learned by Asking Developers One Question

(1) Yes, you should build a portfolio

(2) Build a network

(3) If you want to be a good frontend developer, you should learn at least a little about a backend framework

(4) Several lines readable of code > one line of code that only you understand

(5)Talk about what you're working on (a LOT)

How to Switch to the Engineering Team at your Current Company

Find a Mentor

Find an Internal Advocate

Go for coffee

Toot your own horn

Do a Good Job!

How to: Deploy Create-React-App on Surge

Have a React app you're ready for the world to see? Check out these 5 easy steps to deploy that bad boy!

1. Install Surge

2. Create a build folder for your repo

3. Deploy to Surge

4. Create a Surge Account (or log into your existing account)

5. Get your Domain

Creating a Gatsby Blog Hosted on Netlify

Creating your Gatsby blog:

Customizing your blog site:

Connecting your blog to GitHub repo:

**The How-To (for Mac users):**

**(1) Yes, you should build a portfolio**