
<figure style="display: block; margin: 20px auto; max-width: 500px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/monster-money.png" alt="frankenstein's bride as the face of a dollar bill">
    <figcaption>Source: <a href="https://www.marketwatch.com/story/i-got-engaged-to-a-money-monster-2019-03-28">marketwatch.com</a></figcaption>
</figure>

Once loved by agile teams, the daily stand-up meeting has really been taking heat the last couple of years. Given the commotion from outside teams, we decided to examine our own daily stand-up ritual. Was it still serving us? Or had we become trapped in a monotonous SCRUM cycle, unable to see time-wasting, zombifying “Blah Blah Blah. No blockers. Done” before our very eyes? Spooky. Before I get into my team’s experience, I’ll dive into what stand-up is and identify some of the common complaints. Then I’ll give some tips on resurrecting a stand-up that has lost its luster.

## What Is Stand-Up?

The daily stand-up, a.k.a. scrum meeting, is a brief meeting performed by agile teams. It typically involves physically standing up and having each team member answer three questions: What did you do yesterday? What do you plan to do today? What are any “blockers” you are experiencing or you foresee that could impede your ability to meet your goals? The focus of these meetings is productivity and efficiency, and they typically last 15 minutes or less.

## Why So Much Hate?

Stand-up sounds simple, clean, and brief, so why has it received so much bad press lately? Many argue that the daily stand-up is outdated, and some agile teams have abandoned the practice altogether. This is my summation of common complaints:

1. **Meetings drag on too long.** Though stand-up meetings are intended to be brief, in practice, they can last long past 15 minutes, as sub-teams discuss in-depth details, some over-sharing team members wax on about irrelevant information, and teams’ sizes grow beyond 10 or so members. Time spent in these lengthy meetings disrupts the workflow and keeps you from doing your important tasks.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/scrum.png" alt="meme of Doctor Evil-I booked a meeting room for our two hour SCRUM">
    <figcaption>Source: <a href="https://devrant.com/search?term=standups">devrant.com</a></figcaption>
</figure>

2. **It feels like a pointless waste of time.** On the flipside of the over-sharers are the under-sharers. Some team members are so brief during stand-up to the point of irrelevance—”Yesterday, I did stuff. Today, I will also do stuff. Done!” The exchanges during stand-up no longer mean anything to the rest of the team, and while brief, the stand-up does nothing to improve productivity.
<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/once-again.png" alt="meme of Robert Downey Jr. rolling eyes.-Daily standup once again">
</figure>

3. **It’s a challenge to get an entire team prepared and in one place at the same time to do an efficient stand-up.** Some teams waste additional time standing around waiting for everyone to get up and join the meeting. And among the over-sharers and under-sharers are the under-preparers, who forgot what they did yesterday and aren’t sure what they’ll do today, but darn it, we’ll wait for them to figure it out so they can answer their three questions because that’s what it says in the scrum manifesto.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/waiting.png" alt="meme of Mr. Bean waiting.-waiting for dev team to join stand-up">
</figure>

## Our Thoughts on Stand-Up

Given the complaints addressed above, it’s not surprising to see popular headlines like “Stop the daily stand-up meeting” or “the daily stand-up is an anti-pattern.” During retrospective, we decided to float the idea of retiring our stand-up—not with the intention of actually dismantling the daily ritual, but more as a thought experiment. What would life be like without stand-up? What would we miss? What would we gain?

One by one, we gave our thoughts on stand-up. And from the majority, the sentiment was mostly positive. Here are the highlights of our favorite aspects of stand-up.

### Information Sharing

Beyond answering the “three golden questions of stand-up,” the brief meeting is also a time when tidbits of general knowledge are shared among team members. In our stand-up, it’s common to hear, “Yesterday, I learned this,” or “I started trying this new tool or practice.” These pieces of information might have otherwise trickled throughout the team in Slack chatter or over lunch, but stand-up is a nice time to share quick tips, when the whole team is present and listening. Some might argue that this is anti-pattern, but for us, this type of sharing helps stand-up be more human, keeps us more engaged, and adds more value beyond the basic function of stand-up.

### Onboarding New Members

Stand-up is especially helpful for onboarding new team members. As we all go around the room and discuss our accomplishments from yesterday and goals for today, it gives new members an inside look at other projects and provides some context for what others are working on. As we routinely share our day-to-day, new members quickly become integrated into the team. Right now, we’re hosting junior developer interns from a local code school, Epicodus. When they join our stand-up, they are able to see an abridged version of a day in the life of a software developer and how more senior software developers solve complex problems. This simple daily interaction adds an immense amount of value to their internship experience.

### Celebrating & Venting

We use stand-up as a time to sing the highs and lows of software development. It’s important to celebrate wins, and stand-up is a great time to celebrate as a team before the little wins from yesterday fade into memory. Similarly, stand-up is a valid space to vent about problems as they arise. Sharing sentiments daily, in a group setting, makes sure that issues get addressed quickly, rather than having to wait for the next retrospective (which is when we more formally celebrate wins and discuss problems). Though we try to avoid taking time during stand-up to discuss solutions to these problems, bringing them up can be cathartic, and individuals or sub-teams can organize to formulate solutions outside of the stand-up if necessary.

### Routine

Among the other benefits listed above, one of my favorite aspects of stand-up is its routine nature. You can always count on stand-up. It’s the ritual start of the day, though work and planning usually begin a little before stand-up. When preparing for stand-up, I have to be intentional and organized about how I plan my day and reflect on my goals and results from yesterday. Without this kind of organization and reflection, each day would seem like the same endless stream of completing tickets, nebulous and monotonous. But with stand-up, I focus on what made yesterday unique and how today will build on those results.

Though we mainly had positive remarks about stand-up, we also brought up some room for improvement. Some team members pointed out that it can be easy to space out when someone starts talking about granular details that aren’t helpful or interesting to others. Additionally, using project-specific jargon (such as specific Jira issue numbers) prevents other team members from understanding the full context of what is being discussed and therefore has less value.This feedback gave us an opportunity to hone our stand-up skills as a team, trim the parts that aren’t helpful, and focus on things that are.

## Tips for Making the Most out of Stand-Up

### Time Limits

A key part of a successful stand-up is maintaining its brevity. For our 8 person team, 10-15 minutes is the sweet spot. Depending on the size of your team and the nature of your work, yours might be longer or shorter. Find the right time limit that works for you, and practice hitting it. The scrum manager can help enforce the time in the beginning, but eventually, it will start feeling more natural. Physically standing up (if you’re physically able to) is one trick to keeping stand-up brief. Psychologically, standing up can encourage us to be more focused and to the point. When we sit around together, it’s more natural to start chit-chatting and extend the length of what should be a very brief meeting.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/time-limit.png" alt="meme of Samuel L. Jackson holding a gun-Go over the time limit, I dare you">
</figure>

### Create a Routine

Maintaining a solid stand-up practice requires creating a routine that everyone can and will stick to. If time is wasted on a daily basis, waiting around for someone to join, it defeats the purpose of the efficiency and productivity focus of the stand-up. Some form of mutual understanding (or maybe even enforcement) will be necessary in the beginning to encourage team members to join the meeting in a timely manner.

It’s also important to select a time that works well for everyone. Without this, a routine will be difficult to adopt. For example, we have our stand-up at 10:15 a.m. every morning. For us, a 9:30 a.m. stand-up wouldn’t work because some of us have early morning meetings, kids to drop off at school, or unpredictable commutes. Other teams might find it better to do their stand-up at 8 a.m. or 12 p.m. Try out different times, calibrate a time that works well for your team, and encourage everyone to build a routine around it.

Having a back-up plan is also essential. In a perfect world, we would all be present at 10:15 a.m. on the dot every single morning. That’s the goal, but reality works differently. Thankfully, we have a contingency plan. If anyone is running late or not going to be present, they announce this as early as possible, so we can decide to either start without them, have them join virtually, or push stand-up back if necessary. Your back-up plan might look different than ours, but it’s important to have one to minimize any breakups to the routine.

### Use the Right Tools

Choosing the right tools can help streamline your stand-up routine. I use [Shoutbase](https://www.shoutbase.com/), a convenient time tracking app, which helps with stand-up in three key ways. First, (you guessed it) Shoutbase keeps track of how much time my team spends on stand-up. Each day, we're able to see how long stand-up takes and evaluate if we met our benchmark. We can also get a report to see how our stand-up has progressed over time. Second, I use the description field of Shoutbase time records to capture details about what I'm working on. The next morning, I have a catalog of what I did the day before, so I can easily give a report during stand-up. Third, Shoutbase allows teams to set goals for the day, week, month, or year. It's easy to see if our stand-up goals have been met or exceeded, and it gives us data to bring up during retrospective if necessary. I like using tools that can multitask, and Shoutbase is definitely one of them. Other tools, such as [Notion](https://www.notion.so) and [Trello](https://trello.com), are great for keeping track of progress on tasks, and you can always use a classic stopwatch to time your stand-up.

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/multitask.jpg" alt="meme multitasking like a pro">
</figure>

### Clearly Define Goals & Standards

The basic function of stand-up is clear: communicate your goals for today, progress from yesterday, and forthcoming blockers. But as discussed earlier, stand-up can be more than that. Our goals also include: sharing useful tips, celebrating wins, highlighting problems, expressing feelings, and facilitating cross-project cooperation. We have a running document defining the goals of stand-up and also the basic standards of procedure, so everyone is on the same page. If you don’t have a document like this, I encourage you to create one to keep your stand-up running smoothly.

### Iterate & Improve

Defining goals and procedural standards doesn’t mean your stand-up practices are set in stone. In fact, you should routinely interrogate your practice and make sure it’s still serving your team. Bringing up stand-up during a team retrospective like we did is an excellent way to get everyone's input. Work together to create a stand-up that optimizes the way your team discusses and meets goals.

## Conclusion

Some teams huddle around the campfire and whisper horror stories about a monstrous waste of time...stand-up! Not us. Over the years, we’ve fine-tuned our stand-up routine to serve us. Focusing on brevity as well as meaningfulness will help you make the most out of stand-up. Next time you do stand-up, think twice about responding with a zombie answer. Try to provide something of value to the rest of the team and most importantly, don’t ghost!

<figure style="display: block; margin: 20px auto; max-width: 400px;">
    <img  style="width: 100%;" src="/assets/blog/2019-09-30-stand-up/standup-zombie.png" alt="zombie meme">
</figure>


Daily Stand-Up: Productivity Asset or Monstrous Waste of Time?


<img src="/assets/blog/2019-08-30-graph-hacking/cover-image.jpg" alt="photo by William Iven on Unsplash" style="max-width: 100%;">

Recently, I was assigned to a project where we needed to build a graph with some pretty lofty specs.
[D3](https://d3js.org/) is often considered the best graphing library for frontend developers, but on a cursory glance, the documentation was a bit unclear and seemed denser than I had time to parse, given the scope and timeframe allotted. I shopped around for other graphing libraries and came across [Recharts](http://recharts.org/en-US/), a React-specific graphing library built on top of D3 that had been used more frequently and had a better rating than [Nivo](https://nivo.rocks/), [Victory](https://formidable.com/open-source/victory/), or [react-vis](https://uber.github.io/react-vis/).

While I know good documentation for D3 exists and there are widespread use cases of it in the wild, Recharts piqued my interest. The website for it was snappy and clean, the documentation seemed pretty robust, there were a good number of customizable props, and it followed the same pattern of importing components and giving them prop values, which would reduce the amount of time I’d have to spend bootstrapping. So Recharts was the winner.

## The Project

The client for this project gave us the following specs:

- The graph is a bar chart that can display both positive and negative values with the domain limited to -2000 to +2000.
- Bars with positive values should be blue, and bars with negative values should be red.
- Bars should be selectable.
- When a bar is selected, it is a slightly darker color, and a tooltip should appear over it, which displays the bar’s value.
- If a bar’s value exceeds -2000 or +2000, it remains capped at that height and has a perpetually visible label displaying its actual value.
- Bars with large values in either the positive or negative direction are a more vibrant blue or red than unselected or selected color.
- The graph will continually grow to the right, so its container will scroll once it reaches a certain length.

- The app that utilizes this graph is primarily for use on a tablet through a web browser.
- The Y-axis should remain static while you're scrolling through the X-axis.
- The label for the data point counts up incrementally by 1.
- When the userId changes, i.e. the result is recorded by User B rather than User A, the label for the series starts back at 1 and counts up from there.

And this is what the graph ended up looking like:

<img src="/assets/blog/2019-08-30-graph-hacking/static-graph.png" alt="Screenshot of a graph with red negative bars and blue positive bars">

## The Limitations of Recharts

While using this library to fulfill the requirements, I ran into a few roadblocks:

- The built in `<Tooltip />` component for Recharts only works on hover, which isn’t feasible for a tablet.
- While you can specify a domain for your graph, the graph does not truncate bar values to fall within the domain. That is to say, if the maximum of the domain was 2000, and the value of a given data point was 2500, the positive side of the axis would automatically scale to 2500.
- The conditional color of the bars could not be handled simply in the component. It required a pure function to calculate the color for the fill of the object.
- Many of the customizable props aren’t documented with examples in Recharts. The solutions I came up with to meet the specs were based on reading the Github Issues for the library’s repository, or looking at third-party examples on CodePen and jsFiddle.
- The Y-axis component has no "static" property. If you scroll along the X-axis, the Y-axis will eventually scroll out of view

## So How Did I Do It?

**Transforming the data**

In a perfect world, the data from the backend would come in exactly the correct shape to be easily consumed by Recharts graph, but alas, it did not. The data started like this:

```typescript
interface ResultShape {
  readonly resultId: string
  readonly userId: string
  readonly score: number
}

const results = [
  {
    resultId: "22f0-23as9-9adf-98sfd",
    userId: "user1",
    score: 1000,
  },
  {
    resultId: "18q0-23as3-9adq-98sq",
    userId: "user1",
    score: -200,
  },
  {
    resultId: "9748-2737-1747-7759",
    userId: "user2",
    score: 1500,
  },
]
```

And using this function:

```typescript
interface Coordinate {
  readonly label: string
  readonly value: number
}

export const convertTablesResultsToGraph = (
  results: ReadonlyArray<ResultShape>,
): ReadonlyArray<Coordinate> => {
  // create an ordered sort array of userIds
  const userIds = results.map((r) => r.userId)
  const sortOrderOfUserIds = [...new Set([...userIds])]
  // make a basemap of all results by userId
  const basemap = results.reduce(
    (acc, next): BaseMap<ReadonlyArray<Coordinate>> => {
      const id = next.userId
      const contents = !!acc[id] ? [...acc[id], next] : [next]

      const toReturn = {
        ...acc,
        [id]: contents,
      }

      return toReturn
    },
    {},
  )

  // convert this to an array of arrays.
  const basemaps: ReadonlyArray<ReadonlyArray<ResultShape>> =
    sortOrderOfUserIds.map((id) => basemap[id])
  const coordinates: ReadonlyArray<Coordinate> = basemaps
    .map((rounds) => {
      const cc: ReadonlyArray<Coordinate> = rounds.map((item, i) => {
        const { score } = item

        return {
          label: `${i + 1}`,
          value: score,
        }
      })
      return cc
    })
    .reduce((acc, next) => acc.concat(next), [])
  return coordinates
}
```

It became this:

```typescript
const coordinates = [
  { label: "1", value: 2500 },
  { label: "2", value: 100 },
  { label: "3", value: -1200 },
  { label: "4", value: -4000 },
  { label: "5", value: 1500 },
]
```

**Selecting a bar**

Browsing the examples in the Recharts documentation, I came across [this jsFiddle](https://jsfiddle.net/alidingling/7has60ua/), which demonstrated to me that you can use the component’s local state to track the index of the selected bar. It ended up looking like this:

```typescript
interface ResultGraphState {
    readonly selectedIndex: number | null
}

...
constructor(props: ResultGraphProps) {
    super(props)

    this.state: ResultGraphState = {
        selectedIndex: null
    }
}

...
```

It also demonstrated a way to make the fill of the bar change color conditionally, using the `<Cell />` component. In the example, they use a ternary, but in my case, I needed a function which could output six different colors.

Note: we keep all of our colors in an `appColors` object as hexcode strings.

```typescript
export const colorSelector = (
  value: number,
  trueValue: number,
  index: number,
  selectedIndex: number | null,
): string => {
  if (trueValue >= 2000) {
    return appColors.modalPositiveLargeValue
  }
  if (trueValue <= -2000) {
    return appColors.modalNegativeLargeValue
  }
  if (index !== selectedIndex) {
    return value > 0
      ? appColors.modalPositiveGraphValue
      : appColors.modalNegativeGraphValue
  }

  return value > 0
    ? appColors.modalPositiveGraphValueSelected
    : appColors.modalNegativeGraphValueSelected
}
```

I spun up the click functionality for toggling the selection of the bar in a class method and passed it into the `<Bar />` component as shown in the jsFiddle.

**Creating and rendering a custom tooltip**

The first thing I needed for this part was a custom tooltip, which I built using styled-components and this [CSS generator](https://leaverou.github.io/bubbly/) as a resource for giving the tooltip its signature pointy bit.

```css
const CustomTooltip = styled.div`
    display: flex;
    justify-content: center;
    align-items: center;
    ${({ isPositive }: DisplayProps) => !isPositive && "margin-top: 10px;"}

    .tooltip-body {
        width: 100%;
        position: relative;
        background: ${appColors.tableDataOverviewBackground};
        border: 1px solid ${appColors.tableLabelText};
        text-align: center;
        padding: 1px 3px;
        border-radius: 2px;

        &:after {
            content: "";
            position: absolute;
            left: 50%;
            width: 0;
            height: 0;
            border: 10px solid transparent;
            margin-left: -10px;
            ${({ isPositive }: DisplayProps) =>
                isPositive
                    ? `bottom: 0;
            border-top-color: ${appColors.tableLabelText};
            border-bottom: 0;
            margin-bottom: -10px;`
                    : `top: 0;
            border-bottom-color: ${appColors.tableLabelText};
            border-top: 0;
            margin-top: -10px;`}
        }

        p {
            font-size: 0.75em;
            color: ${appColors.tableLabelText};
            margin: 0;
            align-self: center;
        }
    }
`
```

I probably could have used the [blueprintjs](https://blueprintjs.com/) library for the tooltip component, but I ended up making my own to ensure that it would be lightweight and not contain any additional animations or properties I didn't need. The app was already calculating a data transform on a large swath of data, and keeping the graph performant was a key part of the feature.

Originally, I tossed the tooltip inside of the `<Bar>` component tags and found out the hard way that you can’t just shoehorn a non-Recharts component as a child to a Recharts component, especially given that the whole Recharts graph is actually an SVG. I tried to find a premade tooltip SVG that was free to use, but didn't see anything that really matched the mockups or seemed easy to implement.

Upon digging through the documentation, I came across the `<LabelList />`component, which thankfully can take a React element as a content prop, and even came with [another handy jsFiddle](https://jsfiddle.net/alidingling/a5Leskck/).

This jsFiddle shows that the function that creates the customized label receives props from the parent `<LabelList />` component, which contains the x and y coordinates of where the bar sits relative to the SVG, the width and height of the bar, and the data’s value. From there, I could place the tooltip and feed it the correct data.

The only problem was trying to render the div. It wasn’t showing up, but I knew that _something_ was being rendered based on what was happening in the Chrome dev tools tab. So I started looking into an element called `<foreignObject>`, which through some magic allows HTML to be nested inside an SVG tag. I added conditional rendering for selected vs. non-selected index with my selectedIndex from state, fed the component, and ended up with this:

<img src="/assets/blog/2019-08-30-graph-hacking/tooltip.gif" alt="gif of the graph being clicked on which prompts a tooltip to appear">

**Rendering the true value of a truncated bar**

Initially, I was stumped by this problem, until I remembered that the graph coordinate objects didn't have to just be an "X" and "Y" value. The coordinate could any shape that I needed it to be, as long as I specified the `dataKey` prop in the library components.

I ended up updating the coordinate shape from this:

```typescript
interface Coordinate {
  readonly label: string
  readonly value: number
}
```

to this:

```typescript
interface Coordinate {
  readonly label: string
  readonly displayedValue: number
  readonly trueValue: number
}
```

and updated my data transform utility like so:

```typescript
export const convertTablesResultsToGraph = (
    results: ReadonlyArray<ResultShape>,
): ReadonlyArray<Coordinate> => {
    ...

    const coordinates: ReadonlyArray<Coordinate> = basemaps
        .map(rounds => {
            const cc: ReadonlyArray<Coordinate> = rounds.map(
                (item, i) => {
                    const { score } = item

                    const isLargeValue = isValueTooLarge(
                        score,
                        2000,
                    )
                    const displayedValue = calculateDisplayValue(
                        score,
                        isLargeValue,
                        2000,
                    )

                    return {
                        label: `${i + 1}`,
                        displayedValue,
                        trueValue: score,
                    }
                },
            )
            return cc
        })
        .reduce((acc, next) => acc.concat(next), [])
    return coordinates
}
...
```

Using the updated data transformation utility, I was able to write an additional `<LabelList>` component to track the "true" value of the coordinate while maintaining its height at the very maximum of the graph's domain, which ended up looking like this:

<img src="/assets/blog/2019-08-30-graph-hacking/final-graph.gif" alt="moving image of the graph scrolling to the right and opening up tooltips" style="max-width: 100%">

**Creating a static Y Axis**

I will be the first to admit that this is the hackiest part of the whole process. But it performs well, and it looks pretty good, if I do say so myself.

I opened the modal containing my graph, opened the dev tools, and straight up copy-pasted the whole `<g>` group of lines that made up the Y-axis, the Y-axis labels, and all of the ticks into a new functional component, which looked something like this (with the bulk of it omitted because visual clutter):

```typescript
export const CustomYAxis = (): JSX.Element => {
  return (
    <div className="y-axis-wrapper">
      <SVG width="56" height="360" viewBox="5 0 56 420">
        <g className="recharts-layer recharts-cartesian-axis recharts-yAxis yAxis">
          ...
        </g>
      </SVG>
    </div>
  )
}
```

The SVG props for width, height, and viewBox were copied from the whole Recharts graph, and then modified to trim as much whitespace as possible. In order to maintain the same sizing and scale, I didn't delete the original `<YAxis>` from the graph. I just gave it the property `hide={true}`.

The whole render method for the graph ended up looking like this:

```typescript
return (
  <div className="graph-wrapper">
    <CustomYAxis />
    <BarChart {...props}>...</BarChart>
  </div>
)
```

and the CSS (styled from the parent component) looked like this:

```css
> div > .graph-wrapper {
  display: flex;
  flex-direction: row;
  padding-top: 1em;
  max-height: 435px;
  overflow-x: scroll;
  overflow-y: hidden;

  > .y-axis-wrapper {
    background: white;
    position: sticky;
    left: 0;
    z-index: 1003;
  }
}
```

The result?

<iframe src="https://codesandbox.io/embed/headless-rgb-8xstw?fontsize=14" title="recharts-hacking" allow="geolocation; microphone; camera; midi; vr; accelerometer; gyroscope; payment; ambient-light-sensor; encrypted-media" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

## Conclusion

In general, I'd say that while Recharts lacked a lot of features I needed to fulfill the specs of my project, it's still a good entry-level graphing library. The animations are super smooth (though I turned them off to prevent any potential lag), and there are a lot of component props to customize the graph that I'd be interested in exploring in future projects.

The most important, and the most fun part, was getting the chance to flex my problem-solving skills. I enjoyed having the opportunity to come up with ways around the limitations I encountered, and I hope that the documentation of my process helps other people running into problems with Recharts or helps the devs improve the library in the next version.

Anything I missed in my analysis or could've done better? Feel free to reach out in the comments!


A Practical Guide to Hacking the Recharts Library 


Over the past year, [Olio Apps](https://www.olioapps.com/) has made a commitment to changing our company culture around working remotely. We’d seen other teams enjoy success by going fully or partially remote, but for us, working outside the office felt like an inconvenience. We wanted to change that, and we knew that we had the technology to make it a reality.

Because of the nature of our industry, most of the issues with remote working are easily solved through proper planning, team management, and tools. And for a team like ours, the benefits greatly outweigh any drawbacks.

<img src="/assets/blog/2019-07-30-remote-working/group.png" style="display: block; max-width: 100%;" alt="a collection of photos of people working remotely">

## Benefits of Remote Working

Providing the option to work remotely has a number of benefits. Here are a few that have stood out to us over the past year.

### Fewer Sick Days

For most of us, it’s hard to justify taking off an entire day of work because we woke up with a scratchy throat or stuffy nose, but for the health of the team, staying home on days like this should be a no-brainer. Allowing employees to work from home while they are well enough to work but potentially contagious means fewer sick days taken and less germ spreading to your team members and their families. It goes without saying that a healthy team is a productive one.

### Improved Communication and Organization

When remote working becomes a regular part of company culture, communication hiccups start to diminish. It may seem inconvenient at first, but once you adjust and refine your process, remote working can be just as natural as in-office working and can even improve communication and organization across the board. Because you don’t have a coworker sitting next to you who you can turn to and ask, “Hey, where’s that file? What time is the meeting?” centralizing information and keeping projects more organized becomes a higher priority.

After ramping up our remote working routine, we created “face pages” for all of our projects that included project overviews, contact information, links to tech designs, meeting times, etc. to centralize project information. We made a greater effort to create calendar events with Zoom chat links to all of our meetings. We also set up routine, cross-team check-in times to report our statuses, which alleviated some stress for our project managers and kept projects moving in the right direction. These tweaks improved our remote working as well as our overall workflow.

### Attracting and Maintaining Diverse Talent

A major argument for any company to make remote work available is that it allows teams to hire diverse talent who might not be able to relocate or regularly commute. It also allows teams like ours to accommodate the changing lives of our current employees as their families grow, they buy homes outside of the city center, or their spouses accept jobs elsewhere. This year, we were able to add a fully remote project manager to our team, which previously wouldn’t have been possible.

### Overall Developer Happiness

Being able to work from home means different things to different employees, but the bottom line is: having the option makes us happier. Knowing I have the option to work from my couch or my favorite coffee shop gives me peace of mind, even if I don’t take the opportunity. Having the flexibility to work remotely makes midday doctors’ appointments easier, alleviates the number of long commutes each week, and allows us to spend more time with our pets or families.

<img src="/assets/blog/2019-07-30-remote-working/home.jpg" style="display: block; max-width: 100%;" alt="woman working from home">

## How We Became a Remote-Friendly Company

We took an “easing-in” approach to integrating remote working into our company culture. We started by working remotely one day a week. This required us to set up an online meeting space using [Zoom](https://zoom.us/) or our daily scrum standup, become more familiar with VS Code [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare), and set up a Slackbot reminder for regular check-ins to keep the whole team up to date on our individual progress.

For the first few weeks, preparing for remote day required ample planning, but it wasn’t long before it became a natural part of the routine.

After we became comfortable with working remotely once a week, we added another remote day, working remotely every Tuesday and Thursday. During our team’s weekly retrospective, we discussed pain points and ways to improve our remote days and made the appropriate adjustments the following week.

Right now, we’ve decided to keep Mondays and Fridays as in-real-life as possible to efficiently facilitate our weekly planning meeting, retrospective, and one-on-ones. It’s also nice to maintain the face-to-face social relationships in our workplace. Some of us choose to come in on work-from-home days anyway to get a change of scenery from our home offices or have in-person pair programming or working sessions.

A goal to strive for when transitioning into a semi-remote team is to try to make sure anyone working remotely has the same quality of experience as the in-office team members. Nobody should feel like they are less able to participate because of their remote working status. Pain points like poor audio quality during remote meetings or people being unresponsive in chat channels will reveal themselves early on. Thankfully, as problem-solvers by nature, a team of software engineers (or other technically minded or creative people) can usually find a solution.

One of the most impactful changes that we made to accommodate regular remote working included always having a Zoom number set up for every standup or meeting, so it’s ready and available for anyone who isn’t physically present. We also purchased a quality table microphone, so remote meeting attendees can easily hear all of the conversations in the room.

With the help of this technology and some tweaks to our organization, remote working has become second nature, and special circumstances that were previously burdensome—such as inclement weather, emergencies, or extended vacations—are simply taken in stride.

## Coding on Different Continents

While writing this blog post, I’m on a two week vacation in Europe. Thanks to the efforts of my team to be more remote-friendly, I’m able to stay in touch, keep my project moving forward, and conserve some of my PTO while abroad. Working while thousands of miles and nine time zones away from the office has had its own set of challenges, so I wanted to share my experience and some tips that might help you in a similar situation.

<img src="/assets/blog/2019-07-30-remote-working/plane.jpg" style="display: block; max-width: 100%;" alt="view out an airplane window">

### Preparation and Planning

Weeks before the trip began, we started planning what the team and I would be working on while I was traveling. Some compromises had to be made to make sure my workload was appropriate for working remotely in a situation where I wouldn’t necessarily be able to communicate with the team in real time or have reliable access to the internet. For the feature I was working on, a thorough tech design was completed and agreed upon before I left, so there would be no need for high-level questions while I worked from various planes, trains, and automobiles.

### Communication

Communication is key in situations like this. Even though I wasn’t able to join the team’s daily scrum standup, I did my own standup in Slack every time I checked in to do work. I reported what I had completed during the last working session, what I planned to do next, and any blockers I had (thankfully, none so far, due to good planning). My team was good about providing clear feedback via Slack and Github as prompt as they could, considering the time difference.

### Time Tracking with Shoutbase

[Shoutbase](https://www.shoutbase.com/) is a time tracking tool that I use to record and report my work time to my team. It definitely came in handy for this trip. During my two weeks abroad, I planned to work a total of three business days. But these “three days” looked nothing like my usual 9-5. My work time was chopped up between several stints during train, bus, and plane rides, and some relaxed morning and evenings at cafes and Airbnbs. The short stints allowed me to get work done while still maintaining happy vacation vibes.

Shoutbase made it easy for me to communicate how much time I had worked during my remote sessions, so there was no confusion about how much time I had left to complete my tasks or where I was at in terms of meeting my goals. It also made it easy for me to see my team’s progress while I was away, and I could conveniently track my own progress to make sure I hit my benchmark (without going too far over).

### Expecting the Unexpected

Especially when traveling abroad, something unexpected is bound to happen. One major factor is your access to the internet. I experienced a traveling developer’s worst nightmare: the wifi was down on both of my nine hour international flights. Thanks to some mindful planning (and some Netflix downloads), I was still able to stay productive. As stated earlier, technical designing beforehand will keep you from relying on Google and Stack Overflow or your distant team members. If you anticipate this issue and your project requires data from a remote source, creating a mock API to supply fake data ahead of time can be really helpful. And if regular connection to the internet is a necessity, consider getting a mobile data plan for your laptop, rather than relying on wifi.

### Create a Time Buffer

Don’t plan for every available “downtime” moment to be a remote working hour. I was previously considering doing a lot more remote work during my trip to be conservative with my vacation time, and I’m glad I didn’t. There will be unexpected times when you won’t be able to work effectively because the bus will be too cramped to pull out your laptop, your external battery will die, you might hit an unexpected blocker, or you’ll simply need a break. The buffer will alleviate the stress of working remotely and keep you from worrying about work while you’re vacationing.

<figure>
<img src="/assets/blog/2019-07-30-remote-working/prague.jpg" style="display: block; max-width: 100%;" alt="Stormi in Prague">
<figcaption>Gratuitous photo of me in Prague</figcaption>
<figure/>

## Conclusion

Remote working isn’t for everyone, but having the option to work remotely can open you or your company up to new possibilities. It might seem like a burden at first, but once you employ the right technology and practices, the benefits will become abundantly obvious. If you have any questions about making remote working a reality in your workplace, please reach out to your friends at Olio Apps.


Going Remote: Entering New Territory as a Company and a Developer

Prototyping vs. Production Development: How to Avoid Creating a Monster


I spent the weekend making a technical design and implementing it to challenge myself and evaluate a few different unfamiliar libraries. I've read a lot of positive reviews of Storybook, so I figured creating a small project would be a good way to evaluate. Driven by my interest in Nivo, a charting library, I thought an easy bit of data to visualize would be my [TreeHouse profile points](https://teamtreehouse.com/jonathanwalz).

The React Suspense API and react-fetching-library were technologies that have piqued my interest lately, so I included these intentionally. I’m rather happy with the result other than having to create my own node server to get around a Treehouse server issue (or rather an issue with the client library. More on that later).

I first created a technical design to plan out the broad, architectural pieces needed for the app. The process involved researching what would be needed from the newer and unfamiliar technologies and formulating a procedure for implementing them.

Then, I executed my plan and took note of my opinions regarding the unfamiliar technologies and the hiccups along the way.

### The result

<iframe src="https://codesandbox.io/embed/github/jonwalz/treehouse_chart/tree/master/?fontsize=14&hidenavigation=1&view=preview" title="treehouse-chart" style="width:100%; height:500px; border:0; border-radius: 4px; overflow:hidden;" sandbox="allow-modals allow-forms allow-popups allow-scripts allow-same-origin"></iframe>

### Self-Chart Technical Design

## High Level Design

### Chosen Technologies

- [React](https://reactjs.org)
- [TypeScript](https://www.typescriptlang.org/)
- [React-fetching-library](https://github.com/marcin-piela/react-fetching-library) - newer fetch client for react
- [Jest](https://jestjs.io/)
- [Nivo](https://nivo.rocks) (Charting library)
- [Storybook](https://storybook.js.org/)
- [Postman](https://www.getpostman.com/)

### High level Todo items

- Bootstrap a development cycle by creating a storybook version of components needed in this project.
- Create UI layer with React.
- Define tests, components, client, and data transformation.
- Create client for fetching needed data.
- Create data transformation utility for UI consumption.

No state management library is needed for this simple example. Though no other library is really needed either for something this simple. I just want to learn about them.

## Low Level Design

### Setup

1. Use create-react-app with typescript to get up and running.
2. Start a git repo.
3. Deploy on codesandbox to show the world.

### Storybook

Dependencies:

```bash
  yarn add
  yarn add -D typescript
  yarn add -D awesome-typescript-loader
  yarn add -D @types/storybook__react
```

1. Create a `.storybook` directory and add `config.js` file
2. Create storybook script in your build system
   - In our case, this is npm.
     - In `package.json` write script `"storybook": "start-storybook -p 6006 -c .storybook`
3. Configure the storybook config file with the following script:

   ```javascript
   import { configure } from "@storybook/react"

   // This will iterate through src
   // looking for any extension that matches stories.ts

   const req = require.context("../src", true, /stories.ts$/)

   function loadStories() {
     req.keys().forEach((file) => req(file))
   }

   configure(loadStories, module)
   ```

4. For Storybook to work with TypeScript, create a custom webpack config inside at

   `.storybook/webpack.config.js`

   ```javascript
   module.exports = ({ config }) => {
     config.module.rules.push({
       test: /\.(ts|tsx)$/,
       use: [
         {
           loader: require.resolve("awesome-typescript-loader"),
         },
       ],
     })
     config.resolve.extensions.push(".ts", ".tsx")
     return config
   }
   ```

5. Create tsconfig

`.storybook/tsconfig.json`

```json
{
  "compilerOptions": {
    "outDir": "build/lib",
    "module": "commonjs",
    "target": "es5",
    "lib": ["es5", "es6", "es7", "es2017", "dom"],
    "sourceMap": true,
    "allowJs": false,
    "jsx": "react",
    "moduleResolution": "node",
    "rootDirs": ["src", "stories"],
    "baseUrl": "src",
    "forceConsistentCasingInFileNames": true,
    "noImplicitReturns": true,
    "noImplicitThis": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "suppressImplicitAnyIndexErrors": true,
    "noUnusedLocals": true,
    "declaration": true,
    "allowSyntheticDefaultImports": true,
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "build", "scripts"]
}
```

### PieChart Component

1. Create a chart component under `src/components` named `PieChart.ts`

   ```javascript
    import * as React from "react"

    const PieChart = () => {
    	return ...
    }
   ```

2. Import the pie chart component from `@nive/pie`

   ```javascript
   import { ResponsivePie } from "@nivo/pie"
   ```

3. Use the component within the PieChart component we created
4. Create a chart component under `src/components` named `PieChart.tsx`

   ```jsx
    import * as React from "react"
    import { ResponsivePie } from '@nivo/pie'

    const PieChart = () => {
    	return (
    		<ResponsivePie
    			...
    		/>
    	)
    }
   ```

5. Define data to be used in pie chart

   ```jsx
    import * as React from "react"
    import { ResponsivePie } from '@nivo/pie'

    /*
    	Required props are: { data }

    	Parent element is required to have width and height
    	when using responsive chart components

    	data type is Array<{
           id:    string | number,
           value: number
    	}>
    */

    const PieChart = (data) => {
    	return (
    		<ResponsivePie
    			...
    			data={data}
    		/>
    	)
    }
   ```

### Storybook Component Setup

1. Create an `pie_chart.stories.tsx` file next to the `PieChart.tsx` component file

   ```jsx
   import * as React from "react"

   import { storiesOf } from "@storybook/react"
   import { PieChart } from "./PieChart"

   /*
    	Stories are to demonstrate the capabilities of a component
    	In this instance, we will need to supply data to the pie chart
    */

   storiesOf("PieChart", module).add(
     "Demonstrate simple data passed to chart",
     () => {
       ;<PieChart data={{ exampleData }} />
     },
   )
   ```

> To run storybook : `npm run storybook`

### Client

Dependencies:

    yarn add react-fetching-library

1. Create the directory `src/client`
2. Create the file `api.ts`

   and setup to use library:

   ```javascript
   import { createClient } from "react-fetching-library"

   // Often the host endpoint would be hidden in evironment variables
   const HOST = "HOST ENDPOINT HERE"

   export const requestHostInterceptor =
     (host) => (client) => async (action) => {
       return {
         ...action,
         endpoint: `${host}${action.endpoint}`,
       }
     }

   export const Client = createClient({
     requestInterceptors: [requestHostInterceptor(HOST)],
   })
   ```

3. Create the query action in

`src/client/actions/fetchData.ts`

```javascript
export const fetchData = {
  method: "GET",
  endpoint: "/",
}
```

4. Create the client provider component and suspense wrapper

   `src/index.ts`

   ```jsx
    	...
    import { ClientContextProvider } from 'react-fetching-library';
    import { Client } from './api/Client';

    const App = () => {
      return (
        <ClientContextProvider client={Client}>
   		<Suspense fallback={<ProgressSpinner />}>
   			{// Whatever children need the client>}
   		</Suspense>
        </ClientContextProvider>
      );
    };
    ...
   ```

5. Create container component for chart component to handle the query for data

   `src/components/chart_container.tsx`

   ```jsx
    ...
    import { useQuery } from 'react-fetching-library';
    import { fetchData } from '../client/actions'

    export const ChartContainer = () => {
    	const { loading, payload, error, query } = useQuery(fetchData)

    	if (error) return <ErrorButton onClick={query}/>
    	// Will add some data transformation step here

    	return <PieChart data={transformedData} />
    }
   ```

### Data transformation Utility

- The incoming data from Treehouse is not the correct shape and we need to transform it into a usable shape for the UI

1. Create the directory `src/util`
2. Inside that directory, create the file `fetchData_util.ts`
3. Create a function in the file that takes json data of this shape:

   ```javascript
    {
    	"name": "Beavis"
    	"points": {
    		"total": 12345,
    		"javascript": 2345,
    		"ruby": 0,
    		...
    	}
    }
   ```

   and produces data of this shape:

   ```javascript
    [
      {
        "id": "javascript",
        "label": "javascript",
        "value": 2345,
      },
    	...
    ]
   ```

   Removing the "total" and any data with the value of 0

4. Use this utility function within the component that fetches the data

   ```jsx
   import { useQuery } from "react-fetching-library"
   import { fetchData } from "../client/actions"

   export const ChartContainer = () => {
     const { loading, payload, error, query } = useQuery(fetchData)

     if (error) return <ErrorButton onClick={query} />

     const transformedData = transformData(payload)

     return <PieChart data={transformedData} />
   }
   ```

5. Create the directory `tests`
6. Create the file `tests/fetchData_test.js`
7. Write some tests considering all possibilities for the utility function

   ```javascript
   describe("Confirm transformData", () => {
     test("Should remove key of total from remote data")
     test("Should remove objects with value of 0")
   })
   ```

### Spinner

1. Create the spinner component under the `components` directory
2. Should be a simple emoji animated to spin with css animations
3. Use as the suspense fallback

**Retrospective**

There were a few surprises when implementing this. Some were in Storybook while getting it set up. After following the documentation rather than a tutorial, I got it to work properly.

The other more frustrating surprise was that the client library I used makes an OPTIONS request with every GET request and the Treehouse server was not playing along. I would receive a 500 error on the OPTIONS request, then never get to a successful GET request. By using Postman, I could confirm a GET would work fine without the OPTIONS request. The client library didn't have a way to configure the fetch to drop the OPTIONS request so I ended up creating a node server to be a proxy to the data. The node server made the same GET request, then passed it along to my app. 3 hours later, problem solved.

**Conclusions**

#### **StoryBook**

Storybook seems like an awesome tool to help guide the design of components. I see a cost in learning how to use it and the time spent in designing a component. One could easily burn hours designing a single component. I enjoy Storybook's workflow of isolating a component and its influence on making decisions of a components API. I look forward to learning more about this tool.

#### **React-fetching-library**

This library is newer (2 months old as of writing this!) but I have really good feelings about it already. The docs are well written and very helpful. The composability is great from my perspective. After they work out a few kinks, it could be a great tool for componentized fetch requests.

#### **Nivo**

I chose Nivo for charting mostly because their site is pretty. The documentation is really great as well. This being the first time using it, I thought it was rather easy to get started and figure out how to plug it into my project. A lot of the styling of charts is handled for you, and some may consider that a plus or a minus, but most of it is customizable. It's no D3 ;) but being the react nerd that I am, I found it to be quite an easy and visually pleasing way to jumpstart charts in my project. I look forward to using this library in the future.

### **Tech designs**

As mentioned, part of this weekend activity was to practice technical designs. Our principal engineer wrote a post on the [importance of technical design](https://www.olioapps.com/blog/technical-design/) that goes more in-depth on its value. After using this approach for my weekend hacking extravaganza, I saw how it definitely kept my head out of the details of the code and focused on the bigger picture. After getting together a "template" to follow, implementing the code went rather quickly, then much of the time was spent debugging smaller problems.

This project was admittedly an overuse of libraries and tools, but I now have a functioning template to create charts using React, Nivo, and Storybook.

### TL;DR

- Storybook seems great for large projects that have many reused components.
- Nivo makes very pretty charts. Great documentation. Understandable API.
- React-fetching-library has great composability. It is young but has great potential.
- Creating a technical design greatly increases the speed of development and reveals the difficult parts sooner.

**Repos can be found here:**

[Treehouse Chart](https://github.com/jonwalz/treehouse_chart)

[Treehouse Profile Server](https://github.com/jonwalz/treehouse_profile_server)


Practicing Tech Design with React, Storybook, and Nivo


Wellness or well-being is the state of being comfortable, healthy, or happy. This state of well-being can exist in one's life as a whole, as well as in each arena of a person's life, eg. they have a state of well-being in their social life, their home life, their emotional life, and their work life as say, a software developer.

In many cases, there can be very strong correlations between a person's level of well-being and personal satisfaction of their tasks during their working hours and their productive output. Naturally, we want both personal satisfaction and output to be high, and so we would do well to find ways to improve both, and reap the benefits.

<figure>
  <img src="/assets/blog/2019-05-15-developer-wellness/matcha.jpg" style="display: block; max-width: 100%;" alt="Matcha latte and laptop">
  <figcaption>Photo by Jason Leung on Unsplash</figcaption>
</figure>

## How Developer Wellness Differs From General Personal Wellness

As developer wellness is a subset of personal wellness, it centers especially around the health and robustness of your presence in your job and career. However, the two cannot be completely separated as each feeds the other.

They are essentially the same thing, perhaps with different scopes of interest. How you do one thing is most likely how you do everything else in your life. Although we can talk about the points of well-being in a developer capacity, they correlate strongly to very similar points in your life as a whole.

## What A Healthy State of Developer Wellness Could Look Like

For each person who works as a software developer, the doings of a healthy state of well-being will appear to be different, but will most likely contain most of the same themes and even very similar practices.

The positive consequences of maintaining a healthy state of well-being as a developer are many, and include benefits at work as well as outside work.

### At Work

- healthier relationships with coworkers, managers, and clients.
- more enjoyment of the mental challenges inherent in a developer role.
- a healthy workspace setup, conducive to minimized distractions both on-desk and online.
- an openness to learning and practicing effective techniques to engage more fully on the task at hand and combat mental fuzziness while problem solving.
- a healthier relationship with writing code, and receiving criticism and feedback from others in a healthy and robust way.
- an increased ability to positively influence others helping create an overall healthier and more resilient team of developers, and a firm and solid base for a company or development department to thrive.

### Outside of Work

- an increased enjoyment of non-code related activities.
- an increased ability to "turn off" the work mind, and "tune in" to the moment.
- an increased ability to bring the same level of mental engagement to personal pursuits and hobbies - for example practicing a martial art, or a foreign language, or a musical instrument.
- an increased enjoyment of deliberate omission of screens from certain times and activities in your day to day life.
- an increased ability to be fully engaged with social relationships outside of work and/or within a home, or other social environments.

### The Benefits of a Pursuit of Personal Wellness, as a Developer

As developers, we often take pride in our strong powers of reason and logic, and rightfully so! It is the material of our craft! You can make some amazing improvements and significant changes in your life and career if you can approach the issues you see with a detached and experimental mindset, and come up with possible solutions to the pain points that you find, building on what works in small increments.

## Habits and Practices That Foster Developer Wellness

There are three things that cross into all subsets of wellness and cannot be omitted in the pursuit of wellness within any scopes: **DIET**, **EXERCISE**, and **SLEEP**.

### Diet

There are a myriad of considerations with diet, and for this reason I will leave you only with very general guidelines, if possible:

- Stay well hydrated. Make sure to drink enough water for your body.
- Try to eat more whole foods, and less heavily processed foods.
- Snacks are fine, but be mindful of those times when you're filling a dull moment with excessive sugar/salt/coffee consumption.

### Exercise

Exercise is often looked down upon, as a chore that _should_ be done, but many times isn't. This is not a healthy attitude, and must be addressed.

- If you feel that you are at level 0 in exercise in your life, all that that means is that you can only go up from here. Instead of a snack break, how about an mid-afternoon exercise break? Even a short brisk walk around a few city blocks counts. Afterwards, you will feel more alert and ready to tackle the rest of the afternoon!
- If you stick to some kind of exercise program already and/or go the the gym or participate in some other physical activity, keep it up!
- At the very least, get up from your desk and stretch in whatever ways feel best for your body. Long periods of physical inactivity do not feel great for the body, and are not especially good for you, either.

### Sleep

Sleep is another big piece of the puzzle that many want to downplay. However, this is not a good idea. The effects of not getting enough sleep will creep up on you. Different people require different amounts of sleep, but some general guidelines can still be mentioned:

- Less than 5 hours per day on average in a week is usually not enough sleep.
- There are also upper limits on sleep as well, but some people claim to need up to 10 hours per night.
- If after waking up, you feel generally good and ready to handle the day, that's probably a good number of hours for you.
- Make sure to prepare for sleep before getting into bed: maybe stretch, or read, or whatever thing helps you to wind down and get into a good headspace to let go of the day's events so that you can sleep as easily as possible.

### Questions to Ask Yourself About Wellness

Let's say that you have reached a point where you feel there are pain points that you want to address, or adjustments that you want to make in order to better your time spent at work in various ways mentioned above. Great! Now, where do you start? You can start by asking yourself a few questions as a jump off point:

- What is your personal definition of developer wellness?
- What would it feel like to enjoy a high level of wellness as a developer? Does it seem possible?

  - How can you bring the real and the imagined into closer alignment?

- In what ways would this increase your enjoyment of your experiences, coding and otherwise?

  - If your enjoyment is less than desired, is your effectiveness an addressable issue?
  - What can you get better at (and how?) in order to be more effective, and gain more enjoyment from something that currently pains you?

- What other things can you learn to enjoy and become more effective at?
- How can you model what you've already done in this respect in other areas of your life?

- In your opinion, which social aspects of your job contribute to your perceived wellness?

  - more time collaborating with others? High level collab or lower level collab?
  - more time alone?

- What obstacles appear to be in the way of your new wellness goals?
  - What aspects of these obstacles are physical?
  - What aspects of these obstacles are mental/emotional?
    - How do you define "failure" personally?
    - How do you identify it in your experience as a developer?
    - How do you currently address this pain point?

Each of these answers can be a help in making slight improvements on what you regularly experience, or large sweeping and breaking changes. Both are great things, sometimes things are 95% good with only a 5% margin for improvement. If this is the case, awesome! Changing small things to better suit you is great practice for changing the larger things down the line as you see .

## The Overall Functional Effects of Individual Developer Wellness on The Team at Large

The effects of having more developers than not who are invested in their own developer wellness will make the difference between the presence of a virtuous cycle or vicious cycle.

### What Could Happen When You Do NOT Have Developers Invested in Their Own Well-Being

When your dev team is NOT invested in their own well-being, it can quickly become a glaring obstacle to getting work done in a productive and effective way. Doctor appointments, sick days, coming to work sick are all common occurences when a team is not invested in their wellness. A sick person in office, or one who is out sick often, may become more distant to the rest of the team, initially for reasons of contagions.

Eventually chronically sick people may become sequestered from the rest of the team due to having less context while at work due to being out sick often, or possibly having unhygienic practices that others don't want to be around.

Obviously, this can affect the team as a whole in a negative way. There may grow an unspoken understanding amongst co-workers that working together with a certain person is a less-than-desirable situation because of their constant coughing, or chronic crankiness. As a manager or team lead, it is definitely worth putting some time and money into addressing this potential schism amongst your team.

You may decide to incentivize better health practices and attitudes in order to deal most effectively with this issue. A "wellness" stipend may be a good place to start - allow your team to put company resources towards anything that they each deem a worthy resource towards their own wellness. It could be put towards a gym membership or movement-centric class (yoga, zumba, salsa dancing), or books on self-development in the workplace or even books on computer science principles if they feel that increased knowledge will boost their feelings of being more productive at work.

### What Could Happen When You Do Have Developers Invested in Their Own Well-Being

When your dev team is invested in their own well-being, the air becomes lighter at work. There will be less hesitancy in communication between members about the code, about the technical design, about the last few pull requests. It's okay to move code and logic around as a team, and to talk about these changes from a detached, and pragmatic point of view because everyone understands that they are not the code that they write, and that changes made or proposed are not directed at them in negative, or even personal ways.

A team whose members are invested in their own developer well-being is an example where the sum is greater than the parts. Difficulties and other sticky points become less difficult as a cohesive team instead of merely disjointed members. It’s much easier to assume the best in coworkers with regards to communication, even if there are occasional misunderstandings.

These benefits will exist even on a team where _most_ of the developers are fairly well invested in their own well-being. A virtuous cycle may begin to occur where the more well-balanced personalities begin to exert influence of wellness consciousness on others. As things become generally more pleasant and productive, the rising tide of wellness amongst the team members lifts all boats.

**The team functions as a finely tuned, and well-oiled web development machine.**

## Conclusion

It's been said that _if you enjoy your time at work, you live twice as long._

<figure>
  <img src="/assets/blog/2019-05-15-developer-wellness/happy-kid.jpg" style="display: block; max-width: 100%;" alt="Happy kid">
  <figcaption>Photo by SB Vonlanthen</figcaption>
</figure>

If you treat your own well-being as something to grow and maintain, you will enjoy these benefits: your work will be improved, you will like being at work, you will like the people that you spend time with while working. You will also take more personal satisfaction and pleasure from your time and life apart from work, and create more ways to enjoy it with even more gusto.


Developer Wellness


When the term "legacy code" comes up, it's usually said or received with a tinge of disdain. A preliminary Google search for "legacy code memes" brings up hundreds and hundreds of image macros of people tearing their hair out, looking frazzled, or hugely disappointed.

<img src="/assets/blog/2019-04-26-legacy-code/legacy_meme.jpg" alt="Frazzled looking man with disorganized papers captioned 'explaining legacy code to newly hired employees'" style="display: block; max-width: 100%;">

When I started working as a software developer 6 months ago, I had no idea what legacy code was or what working with it entailed.

During my fourth month as a junior developer, I was asked to add a search filter modal to an app built by one of my coworkers two or three years ago. It seemed easy enough; I'd spent the majority of the last four months working on an incredibly complex app for another client involving our standard stack: [TypeScript](https://www.typescriptlang.org/)/[React](https://reactjs.org/)/[Redux](https://redux.js.org/)/[Redux-Saga](https://redux-saga.js.org/). I had already solved many unique problems and felt confident in my coding ability enough to make a simple modal to pass query parameters to the backend.

As you may have guessed, it wasn't nearly that simple. But why?

## What legacy code is and why it can be challenging to deal with

Legacy code is code inherited from another developer or team which uses older technologies that are no longer supported or have been superceded by a newer version. Many programmers say that "code becomes legacy code as soon as it's written". The functional difference between "regular" code and legacy code could simply be that it has different conventions compared to what you're used to working with.

In my case, the app I was assigned to utilized [Flow](https://flow.org/) rather than TypeScript, and it wasn't as strongly typed as I was accustomed to. This made it a bit harder for me to understand the structure of the data that was being fetched from the backend. No types meant that I was running into TypeErrors on runtime much more frequently, which can be difficult to debug when you're writing a large feature. On top of this, the app used a much older version of React which needed to be reconciled with a compatible version of the component library I wanted to use to build the modal.

Before I get into the nitty-gritty of how to handle legacy code with a sense of poise and rationality, I want to add a disclaimer that legacy code isn't all bad and working on a legacy project doesn't have to be terrible. On the contrary, working on legacy code taught me to be flexible, patient, and above all else, the experience allowed me the chance to solve problems with a new perspective in a novel context.

In fact, it made me a better developer than I was before I started working through the aforementioned codebase, and hopefully your legacy project can teach you something too.

## How to deal with with legacy code on a technical level

<img src="/assets/blog/2019-04-26-legacy-code/old_tools.jpg" alt="Sextnt and leatherbound book on a natural wood bench." style="display: block; max-width: 100%;">
Photo by Jeff Sheldon on Unsplash

### Read documentation and code comments when possible

In a perfect world, every codebase has a robust README that contains concise explanations of how the project works, code comments that explain the exact logic of the original author, and the whole application makes perfect sense. However, this is rarely the case. Many READMEs don't get updated as projects develop, people forget to write comments, assume that their logic is obvious to a new developer, or they simply run out of time to take care of those things.

### Look at the codebase as a whole

If you're lost and don't know where to start, ask yourself these questions:

- What is the app’s purpose?
- How does data flow through the app?
- How does your feature fit into the app?

When you can get a sense of the big picture, it's easier to figure out how best to tackle the problem. Maybe you need to create a new file and create a new component. Maybe you need to write a utility function and test it. Whatever the case may be, understanding the broader context of your problem is a good first step to creating a solution.

### Test the app manually and with unit tests whenever possible

Breaking an app temporarily while adding a new feature is an inevitability, no matter what level of developer you are. This is normal and expected, especially if you're new to the job, working in a legacy codebase with an unfamiliar stack, or some combination of the two.

The best way to prevent these breakages from becoming long term problems is to test your app thoroughly with both unit tests and manual tests. Having these tests in place and knowing exactly what kind of coverage you get out of them will save you and future developers a lot of time. In addition, rigorous tests make the app more scalable and also give you a litte dopamine rush every time your tests run clean.

For unit testing, you can use test frameworks like [Jest](https://jestjs.io/) or [Jasmine](https://jasmine.github.io/).

For manual tests, you'll want to develop a test matrix and make sure the document is accessible to future developers. For the matrix, you'll want to define a set of actions, the expected behavior, the actual behavior when you test it, and any other details that are important, like so:
<img src="/assets/blog/2019-04-26-legacy-code/matrix.png" alt="Spreadsheet for behavior driven development" style="display: block; max-width: 100%;">

I'll be covering how to implement both types of testing efficiently into your workflow in a future blog post.

### Ask for help

Assuming your project was written by a current or former employee at your workplace, someone else probably knows what's going on in the app, or at least knows enough to get you unstuck. Learning to swallow your pride and ask someone else is a an uncomfortable step for some, but a necessary one for growing as a developer, and maybe your coworker can teach you a few new tricks.

A good way to make efficient use of your time (and theirs) is to formulate informed questions. Try going back to looking at the codebase as a whole and figure out the gaps in your understanding. Not only will it help them to get a better sense of what your problem is, but it shows that you took the initiative of trying to solve the problem on your own first.

### Know when to cut your losses

If you’re spending too much time trying to get your foot in the door and haven't made any serious stride towards implementing the feature after trying the steps above, it might be worth refactoring the code around your feature. Don't give up too easily, but also keep in mind what your deadlines are and what your project manager expects from you.

That said, there are drawbacks to going about it that way:

- Rewriting code can introduce bugs, though this can be somewhat circumvented with good unit testing.
- Rewriting code can remove hidden functionality, though this can also be circumvented with good unit tests.
- If you're pressed for time, writing code outside of your feature in addition to your feature might actually be more time-consuming than just building around it.

All in all, use your best judgement. There are pros and cons for either choice, and it's all dependent on your individual circumstances and project budget.

## How to deal with legacy code on a psychological level

<img src="/assets/blog/2019-04-26-legacy-code/meditation.jpg" alt="A man sitting on a dock in a serene mountain lake" style="display: block; max-width: 100%;">
Photo by Simon Migaj on Unsplash

Now that we've covered the technical aspects of dealing with legacy code, let's talk about how to deal with it using our soft skills. After all, developers are people, not just coding robots, and dealing with challenging problems on projects that require creativity and authorship can be emotionally taxing, not only for you, but for your coworkers as well.

### Be humble and kind

This is something that I will sheepishly admit I need to practice more. When I was first assigned the filter modal project, I was fairly vocal about how janky and unappealing the code was to deal with **while the original author of the code was sitting 15 feet away from me.** I intended my comments to be a joke, but in hindsight I recognize that I was being arrogant and hurtful, and that I should have been more empathetic.

There are a lot of factors that can lead to legacy code looking "off" which you should take into account before you start to criticize the author or assume the worst about them (This is loosely tied to the [fundamental attribution error!](https://en.wikipedia.org/wiki/Fundamental_attribution_error)).

#### **The original author may have had their reasons for writing code the way that they did.**

Time constraints and technology constraints can cause a person to write code that works but doesn't necessarily have the best convention. If you picture yourself in a situation with not enough time, outdated tools, and a todo list a mile long, you probably wouldn't write the best code either!

#### **Conventions change.**

In older Olio Apps projects, the convention for code is using single quotes to declare strings, and two spaces was equal to one tab. We had multiple small React components nested inside of a single file. In our current convention, we use double quotes and four spaces, and each React component, no matter how small, lives in its own `.tsx` file in the `component` directory. And in several years, I'm sure that will change too.

#### **All code eventually becomes legacy**

This ties back into the previous point: your code will eventually be legacy. As you move up the ladder of seniority, new developers will be hired on and will have to maintain your old code. You might write clean, flawless, DRY code, but once conventions change or trends change, those new developers might view your code the same way you view the legacy code of others.

### Take pride in the small successes

It’s not easy to work outside of your habitual conventions; there's a reason for the huge trove of memes and jokes about dealing with legacy code. If you've ever learned a language outside of your native tongue, you know how it feels to forget a word or term in your second language, but remember it in your native language and not be able to translate across the gap. The same goes for changing between modern and legacy conventions. Sometimes it just takes a minute to regain your bearings.

In being able to successfully navigate legacy code, you're showing your ability to be adaptable, which is an important skill that benefits you at your current job and all of your future jobs, whether those jobs are in the technology field or not. Legacy code is the perfect playground to practice this skill.

## In conclusion:

### Use this time to bolster your own code writing

Now that you've had the experience of working in a legacy codebase, you should come away from it with a better sense of what you like and don't like in terms of tools and conventions. These are things you can carry on with into future projects, and make you better at reviewing the code of others, offering constructive criticism, and giving mentorship.

### Develop apps for the user **and** the future developer

Whether you've had the experience of great documentation and code comments or no documentation or code comments, you can see how both documentation and comments are powerful tools to help future developers navigate the project. You share a common goal of wanting a smooth, functional, and DRY app; maintaining the documentation and leaving behind informative code comments is a good way of bridging that gap.

### Remember that your code will be legacy someday too

I've mentioned this a few times already, but it's important to reiterate that your code will be legacy too, no matter how DRY and pristine your code and logic are.

The most important takeaway is to be flexible, humble, and that you can definitely learn new tricks from old code.


Legacies Never Die: How to Handle Legacy Code


_Author's note: Inspired by my own recent experience of handling a lot of "newness" all at once, I started writing this blog. While writing it, I realized I was really just writing about my own philosophies on being a developer in general, because so much of what we do involves constant exposure to new ideas and tools. No matter where you are in your career, I hope there's something here to inspire you to learn, grow, and participate in supportive developer communities._

<img src="/assets/blog/2019-04-22-gracefully-handling-newness/new.png"  alt="scrabble pieces" width="100%">

As a software engineer, I find my self torn between two seemingly opposite goals: becoming a master of the skills that I already have and also constantly trying to learn new things. And I'm definitely not alone.

There is some comfort (and a lot of satisfaction) in mastering a subject and having the confidence to tackle any task within your wheelhouse. But equally as satisfying (in different ways) is trading in your "master hat" for your "I'm completely new at this hat", soaking in novel information, and learning a new skill from the ground up. Deep diving into something new, though rewarding and sometimes necessary, can be very challenging.

Sharing a personal example: I had become very comfortable in my web development stack: React/Redux/TypeScript. At the beginning of the year, I became the primary developer on a greenfield project with all new-to-me technology: speech-to-text APIs, Unity, Magic Leap. This was a very exciting opportunity for me, but it also came with it's fair share of challenges.

Along the way, I obviously learned a lot about developing in Unity, programming C#, and working with cutting-edge hardware (Magic Leap One). But I also learned some valuable lessons about how to handle that level of novelty. Here are some tips for handling these challenges gracefully.

## Mindset

A huge part of tackling any challenge is mindset. Some people are naturally drawn to trying new things, while other's prefer to stick to their comfort zones. But things are always changing in software, and learning to love newness and being able to roll with changes will serve you well as a programmer. Here are a couple of things I found helpful to keep in mind while cutting my teeth on several technologies all at once.

<img src="/assets/blog/2019-04-22-gracefully-handling-newness/positive.jpg"  alt="be positive" width="100%">

### Be grateful for this opportunity

Even if trying something new doesn't immediately excite you in and of itself, there are a number of ways it will pay off. Appreciate the opportunity to learn something new, grow your skills, and become an more versatile team member. Think of these challenges as an investment in yourself and your resume.

### A change in pace can be good

While entering new territory, your pace may slow dramatically from your normal work flow. Working in Unity/C# for the first time, it was taking me days to create features that would have taken me hours in TypeScript. Which honestly sucks, but there's lemonade to be made from those lemons.

It was very humbling, which I think is an important part of the personal and professional growth cycle. It helps you remember your roots (we all started from somewhere), and make you more empathetic to new developers. A slower pace can also create more room for reflection and break-taking, which are healthy.

### Perseverance

Giving up is easy. Remember why you wanted to learn this technology and what value learning it can offer. Always reach out for help when you hit a roadblock. Most major technologies have channels for communication, Stack Overflow, or you can use this opportunity to go to a meetup and network with people who can help support you as you learn something new.

## Creating a Solid Foundation

When getting started with something new, try to gain a solid foundation before advancing. This may go without saying, but sometimes our developer prowess can make us forget that. When working in my Unity/Magic Leap/Speech API project, I was tempted to learn all these technologies at once while starting to build the app. In fact, that's how I originally started. However, I quickly realized that was not going to be a suitable way to learn or build the app. I was trying to start at level 5, but I hadn't completed level 1 yet.

Make sure to take the time to practice before jumping into a major project. Once you've completed a couple tutorials, start by integrating the technology into a practice project. The classic example, of course, being a todo list app. If the thought of making another todo list app makes your heart hurt, there are plenty of other options.

If you have a personal project, try adding a new feature or refactor what you have using new technology. Even if this spike never gets merged to production, this helps you keep your personal project alive, gives you extra incentive to keep adding features and helps you practice new things all at once. If you don't have a personal project going, what an excellent time to start one!

Remember: The real value in refactoring existing logic or making another todo list app is that you don't have to worry about doing any logic design (because it's already done), you just get to jump in to applying the new tech.

Depending on the technology or your general experience, getting in the practice could take a few hours, days, or weeks. So it's important to be efficient with your time. Creating a practice plan with time boxed benchmarks can be helpful.

For example (totally hypothetical): I am going to spend 5 hours creating a Unity todo list app with state management. Once I have an understanding of Unity, I'm going to spend 6 hours retrofitting my Unity todo list app to run on the Magic Leap. By the end of the week, I'll add a speech recognition API to the app for adding new items. Things may end up taking more or less time than you expect, but it's good to have a plan.

## Engaging the Community

Some of us prefer to take the lone wolf approach on our learning journeys. But participating in developer communities, especially early on, can really payoff. Many new technologies, the ones with a lot of buzz that you're eager to learn, are surrounded by active communities on forums like Stack Overflow, Slack, GitHub, and even local meetups.
<img src="/assets/blog/2019-04-22-gracefully-handling-newness/engaged.png"  alt="be engaged" width="100%">

### Learning

These online or in-person communities are great resources for receiving help. Working alone, you might find yourself blocked by a problem for days, unable to make meaningful progress. Chances are, you're not the first person to experience this pitfall and a fellow coder could help illuminate the path forward.

### Social Support

Next, not knowing something or stepping into unknown territory can feel very isolating. Meeting others in similar positions can help ease the emotional burden of the learning experience. With community support, learning can be fun, especially when you have someone (and somewhere) to share your wins.

### Honing your Craft

Engaging with a community is also a great way to expose yourself to different styles of coding. You will get a glimpse into other people's projects, what technology they're using, and how their using it. You'll have an opportunity to interrogate other people's code and also pick up tips and tricks to add to your own coding style.

### Giving Back

During this process, take the opportunity to give back to the community. You can do this in a lot of different ways: Write a blog post about your experiences, share your code, answer questions, request new features, point out areas for improvement in documentation. You could even PR into an open source library once you've honed your skills.

## Recognize Patterns & Find what is Familiar

Good patterns tend to repeat themselves in software. Even if you find yourself in what feels like completely unfamiliar territory, most of the skills you’ve used to develop apps in one language, framework, or discipline will still be applicable. For example, if you’re taking the leap from frontend state management to database management on the backend (or vice versa) you’ll notice the event driven architecture of both hum to the same tune.

By recognizing these similarities, you'll be able to learn faster. Try to implement code in a way that feels familiar. If the way you normally write code is clean, efficient, well-documented, and structured appropriately you’ll be able to find your groove in no time. (And if you don't, what a great time to start!)

Identifying these patterns may also help you gain a more solid understanding of your already familiar tools. For example, after using it for years, I found that there was a lot to my current development stack that I took for granted. While implementing state management from scratch in my Unity project, I gained a new appreciation for the mechanisms underpinning the unidirectional data flow in Redux and the value of having a single source of truth.

## Reflection & Sharing

During your learning journey, take time to reflect and share your experiences. I recommend keeping a daily developer journal of your highs, lows, pitfalls, and “ah-ha” moments. This way you will have a record to look back on when you want see how you have progressed over time, want to gather material to share with others, or when you need inspiration. You have a number of tools to choose from to help get this job done: [jrnl](http://jrnl.sh/), [notion](https://www.notion.so/), good old notebook, just to name a few.

If you’re working as part of a team, candid daily reflection in scrum standup is a great way to share your learning experiences. Just like engaging an online technology-focused community, this can help you get through blockers, inspire others on their own learning journeys, and maybe create a supportive micro community inside your workplace.

Reflecting and sharing may seem tedious, especially on top of the stress from learning a new subject, but I think the benefits make it worth while. First, sharing what you've learned, where you got stuck, and how you got un-stuck could help other developers who are new to this topic. Second, reflecting on your experiences and teaching others will help reinforce what you've learned. Third, sharing along the way, especially with coworkers and friends, keeps you accountable and can help you persevere through rough patches.

## Conclusion

There are always going to be opportunities to learn and grow in the field of software development, and I hope you take as many as you can. As you learn new things, you are improving your creative thinking skills and creating muscle memory in your brain for handling "newness". The more skills you have learned, the faster you will be able to pick up new ones. Having the right mindset, creating a solid foundation, engaging communities, recognizing familiar patterns, and reflecting on your experiences will help you tackle these challenges with ease.


Gracefully Handling Newness: Tips for Software Developers 


Another quarter, another chance for the staff at Olio Apps to try their hand at hacking together a project over an 8 hour work day in a friendly competition. If you haven't seen our first attempt at a Hackathon, check out our previous blog post on it [here](https://www.olioapps.com/blog/hackathon/). We enjoyed the experience so much, we decided to make it a quarterly tradition as a way to bond, break out of our normal developer mindset, and come up with new ideas or learn new tools.

## Shoutbase

For this Hackathon, we wanted to focus on improving one of our current products [Shoutbase](https://www.shoutbase.com), a tool for tracking time spent on projects or tasks, either as an individual or as a team with fast setup and customizable project tags.

<img src="/assets/blog/2019-04-01-second-hackathon/shoutbase.png" style="display: block; max-width: 100%;" alt="Screenshot of of Shoutbase dashboard">

We broke up into pair teams, and came up with fairly diverse ideas, transforming the capabilities of this app in three distinct ways.

### Cory & Jason

Cory and Jason decided to take on integrating [GraphQL](https://graphql.org/) as a way of improving Shoutbase's developer-side experience. After spending time in this codebase, they were inspired to use GraphQL to make it more scalable and easy to reason about. At the end of the day, they migrated enough client side and server side code to power an admin dashboard. They learned that the predictability of GraphQL makes it easy to test queries in the GraphQL playground without needing the client and also that sticking to easy to implement features makes code migration much easier.

<img src="/assets/blog/2019-04-01-second-hackathon/graphql.png" style="display: block; max-width: 100%;" alt="Screenshot of of GraphQL Playground using one of our queries">

### Stormi & Ami

The idea of keeping a "Developer Journal" has been a prevalent theme not only in the office, but in the developer zeitgeist as a whole, which is a large part of the reason Stormi and I chose to tackle adding the journaling capabilities to Shoutbase. We wanted the app to be more of an all-in-one tool for not only tracking time, but tracking how things went, personal "wins", and how the user felt about the task. We created a new tab for journal entries, which were posted in a format as normal time entries with field for adding a sentiment and text formatting markdown. The idea was that being able to track and visualize mood or sentiment over time in tandem with project tasks would allow the user to communicate during one-on-ones with a project manager to assist with goal-setting and enhance professional growth.

<img src="/assets/blog/2019-04-01-second-hackathon/shoutbase_journal.png" alt="Screenshot of Shoutbase entry with markdown formatting and a scatterplot" style="display: block; max-width: 100%;">

### Jon & Frank

Jon and Frank decided to go a more experimental route and began to toy around with [WebAssembly](https://webassembly.org/) as a tool to reduce load times with smaller file transfer, and faster performance of CPU-intensive computations. In Shoutbase's case, a team admin, who can see all of the time entries for their team members, would be able to see massive amounts of bucketed time entry data potentially ["up to 5.89 times faster than the JavaScript implementation on realistic benchmarks operating on real world source maps."](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust-and-webassembly/)

## Judging

Judging for this Hackathon was done by Jesse Hallett, friend, former colleague, and [contributor](https://www.olioapps.com/blog/automatic-code-formatting/) [to](https://www.olioapps.com/blog/checking-types-real-world-typescript/) [our](https://www.olioapps.com/blog/the-lost-art-of-the-makefile/) [blog](https://www.olioapps.com/blog/type-driven-development-with-typescript/). The projects were judged based on their concept, utility and implementation. In the end, Stormi and I were awarded extra vacation days (and I go undefeated in Hackathon wins 😁).

## Takeaways

This Hackathon was a lot of fun and it was awesome to try our hand at hacking on the same base product with totally different results. One thing we learned about participating in an event like this (and in general, really) is to be sure to _scope your project appropriately for the amount of time you have_. Another thing we learned through this process is the importance of being able to present and explain code that doesn't necessarily tie into the user interface.

All in all, it was a great experience. We discussed future formats and themes for the next Hackathon and the one I'm looking forward to is splitting the office into two teams led by our bosses Scott and Aron in a larger swarm format, and we're still working out a partnership with a local non-profit to hack a project together for them, so stay tuned.


Reinforced Learning