DEV Community: Jonathan Silvestri

Using Currying and Reducers in your Components

Jonathan Silvestri — Wed, 11 Mar 2020 18:00:27 +0000

Context

I came across some old code from a take home challenge. Part of the challenge was to create a form that could submit a name and an email. Here's how some of the code looks:

  const Form = () => {
    const [name, setName] = useState('')
    const [email, setEmail] = useState('')

    const reset = () => {
      setName('')
      setEmail('')
    }

    const handleSubmit = (event) => {
      event.preventDefault()
      apiCall({ name, email }).then(reset)
    }

    return <div>
     <form onSubmit={handleSubmit}>
        <input
          type="text"
          name="name"
          onChange={event => setName(event.target.value)}
          value={name}
        />
         <input
          type="text"
          name="email"
          onChange={event => setEmail(event.target.value)}
          value={email}
        />
       <button type='submit'>Submit</button>
      </form>
      <button onClick={reset}>Reset Form</button>
     </div>
  }

Please excuse the lack of accessible inputs for this example.

Looking back at this code, it did exactly what I needed to do, but it wasn't easily extensible. If I had to track numerous fields with this form, where each input had its own state declaration, the component would get very large and become more and more bug prone.

Reducers to the rescue!

I'm a big fan of reducers (and useReducer) as they help to both organize the architecture for components and provide an API for when one state value relies on other state values.

In this example, the latter isn't the case as much, but the architecture piece is very important to this example. State reducers typically return your state and a dispatch helper that allows you to dispatch actions to update your state. Keeping all my state in one spot is incredibly beneficial as it greatly reduces the error rate and surface area of any future additions to state.

I suggest giving the React docs on useReducer a read if you haven't yet, as they will help understand my refactor of the above code:

  const INITIAL_STATE = {
    name: '',
    email: ''
  }

  const reducer = (state, action) => {
    switch(action.type) {
      case 'updateName':
       return { ...state, name: action.value }
      case 'updateEmail':
       return { ...state, email: action.email }
      case 'reset':
      default:
       return INITIAL_STATE
    }
  }

  const Form = () => {
    const [ state, dispatch ] = useReducer(reducer, INITIAL_STATE);
    const { name, email } = state

    const handleSubmit = (event) => {
      event.preventDefault()
      apiCall({ name, email }).then(() => dispatch({type: 'reset'}))
    }

    return <div>
     <form onSubmit={handleSubmit}>
        <input
          type="text"
          name="name"
          onChange={event => dispatch({ type: 'updateName', value:  event.target.value)}
          value={name}
        />
         <input
          type="text"
          name="email"
          onChange={event => dispatch({ type: 'updateEmail', value: event.target.value)}
          value={email}
        />
       <button type='submit'>Submit</button>
      </form>
      <button onClick={() => dispatch({ type: 'reset' })}>Reset Form</button>
     </div>

A little more code, but a much more standard API around how we update state. We've also introduced the ability to more easily consider loading states now, which we should be doing for any API calls that are involved. With a reducer that allows us to track and make updates to state based off of other state values, we have the architecture in place to make that sort of change. We'll leave that part alone, for now.

Introducing Currying to the mix

There's another piece that we can to this puzzle. We're going to leverage currying to further our code simplification.

Currying is the process where you take a function of 2+arity (arguments), and break it up into nested unary (single argument) functions. Each function will return a new function until the arguments are exhausted.

Simple math is the best way to illustrate what the above means. Let's implement a function that applies a modifier to some value, perhaps for price calculations.

  const priceMod = (price, markup) => price + (price * markup)

If I use this function in many places throughout my code, it'll get a bit repetitive, and it's likely I'll repeat myself a bunch:

  // In one file
  const tenPercentMarkup = priceMod(50, .1)
  // In another file
  const tenPercentMarkup = priceMod(50, .1)

Now, I could just make a file that has a tenPercentMarkup function exported, but that ends up being an abstraction that could be better represented with currying!

  const priceMod = markup => price => price + (price * markup)
  const tenPercentMarkup = priceMod(0.1)

Now that abstraction for the single 10% markup is inherent to priceMod thanks to the currying we've created!

  // Usage
  tenPercentMarkup(50)

Circling back to our Form

We can apply these concepts to the input fields we're updating in my Form:

const INITIAL_STATE = {
  name: "",
  email: ""
};

const reducer = (state, action) => {
  switch (action.type) {
    case "updateField":
      return { ...state, [action.field]: action.value };
    case "reset":
    default:
      return INITIAL_STATE;
  }
};

const Form = () => {
  const [state, dispatch] = React.useReducer(reducer, INITIAL_STATE);
  const { name, email } = state;

  const handleChange = field => event => {
    dispatch({
      type: "updateField",
      field,
      value: event.target.value
    });
  };

  return (
    <div className="App">
      <form>
        <input
          type="text"
          name="name"
          onChange={handleChange("name")}
          value={name}
        />
        <input
          type="text"
          name="email"
          onChange={handleChange("email")}
          value={email}
        />
        <button type="submit">Submit</button>
      </form>
      <button onClick={() => dispatch({ type: "reset" })}>Reset</button>
    </div>
  );
}

In order to keep my reducer lean, I'm leveraging computed property names to update the specific field value I'm editing. That way, updateField can handle any cases of inputs being changed.

The currying work happens in handleChange, where I am returning a function for each input field that mimics the setup of my original event handlers. With this function, I can create as many input fields as I need to without changing anything other than my INITIAL_STATE value!

Totally okay to not use the computed property names and have a case in the switch statement for each input field value as well, btw. I just like how updateField encapsulates the behavior I'm going for here.

Conclusion

I strongly suggest trying to look for this sort of pattern within your code. It'll probably help you to both uncover bugs and/or impossible states, as well as make your components more predictable and testable.

Affirmations

Jonathan Silvestri — Wed, 01 Jan 2020 20:16:55 +0000

Introduction

I'm going to get right into it and write a bunch in here. Read as much as you need to.

1. "I don't have support."

Your mind is full of brilliance and you deserve better.

2. "I don't know if I'll ever get that first job. It's been so long."

Be confident in your skills, for they are valid and valuable, and someone will appreciate you for all that you offer.

3. "I haven't had a new job in a long time and I feel stuck."

It's never wrong to want for more and seek out the opportunities that will give more to you.

4. "I don't know if I've been making the right choices."

Trust your intuition and inner guide.

5. "I'm surrounded by people who don't value and respect me."

Allow yourself to be who you are without any judgment.

6. "I feel tired and overworked."

Give yourself the care, rest, and attention that you are worth. There is no shame in resting.

7. "This path feels wrong or misguided."

In life, our experiences mold us into better people. Trust that you can find the right path.

8. "What if I fail?"

Failure teaches us and improves us. Embrace failure for the positives it will bring.

9. "I am spread too thin."

We put energy into the things that matter the most to us. It's okay to prioritize who and what gets your attention.

10. "I'm hurting and I don't know how to make it stop."

Everyone hurts and grieves. Everyone fights battles. You don't have to fight them alone. Reach out.

11. "I feel like everyone else is better than me."

You are good enough. No one else's success reduces your own.

12. "Can I do this?"

Yes, you can. Alone or with others, however you want or need to, you can do this.

13. "What if I run out of time?"

There is no rush. Take your time to do whatever it is you want to do, and don't let anyone push you around or make you feel like you need to do more than you have the head space to do.

14. "Am I good enough?"

You are always good enough.

The Importance of Kindness

Jonathan Silvestri — Wed, 04 Dec 2019 18:54:29 +0000

Today I would like to have a conversation about "the most important skill." In reality, what that is is purely subjective.

I'm going to get right to the point. The most important skill you can have in any job or profession is kindness.

What is Kindness?

Kindness is being considerate and engaged. It is being concerned and invested in the well being and growth of yourself and others. It has no elements of selfishness and is something I find to be a core feature of human nature. We all embrace our kindness in different ways and to varying levels, but that doesn't make any one person better than or worse than someone else.

Practice Kindness

Pay attention to when your colleagues are struggling or asking questions. Check in with the teammates you work closely with. These actions build a sense of trust and will help you form a more cohesive and collaborative team.

Commend your teammates when they achieve something, no matter the scale of their success. Kind words and affirmation are the building blocks of continued success. The next time your teammate finishes a feature, congratulate them!

Be there for the failures as well. We learn valuable lessons from failures, and they should be seen as learning opportunities, not weapons to tear others down. In any case, failure is tough to deal with, and having the willingness to talk through those failures inspires courage and helps us become more well-rounded individuals.

(This one takes courage and is not easy) Point out when someone has done something that hurt someone else in some way. Share your feedback on how that made you, and how it could have possibly made someone else feel. Explain how you think the situation could be rectified.

Finally, never forget to be kind to yourself. Don't take on that side project if you don't feel like you have the bandwidth to do so, unless you need to do it for financial reasons. Don't force yourself to work extra hours because you think you owe it someone, again, unless your finances dictate it is necessary. If you can, don't deny yourself breaks and vacations from your work. Be honest with yourself at every turn.

In Closing...

Be kind.

Hard to Read Code is Not Empathetic

Jonathan Silvestri — Wed, 09 Oct 2019 18:48:47 +0000

Prompt

You just finish creating a chain of composed functions with a higher order function wrapper that abstracts many layers of complex conditional logic behind a few function calls. It works, its decently performant, and it just got merged to master. The feature it supports works fairly well without a hitch.

A new edge case in one of the inputs is introduced that breaks your code. However, you aren't the one assessing the problem. A colleague notices it, and they are not nearly as familiar with or comfortable with heavy functional approaches. They struggle mightily to identify the problem, and come to you for help. You explain the entire process and how the composed functions work. You end up needing to implement the fix, which adds more complexity under the hood.

Your colleague points out that the logic could be dramatically simplified by a couple of if statements and one or two functions. Sure, it might not be as performant or might lead to having to account for a few more edge-cases, but it is easier to debug and read.

Empathy in Code

While my prompt is a bit specific (and in no way calling out functional programming -- I have no problem with the concepts in general -- I think it illustrates my point, that the harder code is to read, understand, and explain, the harder it is for other people to make changes to or contribute updates to your code. It's definitely a good idea to find ways to make you and your team better. But hard to read code is not the answer.

The more senior you are, the more vital it is to keep in mind some important questions when implementing code:

Can I explain this code to someone who is less experienced than me?
Can I explain this code to someone who is onboarding to my team?
Can I explain this code to myself after not having seen it for a long time?
If I add documentation for this code, is it spending more time describing the purpose of the feature set, or describing how the code works?

Less is more

We've heard this saying before. But I'm not talking about code in this case. I'm focusing on complexity.

We should strive to have code that is readable, maintainable, and resilient to change. Each one of these things is influenced by human factors - I'd argue that for all of them, the human factor is the most important one. If a feature set can be described and implemented with clear, straight-forward implementations that focus on fundamentals rather than more complex and advanced concepts, the former is the right decisions and approach.

Don't be put off by explicitness

Consider the classic example of adding an array of numbers together:

// Explicit

function sum(array) {
  let sum = 0;
  for(let index = 0; index < array.length; index++) {
    sum = sum + array[index];
  }

  return sum;
}

// Functional

function sum(array) {
  return array.reduce(function(total, number) {
    return total + number;
  }, 0)
}

I much prefer the first approach, which is very clear as to what the end result of the function should be, what variable is used to track the running sum, and how to iterate through the array to increment the sum. You could argue that some of the same approaches can be taken with the second approach, but that doesn't take away from needing to have the context of how reduce's callback function works (and then, what a callback is and how reduce uses it). It's a lot of added knowledge to perform a simple operation that people who have a lot of strength working with reduce take for granted.

Yes, the first example is easier to implement and thus, perhaps, a lot more basic. My argument for that is...so what?

Parting Thoughts

Code is the implementation detail of engineering. How you are able to expand, explain, and collaborate is where the skills lie. Easier to read code opens the door to more collaborative cultures and makes your team one other people will want to join. Embrace simplicity.

Asynchronous Flows...with React Hooks!

Jonathan Silvestri — Fri, 06 Sep 2019 18:45:30 +0000

I got the opportunity to implement some asynchronous data flows the other day at work, and I'd love to share my approach with y'all.

Thought Process

Whenever I work with loading and displaying asynchronous data, I prefer separating the data loading work and the data displaying work into two components. For me, this separation of concerns helps me to focus on what a clean, easy to follow logic tree.

Setting up our Loader

Here's what we want our loading component to handle:

When the component mounts, we should trigger our api call to get our data.
When this api call triggers, we should set some sort of loading state.
When the api call is finished, we should set our data as state and indicate our loading has completed.
We should pass this data down to some other component.

Based on that list, we need two pieces of state -- loading and data. We'll also need to figure out how to hook into our component's mounting. Let's start by setting up our state with the useState hook.

  import React, { useState } from 'React'
  import Breakfast from './Breakfast' // I utilize breakfast foods as my foo/bar/biz/baz

  const DataLoader = () => {
    const [ isLoading, setIsLoading ] = useState(false)
    const [ data, setData ] = useState([])

    return isLoading ? <div>Loading</div> : <Breakfast data={data} />
  }

Alright, state is set up! Now we need to make our API call. I'll split this into a new section to make things a little easier to follow.

useEffect

useEffect is how we handle for mounts and updates. This function lets us capture side effects in our function components for use. The tl;dr of the documentation can be found here:

  useEffect(callback, dependencyArray)

useEffect can be triggered in two ways: whenever a component mounts, and whenever the value of something in the dependencyArray changes. If you pass an empty array as the second argument, it will ensure useEffect only runs when your component mounts.

We'll be using an asynchronous function within useEffect. Of note - we cannot make our callback function asynchronous, because useEffect must either return a cleanup function or nothing. You'll see in a moment I use the async/await approach for Promise declaration. Implicitly, an async function returns a Promise, so without there being a point in time you could resolve what is now a promise-ified useEffect, it'll all blow up! But, using an async function within useEffect is totally fine.

-  import React, { useState } from 'React'
+  import React, { useState, useEffect } from 'React'
   import Breakfast from './Breakfast'

  const DataLoader = () => {
    const [ isLoading, setIsLoading ] = useState(false)
    const [ data, setData ] = useState([])

+   useEffect(() => {
+     async function fetchData() {
+       setIsLoading(true)
+       const fetcher = await window.fetch(/some/endpoint)
+       const response = await fetcher.json()
+       setData(response)
+       setIsLoading(false)     
+     }
+     fetchData()
    }, [])


    return isLoading ? <div>Loading</div> : <Breakfast data={data} />
  }

Here's how the above function works:

With an empty dependency array, this useEffect will only run on mount.
When the component mounts, run fetchData.
Trigger our loading state. Utilize the Fetch API (We made it happen!!!) to resolve a promise that gets us a response.
Resolve that promise using the .json function to parse the response.
Set our data state to this response, and set our loading state to false.

At each point of the state changes, we'll have a re-render with the appropriate UI.

That's it for our loader! The component receiving our data is pretty standard as far as React components go, so I won't worry about that part of the example.

Improvements

Error Handling

There's some more we can do with our useEffect setup. Let's talk about error handling first.

Async/Await lends itself well to try/catch/finally blocks, so let's give that a go. Let's extract the inner part of our useEffect and add try/catch/finally to it.

     async function fetchData() {
       setIsLoading(true)
+      try {
        const fetcher = await window.fetch(/some/endpoint)
        const response = await fetcher.json()
        setData(response)
+      } catch (error) {
+        // Do something with error
+      } finally {
+        setIsLoading(false)   
+      }  
     }
     fetchData()

The try portion will attempt to make our API call. If any error occurs, we will fall into our catch statement. After both of these complete, regardless of the result, we hit our finally block and clear out our loading state.

Cleanup

It's a good idea to handle for a case where the component unmounts so that we don't continue setting state. useEffect supports cleanup functions which run when a component unmounts. Let's add that functionality in.

    useEffect(() => {
+    let didCancel = false
     async function fetchData() {
+      !didCancel && setIsLoading(true)
       try {
        const fetcher = await window.fetch(/some/endpoint)
        const response = await fetcher.json()
+       !didCancel && setData(response)
       } catch (error) {
           // Do something with error
       } finally {
+       !didCancel && setIsLoading(false)   
       }  
     }
     fetchData()
+    return () => { didCancel = true }
    }, [])

The returned function we added will run when the component unmounts. This will set didCancel to true, and ensure that all state is only set if didCancel is false.

Final Words

There's a lot to unpack in this article. However, I wanted to get this out of my head an on to paper. I know other folks have written more in-depth pieces on this topic, but hopefully this encapsulates the challenging parts of leveraging useEffect with async. Please feel free to leave a comment below with any qs!

Knowing When To Ask For Help

Jonathan Silvestri — Thu, 18 Jul 2019 18:26:15 +0000

After some time...

You are sitting at your computer, stuck on a feature. You feel like you have spent a lot of time trying to find a solution to the problem before you. You looked around online for guidance. You are not sure what you could be doing differently.

It is time to ask for help.

But maybe...

You have been stuck on a feature you have been working on for a few days. You tried a few different approaches. None of them are working how you want them to. You are not sure what to search for on Google to proceed.

It is time to ask for help.

Or...

You were given a problem to solve that you have never encountered before. You are not sure where you can look for guidance on the internet to start your approach, and there are no clear examples in the code base you are working on that you can use as direction.

It is time to ask for help.

Have you considered...

You have a problem to solve. You want to talk out your thoughts with a colleague.

It is time to ask for help.

Alright, no more examples.

These examples do not fully capture all the situations when it is time for you to ask for help. There are more branching paths that could lead to points where it is appropriate for you to seek guidance.

Asking for help does not have to be something you consider as a last resort. At any point during your development process, there will be opportunities and times for you to ask for help.

When should I ask for help?

Whenever you want to.

[UPDATED] I got 404 problems...

Jonathan Silvestri — Wed, 10 Jul 2019 19:57:55 +0000

Can you help me find another one?

I got 404 problems...

Jonathan Silvestri — Tue, 09 Jul 2019 19:45:42 +0000

and being not found is one!

I asked my friend to make a promise

Jonathan Silvestri — Mon, 08 Jul 2019 19:21:06 +0000

But he rejected :/

Effectively Receiving Feedback

Jonathan Silvestri — Tue, 11 Jun 2019 17:08:10 +0000

I have seen posts about how to give feedback, constructive or otherwise, in professional settings. I believe that having this knowledge is extremely valuable, but is only half of the picture. Being able to receive feedback is a very important skill that you should be working on improving every day.

I have marked this post for beginners because I want to make sure newer developers see this, so they can understand if the people they work with are doing a good job of receiving their feedback or not. I think it is important that newer developers work in environments where mentorship is valued and prioritized, and effectively receiving feedback is a skill that every mentor needs to have.

For the remainder of this blog post, please consider the framing as if the situation features constructive feedback, vs. simple "Good job on X" feedback.

A Golden Rule

Before diving into the different pieces of what it looks like to effectively receive feedback, I want to establish what I consider to be a golden rule in any feedback scenario:

Be present and attentive. Giving feedback can sometimes be a very uncomfortable situation for the giver. Recognize that this feedback is their reality, and take the situation seriously, no matter what.

As you go through this post, you should be keeping this rule at top of mind. It will be your key to a successful feedback session.

The Steps

Listen and Clarify
Acknowledge and Own
Pause for reflection
Express gratitude
Define clear action items
Follow up

Listen and Clarify

Listen closely to everything that your feedback giver is telling you, and ask for clarification on any of the feedback if you need it. If you are writing anything down, be sure to only write down exactly what they tell you, because any paraphrasing or "in my own words" will either change or fail to properly capture the feedback you are being given. Even if you are only slightly confused about a piece of their feedback -- that is enough for you to ask for clarification.

Acknowledge and Own

Remember the golden rule? It comes through the most here.

My advice on this step is simple - do not deny. Instead of "I didn't say X or imply Y", say "I understand that you interpreted X this way, and I am sorry that I was not clear. My intention was X." (Updated text provided by Jacque Schrag). It is a more empathetic response and allows for progress towards a resolution.

Pause for reflection

Once it is clear that the feedback giver has given you all of their feedback, do not immediately dive into your response. Ask for a moment to process what they have just told you, and organize your thoughts. Being prepared is key to figuring out the action items and next steps you need to define.

Define clear action items

You have reached a point where feedback is delivered, acknowledged, and thought about. Now is the time to work with the giver to set clear action items so that you can avoid the situation occurring again (or, in the case of positive feedback, look for ways to continue having those situations occur!)

Follow Up

This should be among the action items that come out of a feedback session. Schedule time to follow up with the feedback giver to ensure that progress is being made on any action items that arose from the session. This shows your commitment and how serious you are taking the situation.

Conclusion

I hope this small guide will be useful to you the next time someone asks if they can give you some feedback. Following these steps should lead to a good outcome in this kind of situation, and also provide you with a valuable skill and experience along the way.

Encapsulate and Moderate with Closures

Jonathan Silvestri — Thu, 06 Jun 2019 18:19:26 +0000

Have you ever found yourself wanting to modify and update a data structure throughout the life of your application? Take the following code:

const obj = {}

const modifyObj = (key, value) => {
  obj[key] = value
  return obj
}
modifyObj('foo', 'bar') // Returns { foo: 'bar'}
modifyObj('biz', 'baz') // Returns { foo: 'bar', biz: 'baz' }

We have some object, obj, defined in our global scope, and a function, modifyObj that can accept a key/value pair that are assigned to the global object. We can see what happens when we invoke our function via the provided comments.

Given how our function is constructed and where our modified object is defined, is there anything that prevents us from directly interacting with the object outside of our function?

The answer is no:

delete obj.foo // Yup I can do this!
// Or...
obj['foo'] = 'biz' // Totally valid - this is what our modifying function does!

This is not ideal. We really would like for an object that we can modify, but we'd also like to do so without exposing the object to the global scope. We can achieve this with closure!

Closures leverage what is known as a higher order function - a function that returns a function - to encapsulate variables and other data within a private scope. The returned function can access and modify that data, known as creating closure around it.

What this means is, we can create our object within the context of a higher order function, and then modify it without exposing that to the global scope. Let's take a look at the code.

const higherOrderFunc = () => {
  const obj = {}
  return function modifyObj(...args) {
    const [key, value] = args
    obj[key] = value
    return obj
  }
}

const modifyObj = higherOrderFunc()
modifyObj('foo', 'bar') // Returns { foo: 'bar'}
modifyObj('biz', 'baz') // Returns { foo: 'bar', biz: 'baz' } !!!
console.log(obj) // ReferenceError: obj is not defined!

// And I have no method of messing with the object from the outside!

Let's also walk through our code and talk about what's happening.

const higherOrderFunc = () => {
  const obj = {}
  return function modifyObj(...args) {
    const [key, value] = args
    obj[key] = value
    return obj
  }
}

This is our closure. We create a higher order function that returns an inner function which retains knowledge of the outer obj variable. That way, we can invoke our function to modify the obj.

const modifyObj = higherOrderFunc()

Here, we invoke our higher order function to create our object and provide us with a setter function. Nothing has been done to the object quite yet.

modifyObj('foo', 'bar') // Returns { foo: 'bar'}
modifyObj('biz', 'baz') // Returns { foo: 'bar', biz: 'baz' }

We operate on our object with our closure, and can see that the object updates as expected!

console.log(obj) // ReferenceError: obj is not defined!

Finally, we try to log the object outside of our closure's scope. We'll get a reference error, which means we are trying to operate on a variable that does not exist in our current scope!

Hopefully you can find some use for closures in your current or upcoming work. Can you think of some uses for it right now? We'll be discussing one in my next post and how powerful closure is in that context.

BONUS: My function only allows for setters. But there's a way to extend the higher order function to also return a getter so we can check our object. Feel free to provide your solution in the comments below!

Compassionate Empathy: Help your fellow friend

Jonathan Silvestri — Wed, 29 May 2019 15:17:41 +0000

This is the final piece in my Empathy in Tech series, and we'll be talking about the form of empathy we should all be aiming for: Compassionate Empathy.

We've talked about Cognitive and Emotional empathy in previous posts, and I did what I could to illustrate how effective these things are in a workplace setting. My goal was to lay the groundwork for this post, because in reality, the form of empathy you want to embrace the most as a colleague and peer is Compassionate empathy.

If Cognitive empathy is the more logical one, and Emotional empathy is the more emotional one, consider Compassionate empathy as the bridge that combines these two and allows you to consider both what a person is thinking and how they are feeling in any given situation. It's through this connection that we are inspired to offer help to others, if appropriate.

What it looks like

Say a colleague comes to you with after a rough week. They feel like they didn't do a very good job with their work, and the work they did complete introduced some problems. They are concerned that their manager will be mean to them when they chat about it during their next one on one.

You take a moment to understand why they are thinking this way, and share their feelings of concern. Finally, you share that you feel what they are feeling and offer to help them plan out how they will approach the conversation with their manager.

By taking all of these steps, you reduce the mental and emotional overload your friend is experiencing by taking on some of it yourself. This helps clear headspace for developing an actionable plan, which in turn also leads to a reduction in stress/anxiety. Compassionate empathy in action!

Why it's important

Compassionate empathy helps to develop the balance, skill set, and knowledge that will foster a friendly and collaborative workplace setting. It helps to prevent us from leaning too hard in either the logical or the emotional direction, and helps us to make the connections in our brain that drives how we analyze and react to situations.

Situations like the example I presented above are not that uncommon -- you probably run into ones like that on at least a semi-regular basis. Don't avoid these situations if you see them coming! Instead, use them as opportunities to develop your empathetic mindset, so that you can handle situations of increasing seriousness and complexity as they arise.

In Closing

Thank you so much for sticking with me as I talked about empathy. I think it is the among the most important qualities that any person can have, particularly folks in tech. Lean in to that discomfort and achieve your whole self!