DEV Community: Laurie

Functions, fat arrows and parentheses

Laurie — Tue, 07 Sep 2021 15:25:03 +0000

If you develop with JavaScript you likely use functions fairly often. And, because you're a developer, you've likely made some mistakes.

For me, it was last week. I called a function without parentheses and it didn't exactly do what I wanted. But why? Why was that a mistake? In React there are lots of times we use functions without parentheses and everything works just fine!

Today we're going to talk about why.

How do parantheses impact functions

Let's start with a typical function.

const someString = () => {
  return 'some string'
}

If we wanted to call this function, we'd do so like this.

const result = someString()
// result is now "some string"

But what happens if we do this?

const result = someString

result is now equal to [Function: someString]. It's a reference to the function rather than the result of evaluating the function.

Well that was a quick post. Always use parentheses, problem solved.

Not so fast!

React and functions

Sometimes in React we want to execute a function. But other times, we want to pass around a reference.

const ExampleComponent = () => {
  const clickHandler = () => {
    console.log('I was clicked')
  }

  return <button onClick={clickHandler}>Click me</button>
}

onClick is an event handler which takes a function as a callback. So it needs a reference to the function it's going to call.

What happens if we add parantheses? Will it still work?

const ExampleComponent = () => {
  const clickHandler = () => {
    console.log('I was clicked')
  }

  return <button onClick={clickHandler()}>Click me</button>
}

Nope! Nothing will get logged. The event handler was expecting a function that it can call. However, it got the return value of the function.

Any other syntax weirdness we should talk about? Sure, why not!

Parameters

By default, event is passed as an argument to the callback function. Something like this.

const ExampleComponent = () => {
  const clickHandler = event => {
    event.preventDefault()
    console.log('I was clicked')
  }

  return <button onClick={clickHandler}>Click me</button>
}

This actually introduces an interesting detail! The code above is equivalent to the code below, passing our function wrapped in an anonymous function that exposes event.

const ExampleComponent = () => {
  const clickHandler = event => {
    event.preventDefault()
    console.log('I was clicked')
  }

  return <button onClick={event => clickHandler(event)}>Click me</button>
}

Anonymous functions

As it turns out, we can define our function inline.

const ExampleComponent = () => (
  <button onClick={() => console.log('I was clicked')}>Click me</button>
)

This also gives us the opportunity to pass our own parameters.

const ExampleComponent = () => {
  const clickHandler = message => {
    console.log(message)
  }

  return <button onClick={() => clickHandler('I was clicked')}>Click me</button>
}

But what if we want the event object in addition to our other parameter(s)?

const ExampleComponent = () => {
  const clickHandler = message => event => {
    event.preventDefault()
    console.log(message)
  }

  return <button onClick={clickHandler('I was clicked')}>Click me</button>
}

This makes sense if we think about what we already know. That event is always passed, whether we reference it or not.

I'm a little confused

If that last example confused you, that's ok! It looks a lot like our earlier example where we passed the result of a function rather than a reference to it.

The trick is to look at the definition of clickHandler a little bit closer. We'll make it a bit more verbose to make that easier.

const clickHandler = message => {
  return event => {
    event.preventDefault()
    console.log(message)
  }
}

The "result" of clickHandler is a function! It returns a reference to a function. So we're all good.

Functions are fun

I know that was a lot of syntax, but I hope you feel a bit more confident. Knowing what is happening under the hood can turn guess and check errors into intentional fixes. You'll still make mistakes, we all do, but maybe you'll catch them faster.

Interviews are about telling a story

Laurie — Tue, 24 Aug 2021 12:34:23 +0000

Last week I was in Danny Thompson's twitter space talking about tech interviews. One piece of advice I gave was about preparing for conversational interviews and the types of questions you get asked.

Apparently, people wanted to learn more! And as always, I'm happy to oblige.

Tech Interviews aren't only about code

You may be familiar with guides for studying and preparing to ace tech interviews. Oftentimes they focus on algorithms and data structures. You'll also find write-ups and websites on studying for systems design interviews and other abstract exercises. Prepping for these types of questions are great. However, they aren't the only type of interview rounds you're likely to encounter.

In most interview processes you'll have rounds that are very conversational in nature. They're typically a mix of technical and people skills questions. This post is about setting yourself up for success in these interviews.

What type of questions can you expect?

The interviewer in conversational rounds can be anyone from a manager to a colleague to a skip level director. However, their goal is often the same. How do you collaborate? How do you communicate? What level of experience do you have handling challenges that are both technical and people-focused?

Examples of the types of questions they might ask are:

Tell me about a time where you had to say no to a request?
Have you ever had to give feedback to a more senior engineer? Can you tell me about that?
What mistakes have you made in implementing a system? What would you do differently next time?

There are hundreds of these types of questions, but you get the idea.

What does a good answer look like?

Sometimes these answers explicitly ask for a story, e.g. "tell me about a time". Sometimes it's less overt and they say "how would you handle". In either case, having a real life example you can point to helps ground your answer and show the experience you have.

Stories should have a beginning, a middle and an end. They should show a positive outcome or an outcome where you can point to the mistakes that were made and what you'd do differently. They also need to be clear, concise and effective. Most importantly, the story needs to clearly connect to the question being asked.

This sounds like a lot to ask on the spot! You have to think about the question, come up with an anecdote, package it well, and relay it back to the interviewer. All in 5 or so minutes, maybe less. Yikes!

How?!

This is where my original advice comes into play. You don't need to think of every question you might be asked. But you should think of some stories ahead of time.

Have 3-5 stories in your back pocket going into an interview. They should highlight different aspects of your collaboration and communication style so that they can fit the questions being asked.

A story where you did everything right
A story where you did something wrong and learned from it
A story involving a peer
A story involving management
A story involving another team, company, or external player

This list isn't exhaustive, but it will help you start thinking about some good anecdotes. Once you've zeroed in on your stories you can start to practice talking about them.

When prepping a story consider an interview enviroment. You want to:

Get to the point quickly - remove any extraneous or overly detailed pieces of information
Be clear - beginning, middle and end, make sure that your point comes across
Connect to the question - this takes some practice, but try and mention the keywords of the question as you're concluding the story and drive home how it connects
Show off - this doesn't mean you should brag, but try and show yourself in a positive light, even when the story involves a misadventure

Thinking through all of this ahead of time will give you confidence going into these types of interviews. You won't be stuck trying to think of a good anecdote in live time.

Important caveats

There are a couple mistakes to avoid.

If they ask for a time you weren't successful, don't use a story where you were. Always have a story for when you messed up. Be able to analyze what you could have done differently, but don't avoid the point of the question.
You don't need to be an engineer to answer these questions well. If you are a career changer you can tell a story involving retail managers, your fellow line cook, the military. Whatever it is, this is a great opportunity to show how your current experience relates to the role and why you have more to offer than someone straight out of school.

Interviews are about you

For all the flaws with technical interviews, conversational interviews are different. You don't need to be the most outgoing person in the room or have studied a textbook worth of potential questions. A few focused areas of prep will help you show off your skills and experience.

Introducing `findLast` and `findLastIndex`

Laurie — Wed, 16 Jun 2021 15:02:15 +0000

I'm back with another introduction to JavaScript syntax! Currently in Stage 2, we're going to talk about findLast and findLastIndex.

Array.prototype.find

Let's start by talking about a sometimes used array function called find. It's a nice utility method that helps you find the first element in an array that meets the given criteria.

const arr = [
  { letter: 'a', integer: 1 },
  { letter: 'c', integer: 2 },
  { letter: 'c', integer: 3 },
  { letter: 'd', integer: 4 },
]
arr.find(el => el.letter === 'c') // { letter: 'c', integer: 2 },

There is a complimentary function called findIndex.

const arr = [
  { letter: 'a', integer: 1 },
  { letter: 'c', integer: 2 },
  { letter: 'c', integer: 3 },
  { letter: 'd', integer: 4 },
]
arr.findIndex(el => el.letter === 'c') // 1

You can imagine why someone might want to do this. If you're looking for an element that matches what you want, but you only need one, this is super useful and very performant.

But it's only first

While find is great, it always gets the first element that meets the criteria. What happens if you're continuously pushing elements onto your array and you want the "most recent" element that meets the criteria. This would be the element closest to the end.

You could do this in a few ways. The one that comes to mind for me is to reverse the array and then use find. But this isn't performant for large arrays, it requires more steps than it should, and it doesn't work well if there aren't any matching elements in the array.

Enter findLast. It's the mirror function to find, but it works from the end of the array.

const arr = [
  { letter: 'a', integer: 1 },
  { letter: 'c', integer: 2 },
  { letter: 'c', integer: 3 },
  { letter: 'd', integer: 4 },
]
arr.findLast(el => el.letter === 'c') // { key: 'c', integer: 3 }

There is also a matching findLastIndex.

const arr = [
  { letter: 'a', integer: 1 },
  { letter: 'c', integer: 2 },
  { letter: 'c', integer: 3 },
  { letter: 'd', integer: 4 },
]
arr.findLastIndex(el => el.letter === 'c') // 2

Note that if it can't find an element that matches the criteria, it will return -1.

What do you think?

In my mind we can never have too many array utility methods! Whether I need them or not. But how about you?

If you're interested in learning more, check out the proposal.

`at` coming soon to ECMAScript

Laurie — Mon, 14 Jun 2021 14:41:59 +0000

If you're a JavaScript developer you've likely used arrays quite a bit. They're an essential data structure within the language.

In fact, they're so essential that the array prototype has seen rapid expansion in the past few years, with things like flat and filter added. And we're not done yet.

Accessor

In order to access an element in an array, you need to know its index. Indeces in JavaScript are zero-based, so the first element is at index 0.

const arr = ["a","b","c","d"]
arr[0] // this is "a"
arr[2] // this is "c"

As you can see in the example above, you can access the first element, or the third element. What about the last element? In other languages you might be able to do something like this.

const arr = ["a","b","c","d"]
arr[-1] // This is NOT "d"

But not in JavaScript! Why not? Well, as it turns out, -1 is already a valid key. Arrays are really objects with indeces as keys. So arr[-1] is looking at the arr object and the value of the "-1" key, which is undefined.

The last element

Then how do we access the last element without knowing its index? There are ways to do it, but its certainly more verbose. You can use the length lookup.

arr[arr.length - 1] // this is "d"

Or you have the slice option.

arr.slice(-1)[0] // this is "d"

Introducing at

That's why the at function is under consideration. Instead of those options, you'd be able to write this instead.

arr.at(-1) // this is "d"

Note that this works for all valid negative indices, up until you pass the first element.

The great thing about at is that it can replace square brackets all together.

arr.at(0) // this is still "a"

And what about an invalid index?

arr.at(5) // this is undefined

Seems pretty all encompassing.

An aside on history

As it turns out, this was attempted before using item. However, it wasn't web compatible as it clashed with major libraries. So, at is the current proposal.

Would you use it?

Hopefully this will move forward to Stage 4 soon and be officially adopted. I can see this being nice syntactic sugar for accessing array elements.

How to Give Better Code Reviews

Laurie — Thu, 10 Jun 2021 03:23:34 +0000

If you're working on a codebase with more than one contributor you likely participate in code review. Also known as the act of signing off on someone else's code before it can be merged into the main branch.

The idea behind code review is incredibly sound. We all benefit from an extra pair of eyes. It helps team members gain context on other pieces of the code base. It ideally keeps the patterns and choices consistent, helping people onboard down the line.

Yet the words "code review" can often strike fear into the minds of those who hear it. Those who have endured bad code reviews often describe the experience as demoralizing or condescending. We don't want to make people feel that way, so let's talk about what it takes to be a good reviewer.

What not to do

Let's start by explaining what code review is not.

Code review is not being a human linter

If a given piece of syntax should never show up in your codebase, add an automatic linter rule. It's a waste of time to make this a manual process and it doesn't provide a ton of value. If it's not worth it to add the rule then it's probably not worth it to point out in the code review either. If you do, you're being pedantic.

Code review is not about proving how smart you are

The goal of code review is entirely about the person who wrote the code growing their skills, and your codebase getting more robust. None of that is about your ego or showing off how much you know.

So how do I do it right?

Now that we have that out of the way, we can talk about what you should do.

This is a two way conversation

Yes, there are power dynamics at play in code review. The reviewer may have a more senior title or have more experience in the codebase at hand. The original author may take that into account when weighing the recommendations, but as a reviewer you need to recognize that what you say isn't gospel. You may be missing context, or misunderstand what the original author is trying to do.

Given that, it's better to ask questions when phrasing recommendations. Instead of "You should do it Y way", try "Can you talk about your reasons for choosing X? In most cases I'd use Y, is there a reason not to here?". Typically, this has the same outcome but it feels more collaborative and leaves open an opportunity for all participants to learn.

This isn't just about what is wrong

Code reviews are asynchronous, but they don't have to read that way. The goal is to provide feedback and not all feedback is negative. It's just as valid to say "Cool! I didn't know you could do that". And you should. It will balance out the overall tenor of the review and leave the author with a sense of where they can improve as well as where they should double down.

Not everything is blocking

This may seem contrary to my comment above about being a human linter. However, not all things can be linted. Naming is a great example of this. Sometimes, you may have a recommendation that should not prevent the code from moving forward, but you want to note anyway.

Marking these things as "NB" or non-blocking can be a great way to provide a quick note that an author can consider but doesn't have to listen to. This is especially helpful if you have an idea for an improvement but don't feel strongly about it. Or you have a question but don't want the back and forth to hold up getting the feature in.

What am I looking for?

Now that we've talked about how to give feedback, let's talk about what to give feedback on. If code review isn't for pointing out syntax improvements, what is it for?

Integration points

Is there a spot that may cause friction with another system? Do you need to loop someone else into the review? Does there need to be a synchronous conversation? Point that out.

Error boundaries

Is there an edge case that isn't considered or handled? Talk about it. Make sure to address it before the code gets merged.

Unecessary bloat

Does the code propose including a new library or system of some kind? Does it need to? It's worth discussing.

Pattern deviation

Are you deviating from the way you've handled this type of functionality or data elsewhere in the codebase? Why? Let's talk about it.

Scalablility

Is the way the is code written going to cause problems down the road? Bring it up early even if you choose to go for the short term solution.

This is not an exhaustive list, but it should give you an idea of areas of concern that reviews can help aleviate.

Level up your team

The goal of a code review is to help level up the team and improve the long term health of the codebase. So focus on learning opportunities for your colleagues and yourself. And keep practicing--code review is a skill.

React 18: Terms and Functionality

Laurie — Thu, 10 Jun 2021 03:21:14 +0000

As of today, React 18 Alpha is here! This is exciting news as the last major release, 17, didn't include new functionality.

What's new?

If you're interested in learning about the new features, I'd encourage you to look at the GitHub discussions. The React team has done a great job of explaining things in detail and is actively answering questions.

The big takeaway is that you can use React 18 without having to change your existing application code. If you want to use the new features, you'll opt in rather than being forced to rewrite large chunks of code.

Cool, is that it?

If that's all you wanted to know and you're ready to dive into the links above, go right ahead! But since I'm me, I found myself wondering about all the terminology I've heard over the past year or so. What is the right way to talk about React 18 going forward?

Suspense

This functionality was available starting with React 16.6. The idea was that you could designate a loading state while you waited for some code to load.

<Suspense fallback={<Spinner />}>
  <ProfilePage />
</Suspense>

React 18 does indeed dive into more in the world of Suspense. In fact, the way Suspense works has changed. You can read more in the GitHub discussion but it's helpful to point out the terminology changes. Specifically, the pre-React 18 Suspense implementation is now referred to as Legacy Suspense and the new implementation is Concurrent Suspense. Why? Let's talk concurrent React!

Concurrent

This is the term you'll see most often in all of the various discussions/blog posts. So what exactly is concurrent React? "Concurrent" is the word being used to describe a suite of new features that rely on a specific type of internal implementation.

This includes things like startTransition that helps you account for expensive state transitions. It also covers SuspenseList, a way to coordinate the various Suspense fallback states. There are a couple other headline features, but the big takeaway is that concurrent React is a way of getting, and keeping, your pages interactive--even if they're actively doing other things.

It's important to note that these are not the only concurrent features that will eventually end up in React, but they're a big start on the journey.

Server Components

In December of 2020, Dan Abramov and Lauren Tan gave a great talk introducing server components. In this video they talked about writing React components server side and having the result of that component sent to the client and rendered.

This was a very cool demo! ...and it's not a part of React 18. However, React 18 does set the stage for some of this functionality in the future.

Let's talk about Lodash

Laurie — Fri, 04 Jun 2021 18:03:21 +0000

If you were a JavaScript developer during a certain era, you're likely familiar with the library Lodash. It's a utility library full of functions that make it easier to manipulate arrays, objects and strings. Lodash included so many critical functions that, for a long time, it was one of the first things developers would download when setting up a new project. However, times have changed.

So let's talk about how we might think about Lodash in the context of today.

ECMAScript

For a primer on ECMAScript and TC39 I recommend reading my post on the ECMAScript Ecosystem. With that out of the way, let's talk about new features to the language.

Arrays

One of the things Lodash is known for are wonderful functions for handling arrays. For example, flattening them.

const arr = [1, [2, [3, 4]]]
_.flatten.(arr) // [1,2,[3,4]]

We don't need to use Lodash for this anymore! Array.prototype.flat is a thing.

const arr = [1, [2, [3, 4]]]
arr.flat() // [1,2,[3,4]]

In fact, the flat function handles all three of the Lodash flatten methods.

const arr = [1, [2, [3, 4]]]

_.flatten.(arr) // [1,2,[3,4]]
arr.flat() // [1,2,[3,4]]

_.flattenDeep.(arr) // [1,2,3,4]
arr.flat(Infinity) // [1,2,3,4]

_.flattenDepth.(arr, 2) // [1,2,3,4]
arr.flat(2) // [1,2,3,4]

Objects

Another popular method that people reach for is Lodash's get. This one found a JS substitute a bit more recently.

const obj = { a: 1, b: { c: 3, d: 4 } }

_.get(obj, 'a.b.c') // 3

This method helps you dive deep into objects and not worry about whether or not the values exist. As an alternative, we now have optional chaining.

const obj = { a: 1, b: { c: 3, d: 4 } }

obj.a?.b?.c // 3

As it turns out, get takes a third parameter, a default value. To match this functionality we have nullish coalescing.

const obj = { a: 1, b: { c: 3, d: 4 } }

_.get(obj, 'a.b.e', 'default') // default

obj.a?.b?.e ?? 'default' // default

Goodbye Lodash?

You may think that these examples mean Lodash is no more! Well, not so fast.

While ECMAScript has added a number of new features in the past few years, there are still parts of Lodash that don't have native replacements.

Some are under discussion, like the pipeline operator, which has some similarities to Lodash's chain method.

Others are still just a twinkle in JavaScript's eye. groupby and deepmerge are commonly referenced in the category of things people would like native implementations of.

So why does it matter?

You might wonder why this matters. If some things have native alternatives and others don't, why not use Lodash for everything and make your life easier?

Well, Lodash isn't exactly small. Installing it as a dependency in your project doesn't matter so much, but loading it up for every page isn't ideal. So you want to consider a couple things.

If you don't have to use a Lodash dependency and can use a native solution, do so.
If you've determined you need a Lodash method, don't import the entire library.

Instead of doing this:

import _ from 'lodash'

Do something like this:

import map from 'lodash/map'

Alternatively, there is a Babel plugin that can do this for you. There is also a webpack plugin that will further optimize things.

And that's it

Now go forth with your newfound Lodash knowledge! Make intentional choices about what needs a third-party dependency. And be sure to check out the do you need Lodash project.

Diving into Husky and Lint-staged

Laurie — Wed, 12 May 2021 14:47:52 +0000

Last week I talked about ESLint and its usefulness for keeping projects consistent amongst multiple contributors. If you haven't read that post I recommend doing so before diving into this one.

Today, we're going to focus on running ESLint automatically to ensure that the main branch of your project always follows your specific ruleset.

Lint-staged

The first tool to talk about is lint-staged. Lint-staged is configured in your package.json file.

{
  "lint-staged": {
    "*.js": "eslint --fix"
  }
}

As seen in the above example, you can use a glob pattern to tell lint-staged which files to run against. Additionally, you can give lint-staged a command to execute against those files. In many cases, you'll want more than one command, which lint-staged supports. In this case, you'll run ESLint and prettier.

{
  "lint-staged": {
    "*.js": ["eslint", "prettier --write"]
  }
}

So how does lint-staged work? It's specifically designed to work on "staged" files, thus the name. This means files you've changed or created but haven't yet committed to your project. Working on staged files limits the number of files you need to lint at any given time and makes the workflow faster. The commands you configure will run "pre-commit". As you're attempting to commit files to your project you'll see ESLint run in your terminal. Once it's done you may have successfully committed or find yourself with linting errors you need to fix before you're able to commit the code.

However, what you may not realize, is that lint-staged is not the only tool working under the hood. Lint-staged is designed to work with another tool called husky.

Husky

You may have come across husky before without noticing. For many years it was configured via a few lines of code in your package.json file. Something like this.

  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },

However, the latest version of husky, v6, has changed this approach. Now, husky uses distinct bash files with filenames that match the workflow step they correspond to, e.g. "pre-commit". Luckily you don't have to set this up yourself and husky has a nice CLI command to do it for you.

npx husky-init && npm install
npx husky add .husky/pre-commit "npm test"

The first line of the command is a one-time initialization script that ensures all your coworkers will have husky installed on their machine before they try to commit files.

The second line creates the pre-commit file inside the .husky directory. If you look at the file you'll notice it's running a husky.sh script prior to whatever commands you initialized it with. This can technically be removed, but I'd recommend keeping it. The script allows for a few things, including the use of a --no-verify flag that bypasses the checks.

Once you've initialized the directory and associated file you can add whatever commands you want to it. In my case, I replaced npm test with npm lint-staged.

Pre-push

The pre-commit workflow is more or less the husky happy path. But what if your project doesn't want to lint on commit and would prefer to lint when a developer attempts to push their changes to a branch?

While it's tempting to create a .husky/pre-push file and run lint-staged, it won't work. The pre-push husky workflow is correct, but running lint-staged at that point will turn up 0 matching files. This makes sense, though it certainly messed me up for a bit, because committed files are no longer staged. Instead, you have a couple of options.

Run ESLint against all the files: eslint '*.js'
Diff against main: eslint --no-error-on-unmatched-pattern $(git diff main... --name-only --- '*.js')

Note that this is one example of a diff command and there are numerous considerations depending on your project.

Next steps and CI

Running ESLint, or prettier, or even tests as part of your git workflow is important because it helps you fail fast. However, it's not a replacement for CI checks. Typically, you'll want to run these commands in both environments to ensure nothing slips through.

But altogether these tools help ensure a cleaner, more consistent production codebase. Long term, that's a big win for any project.

A Guide to ESLint

Laurie — Tue, 04 May 2021 13:41:23 +0000

I spent the last week working on ESLint configuration and ensuring that syntax checks were built into the developer workflow. In the process, I read a bunch of different docs, which is usually my signal that an "all in one" blog post needs to be written! So here we go.

What is Eslint?

For starters, ESLint is a tool that statically analyzes your code. Typically, it's used to ensure consistent syntax across a project with multiple collaborators. You've likely used ESLint without realizing it because it was already configured in your project. Ever seen those red squiggly lines in VS code? Those are often courtesy of Eslint.

One thing to keep in mind is that ESLint is incredibly powerful. It has the ability to not only analyze code, but transform it. We'll get to that later.

Configuration

ESLint allows you to set project-level rules using an .eslintrc file. Since every team and project are slightly different, the control you have over your ruleset is quite extensive.

Rules

For every rule, let's say you're setting the no-console rule, you can decide whether the rule should be off, or set to warn or error. Like this:

module.exports = {
  rules: {
    'no-console': 'warn',
  },
}

In the above example, the no-console rule determines whether console log statements should exist in the codebase. If the rule is set to off then console.log can be littered through your code and the linter won't care. If it's set to warn, the linter will let you know the there are console.log statements in the code, but it won't be a showstopper. But if the rule is set to error, linting will fail if a console.log statement shows up in the code.

While this is helpful, some rules need to get more specific. For example, ESLint has a rule called import/no-extraneous-dependencies. The goal of this rule is to catch situations in which you've imported a dependency into your file that is not included in your project's package.json.

While you could use off, warn, or error, it's not as helpful as it could be. That's because there are different types of dependencies, like devDependencies and peerDependencies. A more nuanced configuration of the rule would look like this:

module.exports = {
  rules: {
    'import/no-extraneous-dependencies': [
      'error',
      {
        devDependencies: false,
        optionalDependencies: false,
        peerDependencies: false,
      },
    ],
  },
}

The above code will only show a linting error when core dependencies are imported but not included. Any other dependency type can be safely ignored.

Extends

You may be thinking that this seems a bit tedious. Do you really want to go through and determine your preferences for all of these individual rules? You may, but probably not. In fact, in most cases, you'll only need to configure a handful of individual rules; the rules that differ from the ruleset you're extending.

Many projects use the core ESLint rules, as shown here.

module.exports = {
  extends: 'eslint:recommended', // highlight-line
  rules: {
    'no-console': 'warn',
  },
}

However, ESLint also allows you to extend rulesets that are exported by other projects. So you may opt to use the React recommendations, for example.

Root

Another interesting thing about ESLint is that it follows a cascade model. Suppose you're using a monorepo structure with multiple packages that each have their own .eslintrc file. You can include a configuration file in the root of your repo. In that case, ESLint will check the configuration file closest to a given line of code first and move up the tree, merging as it goes.

Typically, the top-level directory will include root: true so ESLint knows it can stop looking for additional config files.

module.exports = {
  root: true, // highlight-line
  extends: 'eslint:recommended',
  rules: {
    'no-console': 'warn',
  },
}

However, this rule can exist in any .eslintrc. So, if you wanted to include a standalone package in your monorepo that should not comply with the top-level .eslintrc, you can do that. This is a great trick so that you don't need to supersede all of the rules at the top level.

Overrides

Alternatively, you may want to supersede individual files that wouldn't have their own .eslintrc. In that case, you can use overrides, like this:

module.exports = {
  root: true,
  rules: {
    'no-console': 'warn',
  },
  // highlight-start
  overrides: [
    {
      files: ['example/*.js'],
      rules: {
        'no-console': 'error',
      },
    },
  ], // highlight-end
}

CLI

Now that you have ESLint configured, what can it actually do?

If you run an ESLint command it will go through the files in your project and spit out all the warnings and errors to the command line.

eslint .

You may remember that I mentioned up top that ESLint can perform transforms. Running ESLint with the --fix flag means it will attempt to change any syntax that errors out! It's worth noting that it can't fix every error it finds, but it can handle some of them.

You can also use the --debug flag which will show you what rules ESLint is using. This is helpful if you're attempting to determine why something is failing/passing that shouldn't be.

Scripts

While running ESLint locally is helpful, the point of ESLint is repeatability and consistency in your project. To get that you likely want to add ESLint commands to your package.json scripts.

{
  "scripts": {
    "lint": "eslint 'packages/**/*.{js,jsx,ts,tsx}'"
  }
}

When you do that you can make use of things like husky! We'll talk about that next time.

Wow

There is a lot in this post but there is, even more, I didn't cover. In the scripts example, I used a glob, there are flags like --quiet, you can even ignore certain files throughout your project. But this is a good start towards helping you understand the setup of an existing project or how to start setting up your own.

And who knows, an ESLinterror may lead to finding and solving a bug! It did for me 😃.

From JavaScript to Rust : Data Types

Laurie — Tue, 27 Apr 2021 13:44:08 +0000

You may have been following my journey to learn Rust as I covered topics like mutable variables, ownership and references and crates. These learnings fell into two distinct categories.

Stuff that has a clear parallel in JavaScript land
Stuff that's brand new, and I have no existing mental model for

Yet, as I started to read and write more Rust code, I realized I was missing one big piece of the puzzle when it comes to learning a new language. I didn't have a strong understanding of data types in Rust. I quickly discovered that this information fell into a third "learning category". Stuff that overlaps with my JavaScript mental model in a way that's contradictory.

Given that reality, I figured a post was in order! So without further ado, let's talk data types.

Primitives

A JavaScript primitive is similar to what Rust calls a scalar type. Rust has four scalar types: booleans, integers, floating point numbers, and characters.

Additionally, The Rust Reference mentions primitive types, which includes str and Never on top of the four scalar types.

Boolean

Let's start with something familiar, booleans. Booleans, or bool in Rust, are a type with two possible values: true or false. This matches up with our JavaScript understanding, so no changes here.

Number

The same can't be said of numbers. In Rust, you need to care about what type of number you're storing. Is it an integer or a floating point number? What amount of space, in bits, does storing it take? Is it signed or unsigned?

In Rust you can initialize integers of five different sizes, from 8-bit to 128-bit, either signed or unsigned. For floating point numbers you have either f32 or f64; the first is single precision and the second, double precision.

String

You may have noticed that I didn't mention strings as Rust scalar types, I mentioned char. This is accurate. However, Rust does have a primitive type str. The strange thing is you likely won't use it other than as a reference to a specific string stored in memory, &str.

If you want to create or manipulate strings, you want the growable type String. But be careful! The methods you're used to, like len (aka length), won't return what you expect.

Structural types

In JavaScript, most structural types are specific implementations of the JavaScript object type. But we'll break them out individually for the sake of this post.

Arrays

Now we get to the part where you'll need to rewire your internal JavaScript dictionary. An array is a valid Rust type. Unfortunately, that's not entirely helpful. An array in Rust is of fixed size. If you expect to create static data that won't change but you want to reference/look it up in an array structure then this may be what you want.

More likely, though, you want a Vector. vec is similar to String. It's an array type that you can own and grow dynamically.

Objects

Search "Rust object type" and you're bound to be confused. You'll end up reading up on Trait object types, which is a bit more advanced than what you're after. What you're really looking for is struct.

In Rust, a struct is defined as a type composed of other types. Sounds like a JavaScript object to me! It's worth reading about structs further because they do some unique things when it comes to mutability.

Sets and Maps

These are relative newcomers in the land of JavaScript, but they're great tools to have at your disposal. When developing in Rust you'll get similar functionality from HashSets and HashMaps.

Note that there are also BTree based implementations of these structures.

Function

As with JavaScript, Rust has first-class functions. In addition to functions, defined using the fn keyword, Rust also has closures. Closures are anonymous functions with syntax that looks similar to JavaScript arrow functions.

Is that it?

JavaScript is pretty minimal when it comes to types. Especially when compared to more verbose languages like Java or C. Rust's offerings are more similar to the latter, so things like Linked Lists are available as a type in Rust.

If you can't find what you're looking for the docs are great! And so is the community. With a little bit of trial and error you'll get what you need.

Setting up my new Machine

Laurie — Fri, 09 Apr 2021 13:56:03 +0000

I started my new job this week, and that meant setting up a new machine. I have a set of tools that I'm comfortable with, so choosing what to download wasn't complicated.

What I did find interesting is the tools I "just had to have" and those I haven't yet configured yet. A lot of my choices are available on my uses page, but it also needs an update.

So with that, I'm going to talk through my must-haves this past week!

Terminal

Over the years, my terminal has become my programming control center. Who would have thought! When I first started doing development work, I was incredibly intimidated by the command line. I suppose building CLIs will rid you of that fear 🤷.

As it turns out, my terminal setup requires a lot of things. Oops!

iterm2: I find this a nicer option than the built-in apple terminal.
oh-my-zsh: All my machines use this and I've gotten comfortable with it rather than bash.
starship: This is a newer tool for me but I love the information-rich command prompts and the overall look.

Once the look and feel of my terminal was ready, I needed additional software.

homebrew: The essential package manager for macOS.
nvm: My JavaScript-loving heart can't live without it.

I also set up Xcode command line tools so I could get git working. But that was most of my first week essentials in terminal.

Apps

Now it was time to get my most-used applications. My machine came preloaded with Slack, so I didn't need to worry about that. But there were a handful of other things I wanted right away.

VS Code: My IDE of choice. I'll dive into this more in a moment.
Magnet: I actually didn't download this until day three and was wondering why my monitor was bugging me so much. Windows managers are so key!
Elgato Control Center: This is how I control my lighting setup and make my video chats higher quality.
Clockwise: I technically downloaded the chrome extension and integrated it with Slack, but close enough. Calendar tools are a first-week necessity.
Google Doc dark mode: Another chrome extension, but this one helps my eyes a ton when I'm trying to do a lot of deep focus reading.

That's a surprisingly low number of apps. I'm sure it'll grow in the coming weeks.

VS Code

Now we get to the really good stuff. I'm a developer after all! As it turns out, I didn't do much coding in this first week, but I did look at a lot of existing projects. So what were my go-to extensions?

ESLint
Prettier
Bracket Pair Colorizer
Indent Rainbow
JavaScript and Typescript
Peacock
Monokai theme

And that's the current list! It'll get longer, but you can already tell that it's focused on readability. I don't necessarily know what functional helpers I'll need yet.

Yay first week!

So that's my current computer setup. It's connected to all my existing hardware and you can read more about that on my uses page. Thus far, I've done a lot of reading, had plenty of onboarding chats about logistics, and started to get a handle on what my new role is. Excited for what's to come.

If Your Tech Interview is Three Tech Interviews in a Trench Coat and I Do Five is It Additive or Exponential

Laurie — Mon, 29 Mar 2021 13:10:47 +0000

I want to warn you all ahead of time. This is going to be a lengthy post. So feel free to take it in chunks. I also want to add that this post is filled with privilege. At no point during this process did I fear losing my job, my basic needs were always more than met, and I'm a white cis woman. This is a narrative of my experience and the lessons I learned along the way. It is not meant as universal tips for the job search process. That's deeply personal.

There are a large number of people in tech who subscribe to the "you should always be interviewing" mentality. To be honest, I've never been one of them. If you've been around me much, you know that I'm not fond of how we interview in this industry. So it makes sense that I wouldn't choose to subject myself to that process for no reason.

That being said, I opted to begin a job search around six months ago. What did that mean for me? It meant I told some friends privately that I was willing to entertain opportunities. And if I saw something appealing, I'd apply.

That's where our story starts. This post will include lessons I learned as a job seeker. As well as patterns I hope companies will address.

Quick note. I receive a LOT of recruiter inbound. Of the companies I mention in this post, only a few of them were places I considered because of unsolicited outreach. I'm far more likely to rely on the recommendations of friends.

My Network has grown

I've not "searched" for jobs in some time. The last time was my first full-time coding job where I interviewed at nine different companies. From there, I fell into another opportunity. And when I joined Gatsby I had only applied to that specific role.

The last few years have been a lot of fun as I've gotten to broaden my reach in the JavaScript ecosystem and meet a lot of incredible people. To be honest, I hadn't realized what that would mean should I ever look for a new role.

My search quickly became overwhelming. My friends, who are awesome and I thank them, sent me so many leads and connected me with even more people. I wound up with five or so concrete interview opportunities within a week. And in the end, I went through two distinct periods of interviewing with a break in between. Let's talk about how that played out.

Search Part I

We'll start with the first "phase" of interviews, the initial five companies. For two companies, the process ended after the first conversation. One was on my side--I couldn't go through five processes at once. I was working a full-time job. The second was on their side. They liked me, but they'd just closed the role with someone else.

LESSON #1
The first qualified candidate through the process will get hired. If there is a difference of under a week they may hold off, but not always. Find out if you're part of a search for a single seat and what their timeline is.

Now for the other three opportunities! I'll start by saying I made it to final rounds for all of them. And I didn't get offers from any of them. Demoralizing? Yes. Exhausting? Without a doubt. I'm not going to name specific companies, but I will talk about each of those experiences individually.

Company A

This was my first technical interview process in quite some time. I coded in front of them in at least three interviews. One went well, one I thought went well (we'll get to that in a second), one went poorly.

They had a two-part final round and called me the night after part one to cancel the following day. I genuinely appreciate them not wasting more of my time.

But let's talk about how we got there in the first place. Their interviews were very tool-user specific. This was for a tech lead role that would need to help guide the team to solve problems, use more scalable practices, and yes, code.

Their interviews focused on whether I put curly braces in the right place on the first try (and yes, that was actually part of the feedback). I had told them prior to the interview that I was working in the frontend ecosystem in a very niche area! That some of my generic frontend skills were rusty. But sometimes, even when you set expectations, there is a clear disconnect.

You won't be surprised to hear that this experience inspired my senior interviews post.

Company B

Fun fact, this would not be the only time I interviewed with this company in the six-month period, but this was the first.

The full interview process involved eleven conversations when all was said and done. To be honest, I made some mistakes here and I think they're important to talk about.

The job seemed perfect at first! But as the process went on I realized it was very systems architecture heavy. And I ignored that. Choosing to move forward because they were moving me forward. It wasn't the right job for me, we both knew it, but neither party wanted to admit it.

Was that a bad thing? Well, yes. Because I didn't have the right kind of experience for what they were indexing on (there were other parts of the job I could do well), they added extra interviews on that subject. They wanted to be super sure I couldn't do the job! Because they liked me! And that sucked.

It seemed like everyone was being nice and giving me my fair shot. But in reality, we all knew I didn't have that skill at the level they wanted. So it wasn't super fair to keep putting me through those extra interviews.

I also froze in one of the early interviews on that subject. I can normally BS and talk through most situations, even when I'm terrified. I couldn't in this scenario. I suspect this is a big reason they opted to add additional interviews--in case it really was just nerves.

LESSON #2 The company may be awesome. You may want it to work. But if the interviews are focused on things you don't like/aren't good at AND you've confirmed that matches the tasks of the role, drop out.

Company C

I'll state up front that this was my most frustrating interview experience. And I'm still not pleased with how it went. I applied for a staff-level position, had an initial call, and was fast-tracked to their final interview process. Awesome!

This company does generic interviews for candidates at that level (they're not alone, I'll touch on this later). The problem was how this played out. I was applying for a somewhat specialist position. As I moved through conversations and they didn't seem to match the role at all, I'd ask "is this type of work part of what I'll be doing in this position"? 3/4 interviewers didn't know what I was interviewing for. 2/4 looked it up and hadn't heard of the team.

I would never recommend a company do this for so many reasons. I knew as soon as I left the final conversation I hadn't met the bar. Because the bar didn't even make sense. Plus, I was exhausted (we'll hit on that in a moment too).

When the recruiter emailed me she mentioned how amazing I clearly was and that she was sure I'd land somewhere great. I had a sense she was stunned I could tank their interview so badly when it was clear I had experience. Tech is big! People can't know everything. So don't interview them for things you aren't hiring them for.

Now to the exhausted point. I was exhausted. This was the last of my processes. I was doing interviews almost exclusively in west coast time because I had a day job. If I recall correctly, that final round started at 6 pm on a Friday night for me.

LESSON #3
Interviews when you're tired put you at a disadvantage. Schedule them as best you can to prevent that eventuality. And if there are jobs you don't want? Drop out and save your energy for the ones you do.

So where does that leave us?

And that was the first stretch of interview processes I went through! By this point it was Fall. I was moving. The holidays were coming up. I was exhausted. I'd followed through on the initial leads and nothing had panned out. So I stopped.

This is the absolute best thing I could have done for myself. I had barely made it through some of the end rounds with my mental health. It was a pandemic still. Work had been really busy, and a bunch of my friends had left.

As I was about to take two weeks off for the holidays, something shifted.

Search Part II

I still hadn't told any additional people I was looking beyond the original handful. But apparently, the end of 2020 meant a lot of roles were about to open up.

All of a sudden I was contacted for, referred to, and otherwise told about over a dozen roles. I won't go through each of these individually, but I'll capture the highlights.

Company D

I was so so excited about this role. I didn't start an official interview process, it was all conversations about me, my background, what the role entailed, if I was interested in it.

But part of the reason I didn't interview was because they didn't want to put me through that until they were sure they could hire me. In the end, they couldn't. They didn't have the right headcount in the right places. But the company treated me as a human and an individual. Timing didn't line up but if they came back in the future I certainly might consider working there.

LESSON #4
Timing is everything. A company may contact you to interview just as you're about to accept an offer. You may find an amazing role that would be perfect for past you, or future you, but not current you. It's frustrating, but it's good to recognize that a lot of job searching is out of your control.

The Start-Ups

This is not an entirely fair grouping, but there were three companies in my space that had various roles they were interested in me for. I took those conversations, sometimes going a bit further into the process.

The problem was I sort of knew that wasn't what I wanted for my next step. But it took me a while to feel confident in that and walk away from those processes. And I had too much going on at the time too, so that forced my hand.

LESSON #5
It's really hard to say no. Like, really hard. Especially when the company is small and you don't feel like just another number. But it's best for everyone that you do. Even if you were referred to the role. Be respectful and fair.

The repeats

This may seem surprising, but there were a lot of companies I talked to more than once, for different roles. Some didn't move quickly enough before I had another offer I wanted to take. In other cases the role wasn't right the second time around, so I dropped out.

Talking to places twice was great because they tried to limit the conversations I'd already had. And they were keyed into the type of work I wanted to do.

LESSON #6
There will always be another role open at a company eventually. Don't burn bridges if things don't work out the first time around. And don't be afraid to apply to a new listing even if it's at a company you just completed a process with.

The title "cuts"

This one is interesting and was a part of the conversation at a lot of different companies, but two in particular. These companies had openings for roles with a specific level in mind, rather than a sliding scale that they'd peg to the candidate in question.

That was great information to have upfront! I decided not to pursue either role in the end, though the level misalignment was not ultimately a factor in those decisions. One was a timing thing. The other had a bad reputation for women when I asked around.

LESSON #7
Make sure to use your network and ask around about companies you're considering. Typically you'll do this research before applying, but recruiter inbound is different. This is especially important as a minoritized individual; be sure to get a clear picture of the company culture before investing too much time in the process.

But let's get back to the title cut conversations. Knowing the company had a specific level in mind ahead of time was a perfectly reasonable explanation. Unfortunately, there was more than one place I spoke with where the recruiter opened with "you may have to take a title cut" and no further explanation. They were projecting what they thought my experience would count as before interviewing me in any capacity. That was a red flag.

LESSON #8
There can be a lot of reasons for titles, compensation, etc. Make sure you know why. Context does matter.

The offers

Now we're getting to the final two. The places where I chose to go through all the interviews and ultimately received offers.

Company E

Another generic interview! I told you we'd come back to this. But this one was done really well! All the rounds were applicable to my skills, everyone knew what types of signals they were looking for, etc.

But I still don't like generic interviews. While this experience was far better, it left the team match until the end. It was essentially, "if we like you, we'll find where you fit when we're done". That meant a lot of time was put into a process for a job I didn't know anything about.

And in the end, I really liked the company. But finding the right team and the right manager felt like a burden I was putting on them, dragging out the process. That wasn't a great way to feel.

LESSON #9
Always take your time and do your research after you're given an offer. If the company tries to rush you, be wary. However, see my note about privilege at the beginning. You may not be able to do this, and that's perfectly ok.

Company F

This was a repeat process so they nixed a few interviews. But the role was in such a different technical area than the first process that it was hard to do more than that. What's interesting about this process was that I was in touch with the hiring manager throughout. I spoke to him early on and checked back in for ~15-minute calls between almost every set of rounds. This was unique among the places I interviewed. In most cases, I'd meet the hiring manager once. And in at least one process they planned to hire me without having met them at all!

Another interesting part of this process was they were clearly aware of the possibility that I may not choose to work there. This is always true, but rarely is it acknowledged in a scenario where companies hold a lot more power than candidates. This meant that they asked me a lot of questions about what I wanted to do, raised concerns they saw about where the role may not match my needs, etc. I felt confident by the end that I knew what to expect.

LESSON #10
You will almost always have more questions than they give you the time to ask. If you don't feel like you have a good sense of the role, or the team, or the company, or anything else you want to know, make sure you have someone you can follow up with asynchronously.

The Patterns

Every final process included multiple interviews. And each time they'd talk about how each of those interviews was focused on different skills/questions. Yet they consistently repeated questions and I repeated examples/anecdotes. This is a frustrating waste of time that we should address as an industry.
Interviewers need to know the skills they're looking for in a candidate or they shouldn't be interviewing them. One size fits all makes zero sense for a company of a certain size, regardless of the level targeted.
The tool user problem I talk about in my senior engineers post is absolutely real. The best interviews I had included only one hands-on coding task and you passed based on your approach to the problem, rather than familiarity.
There were some red flags I witnessed that I think are worth writing down. They may not be flags to everyone, but they were to me.

Using the term "famous" or "superstar" as a way to appeal to me as a hire. It made me worry about what criteria they were using for the team/company.
Mentioning that I would help them break the mold of a homogenous team based on friends of friends. I had no interest in being a guinea pig.
Managers who made it clear they'd rather be ICs and used their time accordingly. Not someone I want helping me navigate the next stages of my career.

There were others, but those three stick in my brain.

So what's next?

I'm starting a new job next week! I'll probably mention where in the next few days. But I wanted to focus on the process first. I truly hope it's useful to see this all written down.

It took a considerable amount of time to find a company I wanted to work for, with a role I was interested in, where the timing aligned. There were times it existed and I didn't pass muster. It was a hard and tiring process but I'll leave you with one final lesson.

LESSON #11
People tell you to always be interviewing because the tech industry has turned interviewing into its own skill that you can get rusty at. If you don't want to do that--I didn't--make sure the company you’re most interested in isn’t the one you interview with first. Give yourself a true trial run, with real stakes, to stretch those interviewing muscles. By the time I got to the second phase of companies, I was seeing exercises I'd already seen and solved.

Lessons Summary

The first qualified candidate through the process will get hired. If there is a difference of under a week they may hold off, but not always. Find out if you're part of a search for a single seat and what their timeline is.
The company may be awesome. You may want it to work. But if the interviews are focused on things you don't like/aren't good at AND you've confirmed that matches the tasks of the role, drop out.
Interviews when you're tired put you at a disadvantage. Schedule them as best you can to prevent that eventuality. And if there are jobs you don't want? Drop out and save your energy for the ones you do.
Timing is everything. A company may contact you to interview just as you're about to accept an offer. You may find an amazing role that would be perfect for past you, or future you, but not current you. It's frustrating, but it's good to recognize that a lot of job searching is out of your control.
It's really hard to say no. Like, really hard. Especially when the company is small and you don't feel like just another number. But it's best for everyone that you do. Even if you were referred to the role. Be respectful and fair.
There will always be another role open at a company eventually. Don't burn bridges if things don't work out the first time around. And don't be afraid to apply to a new listing even if it's at a company you just completed a process with.
Make sure to use your network and ask around about companies you're considering. Typically you'll do this research before applying, but recruiter inbound is different. This is especially important as a minoritized individual; be sure to get a clear picture of the company culture before investing too much time in the process.
There can be a lot of reasons for titles, compensation, etc. Make sure you know why. Context does matter.
Always take your time and do your research after you're given an offer. If the company tries to rush you, be wary. However, see my note about privilege at the beginning. You may not be able to do this, and that's perfectly ok.
You will almost always have more questions than they give you the time to ask. If you don't feel like you have a good sense of the role, or the team, or the company, or anything else you want to know, make sure you have someone you can follow up with asynchronously.
People tell you to always be interviewing because the tech industry has turned interviewing into its own skill that you can get rusty at. If you don't want to do that--I didn't--make sure the company you’re most interested in isn’t the one you interview with first. Give yourself a true trial run, with real stakes, to stretch those interviewing muscles. By the time I got to the second phase of companies, I was seeing exercises I'd already seen and solved.