DEV Community: charlie⚡

How to Make Your Code Reviews Awesome

charlie⚡ — Wed, 20 Oct 2021 16:19:34 +0000

You ever stare at a pull request (PR) with 40 open comments, all of which require resolution or response in order to merge your work? I have. I learned loads from those, we would get into great discussions documented right in your project. But it's a double-edge sword, you can learn a lot from these experiences and at the same time it can also suck the life out of you leaving you just a desiccated hunk of VSCode shortcuts and a mild caffeine addiction.

It doesn't have to be that way. It can actually get worse, pull request reviews can become a politic dumping ground and a toxic element of broken engineering cultures and horrible teams.

You deserve better.

You invested in the work you did and your reviewer invested energy and attention into reviewing it. It's easy to forget that, your reviewer is an impediment to your progress, and you're a distraction from whatever they were working on. You both are worthy of respect and kindness.

So I developed a system for PRs I like to float when I'm working with teams. I call it: Ranked PRs.

These are kinda my rules for Ranked PRs:

Keep things low stakes for both the reviewer and the author.
Buffer harsh interactions with sincere praise.
Make opportunities to bail
Automate as much as possible

But the manner for doing all of this is pretty blunt: If you're leaving a comment on someone else's work it should be qualified or at the very least categorized.

In practice, I end up prefixing each comment:

REQUIRED must resolve the following comment, usually provide a link for more context or example
QUESTION/CLARIFICATION = must respond to question or create follow up comment
NIT can be ignored, usually response to stylistic preference or consistency
COMMENT general, no need for resolution
PRAISE encouraging

Emojis for some teams might be neater:

❗️ = must resolve the following comment, usually provide a link for more context or example
✅ = must respond to question or create follow up comment
🙄 = can be ignored, usually response to stylistic preference or consistency
✨ = general, no need for resolution
🎉 = encouraging

This accomplishes two big things:

You get a focused scope as the reviewer to work in. You can prevent a lot of hassle from knowing you have a finite way of responding; fewer rabbit trails to go down and clearer targets to hit.
You give the author of the PR a way to navigate your feedback. For instance, if they've got 4 REQUIRED comments, they can resolve them quickly and focus on bigger pieces of feedback.

It ends up looking like this:

Making praise and ignorable comments a key part of this setup makes it easy to call out growth and identify what issues you should let go of in time. For instance do I actually care if someone is casting something to a type? Maybe I do, maybe I don't, but calling it out gives them an opportunity to explain or ignore you and you can be okay with either. Should another engineer get some praise for making a cleaner abstraction for that one thing that bugs everyone? Yes, yes they should.

However, I have found some caveats (YMMV):

In teams that are growing I’ve found this method for commenting works effectively, especially when you have a mix of junior and senior engineers.
If you present this as a prescriptive solution it will fail, it's usually better floated as a discussion topic or an experiment.
If you haven't automated formatting and code linting rules (think SwiftLint, Prettier, ESLint, etc), you're in for a bad time. It's not worth the collective energy to keep calling these things out and usually ends up looking like dog-piling on someone. Like just set it up and if someone has a real issue with it, have a conversation and be flexible. (My experience has been bad managers don't like these tools but they don't have to write the code so 🤷.)
If you have someone new to a team or new to coding and it's their first PR, setting expectations of "Hey, 40 comments is totally normal, not an indicator of anything wrong" can be so helpful.

There are some tools that can help make working like this a little bit easier:

Jiffy: This is really great for adding GIFs to a PR because you can just drag from a menubar app directly onto GitHub
Add PR Comment: I've used this to automatically add the legend of what comments mean what anytime someone opens a PR. It works pretty okay.

Ultimately GIFs and emojis cannot fix a broken engineering culture, but a little bit of levity and lowering the stakes of giving feedback fosters a more giving group of engineers.

This was originally posted here

A Self-Care Primer

charlie⚡ — Fri, 27 Dec 2019 20:50:19 +0000

"Self-care" was something I'd had read about a lot on Twitter and I couldn't help but think of it as a troupe. Ask my therapist, well, ask her if I ever waive confidentiality but there's paperwork for that so not likely. But every time I heard "self-care" like most skeptics I conjured the most ludicrous and lavish examples that the internet hash-tagged into ubiquity. Images of spend money irresponsibly or being selfish for purposes of gratification and pleasure.

If you're thinking this is ridiculous, most definitions that come from a quick Google search will have to disambiguate from that what self-care actually is and does for you. Eventually, I discovered that's not self-care, that's pageantry. Self-care is literally, doing something to care for yourself and your health or well-being. It's not necessarily champagne, spa retreats, removing all meaning from the word "mindfulness", spamming Instagram with your candle business.

I've been having some hard days at work, I ended working close to 60 hours last week on top of attending a conference. I'm doing more lead work recently. Sleeping has been rough going (which is my normal, but this is worse), relaxing seems like a chore, things I was super excited for like replacing. If my therapist is to be believed, self-care is essential to keep being a human.

Self-care needs to be an intentional choice, so when I get into binge mode by default and consume streams of content.

One thing that I've observed, is that I can't really do my job nor should I super be expected to if I can't function as a human. Self-care, taking care of yourself, or "humaning". Whatever you want to call it is essential to maintaining that functionality.

A note about privilege and ableism

What I'm about to outline, is a framework I apply to thinking about taking care of myself, it is in by nature personal. And not every application can be applied to everyone, my hope is that after reading you see the framework behind the questions and can take the questions as starting blocks.

My biases in forming these revolve around my own privilege that comes from being white, cisgender, reasonably able-bodied, male and being seen (wrongly) as straight. The questions and particulars as to how I apply this framework come from that privilege that's not distributed evenly, and I can't in good faith continue without prefacing this fact.

Back to Basics

When I get into this state I've described of being barely functioning, it's helpful to go back to the basics. Abraham Maslow's classic "Hierarchy of needs", represents a progressive state of needs, ranking physical needs as a bedrock for being able to the next level of needs and that level being the foundation for being able to attain the next set of needs. For example, it's hard to worry about whether you're loved or have a sense of belonging if you're starving and need shelter.

It's hard to focus on the whole litany of everything you're supposed to be or do as a software engineer if you can't keep your eyes open. So I started to develop a framework (because I am who I am) of questions to start to probe whether those needs are being met:

Did I eat something recently that was actually food?
Do I have clean underwear and matched socks?
Did I talk to a human being that doesn't reside in my apartment building?
Did I try and sleep in the last 36 hours?
Does the screen go all fuzzy when I try to look at it?

Yea that's a low bar. That's intentionally a low bar, some of these things sound trivial or worrying that you might need to double check. I've found in my life living off of McDonald's and delivery is a bad idea, eating a plate of eggs and ham is better. Having clean underwear and matched socks is evidence of laundry having been done recently and speculation around the idea of a shower has happened. Talking to other humans is a chore sometimes but cheap shots on Twitter aren't great substitutes for human interaction.

These concerns all certain around forming a baseline.

Next Level

If those concerns are addressed I feel like I can move onto the next level of things. This group is more concerned with feeling like a person once you can do basic human things.

Did I go to therapy this month? Mental health is so important. Therapy can be such a trope but it can also be an opportunity to confess in a space "Things are not okay and I don't know what to do next". Plus my therapist is awesome, she wears glasses and everything.
Did I read a book made out of a dead tree? "Blue light is bad and a tree had to die for me to get this book in my apartment, I should read it." That's a little chant I say in my head sometimes to convince myself to read a book. Just remember disengaging from work can be as simple as a context switch and opening a physical book or closing your eyes and listening to an audiobook can do wonders to get you there.
Is the bed made? This is a weird new obsession of mine from the last two months. There's books written about how this can help your outlook and I have no interest in reading them. For me, it's a reminder that my home and my place in it have value and that being in a place of rest won't be a burden later. Also it's really fun now that I figured out what the hell "hospital corners" are and how to make them.
Is the mess in my apartment going to prohibit me from doing the stuff I need to do or the stuff I want to do?

Next Next Level

This layer actively preserves the previous too, in mind this goes human → person → semi-responsible person

Is there anything nagging at me? Is there anything I'm ignoring that's keeping me up at night? That's not a cliche to me, there's a whole host of things that have real potential to interrupt my ability to sleep. These things usually revolve around money, or phone calls or messages that I tend to ignore. Occasionally this can be mounds of trivial things like: "Is Notion organized?" or "It's been a minute since I've written a blog post."
Is everyone just hard to deal with? This is usually a good question to ask when being around other humans reaches a new height of difficulty. Usually, if everyone around me is being a jerk, it's them being the jerk it's me and usually that indicates something wrong internally like lack of sleep, feeling restricted, something personal going on that they had no hand in.
Do I actually know where I'm going? Often a source of lack of focus or productivity and in turn a lack of being well is a result of not having a clear understanding of why I'm doing what I'm doing or how it will be in service of whatever goal and worse not knowing what the goal was to begin with. Not understanding where you're going can confuse where you are. Sometimes this distance is where I'm hoping to be in the next hour or next three years, it doesn't matter, taking basic inventory of the why can only clarify the what.

Ever Upwards

This is where I think we have some basic level of functioning and cognition and we move onto what can actually bring some excitement back into the work itself.

Am I engaged in what I'm being paid to build or am I just applying a "paint by numbers" approach? Some times that's easy to do. Some times this is the job and that's fine. Just getting a clear answer to this can tell you a lot and give you coordinates as to what to do next. Say you're content with the work being simple, it gives you some reserves back to invest in the rest of your team or pick up some background task. If you're not okay with the answer being yes, it's a great opportunity for on a technical level automation or abstraction and on a career level the chance to say to your manager, you need something with more to chew.
Is there any tech that I care about that I'd like to see at use at work? We all have little lists, maybe it's Rust or Go or Elixir or Vue.js. We all have things we want to learn and this list can shame or taunt us. Spending an hour of your time (or better yet your employers time) to do a "Hello world!" tutorial with one of the things on your list is a low-cost remedy to this.
Why am I building what I'm building and who does it help? You can take as many tickets as you like, work your backlog until someone notices, but if don't understand who you're building it for, there's not a lot of point. Some times the answer to this question is unsavory, like you're building something so people in suits and put a PowerPoint presentation together to talk to other people in suits. Other times, what you're doing can bring someone real value. Find that answer.

What about making software?

If you got this far and were expecting a post about software engineering and have been disappointed. I'm going to balance that binary tree in your heart.

First of all you can think of this outline as a framework, let's see how many stars on GitHub it gets.

Second, software is made by humans, ensuring the bare minimum care and humanity of anyone who needs to build things and affirming that humans actually have needs can only aide in the process of growing as an engineer. To put that more practically, I don't care how the performance of using observables in my application really impacts my users, if I haven't slept or eaten something proper.

I can't be a good engineer, if I'm not a good human. I'm done shirking that notion or battering with it. Most software engineers make software for other humans to use, if we can't acknowledge the baseline humanity we possess and care for it, why are we making things for other humans? If we can't, we're no better than the amassing pile of La Croix and Red Bull cans in the recycling bins.

Originally published on charlespeters.net

Sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net.

Formik & React Testing Library and Screaming at a Computer for an Hour

charlie⚡ — Mon, 16 Dec 2019 01:37:38 +0000

I have loved using both Formik and React Testing Library. At this point in the React community, I consider these tools to be nice sensible defaults of projects of any real size.

This afternoon, I needed to write some unit tests for some components that I had to add to my project and they were horribly broken.

import * as React from 'react';
import '@testing-library/jest-dom/extend-expect';
import { Formik, Form, Field } from 'formik';
import { render, fireEvent, waitForElement } from '@testing-library/react';

describe('Very important form', () => {
  it('submits values and fires', async () => {
    const mock = jest.fn();
    const { getByText, getByTestId } = render(
      <Formik initialValues={{ name: '' }} onSubmit={mock}>
        <Form>
          <Field name="name" data-testid="Input" />
          <button type="submit">Submit</button>
        </Form>
      </Formik>
    );

    const input = await waitForElement(() => getByTestId('Input'));
    const button = await waitForElement(() => getByText('Submit'));

    fireEvent.change(input, {
      target: {
        value: 'Charles',
      },
    });

    fireEvent.click(button);

    expect(mock).toBeCalled();
    expect(mock.mock.calls[0][0].name).toBe('Charles');
  });
});

What I want to validate is that mock was called when the form submits and to see the results of onSubmit include the value I typed.

Identifying the Problem

⛔️ Jest's Cache

Normally, when I have tests like this don't pass, where everything looks good, I start to blame Jest itself. Jest has a pretty heavy caching system. This allows you to continually be watching test files and run them very quickly and its cache is a good thing. But occasionally (am empirically) that cache gives false positives and I have found that clearing this cache and re-running your tests can give you the validation that your tests are rightfully passing. You can do that by running:

jest --clearCache

And typically in your CI process (like Travis or GitHub Actions), you should include:

jest --no-cache

But running your tests locally on your machine, caching is a good thing.

And with the cache cleared, still broken.

⛔️ Maybe `act()`

React DOM's test utils package (react-dom/test-utils) has a utility called act() and React Testing Library has a wrapper around it too. act() (from what I understand) prepares a container to be updated by batching all updates like the way it would work in the browser. So things like updating the state or re-rendering components should be wrapped in act().

Anytime you're performing an async operation, it's helpful to wrap things in act() and it's covered in the FAQ section of React Testing Library.

Wrapping the events that update the component like this:

import { act, fireEvent } from '@testing-library/react';


act(() => {
  fireEvent.change(input, {
    target: {
      value: 'Charles',
    },
  });
});

act(() => {
  fireEvent.click(button);
});

Didn't help, still broken.

⛔️ User Error

At this point, I read through (perhaps too quickly) both Formik and React Testing Library's documentation sites and not finding anything that stood out about the tests I was writing being wrong or missing anything.

I read through all of the documentation from Jest on using jest.fn() mocks. And nothing. 😭

At this point, I was incredibly frustrated, I uttered every swear word at an array of volumes at my computer and even perhaps invented new swear words. I contemplated switching professions, I went for a walk around the office and drank a glass of water. 🤬

My tests were still broken. 😤

✅ A mysterious solution found buried in GitHub Issues

Then I searched for "React Testing Library" in the Issues section of the Formik repo and found this #1554. Since, Formik runs it's validations internally, async, then calls the onSubmit props, we need to await the results. React Testing Library gives us a utility for this it's called wait(). We need to wait to see if mock is called and to checkout the results.

The solution looks like this:


import * as React from 'react';
import '@testing-library/jest-dom/extend-expect';
import { Formik, Form, Field } from 'formik';
import { render, fireEvent, waitForElement, wait } from '@testing-library/react';

describe('Very important form', () => {
  it('submits values and fires', async () => {
    const mock = jest.fn();
    const { getByText, getByTestId } = render(
      <Formik initialValues={{ name: '' }} onSubmit={mock}>
        <Form>
          <Field name="name" data-testid="Input" />
          <button type="submit">Submit</button>
        </Form>
      </Formik>
    );

    const input = await waitForElement(() => getByTestId('Input'));
    const button = await waitForElement(() => getByText('Submit'));

    fireEvent.change(input, {
      target: {
        value: 'Charles',
      },
    });

    fireEvent.click(button);

    wait(() => {
      expect(mock).toBeCalled();
      expect(mock.mock.calls[0][0].name).toBe('Charles');
    });
  });
});

And now my tests are passing.

Conclusion

Feel your feelings. If your tests aren't passing with either of these libraries, see if using wait() or act() might help and swearing at your computer isn't the worst thing in the world but having a glass of water is also a good idea.

Sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net.

Learning TypeScript: Value of a Strongly Typed Projects 💪

charlie⚡ — Tue, 05 Nov 2019 22:06:48 +0000

One the first things you're going to encounter working with TypeScript is this idea that it's prohibitive or it's a lot of setup. I've been there. Then I remember this quote:

TypeScript shines not on day 1, but on on day 100, and becomes a freaking supernova on day 500. -- Jared Palmer

As you start working in a codebase you don't have a lot there. Then add some community types for the libraries you're using; that's one level of productivity, the libraries you're using are now showing where you're using their API wrongly, and that's sort of helpful on a level but we can do better.

Then you have more code and more requirements in your project and those types you're adding accrue by a magnitude. At this point your application has certain models or pieces of UI or concepts that you want to make discernible, like in a chat app you might have a type interface for the message and one for the thread of messages.

interface IMessage {
  content: string;
  attachments: IAttachment[];
  sender: IUser;
  dateSent: Date;
}

interface IThread {
  messages: IMessage[];
  isTyping: boolean;
  pollingInterval: number;
}

Now let's image the IMessage interface changes, your code to add a message or poll for new messages is likely to be broken because of that. Because you introducted this interface and can now see where your application was using, you can see with a small change the impact of that change. That to me this is one of the key values of using strong types and it's not one you see you day one, it's one you see when you're deep into a project and adding new features.

Strongly Typed?

You might've heard people throw around this term "strongly typed" (like I just did), a strongly typed project or a strongly typed language. When I first heard it, I wasn't quite sure what it meant. To answer that we need to define what a "weak" types are; weak types are type annotations that don't break compliation or in some way permissible where by contrast, strongly typed projects or languages fail compliation if a type error exists. Using TypeScript's "strict mode" can be a method for building a strongly typed project.

Anyway, if you're feeling the pain or the tedium of migrating to TypeScript or getting start with it, trust me from experience, it pays off, especially when you get to a point where you have to make bigger refactors in your project or need to build more features, from experience you can do that with my more confidence embracing a strong types in your project.

Wherever you are in your journey with TypeScript, sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net, I'm working on some resources to help.

Links 📝

These are some seriously cool things I encountered while I was working the last couple of weeks.

Formik 2 in Hooks: Formik, like React Router or is one of those tools you just grab when you're building a project of any real size. With the latest release, you can now ditch the Render Props pattern for hooks and components and I got the rare chance to role this out on a branch in my current sprint and I couldn't be happier with how much code I got rid and how much easier it was to work with.
Effective TypeScript: 62 Specific Ways to Improve Your TypeScript: I heard Dan Vanderkam speak at TSConf this year and I am ridiculously excited for the giant company that delivers things quickly to my house, to quickly deliver his book to my house.

Sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net.

Exponents: Learning to Grow

charlie⚡ — Fri, 01 Nov 2019 20:09:41 +0000

I wrote this last year and each one of these things are still something I do every day

I feel like I've been falling into front-end engineering roles for years. I'm mostly self-taught (and that story is detailed more here). Some concept or problem never quite clicked right, something I don't know how to describe well or even understand. I shrug it off, I get back to the job at hand, fervently googling, finding a good fix and moving on. Lately, I'm noticing I want to grow more deliberately versus as just a byproduct of my experience.

Don't get me wrong: practical experience is good. Top shelf; would recommend.

But I don't feel like I grew as an engineer as exponentially as I wanted to and I didn't know what to do other than getting a CS degree (which I didn't feel like investing time or money in). Or more succinctly, I plateaued on experience. So I started working with different senior engineers and seeking advice and cobbling together something of a curriculum.

This post is basically 5 quick behavior changes and shifts in thinking that have helped me grow more as an engineer in the last summer.

If you wanna save some time, watch this older talk "JavaScript Masterclass", by Angelina Fabbro from JSConf US 2013. I watch it pretty regularly and still learn a lot from it, every one of her points is still relevant 5 years later. Below are things I've been trying to do, most of those come from that talk.

1. Read the Source Code

Read the source code of the projects you use. I use React almost everyday, Next.js just as much. I spend time browsing these repositories a lot. I don't understand all the code I read; that's okay. Occasionally I learn something.

This process takes about 20 minutes, a few times a week of the projects you use. With Next.js I found settings that weren't well documented, I understood more about the way data-fetching works in that framework and more importantly made sense of work I was currently doing.

I feel like you'd get more diminishing returns on projects you don't use or care about. Like if I read Angular's source code, I wouldn't necessarily get any value from it, because I have never used it.

2. Spend Time in Another Language

JavaScript is my first programming language. I worked in PHP for a little bit, but primarily just JavaScript. But I get tunnel visioned since I know how to get things done without having to think too much about it. Spending time in another language, where that cursory knowledge doesn't exist, forces you to rethink why you're making the choices you're making.
Vacation in another language; ReasonML and Elixir are pretty damn cool and so is Python or C#.

Coming back to the work you do every day, knowing why the pipe operator exists in Elixir or why C# has namespaces or how immutability works in Python, has made me appreciate JavaScript more and want to see the overarching design patterns in programming.

3. Test — Let the Errors Guide You

This one feels like common sense. This is more of a shift in perspective. Errors used to piss me off, so, so much. I watched a preview for Ben Orenstein's Refactoring Rails course and one guiding principle was:

Write the code you wish you had. Let the errors guide you.

First, this makes me want to write more unit tests that are unit tests and not pinning tests; meaning that tests cover the objective versus the hyper specific implementation you have. Then, it gives me a different way to look at errors, instead of angry demands from a cold indifferent universe but as guide-posts towards code I want to have in my project.

Static analysis is often a great stop gap to testing and arguably can give you more immediate and relevant value than unit testing alone. I had to learn TypeScript when I started my current contract. The process of learning how to use TypeScript made me rethink how I want to write JavaScript to make sure my code is easier to read, share and annotate.

4. Learn Big O Notation

Big O is the runtime of an algorithm. It measures how long a piece of code will take to run, the input and how much memory they use. There are different types of algorithms: Constant, Linear, Quadratic, Logarithmic, Factorial. The more iteration, the longer your code needs to run.

To be honest, I don't understand this concept really well. My main take away was that arrays and for loops were not a great answer for everything. Sometimes Maps and Sets in JavaScript were better answers and led me to spend time reading and finding ways to implement them. But the awareness of other options makes a huge difference, in that you're less isolated with the wrong primitives.

If you want to read something about Data Structures and Big O read ‌Itsy Bitsy Data Structures, by Jamie Kyle. It makes these difficult concepts easier to understand.

https://medium.com/cesars-tech-insights/big-o-notation-javascript-25c79f50b19b

5. Try Vim

This is more of a bonus. Lately, I'm using a Vim mode inside VSCode because my team really loves the workflow with shared settings; I really miss terminal Vim.

But working in Vim makes you think about how you navigate around a file and how inefficiently you move. Vim uses an idea called "modal editing" which means you update text by switching in and out of modes. Normal Mode doesn't allow you to type, where Insert mode actually allows you to add code to your file. The common wisdom is that you don't live in Insert mode but you should normally be in Normal mode and this switch just causes me to be more deliberate about what I write. It's just a mental switch.

That's all I got so far. Small behavior changes and shifts in thinking. As always: YMMV.

Originally published on charlespeters.net

Sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net.

Learning TypeScript: Start By Adding Notes 👩‍💻

charlie⚡ — Tue, 22 Oct 2019 05:22:21 +0000

A lot of people I've talked to who are getting started with TypeScript have some sentiment that it feels more daunting than it might actually be or they don't know enough to get started. I can definitely empathize with both. There's a lot of misconceptions about how you have to write code or changing your code to fit into being typed or that there's a lot they need to learn to be efficient.

When I had to learn TypeScript, I just kept thinking that it was notes on the code I'm already writing, nothing is really changing, only adding "annotations" on top of the components I'm already writing.

Before:

class CustomComponent extends React.Component {
  static defaultProps = {
    type: "default"
  };

  state = {
    content: ""
  };

  updateContent = content => {
    this.setState({ content });
  };

  render() {
    return; // ...
  }
}

After with TypeScript:

interface Props {
  type: "default" | "error" | "warning";
}

interface State {
  content: string;
}

class CustomComponent extends React.Component<Props, State> {
  static defaultProps: Props = {
    type: "default"
  };

  readonly state: State = {
    content: ""
  };

  updateContent = (content: string): void => {
    this.setState({ content });
  };

  render(): JSX.Element {
    return; // ...
  }
}

The code I wrote didn't change at all while writing this, it only added small annotations as to what types, and what shape some objects are intended to be. There's really not a lot that you need to understand, primitive types for return values for each method, string and void (meaning returns a string or nothing, respectively), there's now an interface and that just shows what an object will look like and they're attached via this syntax with the <,> (they're called generics and they're not super important to getting started, you'll typically see them a lot when you're working with a framework). We also added a type for the parameter, (content: string), meaning the only value we can pass that method must be a string.

When you're getting started with TypeScript, my number one recommendation is to change your file type from .js to .ts or .tsx and don't amend the code you were going to write, just add annotations. Eventually you'll run into some errors, and when they do come up, let the errors guide you. But don't intentionally change your code.

You'll notice as you start doing this your application will start show patterns you may not have noticed, useful places you can breakout in to sharable patterns, you'll also start to notice that there's parameters you're not using or parts of objects you're not using.

TypeScript can do a lot for a project, big or small, but it doesn't take a lot to start feeling the value and reaping the benefits.

Writing code and documenting the type annotations can start to inform how you write code and write your type annotations. My experience has been after a few weeks, I was thinking about types before I started to write code and then wrote the code and saw where TypeScript was throwing errors and those became guides to what to work on next.

Wherever you are in your journey with TypeScript, sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net, I'm working on some resources to help.

Links 📝

These are some seriously cool things I encountered while I was working the last couple of weeks.

graphql-codegen: seriously, this tool saved so much of my time this week. If you use TypeScript or GraphQL this tool is pure MAGIC ✨. It not only autogenerated the interfaces from my schema but custom hooks 🎣 to match the queries and mutations.
Yehuda Katz on TypeScript 3.7 (a Twitter thread): "TS has also helped push JS forward. It's not only a mostly-compliant JS transpiler (e.g. class features), but it also does a really great job of adding type semantics to virtually all new features as quickly as possible (symbols in interfaces, generators, optional chaining)"
React Router v5.1: React Router now ships with hooks and I deleted so much code because of it. And there's nothing nicer.

Sign up for my newsletter, follow me on Twitter @charlespeters or find me at charlespeters.net.

DEV Community: charlie⚡

How to Make Your Code Reviews Awesome

A Self-Care Primer

A note about privilege and ableism

Back to Basics

Next Level

Next Next Level

Ever Upwards

What about making software?

Formik & React Testing Library and Screaming at a Computer for an Hour

Identifying the Problem

⛔️ Jest's Cache

⛔️ Maybe act()

⛔️ User Error

✅ A mysterious solution found buried in GitHub Issues

Conclusion

Learning TypeScript: Value of a Strongly Typed Projects 💪

Strongly Typed?

Links 📝

Exponents: Learning to Grow

1. Read the Source Code

2. Spend Time in Another Language

3. Test — Let the Errors Guide You

4. Learn Big O Notation

5. Try Vim

Learning TypeScript: Start By Adding Notes 👩‍💻

Links 📝

⛔️ Maybe `act()`