DEV Community: Jonathan Cutrell

Test-Driven Meetings

Jonathan Cutrell — Wed, 12 Jun 2019 13:54:18 +0000

Write a test, make it fail. Write the code to make it work. Refactor.

This "red-green" cycle is something most modern developers understand. Many of us have built our whole workflow with this concept in front and center.

We also identify with each other's pain when it comes to meetings.

Why are we meeting again? Why does this meeting have to last 2 hours? Doesn't everyone already have this information? Wouldn't it be better if we would all just go back to our work? This isn't real work... it's just making us feel like we're working.

Some meetings feel more productive than others. Maybe you really enjoy daily standup meetings, but can hardly tolerate "town hall" meetings.

Wherever you are in your career, you can make meetings drastically more useful by applying the test-driven model of thinking to your meeting schedule.

Let's break it down!

1. Look at your calendar and identify all events that are meetings.

Not every event is a meeting. Make a calendar specific for your meeting events. If you have informal meetings, put them on the calendar too.

2. In the calendar event, write out the expected output of the meeting.

Arguably, great functions always produce output. What will you take away from this meeting? Here are some types of output:

Tasks - is your meeting intended to generate work to be completed?
"Decision record" - wherever you keep documentation of your work in progress, the output of a meeting might be as simple as making a decision about something and documenting it.
Notes - At the very least, your meeting should be able to output a simple summary about what was discussed.

3. In the calendar event, also write out the desired side effects of the meeting.

While most of your meetings should produce functional output, you will also have meetings intended to produce side effects. Here's a list of side effects you may care about.

Camaraderie - Does your team feel closer to each other after a meeting?
Belonging / in-the-know - does your team feel like they are included on important information?
Emotional support and expression - do your team members feel emotionally supported? Has everyone had a chance to express their opinions?

Don't fly blindly into a meeting.

It's easy to ignore meeting prep as a practice. It's difficult to immediately see the value in stopping the "important" work you are doing for something seemingly less important.

Make your meetings matter by creating these expectations, and testing against them. If a meeting is failing to produce expectations, do what a good developer does when tests fail: refactor the meeting!

What languages are you learning or planning to learn, and why?

Jonathan Cutrell — Mon, 03 Jun 2019 14:23:29 +0000

Are you learning a new language? What is the reasoning behind what you are learning? What principles are you picking up along the way?

What mistake did you make last week?

Jonathan Cutrell — Mon, 27 May 2019 13:33:09 +0000

Growth comes from failure, and failure is inevitable. Share your story of a recent failure, no matter the size. Other people need to hear about it!

You will probably get some encouragement along the way, and feel less vulnerable when you see that you're not alone in your mistakes.

Let's get honest with each other!

React Anti-pattern: renderThing

Jonathan Cutrell — Fri, 24 May 2019 16:46:58 +0000

If you've done much with React, you've probably run into this kind of scenario:

class Tabs extends React.Component {

  constructor(props){
    super(props)
    this.state = {}
  }

  setActiveTab(activeTab){
    this.setState({ activeTab });
  }

  renderTabs(){
    return (
      this.props.tabs.map(tab =>(
        <a onClick={e => this.setActiveTab(tab.id)}
           key={tab.id}
           className={this.state.activeTab == tab.id ? "active" : ""}
        >
          {tab.title}
        </a>
      ))
    )
  }

  render(){
    return (
      <div>
        <p>Choose an item</p>
        <p>Current id: {this.state.activeTab}</p>
        <nav>
          {this.renderTabs()}
        </nav>
      </div>
    )
  }
}

This would be used like this:

<Tabs tabs={[{title: "Tab One", id: "tab-one"}, {title: "Tab Two", id: "tab-two"}]} />

And this works! If this is all you need for this component forever, by all means, stop here!

But if this code will change in the future, you're likely to end up with a confusing and long component.

The first and most obvious refactor smell here is the renderTabs method. A few things are wrong with this.

First, the Tabs component already has a render method. So what's the difference between the Tabs render and the renderTabs methods? In one, we are rendering the list of tabs. In the other, we are adding some context. We see this often with things like filtered lists.

It may be tempting to wrap up this kind of rendering functionality inside the component specifically because the tabs need to share state somehow with the containing context.

Let's think about how we might refactor this to be easier to understand.

P.S. Let's assume you've got some kind of testing strategy. In this case, we're not going to write tests, but if you did, you'd probably want to assert that your list is rendering, and that clicking on your tabs renders out what you want it to render.

Let's start by removing the renderTabs method. This is going to look ugly at first.

class Tabs extends React.Component {

  constructor(props){
    super(props)
    this.state = {}
  }

  setActiveTab(activeTab){
    this.setState({ activeTab });
  }

  render(){
    return (
      <div>
        <p>Choose an item</p>
        <p>Current id: {this.state.activeTab}</p>
        <nav>
          {this.props.tabs.map(tab =>(
            <a onClick={e => this.setActiveTab(tab.id)}
               key={tab.id}
               className={this.state.activeTab == tab.id ? "active" : ""}
            >
              {tab.title}
            </a>
          ))}
        </nav>
      </div>
    )
  }
}

This is actually a perfectly fine component on its own. But in the future, you probably will have other places you want to use the same tab-style button, so let's see if we can make that button shareable.

Let's look at a single tab on its own.

<a onClick={e => this.setActiveTab(tab.id)}
   key={tab.id}
   className={this.state.activeTab == tab.id ? "active" : ""}
>
  {tab.title}
</a>

Now let's make this component a standalone functional component. (In other words, we want the component to take props, but we don't need it to have its own state.)

const TabButton = ({ onClick, active, title, tabId, ...props}) => (
  <a onClick={e => {e.preventDefault(); props.onClick(tabId)}}
    {...props}
    className={active ? "active" : ""}
  >
    {title}
  </a>
)

Now that we have a functional component, we can integrate this back into our original Tabs component.

const TabButton = ({ onClick, active, title, tabId, ...props}) => (
  <a onClick={e => {e.preventDefault(); props.onClick(tabId)}}
    {...props}
    className={active ? "active" : ""}
  >
    {title}
  </a>
)

class Tabs extends React.Component {
  constructor(props){
    super(props)
    this.state = {}
  }

  setActiveTab(activeTab){
    this.setState({ activeTab });
  }

  render(){
    const { tabs } = this.props;
    const { activeTab } = this.state;
    return (
      <div>
        <p>Choose an item</p>
        <p>Current id: {this.state.activeTab}</p>
        <nav>
          {this.props.tabs.map(tab =>(
            <TabButton onClick={this.setActiveTab}
               active={activeTab == tab.id}
               tabId={tab.id}
               key={tab.id}
               title={tab.title}
            />
          ))}
        </nav>
      </div>
    )
  }
}

So what do we really gain here?

Removed unnecessary/confusing renderTabs button
Created a reusable TabButton component that doesn't rely on any external state
No API changes for the Tabs interface
Easier to reason about and separate concerns - two smaller components over one larger component.

This example is contrived and small, but you are almost certainly going to find places where renderThing monsters show up.

The refactoring pattern looks like this:

Remove the monster renderThing method by moving that code back into the original render. Stop there if the code is reasonable.
Isolate a subset of the rendered output to create a new component from. (Note that you may be able to move directly to this step and jump over step 1, but I like to move it back into the render method first to see if it makes sense to just leave it there.)
Work to separate what pieces of state can go away. Ideally, shoot for a functional component; however, beware of a vanity functional component, where you keep state that should be in the subcomponent in it's parent so you can make it "functional." This is far worse than having two well-designed stateful components.
Incorporate your new component into your previous component, replacing markup. If you find yourself passing too many things directly into the child component, it's possible that you should have stopped at step #1 and not abstracted the component out at all.

Knowing when to abstract a component or routine out into its own dedicated component can be hard. Sometimes, it's purely preference; there is no one right way. When in doubt, smaller components are easier to reason about, but abstraction should have a purpose.

What other refactoring patterns are you interested in seeing a writeup on? Comment and let me know!

5 Things I wish I knew about searching for a job as a young developer

Jonathan Cutrell — Fri, 24 May 2019 15:47:54 +0000

1. Companies want you to succeed.

Companies spend a lot on hiring. Most companies would prefer to complete the hiring process quickly. They want you to succeed.

If you understand this, instead of feeling like you are being scrutinized, recognize that there's a shared desire for you to succeed.

There's not a perfect number for how much it costs to hire a developer, but you can do some basic math to figure out that it's probably at least $20k on average.

What this means is that the hiring manager has two competing incentives: 1. find the right candidate; 2. find the candidate quickly. The longer the search takes, the more expensive it is.

But it's not just a monetary cost.

It's to your advantage to understand that your potential employer is probably tired of interviews that don't pan out. They want to get to the work, and stop spinning their wheels. That can have a heavy emotional toll.

tldr; The person interviewing you likely wants you to succeed. Join them in that mindset.

2. The right job might feel slightly out of reach

If you apply for whatever feels safe today, you likely won't feel like you are growing. Apply for something out of reach! The worst that can happen is denial.

Use some discretion here. If the job requires 10 years of experience and you're brand new to the career, it's probably a better idea to reach for the mid-level position that requires two years of experience instead.

tldr; Give yourself the challenge and expectation that requires growth. Focus on jobs that are barely out of your reach. Avoid jobs that are easy, or are three times beyond your reach.

3. Reflect the posting in your resumé

Reflecting the original job posting language can help you directly address the requirements outlined.

Look for language used. For example, if the posting says "developer", don't use the term "engineer." If the posting mentions any requirements, address each one that you have relevant experience with. Rule of thumb: convert the job posting into a checklist, and make sure your resumé and/or cover letter hits all of those items.

tldr; Match language and address the full job posting. Don't just send your resumé along without adjusting to meet all necessary criteria.

4. Your non-coding experience matters

What you learn in other areas of your life and career is relevant to your experience as a developer, for a few reasons.

First, your reasoning ability and mental models you build in a different domain are likely transferable to software development, whether directly or indirectly.

Second, your habits, personality, and perspective are all incredibly important to your future employer. For example, previous job habits may show your ability to collaborate well with others, engage with clients, operate under uncertainty, or communicate complex topics with clarity. All of these skills can be exhibited in jobs that have nothing to do with software development.

tldr; Most skills and experience are transferable and relevant, so don't leave out cross-industry employment and experience.

5. Connections are the goal; a job comes after

No matter how good your resumé, cover letter, and experience is, you are most likely one of a large number of applicants for any given job. The wording of a particular line on your resumé is not going to move the needle very much. Most jobs come as a result of a personal connection. So, go make connections! Talk with people in the industry, discuss the problems they are facing, and learn about what they love.

tldr; Job postings are fine, but relationships trump all other avenues of job searching.

Conclusion and a final recommendation:

When you are searching for a job, remind yourself that employers do not have an "all-seeing eye." Just because you don't get a job doesn't mean you couldn't do that job. Be encouraged in your journey! Finding a job is hard, so it pays off to think differently about the process. I hope these tips can help you in your search. Good luck!

P.S. - feel free to reach out for career advice. We also talk about topics like this on Developer Tea (a podcast for driven developers like you) all the time, so be sure to check that out!

Three Things I Wish I had Learned Earlier in My Career as a Software Developer

Jonathan Cutrell — Tue, 21 May 2019 01:47:09 +0000

Three Things I Wish I had Learned Earlier in My Career as a Software Developer:

https://spec.fm/podcasts/developer-tea/298247

Challenge for Day 19

Jonathan Cutrell — Sat, 19 Jan 2019 05:01:00 +0000

Putting how you feel into words can help you understand those feelings more completely. Today, take time to notice any particularly strong feeling, and try to explain that feeling in words. Start with the actual physical sensations you feel, and continue with more complex devices like metaphors.

Tea Break Challenge #9 - #17

Jonathan Cutrell — Thu, 17 Jan 2019 23:04:20 +0000

Day 10:
Self control is a lot like a muscle; once you’ve exercised self-control in one area, it is perhaps easier to exercise it in another area. Decide on something you will (or will not) do today, and follow through as soon as possible.

Day 11:
If you are like most people, you have a lot of incoming noise. Take some time to permanently silence one source of incoming noise. This might mean unsubscribing to a newsletter, turning off push notifications, or removing a recurring meeting from your calendar.

Day 12:
Studies show that thank you notes are not only appreciated more than expected, but that people also overestimate how awkward giving one will feel. Give someone you know an unexpected note of appreciation today.

Day 13:
Most of us carry around stress, but most of us don’t try to locate the source of that stress. Take 5 minutes to figure out what your biggest stressor is today.

Day 14:
Naming things is very important, and very hard. The next thing you name - a file, a concept, a presentation, or a variable - take an extra pass over it and evaluate the quality of your naming.

Day 15:
Take out a sheet of paper and write down the basic schedule of your day. What things stand out to you as most useful? What things stand out as time wasters? How are you prioritizing these things?

Day 16:
Best practices always require context. Today, when encountering a situation where you might use a best practice, ask yourself how it works in this specific context.

Day 17:
Variety can provide major benefits to our mental schema and life experience. Take a different route home, try a new food, or listen to a genre you’ve never heard before today.

Tea Break Challenge, Day #8

Jonathan Cutrell — Wed, 09 Jan 2019 00:07:44 +0000

Today, make it a point to notice things that make you feel happy, satisfied, or otherwise positive emotions. Write them down, and put stars next to the things that really stand out to you. Adopting this habit can help you learn about your own preferences and values in an observatory way.

Tea Break Challenge Day #6 + Day #7

Jonathan Cutrell — Mon, 07 Jan 2019 13:17:25 +0000

Day #6

Today, take 5 minutes to clean something around you. This could be your inbox, or it could be making your bed. The simple act of doing something positive for your environment can have a positive effect on your mood and productivity.

http://tea.is/d/6

Day #7

Your challenge today is to abstain from all social media for at least one full hour, and focus on something (anything) else for that full hour. Your focus does not have to be on code; the goal here is to get better at focusing, not to do “more work.”

http://tea.is/d/6

Tea Break Challenge, Day #5

Jonathan Cutrell — Sat, 05 Jan 2019 22:06:31 +0000

Take 3 minutes today to listen with 100% focus to someone else’s story, opinion, complaint, or celebration. Try to understand what they are feeling, thinking, and experiencing.

http://tea.is/d/5

Tea Break Challenge, Day #4

Jonathan Cutrell — Fri, 04 Jan 2019 16:22:56 +0000

Intuition is a very powerful tool; it can lead to amazing outcomes, both good and bad. Reflect on a recent event where your intuition served you well.

http://tea.is/d/4