DEV Community: Jacque Schrag

Nevertheless, Jacque Coded, Even When She Wanted to Quit

Jacque Schrag — Sun, 07 Mar 2021 18:32:53 +0000

Like many other people, my 2020 did not turn out the way I had thought it would. In January, I spoke at a conference and had more speaking & writing gigs lined up. I was anticipating a new role at work. I was excited, and ready to keep growing!

By the time August hit, I was one breakdown away from quitting my job and permanently becoming a part of my couch.

I was depressed, miserable, stressed, burnt out...and embarrassed that I felt that way. Even with the perfectly valid reason of gestures at everything, I was ashamed of how I felt and frustrated by my inability to push through it so I could get back to doing the projects I enjoyed.

I didn’t publish a single new blog post in 2020, nor did I work on a single side project. But I did start seeing a therapist, and being more open with friends & colleagues about how I was feeling. The support & encouragement I’ve received has been amazing, and for now, that’s more than enough for me.

I still have days where I’d rather be a potato than a programmer. But I’m grateful for the creativity, joy, & delight that exist in this field, and want to continue to be a part of it even if I only have the energy to be a spectator.

In 2021, I will continue to code, but not at the expense of my well-being. And if that means less talks, blog posts, and side projects, then that’s okay with me.

Supported, Jacque Kept Coding

Jacque Schrag — Mon, 09 Mar 2020 03:29:49 +0000

Last year, I shared how supported I've generally felt in the tech community since I started being a more active participant in it.

I've continued to be supported this year in so many ways. I began writing about code online, and the reception by the Dev Community has been incredible. Writing those posts led to having more conversations and feeling more comfortable in sharing my own journey in becoming a better developer. Conversations online turned into speaking opportunities at meetups and conferences, with a few more to come.

I'm grateful that I've had so many positive experiences this year, and have been actively encouraged and supported by so many people. I look up to so many of you, especially my fellow lady devs, and promise to continue to support you as you've supported me while I keep coding, writing, and speaking. I could not have done it without all of you. 💚

Creating Pixel Art with CSS

Jacque Schrag — Wed, 12 Jun 2019 01:03:55 +0000

I have always enjoyed looking at and creating pixel art. Before online pixel makers were a thing, I used to spend hours making my own pixel art in Photoshop with the pencil tool. This article will show you how using CSS (and a tiny bit of HTML), you can use code to make your own pixel art creations.

The Power of `box-shadow`

While it is 100% possible to create pixel art by creating a bunch of <div>s and changing their background color, that's a lot of <div>s to keep track of and copy if you want to reuse your pixel in multiple places. I prefer to create pixel art with a single <div>, which we can do thanks to the box-shadow property.

box-shadow is commonly used to create a drop shadow effect behind an element, like in the example below.

How does that help us with creating the straight-edged pixel art? By removing the blur & spread parameters from the box-shadow definition, we can straighten out the sides of the shadow.

Next, we want to move the shadow so it is beside the block instead of being behind it. We can do this by adjusting the X- & Y-offset parameters according to the rules below.

X-offset:

Positive value moves right
Negative value moves left

Y-offset:

Positive value moves down
Negative value moves up

Shadows inherit their dimensions from the element they're applied to. To move the shadow to the right of the block, we need to set the X-offset to be the same as the width of the block: 20px. If we change the Y-offset to 0, the result looks like if we had two blocks sitting side-by-side.

It's starting to look like pixel art! But this only gives us two "pixels", and we're going to need a lot more than that. Thankfully, the box-shadow property isn't limited to just one effect. By separating our effects with a comma, we can create multiple pixel-looking shadows.

Now that we know how we can use box-shadow, it's time to start making a real piece of pixel art.

Creating a Pixel Cat

We're going to be creating a pixel version of Pusheen. If you're new to making pixel art, I recommend searching for existing art so you have a reference for where your pixels should be placed. I'm going to be recreating this version of pixel Pusheen.

It is made up of 414 pixels (23 columns x 18 rows). To help me easily identify the individual pixels, I've used Photoshop to overlay a grid on the reference image.

Although you could start drawing your pixel from anywhere, I'm going to start in the uppermost left corner so I don't have to worry about any negative offsets in my box-shadow effects.

I'm also going to use SASS instead of vanilla CSS to avoid writing 414 box-shadow declarations by hand. By utilizing a custom SASS function and lists, we can automate calculating the offset positions and make our code more DRY.

First, I’m going to make some modifications to our #cat block. Instead of applying the box-shadow to the block itself, I’m going to apply it to a pseudo element instead that is absolutely positioned relative to the block. Why? Because box-shadow doesn’t take up space, meaning if I were to put another element next to my cat block, it would sit on top of my shadows. If we make the size of the cat block the final size of our pixel art, we can avoid this problem, but we need the pseudo element to separately define the width/height of our pixels (remember, the size of the shadow is inherited from the element the box-shadow is applied to). This is what those changes look like:

#cat {
  position: relative;
  width: calc(23 * #{$size}); // Pixel size * # of columns
  height: calc(18 * #{$size}); // Pixel size * # of rows
  margin: 1rem;

  &::after {
    content: '';
    position: absolute;
    top: 0;
    left: 0;
    width: $size;
    height: $size;
    // box-shadow will be applied here
  }
}

Next, let’s set up some variables.

// The width/height of each of our "pixels".
$size: 20px;

// Colors
$t: transparent;
$black: #000;
$gray: #cdc9cf;
$dkgray: #a09da1;
$pink: #ffa6ed;

Now we’re going to create a list to track what color each pixel should be. Starting on the left, let’s create a list for the first row.

$first: ($t, $t, $t, $black, $t, $t, $t, $t, $black);

We could create new variables for each of the subsequent rows ($second, $third, etc.), but a better approach is to create a nested list, like so:

$cat: (
  ($t, $t, $t, $black, $t, $t, $t, $t, $black),// 1st Row
  ($t, $t, $black, $gray, $black, $t, $t, $t, $t, $black, $gray, $black)// 2nd Row
  // Additional rows
);

The nested list approach has the benefit of providing us with all the information we need to generate our box-shadow effect for each of the cell: the X/Y positions to calculate our offset and the color of the shadow. We'll access that information with a custom "pixelize" function.

Writing a SASS Function to Draw a Pixel

Our "pixelize" function is going to do the heavy-lifting of turning our list of colors into usable box-shadow definitions. I've provided line-by-line explanations of what this function does below.

@function pixelize($colors, $size) {
  $result: '';
  $numRows: length($colors);

  @for $rowIndex from 1 through $numRows {
    $y: ($rowIndex - 1);
    $row: nth($colors, $rowIndex);
    $numCols: length($row);

    @for $cellIndex from 1 through $numCols {
      $x: ($cellIndex - 1);
      $color: nth($row, $cellIndex);

      $sep: ', ';
      @if $x == 0 and $y == 0 {
        $sep: '';
      }

      $result: $result + '#{$sep}#{$x * $size} #{$y * $size} #{$color}'
    }
  }

  $result: unquote($result);
  @return $result;
}

Line 1: The function takes two arguments: the list of $colors and the $size that the pixels should be
Line 2: Initializes our $result variable as a string. This is the variable the function will modify and return.
Line 3: Returns the number of rows in the list using the built-in length function
Line 5: Starts a loop that iterates X times, where X is the number of rows in our list. The $rowIndex will increment by 1 on each loop.
Line 6: Calculates the Y-offset of all cells in that row. SASS Lists are index-1 (not index-0), so we subtract 1 from the current index so the 1st row has a Y-offset of 0, 2nd has Y-offset of 1, etc.
Lines 7 & 8: Returns the value of the current list item (the list of colors for the row) & calculates its length to determine the number of columns in the row
Line 10: Starts a loop to iterate over each column in the row
Line 11 & 12: Calculates the X-offset of that cell & returns the corresponding color
Lines 14-17: Sets the separator for the box-shadow effects, but removes it for the first cell to ensure a valid property value.
Line 19: Updates the $result value to its existing value plus the new cell:
- Separator
- X position * $size = X-offset
- Y position * $size = Y-offset
- Color
Line 23 & 24: $result is a string, so we use the unquote function to remove the containing quotes. Finally, return the result.

The Final Result

Put it all together, and here is our final Pusheen pixel!

Pretty neat! With a little refactoring, the use of CSS Variables, & a smidge of JavaScript, we could even allow users to select their own colors for their cats.

I hope this post has inspired you to make your own pixel art. Even if it hasn't, I hope you've learned how you can use the box-shadow property to create some neat effects in your projects. If you're interested in seeing more pixel art, including examples of how to animate them, check out "Fun Times with CSS Pixel Art" by Geoff Graham on CSS-Tricks.

What are your "must have" custom snippets for your editor/IDE?

Jacque Schrag — Wed, 24 Apr 2019 13:50:33 +0000

A custom snippet is a template that allows you to easily enter repeated code patterns. This Snippet Generator by Pawel Grzybek makes it easy to create your own for VS Code, Sublime, & Atom.

Refactoring the Worst Code I’ve Ever Written

Jacque Schrag — Thu, 18 Apr 2019 12:00:03 +0000

During the recent #DevDiscuss chat on "Developer Confessions", I confessed that I didn't really know what I was doing when I started my first dev job 3 years ago. To demonstrate my inexperience, I shared an example of the kind of code I was writing at the time.

// Detect dark theme var iframe = document.getElementById('tweet-1113248130600927232-723'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1113248130600927232&theme=dark" }

The response I received has been overwhelmingly positive. Most of us have written "bad"* code that we're not proud of, but it's a sign of growth when you can look back at that older code, recognize how it could be better, and maybe laugh at yourself for the choices you made. In the spirit of continuing to learn, I want to share some of the ways I might solve this problem today.

*Although this bit of code is silly and could have been written much more efficiently, hard-coding accomplishes the task it needed to just fine.

Context & Goals

Before refactoring any legacy code, it's critical to step-back and assess the context that the code was written in. There could be an important reason for the ~~madness~~ choices a developer made that were influenced by context that you might not be aware of (or remember, if it's your code). In my case, I was simply inexperienced, so this code can be safely refactored.

The code was written for two data visualizations: "Global Foreign Direct Investment Stocks" (in/out) and "China Bilateral Investment Outflows" (China). They have similar data & functionality, with the primary goal allowing the user to explore the datasets by filtering by type, year, or region. I'm going to focus on the global data, but the China dataset can be refactored in a similar way.

Let's assume that changing one of the filters will result in the below values being returned:

    let currentType = 'in' // or 'out'
    let currentYear = 2017
    let currentRegions = ['Africa', 'Americas', 'Asia', 'Europe', 'Oceania']

Note: The region checkboxes don't currently work this way, hence the "All" and "Partial" in the snippet, but this is how it should have been done.

Finally, here is a simplified example of the data itself after it's been loaded in from a CSV:

    const data = [
      { country: "Name", type: "in", value: 100, region: "Asia", year: 2000 },
      { country: "Name", type: "out", value: 200, region: "Asia", year: 2000 },
      ...
    ]
    // Total Items in Array: ~2,400

Option 1: Initializing Empty Objects

Beyond being hard-coded, my original snippet completely violates the Don't Repeat Yourself (DRY) approach to writing code. There are absolutely instances where repeating yourself makes sense, but in this case when the same properties are being repeated over and over again, it's a smarter choice to create the objects dynamically. Doing so also reduces the amount of manual work required when a new year is added to the dataset, and limits the opportunities for input error.

There are several different approaches to making this more DRY: for, .forEach, .reduce, etc. I'm going to use the .reduce Array method, because it processes an array and transforms it into something else (in our case, an object). We're going to use .reduce three times, once per categorization.

Let's start by declaring our categories as constants. In the future, we only need to add a new year to our years array. The code we're about to write will take care of the rest.

    const types = ['in', 'out']
    const years = [2000, 2005, 2010, 2015, 2016, 2017]
    const regions = ['Africa', 'Americas', 'Asia', 'Europe', 'Oceania']

Rather than thinking about this as types → years → regions, we want to reverse it and start with regions. Once regions is turned into an object, that object will be the value assigned to the years properties. The same is true for years in types as well. Note that it's possible to write this in fewer lines of code, but I'm opting for clarity over cleverness.

    const types = ['in', 'out']
    const years = [2000, 2005, 2010, 2015, 2016, 2017]
    const regions = ['Africa', 'Americas', 'Asia', 'Europe', 'Oceania']

    /*
      Convert regions to an object with each region as a property and 
      the region's value as an empty array.
    */
    const regionsObj = regions.reduce((acc, region) => {
      acc[region] = []
      return acc
    }, {}) // The initial value of the accumulator (`acc`) is set to `{}`. 

    console.log(regionsObj)
    // {Africa: [], Americas: [], Asia: [], Europe: [], Oceania: []}

Now that we have our regions object, we can do something similar for the years and types. But instead of setting their values to an empty array like we did for the regions, we set their values to the previous category's object.

Edit: It was brought to my attention that the original code snippet didn't actually work once you attempted to load data into it because I was merely referencing an existing object instead of instantiating a new one. The below snippet has been updated to fix this problem by creating a deep copy of the existing object. An explanation is available in this article on "How to differentiate between deep and shallow copies in JavaScript" by Lukas Gisder-Dubé.

    function copyObj(obj) {
      return JSON.parse(JSON.stringify(obj))
    }

    /* 
      Do the same thing with the years, but set the value 
      for each year to the regions object.
    */
    const yearsObj = years.reduce((acc, year) => {
        acc[year] = copyObj(regionsObj)
      return acc
    }, {})

    // One more time for the type. This will return our final object.
    const dataset = types.reduce((acc, type) => {
      acc[type] = copyObj(yearsObj)
      return acc
    }, {})

    console.log(dataset)
    // {
    //  in: {2000: {Africa: [], Americas: [],...}, ...},
    //  out: {2000: {Africa: [], Americas: [], ...}, ...}
    // }

We now have the same result as my original snippet, but have successfully refactored the existing code snippet to be more readable and maintainable! No more copying and pasting when it comes to adding a new year to the dataset!

But here's the thing: this method still requires somebody to manually update the year list. And if we're going to be loading data into the object anyway, there's no reason to separately initialize an empty object. The next two refactoring options remove my original code snippet completely and demonstrate how we can use the data directly.

Aside: Honestly, if I had tried to code this 3 years ago, I probably would have done 3 nested for loops and been happy with the result. But nested loops can have significant negative performance impacts. This method focuses on each layer of categorization separately, eliminating extraneous looping and improving performance. Edit: Check out this comment for an example of what this method would look like and a discussion on performance.

Option 2: Filtering Directly

Some of you are probably wondering why we're even bothering with grouping our data by category. Based on our data structure, we could use .filter to return the data we need based on the currentType, currentYear, and currentRegion, like so:

    /*
      `.filter` will create a new array with all elements that return true
      if they are of the `currentType` and `currentYear`

      `.includes` returns true or false based on if `currentRegions`
      includes the entry's region
    */
    let currentData = data.filter(d => d.type === currentType && 
    d.year === currentYear && currentRegion.includes(d.region))

While this one-liner works great, I wouldn't recommend using it in our case for two reasons:

Every time the user makes a selection, this method will run. Depending on the size of that dataset (remember, it grows every year), there could be a negative impact on performance. Modern browsers are efficient and the performance hit might be minuscule, but if we already know that the user can only select 1 type and 1 year at a time, we can be proactive about improving performance by grouping the data from the beginning.
This option doesn't give us a list of the available types, years, or regions. If we have those lists, we can use them to dynamically generate the selection UI instead of manually creating (and updating) it.

Yep, I hard-coded the selectors too. Every time we add a new year, I have to remember to update both the JS and the HTML.

Option 3: Data Driven Objects

We can combine aspects of the first and second options to refactor the code in a third way. The goal is to not have to change the code at all when updating the dataset, but determine the categories from the data itself.

Again, there are multiple technical ways to achieve this, but I'm going to stick with .reduce because we're going to transform our array of data into an object.

    const dataset = data.reduce((acc, curr) => {
        /*
          If the current type exists as a property of our accumulator,
          set it equal to itself. Otherwise, set it equal to an empty object.
        */
        acc[curr.type] = acc[curr.type] || {}
        // Treat the year layer the same way
        acc[curr.type][curr.year] = acc[curr.type][curr.year] || []
        acc[curr.type][curr.year].push(curr)
        return acc
    }, {})

Note that I've eliminated the region layer of categorization from my dataset object. Because unlike type and year, multiple regions can be selected at once in any combination. This makes pre-grouping into regions virtually useless since we have to merge them together anyway.

With that in mind, here is the updated one-liner to get the currentData based on the selected type, year, and regions. Since we're limiting the lookup to data with the current type and year, we know that the maximum number of items in array is the number of countries (less than 200), making this far more efficient than option #2's implementation of .filter.

    let currentData = dataset[currentType][currentYear].filter(d => currentRegions.includes(d.region))

The last step is getting the array of the different types, years, and regions. For that, I like to use .map and Sets. Below is an example of how to get an array that contains all the unique regions in the data.

    /*
      `.map` will extract the specified object property 
      value (eg. regions) into a new array
    */
    let regions = data.map(d => d.region)

    /*
        By definition, a value in a Set must be unique.
        Duplicate values are excluded. 
    */
    regions = new Set(regions)

    // Array.from creates a new array from the Set
    regions = Array.from(regions)

    // One-line version
    regions = Array.from(new Set(data.map(d => d.region)))

    // or using the spread operator
    regions = [...new Set(data.map(d => d.region))]

Repeat for type & year to create those arrays. You can then create the filtering UI dynamically based on the array values.

Final Refactored Code

Putting it all together, we end up with code that is future-proofed to changes in the dataset. No manual updates required!

    // Unique Types, Years, and Regions
    const types = Array.from(new Set(data.map(d => d.type)))
    const years = Array.from(new Set(data.map(d => d.year)))
    const regions = Array.from(new Set(data.map(d => d.region)))

    // Group data according to type and year
    const dataset = data.reduce((acc, curr) => {
        acc[curr.type] = acc[curr.type] || {}
        acc[curr.type][curr.year] = acc[curr.type][curr.year] || []
        acc[curr.type][curr.year].push(curr)
        return acc
    }, {})

    // Update current dataset based on selection
    let currentData = dataset[currentType][currentYear].filter(d => currentRegions.includes(d.region))

Final Thoughts

Cleaning up syntax is only a small part of refactoring, but often "refactoring code" really means reconceptualizing the implementation or relationship between different pieces. Refactoring is hard because there are several ways to solve problems. Once you've figured out a solution that works, it can be hard to think of different ones. Determining which solution is better is not always obvious, and can vary based on the code context and frankly, personal preference.

My advice to getting better at refactoring is simple: read more code. If you're on a team, actively participate in code reviews. If you're asked to refactor something, ask why and try to understand how others approach problems. If you're working alone (as I was when I first started), pay attention when different solutions are offered to the same question and seek out guides on best code practices. I highly recommend reading BaseCode by Jason McCreary. It's an excellent field guide to writing less complex and more readable code, and covers a lot of real world examples.

Most importantly, accept that you're going to write bad code sometimes and going through the process of refactoring - making it better - is a sign of growth and should be celebrated.

Supported, Jacque Coded

Jacque Schrag — Fri, 08 Mar 2019 21:49:06 +0000

There are so many people sharing their stories today about the harassment they've received and the doubt (both self and externally generated) they have about being in the field. In spite of it all, they continue to do incredible things and persevere.

Today, I am reminded that my experience as a woman in tech has been different than others.

My development team is made up 3 women (myself included).

My entire team is made up of 15 people. 13 of them, including most of the leadership are women.

My online interactions have largely been positive. I do not receive unsolicited comments on my appearance. My expertise or position on a technical topic has rarely been questioned or dismissed because of my gender.

But I've seen the harassment and abuse that the women in my community endure on a regular basis. I've heard their stories of being isolated or overlooked in professional settings. I've seen them be questioned about those experiences, and disregarded because "there's no way that happens" to women.

Those experiences are very, very real. I wish my experience was the norm, and that more women were truly supported by their colleagues and their communities.

So I will continue to code in 2019 because...

I want to make the larger tech community more like my own. Continuing to code and actively engaging with all of the wonderful content produced by other women is the best way I know how to do that. I will continue to offer support and encouragement to them, because I am totally inspired by them on a daily basis. I'm so grateful that they continue to be a part of the community and produce amazing content we can all learn from, even when their experiences are sometimes impossibly difficult.

I hope to see the tech community...

Help me make my experience the norm, so all women can feel as supported as I have felt in this field. So all women can continue to grow and learn and make mistakes without fear of being targeted and held back because of their gender.

10 Lessons Learned Conducting Code Reviews

Jacque Schrag — Wed, 06 Mar 2019 14:36:14 +0000

Last fall, my development team grew from 1 person (me) to 3. Proper pull requests and code reviews all of a sudden became critically important to ensure we had a cohesive codebase after multiple developers from wildly different backgrounds had worked on it.

As the Lead Developer on the team, I was the primary person responsible for conducting these reviews. Having never done this before, there was a lot for me to learn about making these reviews effective. Here are #10 tips and lessons learned from my experience doing code reviews over the past several months.

1. Always Start with a Positive

Sometimes, there’s a lot wrong with a PR: the right elements weren't used, the implemented design doesn't match the mockups, the logic doesn't make sense, etc. As a reviewer, your job is to look for these kind of mistakes and point them out to be corrected, and it can be easy to only focus on those negatives.

But nobody intentionally makes mistakes, so having those mistakes pointed out publicly can be a negative, uncomfortable experience. Writing out all those mistakes isn't fun for the reviewer either. To set a positive tone, I've learned to always start my reviews with gratitude and something I thought they did well. Even if there are a lot of issues with the code that need to be addressed, it's important to thank the person for their contribution. Code with mistakes is better than no code at all, so thank them for taking a first pass at resolving the issue.

If code isn't mentioned in a review, it is generally assumed to be good, but being active with your praise goes a long way. It builds confidence and makes people more receptive to feedback because they know you've spent time thoroughly checking their code. If their logic for X wasn't so great, but they did Y and Z well, let them know!

2. It's not "you", it's "the code"

If you've ever learned about conflict resolution, you've probably learned the importance of "I" statements. Using phrases like "I think...", "I feel..." instead of "You did..." can go a long way in resolving tension and shifting the focus from an individual to the problem itself.

The same approach should be applied to code reviews. When offering criticism, it's important to avoid the word "you". It's already difficult to accept criticism of your work, so don't make it harder by making the person feel like it's them who are wrong. For example, switching

Your logic on line #25 isn't clear.

The logic on line #25 isn't clear to me.

changes the tone of the comment completely. And I know which one I'd rather read when it's my code being reviewed.

3. Use Line Item Suggestions

My team uses GitHub for most of our projects, and one of my favorite features is the ability to post a comment about a specific line of code. It takes away a lot of the hassle and potential confusion that comes from writing out the specific file/line number in a larger comment. If most of your comments are single changes, this can help make a simple checklist of fixes that need to be made.

Bonus: GitHub has line item suggestions. Check out @_darrenburns "8 Productivity Tips for GitHub" for details.

If you use a different platform that doesn't offer this feature, then I highly recommend including/linking to the specific line numbers when writing your review. It might be more work for you as the reviewer, but it will help ensure those necessary changes aren't overlooked.

4. Set Project Standards Early & Tools to Help Review

We all learn how and prefer to write code differently. When I was the sole developer, I never had to worry about things like code style, naming conventions, or other project standards because however I did it was the "right" way. I realized very, very quickly when I started to review other people's code that not everyone had the same internal standards as me and that not only led to confusion in the codebase, but required a bunch of extra mental energy for me to review.

The lesson learned here is simple: set your project standards early.

Whatever those standards are, it's important that the whole team is on board with them and knows what is expected. And you need them for everything: languages being used, branch naming conventions, project organization, comment conventions, etc.

Aside: This process made me realize I had strong opinions about CSS property order, so I made a point to address that in our discussion.

Whether you develop your own standards in-house or use one of the many existing standards out there is up to you, but it's critically important that you do if you want to have any semblance of a cohesive codebase at the end of a project.

Tools to Help Review

Once you have your project standards, it's worth spending the time to set up the tools that are designed specifically to help enforce those standards. You can use a Linter to analyze your code and compare it against a set of guidelines for syntax-related standards. It will flag any errors, or can possibly even fix them for you automatically.

To catch any errors that make it into the PR (although ideally, they're caught and dealt with locally first), we've set up TravisCI to run additional checks. So if the Travis build is failing when I go to review, it gives me a place to start before diving deeper.

5. Start Broad & then Dig Into Details

There can be a lot of code in a single pull request, so in terms of actually doing the code review, I like to start broadly and work my way into the nitty-gritty. For me, that process usually looks like this:

Are there any failing tests? If yes, why are they failing?
Are there any extra files included in the PR that shouldn't be there?
Can I checkout the branch without any errors?
Was any relevant documentation updated to reflect the changes?
Were new packages or dependencies added to the project? If yes, why were they added? Are they needed?
Is the HTML valid, semantic, and accessible?
Does the CSS follow the project standards? Are all viewport widths accounted for in the implementation? What about cross-browser compatibility?
Does the JavaScript follow the project standards? Is it modular? Is it easy to follow the logic? Are edge cases accounted for? Are there stray logs in the console?

If there are a lot of issues in the first few steps, I usually end my review there and wait for those issues to be addressed before digging into the denser part of the code.

6. Establish Dedicated Review Time

This has been one of the hardest lessons for me to learn, and is something that I still actively struggle with. Doing a thorough and productive code review takes time. Even if the PR is small, it still (usually) requires checking out the branch, checking the logic, reviewing the issue, etc. When you have other competing priorities, it can be tempting to ignore that pull request or do the bare minimum when reviewing, but that isn't a good long-term solution.

My solution to this was fairly straightforward: I have a dedicated time when I do reviews. I block it on my calendar and my team knows when those times are so they know when to expect feedback. Setting expectations for your team and yourself is key.

7. Establish What You're Expecting

Do you link your pull requests to issues? Require a certain format when submitting a pull request? Have a limit to how many lines of code should be included in a single request?

If you answered yes to any of these questions, then it's important to establish those expectations up front. It saves you time as the reviewer and helps prevent your team from having to guess what it is that you're looking for. Take the time to talk to your team and figure out what works best for all of you because...

8. Everyone Reviews

On our team, everyone has the opportunity to do code reviews and everyone has their code reviewed. As the senior developer on the team, my pull requests are reviewed by the two other members before they can be merged. I do this because:

My code has mistakes and often can be improved, and
It creates space for the more junior devs to ask questions about how/why I implemented something the way that I did.

I'm a big-believer in that the best way to learn how to code well is to read well-written code, so even if there is nothing to change, it allows them to read good code examples that are relevant to the project they are working on. We frequently have good conversations about implementation in our code reviews, and it's made me more confident in my decisions when I'm able to answer questions about them.

9. Reevaluate Often

Conducting code reviews has been one big learning process for me and for our team. We've made a lot of changes along the way based on our experience. It's important to carve out time to reflect on this aspect of the project; I usually do it as a part of a broader post-mortem on a project which helps solidify code reviews as a critical part of the development process.

Ask what worked well and what doesn't, and be honest with the answers! Ask your team members what kind of feedback they found helpful or identify areas where the critique can be improved. Consider how much time you spent doing reviews and identify any patterns from it. If you were frequently commenting on the same types of issues, are there steps you can take to address it so there are less of those issues on the next project? Reflecting on these types of questions and making changes will improve the review process for everyone on the team.

10. There's more than One Solution

This one is hard. Really hard. When you are the reviewer, it can be so tempting to start refactoring the submitter's code to reflect how you would have done it. What starts out as a simple refactor can very easily turn into redoing the entire section of code to your "right" solution. But that isn't the purpose of a code review.

It's a fine line, to be sure. Sometimes the code does genuinely need to be reimagined and fully rewritten, but that should not be happening frequently. If it does, then a better approach would be to pair program before the code review stage.

But just because it isn't how you would have approached and solved the problem, doesn't mean it isn't good. When you open a pull request and start the review, you need to check your ego at the door and be open minded to considering new solutions. Use it as an opportunity to learn, not show off how smart you think you are.

Bonus: @maxwell_dev wrote a brilliant post on "It's Not About You" that addresses this.

It's been a journey learning all of this, and I'm grateful to my team for their continued patience while I've figured it out. In the nature of continued learning and reevaluating often (#9!), what are some of your tips for conducting code reviews?

How do you keep track of what you're reading?

Jacque Schrag — Wed, 18 Jul 2018 14:08:43 +0000

One of my New Year's resolutions was to try and take better notes on the various articles and books that I read related to development. I'm one of those people that needs to write things down if I'm going to remember it later. With so much helpful content being written on a regular basis, it can get overwhelming keeping track of what I've read and what the key points I want to remember were.

My current solution is to use Boostnote as a note taking app. Every day, I create a new note and post the links and my summaries of the articles for that day, tagged according to the topics.

How do you keep track of what you've read? Tools, methods, etc.?

Nevertheless, Jacque Schrag Coded

Jacque Schrag — Fri, 02 Mar 2018 21:25:36 +0000

I began to code because...

when I was in elementary school, my dad went back to school so he could become a web developer. For Christmas that year, he gave me his HTML4 reference book when I started asking questions about how he was making websites. I started reading and never looked back. Although it has always been a passion hobby of mine, coding did not become something I considered doing professionally until graduate school when I realized that there was a serious need in the policy sphere for web development. I've been fortunate enough to be able to create a position for myself where I can work on topics I care about and build cool web projects.

I recently overcame...

shyness about sharing my work and participating in development communities. Imposter syndrome is incredibly real and has been a frustrating aspect of getting into this career. I hope to be a more active member of the communities I'm in and not just lurk on the sidelines.

I want to brag about...

the team I work on. We're an award-winning creative agency inside of a think tank and are producing some really cool stuff. We're also (almost) an entirely women team, which is a rarity in both the tech and think tank spheres. I love coming to work and feeling inspired everyday by the work my colleagues do and it gives me courage to keep working even when the feeling of imposter syndrome becomes overwhelming.

My advice for allies to support women who code is....

be vocal about your support and be vulnerable about the things you struggle with. Knowing that there is somebody else out there who feels just as lost when they look at the state of the JavaScript ecosystem (seriously though - I finally got a handle on Webpack 3) can mean everything when you're questioning whether or not you have the skills to make it in the field.